The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Google представил библиотеку jpegli для более эффективного сжатия JPEG-изрбражений , opennews (??), 04-Апр-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


126. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/–
Сообщение от Аноним (126), 05-Апр-24, 00:45 
> использовать можно, не париться не получится - гугль еще не написал для
> него "более эффективного кодировщика" (и, главное - декодировщика). А референсный -
> тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом
> со своими вейвлетами и прочей заумью)

Они вообще разные. JPEG для фоточек, PNG для скриншотов, доков, схем, чертежей и проч - с контрастными четкими линиями, фонтами и проч.

Хранить фоту в PNG - можно, но это ж zlib с префильтрами. Сильно такое не ужмет. Зато line art и прочие скриншоты - вполне. При том lossless by design. Можно 20 раз редактировать и не париться. Это чуть более продвинутый вариант .bmp.gz - всего лишь. Оптимизаторы кстати есть, типа optipng, pngcrush, advpng и проч. В последнем, кстати, есть "zophli". Да, это - гугловая штука! Алго сжатия deflate на максималках. Жмет медленно - но лучше остальных, при 100% совместимости с форматом. Есть такая штука - "optimal parsing". Для двухфазных схем с huffman'ом внагрузку оно, правда, обречено быть "приблизительным" но остальные оптимизацией вариантов представления потока вообще не парились и жали еще хуже.

Сохранить вон то ("line art") в JPG можно - но DCT очень плохо реагирует на резкие перепады контраста, он под фотореалистику делался же. И там немеряно артефактов будет. Не для этого оно. А первая версия webp вообще только subsampled yuv умеет. Ибо i-frame от VP8. И для чего-то типа скрина с компа - капец полный по цветности.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

133. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (92), 05-Апр-24, 02:34 
Среди оптимизаторов pingo и ECT лидировали. pingo и быстрый, и лучший по степени сжатия, ECT иногда вырывался вперёд на какое-то микроскопическое расстояние.

https://css-ig.net/benchmark/png-lossless

Ответить | Правка | Наверх | Cообщить модератору

140. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (-), 05-Апр-24, 05:15 
> Среди оптимизаторов pingo и ECT лидировали. pingo и быстрый, и лучший по степени сжатия,

С одним маленьким недостаточком - блоб онли варезок, под маздайку. В таком виде он мне нафиг не упал.

> ECT иногда вырывался вперёд на какое-то микроскопическое расстояние.

С PNG все не так просто: там кроме супер-сжатия еще префильтры есть и в зависимости от его выбора - optipng периодически показывает продвинутым пакерам с ломовым zlib'ом мастеркласс подыскав более удачный префильтр.

Разумеется упомянуть этот тонкий момент авторы того блобика немного постеснялись. А суперкомбо ака подобие optimal parsing + брут префильтра таки займет весьма нетривиальное время, и вот нафиг кому пнг на 3% меньше - путем нагрева проца полдня? :)

> https://css-ig.net/benchmark/png-lossless

Сейчас бы, блин, на сайте автора того блоб онли варезка - смотреть объективные результаты бенчмарков то. Сразу после того как Get The Facts на сайте корпорации Майкрософт дочитаю.

Ответить | Правка | Наверх | Cообщить модератору

147. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (92), 05-Апр-24, 09:17 
Не знаю, чего тебя так раскукожило, но:
- мне запомнились именно эти две софтины, раньше у меня они показывали себя лучше, чем zopfli и optipng
- из png в одном солидном бенчмарке[1] выжимали все соки именно связкой pingo+ECT. Наверное, ECT обгоняет pingo не "иногда", но "Generation 12562..." спустя часы в консоли напоминает, почему я предпочёл об этом забыть.
- optipng -o7 уже включает перебор всех фильтров (-f0-5)
- (ещё одна ошибка - с lossless WebP в другом комменте, под ним ответил)

[1] https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_.../

Ответить | Правка | Наверх | Cообщить модератору

155. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (118), 05-Апр-24, 13:03 
Так avif вроде и не лосслесс ни в одном из смыслов. Ну, во всяком случае, libaom говорит, что лосслесс с нужными флагами, но просто раздует файл до невозможности и выдаст очень даже лосси под видом лосслесс (в частности, проредит цвета). Чё они там сравнивали?
Ответить | Правка | Наверх | Cообщить модератору

166. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от анонимус (??), 05-Апр-24, 17:25 
Вот не надо, очень даже lossless, а цвета у тебя ломаются потому что надо было читать спецификацию, avif умеет в 8,10 и 12 битность и 400, 422 и 444 сабсэмплинг.
Ответить | Правка | Наверх | Cообщить модератору

167. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (118), 05-Апр-24, 18:00 
Неа, я прошёлся по всем параметрам кодера. А теперь рассказывай, как у тебя получился lossless avif? Сравнить соответствие оригиналу можешь с magick "${fsrc}" "${file}" -metric PAE -compare -format '%[distortion]' info: и цвета искажает даже со всеми дополнительными параметрами вроде -L -p chroma=444 --matrix_coefficients=0 (что заявлено как лосслесс с rgb).
Ответить | Правка | Наверх | Cообщить модератору

173. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от анонимус (??), 05-Апр-24, 21:58 
>что заявлено как лосслесс с rgb

вот тут и собака зарыта. avif не умеет в RGB, только в YUV, поэтому и потери в цвете. У jpeg xl этого недостатка нет.

Ответить | Правка | Наверх | Cообщить модератору

174. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (92), 06-Апр-24, 05:22 
Проблема в твоих руках. Lossless-режим в AV1 сделан для галочки, пользоваться им не надо и раньше баги в реализациях были, но сейчас проблема только в твоих руках.

Посмотри на вывод ffprobe, в lossless-режиме yuv444p(бла-бла-бла) должен смениться на gbrp(бла-бла-бла), закодируй правильно, правильно сверь картинки.


avifenc --lossless in.png out1.avif
ffmpeg -i in.png -aom-params lossless=1 out2.avif
ffmpeg -loglevel error -i in.png    -pix_fmt rgb24 -f md5 -
ffmpeg -loglevel error -i out1.avif -pix_fmt rgb24 -f md5 -
ffmpeg -loglevel error -i out2.avif -pix_fmt rgb24 -f md5 -

-f md5 считает хэш от bitmap'а после декодирования, -pix_fmt rgb24[*] приводит bitmap'ы к единому формату (interleaved/planar, rgb/bgr...), а то avif и png по умолчанию декодируются в разные форматы - "rgb24" и "gbrp".

* для картинок с альфа-каналом и с не-8-битами на канал нужен другой общий знаменатель, очевидно

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

175. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (118), 06-Апр-24, 08:06 
Отмазки пошли. Какой же, к чёрту, это лосслесс тогда? Получается, проблема и не в моих руках вовсе.
Ответить | Правка | Наверх | Cообщить модератору

176. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (92), 06-Апр-24, 09:40 
...в твоих руках, а ещё глазах (и руках соседнего анонимуса).

Если протереть глаза, то там описан процесс для исходника в RGB с 8 битами на канал. Lossy его превратит в YUV. Lossless - нет. Подходящий общий формат для битмапов: "-pix_fmt rgb24".

Ответить | Правка | Наверх | Cообщить модератору

177. "Google представил библиотеку jpegli для более эффективного с..."  +/–
Сообщение от Аноним (92), 06-Апр-24, 10:09 
И смотри какие чудеса, название забагованного энкодера не указываешь ты, а баг в нём вижу я.

https://github.com/strukturag/libheif/issues/62#issuecomment...

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

189. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/–
Сообщение от Аноним (-), 07-Апр-24, 04:48 
> Не знаю, чего тебя так раскукожило, но:

То что совать непонятную проприетарь под винду на ресурсе про открытое ПО - это немного невежливо. И может крепко промазать с адресатом.

> - мне запомнились именно эти две софтины, раньше у меня они показывали
> себя лучше, чем zopfli и optipng

Мои эксперименты с оптимизаций PNG показали что таки - весьма контентозависимо, иногда optipng подбирает более удачный префильтр и остальные напрягаются его побить.

И кстати да, ниоткуда не следует что это же комбо фильтров - столь же оптимально для более сильного zlib пакера. Откуда и идея что полный брут

> pingo+ECT. Наверное, ECT обгоняет pingo не "иногда", но "Generation 12562..."

Ну я и намекал что в какой-то момент таки - и хрен с ним на целые 3% большей PNG'шкой. Убиваться ради нее имеет смысл только если делается "на века" а проц нагрузить совсем нечем.

> - optipng -o7 уже включает перебор всех фильтров (-f0-5)

Угу. Вот это бы с продвинутым пакером скрестить... но тогда все придет к вооон тому, и через полдня этого - захочется ctrl+c вкатить. И черт с ними с 3% улучшений.

> - (ещё одна ошибка - с lossless WebP в другом комменте, под ним ответил)

IIRC таки изначально он был с subsampling и YUV. В v2 вроде что-то более приличное сделали.

> [1] https://www.reddit.com/r/AV1/comments/fjddcj
> /lossless_image_formats_comparison_webp_jpeg_xl/

Ну просто не в обиду ISO но их рабочая группа по видео - себя дискредитировала в хлам. Видимо в целом индустрия не очень доверяет и этой группе, хоть они и другие.


Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

191. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/–
Сообщение от Аноним (92), 07-Апр-24, 14:37 
Но тебя перераскукожило до ошибок. С обсуждаемой проприетарью optipng сравнить не можешь, но отвечаешь; свободный fhanau/ECT тоже внимания заслуживает. WebP2 у гугла до сих пор называется "WebP 2: experimental successor" и в сравнении по ссылке с реддита обе версии протестированы же.

> Ну просто не в обиду ISO но их рабочая группа по видео - себя дискредитировала в хлам. Видимо в целом индустрия не очень доверяет и этой группе, хоть они и другие.

Эта в целом индустрия называется Google и доверяет, конечно, своим WebP, WebP2, AVIF, AVIF@AV2. Но Google ещё, видимо, самодискредитацией занимается, принимая участие в разработке JXL.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру