Image Catalyst 2.5

[@Fesor]

TinyJPG.org — 15Kb

[@1514m]

У Вас сжато с потерями.

[@Fesor]

Я это понимаю.

[@AxisPod]

Невооруженным взглядом вы видите эти потери?

[@andrewiWD]

Да! Особенно ярко я их видил, когда пытался ужать сборку флагов стран.

[@Ryotsuke]

Я вижу. Тень особенно ужасна, но видно на всех градиентах

[@Lorents]

Image Catalyst оптимизирует без потерь.

[@Evgeny42]

Понимаю что работает по другому. Но какой смысл сжимать png на пару килобайт, когда какой-нибудь tine PNG может сделать это в разы лучше.

16КБ

Упс, кажись не успел.

[@Lorents]

1. tinePNG жмет с потерями. Вы считаете 256 цветов хватит любому изображению?
2. можетt оптимизировать tinePNG + Image Catalyst и получите результат еще выше.

[@Evgeny42]

1) Не любому но большинству точно.
2) К сожалению у меня убунту.

[@ninacarrot]

Не очень понял, как вы насчитали килобайты для картинок из заголовка. Я скачал их, и получил вот что:

/tmp/test_data$ ls -l -S
-rw-rw-r-- 1 sourcerer sourcerer 60030 мая   28 21:42 test_ps.png
-rw-rw-r-- 1 sourcerer sourcerer 59993 мая   28 21:42 test_kraken.png
-rw-rw-r-- 1 sourcerer sourcerer 57410 мая   28 21:42 test_catalyst.png

/tmp/test_data$ pngcrush --brute test_ps.png test_pngcrush.png 
$ ls -l test_pngcrush.png 
-rw-rw-r-- 1 sourcerer sourcerer 58564 мая   28 21:45 test_pngcrush.png

/tmp/test_data$ pngcrush -brute test_kraken.png test_pngcrush.png 
$ ls -l test_pngcrush.png 
-rw-rw-r-- 1 sourcerer sourcerer 58564 мая   28 21:45 test_pngcrush.png

/tmp/test_data$ pngcrush -brute test_catalyst.png test_pngcrush.png
/tmp/test_data$ ls -l test_pngcrush.png 
-rw-rw-r-- 1 sourcerer sourcerer 55795 мая   28 21:46 test_pngcrush.png

Отсюда следует, что у вас
а) возможно, какие-то «не те» картинки в шапке
б) возможно, картинка после обработки в Catalyst теряет часть информации
в) возможно, Catalyst сжимает не оптимально — pngcrush смог сжать ещё лучше

[@Lorents]

В шапке действительно не те картинки, не знаю почему habrastorage.org изменил картинки.
pngcrush не мог сжать лучше, pngcrush использует zlib, а я zopfli.

[@Boomburum]

Habrastorage действительно перезаливает картинки из статьи (если они на внешнем сайте лежат, например), сжимает или нет при этом — не знаю. Так что как вариант — сделайте кликабельные ссылки на изображения на стороннем сайте (или в архив залейте куда-нибудь).

[@Lorents]

Не совсем так. На оптимизацию png влияют несколько моменмтов. В частности фильтр оптимизации и алгоритм сжатия deflate.

Алгоритм deflate имеет несколько реализация:
Zlib
7-zip
Kzip
zopfli
И каждая имеет свои достоинства и недостатки.

[@Javian]

Была такая программа:

JPG Cleaner for DOS, Win32 Console and Win32
Copyright © 2000-2002 Rainbow Software

В большинстве случаев очень сильно уменьшала размеры jpg файлов. Удаляла EXIF и другую дополнительную информацию. При разрешении файлов в то время в пределах 640x480, 800x600 дополнительная информация могла занимать десятки килобайт, что могло быть половиной от размера файла с изображением низкого разрешения.

[@bolk]

Больше всего занимал превью, который в JPEG помещал, например, Photoshop. Я тоже когда-то писал такую штуку на PHP в каком-то бородатом году.

[@Javian]

Да, после фотошоп вычищалось больше всего.

[@jaguard]

На фоне того, что сжатие с потерями не доступно, пресловутые преимущества вообще не вызывают интереса.
Сам использую truePNG, нравится что можно задать конкретное количество цветов квантизации и уровень дизеринга, хотя от какого-нибудь интеллекта в программе не отказался бы (чтобы подбирала оптимальное количество дизеринга и цветов — размер небольшой и без заметных искажений).

[@pewpew]

Для PNG пользуюсь PNGOUT

[@Lorents]

до появления zopfli от google, пользовался PNGOUT для максимального сжатия. Image Catalyst на много сильнее жмет чем PNGOUT, при этом с меньшими временными затратами.

[@kentastik]

16.36 KB — compressor.io

[@Lorents]

14.96 KB — kraken.io

[@Ryotsuke]

Что удивительно у kraken размер меньше, а потерь в градиентах меньше, но тоже заметны

[@FishDude]

Если уж вы начали сравнивать с 256-цветными картинками, взгляните и на это:
Color Quantizer авторства x128 с его собственным алгоритмом квантования, 15.41 Кб.
Здесь огрехи распределены в основном по границам областей, а не по плавным переходам.

[@FishDude]

Картинка не приложилась, ссылка тоже; наверное, грехи кармы их покарали. А вот-с:
dl.dropboxusercontent.com/u/13729396/pic/habr-post-215213-1.png

И вот другой достойный вариант, патентованный алгоритм Optpix из далекого 2001 года + дожато CQ, 13.7 Кб:
dl.dropboxusercontent.com/u/13729396/pic/habr-post-215213-2.png

Это два лучших алгоритма кватнизаторов — x128 и японский Optpix, из известных мне на сегодняшний день.

«Вы все еще жмёте „Кракенами“? Тогда мы идем к вам!»

[@Lorents]

Вы не могли бы чуть поподробнее рассказать про Optpix, и где ее можно скачать?

[@FishDude]

Конкретно вот это сделано в древнем «OPTPiX iMageStudio». Назначение программы — геймдев, работа со спрайтами.

Можно скачать триал продуктов у них на сайте, ближайший современный аналог называется «OPTPiX Imésta». И, кстати, цены на софт у них космические.

Технически, ценен для меня в их программах только квантизатор — собственно «оптимизировать» они не умеют. Мне пришлось взять оригинал картинки, сжать его чем-то оптимизирующим в png (собственно, ради предварительной обработки, чтобы удалились невидимые под альфа-каналом области), потом с помощью imagestudio уменьшить количество цветов, а затем дожать современным оптимизатором png.

[@kiltum]

Пользуясь случаем: а посоветуйте аналогичное, но для pdf'ок?

[@bolk]

Abbyy MRC SDK. Бесплатного, увы, не видел.

[@x128]

Есть универсальный оптимизатор FileOptimizer, он многое умеет оптимизировать, в том числе и pdf.

[@SamDark]

Отличный проект. Держите github.com/lorents17/iCatalyst/pull/2 и github.com/lorents17/iCatalyst/pull/1.

[@Lorents]

Спасибо! Ни как не могу добавить в проект. Подскажите как сделать?

[@SamDark]

Там есть кнопочка merge.

[@Lorents]

Спасибо большое!

[@Nomad1]

Очень не хватает совместимости с другими ОС. Хотя бы .bat файл подровняйте, чтобы была совместимость c wine, а лучше ведите одновременно .bat и .py, ведь сами .exe утилиты отлично работают и под wineconsole.

P.S. В копилку меряния любимыми методами сжатия. Квантизация и понижение до 256 цветов мне не всегда подходят, потому использую Lossy алгоритм для PNG. Вот один из примеров с 32-битным цветом и PSNR 54.1568 против 41.7669 у квантизаторов, размер 48.56 KB.

[@Nomad1]

Habrastorage не согласен :)
Одним словом тут: runserver.net/temp/tmp.opt.png

[@FishDude]

Есть простой вариант компромиссного «lossy» — попытаться уменьшить количество цвето не до 256, а скажем до 512.

[@Nomad1]

В первую очередь, всякие там pngquant так не позволяют, потому как заточены под 256 цветов. Я встречал (да, каюсь, и сам писал) утилиту, которая позволяет уменьшать палитру до произвольного значения, например, 4096 цветов, но там было далеко не все хорошо с Dithering-ом, точнее квантизацией. Популярные алгоритмы dithering заточены под уменьшение битности цвета, например RGB 888 -> 565, а в случае с палитрами у нас как раз точность цвета не падает — хранится полноценная RGBA 8888 палитра. Но тут наступает еще и другая проблема: допустим мы используем палитру из 512 цветов, такой тип картинки контейнером PNG не поддерживается, потому придется хранить таки изображение как и раньше в RGBA 8888, т.е. выделять 32 бита на пиксель, а не 8, как в 256-цветном режиме с палитрой. Но уже из-за dithering у нас увеличится сложность картинки и будет размер даже больше, чем изначально. Если же не использовать dithering в принципе, то будет уж очень-очень lossy качество.
Отдельно можно рассмотреть собственный формат файла, где будет выделяться, допустим, 9 бит на пиксель (для палитры 512). Если в случае 8-бит на пиксель у нас последовательность из 7 пикселей одного цвета с индексом 1 будет выглядеть как набор из 7 байтов с кодом 1 (01 01 01 01 01 01 01), то для 9-битного режима это будет уже 8 байт (01 02 04 08 20 40 80 00). Архивировать вторую последовательность уже заметно сложнее. Логично предположить, что на пиксель удобнее всего выделять число, кратное 8, т.е. 8 или 16 бит. В случае с 16-битными индексами мы можем хранить палитру до 65536 цветов, изображение будет относительно хорошо архивироваться, только занимать будет чуть больше, чем хорошо пожатый изначальный PNG :) Это не говоря уже о том, что это будет свой формат, который надо на лету декодировать.

[@FishDude]

Полностью согласен, это далеко не панацея, но довольно часто встречающийся частный случай.
Скверно работает на чистом синтетиском оригинале, но неплохо справляется с зашумленными картинками.
И, да, dithering категорически противопоказан.

[@Lorents]

По поводу wine постараться сделать в следующей версии. К сожалению я не владею Python.

[@iZevs]

Хорошо бы добавить опцию «не удалять exif» для jpeg.

[@Lorents]

Можно отключить удаление метаданных

в файле config.ini
metadata=true
заменить на
metadata=false

[@4ikist]

не смотрите на сердечки