Комментарии 31
Давыным давно, когда деревья были большими… я тоже работал над своими алгоритмами сжатия изображений. И они тоже были лучше того, что использовалось везде. Но естественно это никому не нужно было тогда, не нужно и сейчас, и вот почему: когда создается используемый всеми алгоритм сжатия, почти всегда в то же время известны алгоритмы лучше него.
Когда делали старый JPEG — уже были и выйвлеты, и арифметическое сжатие, но сделали то, что сделали.
А причина в том, что критериев хорошего алгоритма сжатия изображений намного больше чем скорость сжатия/распаковки и степень сжатия. Учитывается и весь спектр патентов, и требуемые ресурсы для аппаратной реализации, и многое другое.
Когда делали старый JPEG — уже были и выйвлеты, и арифметическое сжатие, но сделали то, что сделали.
А причина в том, что критериев хорошего алгоритма сжатия изображений намного больше чем скорость сжатия/распаковки и степень сжатия. Учитывается и весь спектр патентов, и требуемые ресурсы для аппаратной реализации, и многое другое.
Предлагаете ничего не делать? Пусть всегда будет солнце, пусть всегда будет лето, пусть всегда будет PNG'то? :)
Делать конечно можно все что угодно. Но практической отдачи для человечества — близко к 0 :-)
Нельзя сделать мир лучше, просто ничего не делая. К тому же, если не прикладывать энергию, энтропия в рамках системы увеличивается. Иначе говоря, опуская руки и нагнетая пораженческие настроения, вы не помогаете, и даже, возможно, мешаете улучшению мира.
Я вас не виню, просто делюсь своим мнением. И да, вспомните историю Linux.
Я вас не виню, просто делюсь своим мнением. И да, вспомните историю Linux.
Я делаю не только для того, чтобы изменить мир, но и для того, что получить моральное удовлетворение. Да и как сказать, я на прошлой работе делал web cms, потому, что опенсорсных аналогов для таких масштабов нет и возможно никогда не будет. Некоторые вещи делались методом проб и ошибок, в итоге получилась очень мощная вещь с большим кол-вом интересных решений. Так программисты растащили все кому не лень, даже для малых проектов.
Так что все зависит не от того надо или нет, а от качества, если проект хороший, то рано или поздно он займет свою нишу.
Так что все зависит не от того надо или нет, а от качества, если проект хороший, то рано или поздно он займет свою нишу.
Некто не говорит что требуется делать универсальный метод сжатия изображения, достаточно для своих определенных целей.
Тут нужно не забывать, что это lossless алгоритм, в отличие от JPEG. То есть для алгоритмов с потерей действительно куча критериев: есть ли артефакты, какие пространственные гармоники они передают, насколько хорошо картинка выглядит для человека после сжатия и т.п.
А для lossless алгоритмов основных критериев по сути всего три (не учитывая патенты): скорости распаковки, упаковки и степень сжатия (хотя она, конечно, может зависеть от типа изображения).
Так что пример со jpeg не совсем подходит сюда. Хотя патенты и аппаратную часть, конечно, интересно было бы сравнить.
А для lossless алгоритмов основных критериев по сути всего три (не учитывая патенты): скорости распаковки, упаковки и степень сжатия (хотя она, конечно, может зависеть от типа изображения).
Так что пример со jpeg не совсем подходит сюда. Хотя патенты и аппаратную часть, конечно, интересно было бы сравнить.
Вообще-то арифметическое кодирование есть в стандарте JPEG, и референсную библиотеку (libjpeg) можно собрать с поддержкой арифметического кодирования. Но на алгоритм арифметического кодирования, использованном в JPEG, действуют патенты, поэтому большинство программ не умеют даже декодировать JPEG с арифметическим кодированием.
На арифметическое сжатие у IBM очень долго был патент. Может быть, и сейчас есть.
Жалко, что пока поддерживается только PPM. Скомпилировал, а потестить нечем.
А в чём проблема? Берёте PNG, BMP и конвертируете в PPM. Под линукс что консольный convert (из ImageMagick) умеет, что Gwenview, что GIMP. Под винду, тот же ImageMagick есть. Да и плагин Imagine для Total Commander обладает поддержкой PPM (умеет ли сохранять — не знаю). Впрочем, GIMP под винду тоже есть (впрочем как и KDE с Gwenview, но это будет слишком).
Как собрали? У меня ругается на aclocal.
В батник загнал вот это:
g++ -O2 -mmmx -Winline -fomit-frame-pointer -fno-rtti -fno-exceptions *.cpp -o iz
pause
За основу использована команда gcc, написанная Black_Fox. g++ ставил вручную по инструкции mingw.org/wiki/InstallationHOWTOforMinGW.
g++ -O2 -mmmx -Winline -fomit-frame-pointer -fno-rtti -fno-exceptions *.cpp -o iz
pause
За основу использована команда gcc, написанная Black_Fox. g++ ставил вручную по инструкции mingw.org/wiki/InstallationHOWTOforMinGW.
Если алгоритм не будет добавлен в поддержку браузерами, он будет работающим трупом.
Думаю использовать его для сканов фоток из семейного архива. Повыгоднее чем TIFF-LZW будет…
Думаю использовать его для сканов фоток из семейного архива. Повыгоднее чем TIFF-LZW будет…
Ну как сказать…
Есть замечательная программка MyPaint. Она использует формат, фактически представляющий собой архив с png'шками.
Так вот, картинки с полусотней слоёв, пара-тройка из которых — размерами тысяч по пять пикселей в обоих направлениях, он сохраняет ощутимо долго. А замена png на iz сделает сохранение почти мгновенным.
В общем, даже без веба — будущее у быстрых алгоритмов сжатия картинок есть всегда: как минимум, в качестве внутренних форматов графических редакторов.
Есть замечательная программка MyPaint. Она использует формат, фактически представляющий собой архив с png'шками.
Так вот, картинки с полусотней слоёв, пара-тройка из которых — размерами тысяч по пять пикселей в обоих направлениях, он сохраняет ощутимо долго. А замена png на iz сделает сохранение почти мгновенным.
В общем, даже без веба — будущее у быстрых алгоритмов сжатия картинок есть всегда: как минимум, в качестве внутренних форматов графических редакторов.
Я тоже думал, как бы в браузеры свой кодек добавить :-)
Вон для JPEG2000 поддержку уже почти сделали, но в результате — его нигде нет.
И это — индустриальный, принятый всеми стандарт.
У поделки нет шансов, кроме как если папа миллиардер, и может забашлять напрямую в M$, Apple и Google :-D
Вон для JPEG2000 поддержку уже почти сделали, но в результате — его нигде нет.
И это — индустриальный, принятый всеми стандарт.
У поделки нет шансов, кроме как если папа миллиардер, и может забашлять напрямую в M$, Apple и Google :-D
а WebM (он тоже и для картинок приспосабливаем) не добавите в бенчмарк?
Он с потерями.
WebP, я так понимаю, а не WebM. Он поддерживает сжатие с потерями и без.
code.google.com/speed/webp/
code.google.com/speed/webp/
Думаю, стоит сравнить степень и скорость сжатия с JPEG2000 в режиме сжатия без потерь.
Взял стандартный openjpeg-tools и указанную картинку с flickr.com.
С дефолтными настройками:
12,836 КБ за 6 секунд сжатие, 8 секунд распаковка.
Конечно, медленнее (вейвлеты и целочисленное кодирование как-никак), но размер ощутимо меньше.
И да, PNG из этого изображения сжался до 15,896 КБ. Видимо автор сжимал не на максимальном сжатии :)
С дефолтными настройками:
12,836 КБ за 6 секунд сжатие, 8 секунд распаковка.
Конечно, медленнее (вейвлеты и целочисленное кодирование как-никак), но размер ощутимо меньше.
И да, PNG из этого изображения сжался до 15,896 КБ. Видимо автор сжимал не на максимальном сжатии :)
Автор даже не использует арифметическое кодирование, только Хаффмана. Иначе размер был бы ещё на 25% меньше.
Ё-моё, не поймите меня неправильно, но может мне тоже заняться репостом новостей с опеннета недельной давности? Если уж репостить, то чем раньше, тем лучше.
Я, к примеру, не возражаю, занимайтесь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Алгоритм ImageZero (IZ): быстрое сжатие без потери качества