Компания Google объявила (https://opensource.googleblog.com/2017/03/guetzli-new-open-s... об открытии кода высококачественного JPEG-кодировщика Guetzli с реализацией нового алгоритма (https://arxiv.org/abs/1703.04421) кодирования, позволяющего добиться существенного сокращения размера изображения без потери качества, но с сохранением совместимости со всеми штатными декодировщиками JPEG и полным соответствием стандарту JPEG. Например, по сравнению с эталонной библиотекой libjpeg предложенный алгоритм позволяет сократить размер изображений на 20-30% c сохранением идентичного качества. Код библиотеки и базовых утилит с реализацией Guetzli написан на языке С++ и распространяется (https://github.com/google/guetzli/) под лицензией Apache 2.0.
Guetzli близок по своему назначению к алгоритму Zopfli (https://www.opennet.ru/opennews/art.shtml?num=36267), позволяющему добиться повышения уровня сжатия файлов PNG и gzip, без потери совместимости. В отличие от WebP (https://www.opennet.ru/opennews/art.shtml?num=39378), RAISR (https://www.opennet.ru/opennews/art.shtml?num=45998) (Rapid and Accurate Image Super-Resolution) и алгоритмов упаковки изображения на базе нейронных сетей, требующих специальных декодировщиков, Guetzli нацелен на достижение максимального уровня сжатия без нарушения совместимости с уже существующим клиентским ПО. Обратной стороной предложенного алгоритма является очень большая ресурсоёмкость. Guetzli также требует достаточно много оперативной памяти, например, для каждого 1MPix картинки требуется 300 Мб ОЗУ. Относительно других кодировщиков Guetzli работает очень медленно и не подходит для сжатия на лету, но вполне пригоден для одноразовой переупаковки имеющегося контента.В процессе кодирования JPEG наиболее заметная потеря качества наблюдается на стадии квантования. Стадии преобразования цветового пространства (https://ru.wikipedia.org/wiki/YUV) и дискретное косинусное преобразование (DCT (https://ru.wikipedia.org/wiki/%D0%94%D0%... не столь сильно поддаются оптимизации. Guetzli оптимизирует таблицы квантования и коэфициенты DCT для каждого блока JPEG, применяя специальный оптимизатор. Для оценки оптимальности найденных параметров квантования Guetzli использует алгоритм Butteraugli (https://github.com/google/butteraugli), использующий в качестве метрики уровень различий между психовизуальным моделированием JPEG и собственным более эффективным методом психовизуального моделирования, что позволяет снизить число возникающих артефактов. Например, на изображениях ниже слева представлен исходный вариант, в центре результат работы libjpeg, а справа - Guetzli.
URL: https://opensource.googleblog.com/2017/03/guetzli-new-open-s...
Новость: https://www.opennet.ru/opennews/art.shtml?num=46208
И вообще почти все инновации гугля анонсируются как "высококачественные", но почему-то требуют в раз больше ресурсов (и в перспективе могут быть приколы с вендор локом). С каждой такой новостью приходится допаивать еще один этаж РУ7 на свой телефон.
высококачественные != высокопроизводительные
> И вообще почти все инновации гугля анонсируются как "высококачественные", но почему-то
> требуют в раз больше ресурсов (и в перспективе могут быть приколы
> с вендор локом). С каждой такой новостью приходится допаивать еще один
> этаж РУ7 на свой телефон.Не так и сложно бутербродов РУ7 допаять. Если шины небуферизированы, АП6 допаяй и КМок на Каждую РУшку тоже! А то от звона глючить телефон будет.
Отлично. Фото из Raw преобразовывать - самое оно.
Удалять raw глупость. Даже если идеально выставишь уровни, через несколько лет у тебя умения всё-равно будут выше. Да или банально вкусы поменяются и захочется чуть приглушить контраст, а х.ен...
А кто говорил про удалять?
Разумеется, но слать родителям их тоже не будешь.
> Отлично. Фото из Raw преобразовывать - самое оно.чем тебе для фото плох png ? Жрет в разы меньше, потерь нет.
Это - для фото залитых юзером на хранилку, на вечное хранение. Чтоб поменьше своей едой места занимал.
За ликбезом насчёт raw - не сюда.
Обычный джипег лучше этой новой шняги.
> Обычный джипег лучше этой новой шняги.второй ряд фоток как бы намекает, что да - новая шняга потеряла начисто информацию о цвете центральной кляксы, libjpeg сохранил.
На первом изображено незнамочто, вероятно, совершенно пофиг, как его закодировать.странное ненужно выкатил гугль...
Видимо это вариант джпег для дальтоников
В первом ряду могло быть изображение провода или чего-то тонкого вдалеке - они часто в один пиксель цифруются, несмотря на истинный размер, ибо мельче нельзя. Так нативное и джипег менее расплывчатые и более темные - контрастные, мне кажется более правильные для подобной ситуации (если это она, конечно).
> второй ряд фоток как бы намекает, что да - новая шняга потеряла
> начисто информацию о цвете центральной кляксы, libjpeg сохранил.В целом видно, что артефактов меньше. Но вот, что он почти все цвета сдвинул во втором ряду, это конечно крайне плохо. Будем надеяться что это просто баг и он будет устранен.
интересно сравнение с mozjpeg
https://github.com/mozilla/mozjpeg/issues/242
тред не читай, да вообще ничего не читай:
а что стало со "jpeg turbo" ? он же самый
> а что стало со "jpeg turbo" ? он же самыйОн быстрый, но качество тоже, что и у обычного libjpeg.
Лучшее качество сжатия у mozjpeg.
в общем, артефактов меньше, зато потерь чуть больше
открыли, что бы они засунуть в хром и андроид, что бы юзер при загрузке в облако ужимал фотки. тогда нагрузка на сервера снизится и за качество будет отвечать юзер, а не гугл. они все так делают... всю нагрузку на юзеров переносят
Убрали шум из изображений - за счет этого улучшилось сжатие. Отличная новость.
детали, цветовые, а не шум они убрали (поскольку отличить одно от другого - даже ИИ гугля не очень справляется)
6. OpenNews: Dropbox опубликовал реализацию алгоритма сжатия изображений Lepton
в сортах jpeg не разбираюсь,только BMP :)
Странный у вас вкус.
Я предпочитаю tiff.
> JPEG-кодировщика Guetzli с реализацией нового алгоритма кодирования, позволяющего добиться существенного сокращения размера изображения без потери качестваКак в одном предложении может сочетаться "JPEG" и "без потери качества"? Что употреблял автор? Я уверен что речь не про lossless в JPEG2000.
Без потри качества в сравнении с обычным кодировщиком JPEG.
А что за название такое чудное? Неужели "гусли"? )
> А что за название такое чудное? Неужели "гусли"? )Конечно же гусли! И пофиг на то, что читается оно как "гёт(з|ц)ли" и совпадает со швейцарским обозначением печенек (или баварским - кофет/сладостей) … o_O
Кстати, в той же "серезной" биологии полно таких чудных названий: "галушко-протеин" (spaetzle) "огуречный" (gurken), "криптонит" (потому что подавляет "локус супермена").
переведёшь так все свои фотки скопом этим кодировщиком, а через 20 лет глянешь, пары человек на каких-нибудь фотках не хватает, алгоритм не учёл :)
Ты это в "Назад в будущее" подсмотрел. :)
Я о том же подумал. Но мне в голову вот эта видяшка пришла: https://www.youtube.com/watch?v=vJG698U2MvoТам явно есть элементы, которые можно было бы удалить без потери качества в силу выборочности внимания.
Ну или развитие темы:
https://www.youtube.com/watch?v=IGQmdoK_ZfY
https://www.youtube.com/watch?v=ubNF9QNEQLA
https://www.youtube.com/watch?v=v3iPrBrGSJMЧеловек вообще ничего не видит, и половину можно поудалять.
Хмм... Судя по сравнению фоток (низкий ringing) и заявлениям типа
> Из недостатков Guetzli также упоминается поддержка кодирования только в режиме наивысшего качества (-quality 90).ненужность 10-битного h.264 считается доказанной? Ну т.е. теперь все то же самое можно повторить без необходимости промежуточного увеличения глубины цвета исходника с 8бит до 10бит.
Хорошая вещь для растровых спутниковых карт. Гуглу в сторону уменьшения памяти и использования OpenCL надо копать.