Комментарии 31
Давыным давно, когда деревья были большими… я тоже работал над своими алгоритмами сжатия изображений. И они тоже были лучше того, что использовалось везде. Но естественно это никому не нужно было тогда, не нужно и сейчас, и вот почему: когда создается используемый всеми алгоритм сжатия, почти всегда в то же время известны алгоритмы лучше него.
Когда делали старый JPEG — уже были и выйвлеты, и арифметическое сжатие, но сделали то, что сделали.
А причина в том, что критериев хорошего алгоритма сжатия изображений намного больше чем скорость сжатия/распаковки и степень сжатия. Учитывается и весь спектр патентов, и требуемые ресурсы для аппаратной реализации, и многое другое.
Когда делали старый JPEG — уже были и выйвлеты, и арифметическое сжатие, но сделали то, что сделали.
А причина в том, что критериев хорошего алгоритма сжатия изображений намного больше чем скорость сжатия/распаковки и степень сжатия. Учитывается и весь спектр патентов, и требуемые ресурсы для аппаратной реализации, и многое другое.
+4
Предлагаете ничего не делать? Пусть всегда будет солнце, пусть всегда будет лето, пусть всегда будет PNG'то? :)
+9
Делать конечно можно все что угодно. Но практической отдачи для человечества — близко к 0 :-)
-3
Нельзя сделать мир лучше, просто ничего не делая. К тому же, если не прикладывать энергию, энтропия в рамках системы увеличивается. Иначе говоря, опуская руки и нагнетая пораженческие настроения, вы не помогаете, и даже, возможно, мешаете улучшению мира.
Я вас не виню, просто делюсь своим мнением. И да, вспомните историю Linux.
Я вас не виню, просто делюсь своим мнением. И да, вспомните историю Linux.
+2
Я делаю не только для того, чтобы изменить мир, но и для того, что получить моральное удовлетворение. Да и как сказать, я на прошлой работе делал web cms, потому, что опенсорсных аналогов для таких масштабов нет и возможно никогда не будет. Некоторые вещи делались методом проб и ошибок, в итоге получилась очень мощная вещь с большим кол-вом интересных решений. Так программисты растащили все кому не лень, даже для малых проектов.
Так что все зависит не от того надо или нет, а от качества, если проект хороший, то рано или поздно он займет свою нишу.
Так что все зависит не от того надо или нет, а от качества, если проект хороший, то рано или поздно он займет свою нишу.
0
Некто не говорит что требуется делать универсальный метод сжатия изображения, достаточно для своих определенных целей.
0
Тут нужно не забывать, что это lossless алгоритм, в отличие от JPEG. То есть для алгоритмов с потерей действительно куча критериев: есть ли артефакты, какие пространственные гармоники они передают, насколько хорошо картинка выглядит для человека после сжатия и т.п.
А для lossless алгоритмов основных критериев по сути всего три (не учитывая патенты): скорости распаковки, упаковки и степень сжатия (хотя она, конечно, может зависеть от типа изображения).
Так что пример со jpeg не совсем подходит сюда. Хотя патенты и аппаратную часть, конечно, интересно было бы сравнить.
А для lossless алгоритмов основных критериев по сути всего три (не учитывая патенты): скорости распаковки, упаковки и степень сжатия (хотя она, конечно, может зависеть от типа изображения).
Так что пример со jpeg не совсем подходит сюда. Хотя патенты и аппаратную часть, конечно, интересно было бы сравнить.
+1
Вообще-то арифметическое кодирование есть в стандарте JPEG, и референсную библиотеку (libjpeg) можно собрать с поддержкой арифметического кодирования. Но на алгоритм арифметического кодирования, использованном в JPEG, действуют патенты, поэтому большинство программ не умеют даже декодировать JPEG с арифметическим кодированием.
0
На арифметическое сжатие у IBM очень долго был патент. Может быть, и сейчас есть.
0
Жалко, что пока поддерживается только PPM. Скомпилировал, а потестить нечем.
0
А в чём проблема? Берёте PNG, BMP и конвертируете в PPM. Под линукс что консольный convert (из ImageMagick) умеет, что Gwenview, что GIMP. Под винду, тот же ImageMagick есть. Да и плагин Imagine для Total Commander обладает поддержкой PPM (умеет ли сохранять — не знаю). Впрочем, GIMP под винду тоже есть (впрочем как и KDE с Gwenview, но это будет слишком).
0
Как собрали? У меня ругается на aclocal.
0
В батник загнал вот это:
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.
0
Если алгоритм не будет добавлен в поддержку браузерами, он будет работающим трупом.
Думаю использовать его для сканов фоток из семейного архива. Повыгоднее чем TIFF-LZW будет…
Думаю использовать его для сканов фоток из семейного архива. Повыгоднее чем TIFF-LZW будет…
+4
Ну как сказать…
Есть замечательная программка MyPaint. Она использует формат, фактически представляющий собой архив с png'шками.
Так вот, картинки с полусотней слоёв, пара-тройка из которых — размерами тысяч по пять пикселей в обоих направлениях, он сохраняет ощутимо долго. А замена png на iz сделает сохранение почти мгновенным.
В общем, даже без веба — будущее у быстрых алгоритмов сжатия картинок есть всегда: как минимум, в качестве внутренних форматов графических редакторов.
Есть замечательная программка MyPaint. Она использует формат, фактически представляющий собой архив с png'шками.
Так вот, картинки с полусотней слоёв, пара-тройка из которых — размерами тысяч по пять пикселей в обоих направлениях, он сохраняет ощутимо долго. А замена png на iz сделает сохранение почти мгновенным.
В общем, даже без веба — будущее у быстрых алгоритмов сжатия картинок есть всегда: как минимум, в качестве внутренних форматов графических редакторов.
+3
Я тоже думал, как бы в браузеры свой кодек добавить :-)
Вон для JPEG2000 поддержку уже почти сделали, но в результате — его нигде нет.
И это — индустриальный, принятый всеми стандарт.
У поделки нет шансов, кроме как если папа миллиардер, и может забашлять напрямую в M$, Apple и Google :-D
Вон для JPEG2000 поддержку уже почти сделали, но в результате — его нигде нет.
И это — индустриальный, принятый всеми стандарт.
У поделки нет шансов, кроме как если папа миллиардер, и может забашлять напрямую в M$, Apple и Google :-D
-1
а WebM (он тоже и для картинок приспосабливаем) не добавите в бенчмарк?
0
Он с потерями.
+1
WebP, я так понимаю, а не WebM. Он поддерживает сжатие с потерями и без.
code.google.com/speed/webp/
code.google.com/speed/webp/
+1
Думаю, стоит сравнить степень и скорость сжатия с JPEG2000 в режиме сжатия без потерь.
0
Взял стандартный openjpeg-tools и указанную картинку с flickr.com.
С дефолтными настройками:
12,836 КБ за 6 секунд сжатие, 8 секунд распаковка.
Конечно, медленнее (вейвлеты и целочисленное кодирование как-никак), но размер ощутимо меньше.
И да, PNG из этого изображения сжался до 15,896 КБ. Видимо автор сжимал не на максимальном сжатии :)
С дефолтными настройками:
12,836 КБ за 6 секунд сжатие, 8 секунд распаковка.
Конечно, медленнее (вейвлеты и целочисленное кодирование как-никак), но размер ощутимо меньше.
И да, PNG из этого изображения сжался до 15,896 КБ. Видимо автор сжимал не на максимальном сжатии :)
0
Автор даже не использует арифметическое кодирование, только Хаффмана. Иначе размер был бы ещё на 25% меньше.
+4
Ё-моё, не поймите меня неправильно, но может мне тоже заняться репостом новостей с опеннета недельной давности? Если уж репостить, то чем раньше, тем лучше.
-1
Я, к примеру, не возражаю, занимайтесь.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Алгоритм ImageZero (IZ): быстрое сжатие без потери качества