Comments 44
TinyJPG.org — 15Kb
Понимаю что работает по другому. Но какой смысл сжимать png на пару килобайт, когда какой-нибудь tine PNG может сделать это в разы лучше.
16КБ
Упс, кажись не успел.
16КБУпс, кажись не успел.
Не очень понял, как вы насчитали килобайты для картинок из заголовка. Я скачал их, и получил вот что:
Отсюда следует, что у вас
а) возможно, какие-то «не те» картинки в шапке
б) возможно, картинка после обработки в Catalyst теряет часть информации
в) возможно, Catalyst сжимает не оптимально — pngcrush смог сжать ещё лучше
/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 смог сжать ещё лучше
В шапке действительно не те картинки, не знаю почему habrastorage.org изменил картинки.
pngcrush не мог сжать лучше, pngcrush использует zlib, а я zopfli.
pngcrush не мог сжать лучше, pngcrush использует zlib, а я zopfli.
Была такая программа:
В большинстве случаев очень сильно уменьшала размеры jpg файлов. Удаляла EXIF и другую дополнительную информацию. При разрешении файлов в то время в пределах 640x480, 800x600 дополнительная информация могла занимать десятки килобайт, что могло быть половиной от размера файла с изображением низкого разрешения.
JPG Cleaner for DOS, Win32 Console and Win32
Copyright © 2000-2002 Rainbow Software
В большинстве случаев очень сильно уменьшала размеры jpg файлов. Удаляла EXIF и другую дополнительную информацию. При разрешении файлов в то время в пределах 640x480, 800x600 дополнительная информация могла занимать десятки килобайт, что могло быть половиной от размера файла с изображением низкого разрешения.
На фоне того, что сжатие с потерями не доступно, пресловутые преимущества вообще не вызывают интереса.
Сам использую truePNG, нравится что можно задать конкретное количество цветов квантизации и уровень дизеринга, хотя от какого-нибудь интеллекта в программе не отказался бы (чтобы подбирала оптимальное количество дизеринга и цветов — размер небольшой и без заметных искажений).
Сам использую truePNG, нравится что можно задать конкретное количество цветов квантизации и уровень дизеринга, хотя от какого-нибудь интеллекта в программе не отказался бы (чтобы подбирала оптимальное количество дизеринга и цветов — размер небольшой и без заметных искажений).
Для PNG пользуюсь PNGOUT
16.36 KB — compressor.io
14.96 KB — kraken.io
Что удивительно у kraken размер меньше, а потерь в градиентах меньше, но тоже заметны
Если уж вы начали сравнивать с 256-цветными картинками, взгляните и на это:
Color Quantizer авторства x128 с его собственным алгоритмом квантования, 15.41 Кб.
Здесь огрехи распределены в основном по границам областей, а не по плавным переходам.
Color Quantizer авторства x128 с его собственным алгоритмом квантования, 15.41 Кб.
Здесь огрехи распределены в основном по границам областей, а не по плавным переходам.
Картинка не приложилась, ссылка тоже; наверное, грехи кармы их покарали. А вот-с:
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, из известных мне на сегодняшний день.
«Вы все еще жмёте „Кракенами“? Тогда мы идем к вам!»
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, из известных мне на сегодняшний день.
«Вы все еще жмёте „Кракенами“? Тогда мы идем к вам!»
Вы не могли бы чуть поподробнее рассказать про Optpix, и где ее можно скачать?
Конкретно вот это сделано в древнем «OPTPiX iMageStudio». Назначение программы — геймдев, работа со спрайтами.
Можно скачать триал продуктов у них на сайте, ближайший современный аналог называется «OPTPiX Imésta». И, кстати, цены на софт у них космические.
Технически, ценен для меня в их программах только квантизатор — собственно «оптимизировать» они не умеют. Мне пришлось взять оригинал картинки, сжать его чем-то оптимизирующим в png (собственно, ради предварительной обработки, чтобы удалились невидимые под альфа-каналом области), потом с помощью imagestudio уменьшить количество цветов, а затем дожать современным оптимизатором png.
Можно скачать триал продуктов у них на сайте, ближайший современный аналог называется «OPTPiX Imésta». И, кстати, цены на софт у них космические.
Технически, ценен для меня в их программах только квантизатор — собственно «оптимизировать» они не умеют. Мне пришлось взять оригинал картинки, сжать его чем-то оптимизирующим в png (собственно, ради предварительной обработки, чтобы удалились невидимые под альфа-каналом области), потом с помощью imagestudio уменьшить количество цветов, а затем дожать современным оптимизатором png.
Пользуясь случаем: а посоветуйте аналогичное, но для pdf'ок?
Abbyy MRC SDK. Бесплатного, увы, не видел.
Есть универсальный оптимизатор FileOptimizer, он многое умеет оптимизировать, в том числе и pdf.
Отличный проект. Держите github.com/lorents17/iCatalyst/pull/2 и github.com/lorents17/iCatalyst/pull/1.
Очень не хватает совместимости с другими ОС. Хотя бы .bat файл подровняйте, чтобы была совместимость c wine, а лучше ведите одновременно .bat и .py, ведь сами .exe утилиты отлично работают и под wineconsole.
P.S. В копилку меряния любимыми методами сжатия. Квантизация и понижение до 256 цветов мне не всегда подходят, потому использую Lossy алгоритм для PNG. Вот один из примеров с 32-битным цветом и PSNR 54.1568 против 41.7669 у квантизаторов, размер 48.56 KB.
P.S. В копилку меряния любимыми методами сжатия. Квантизация и понижение до 256 цветов мне не всегда подходят, потому использую Lossy алгоритм для PNG. Вот один из примеров с 32-битным цветом и PSNR 54.1568 против 41.7669 у квантизаторов, размер 48.56 KB.
Habrastorage не согласен :)
Одним словом тут: runserver.net/temp/tmp.opt.png
Одним словом тут: runserver.net/temp/tmp.opt.png
Есть простой вариант компромиссного «lossy» — попытаться уменьшить количество цвето не до 256, а скажем до 512.
В первую очередь, всякие там 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 :) Это не говоря уже о том, что это будет свой формат, который надо на лету декодировать.
Отдельно можно рассмотреть собственный формат файла, где будет выделяться, допустим, 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 :) Это не говоря уже о том, что это будет свой формат, который надо на лету декодировать.
По поводу wine постараться сделать в следующей версии. К сожалению я не владею Python.
Хорошо бы добавить опцию «не удалять exif» для jpeg.
не смотрите на сердечки
Sign up to leave a comment.
Image Catalyst 2.5