Фрактальное сжатие графики
Неужели кто-то все еще у верен, что в массовом использовании находятся сами самые технологически успешные и удачные решения? — Ничего подобного.
Рассмотрим, например, сжатие графики: Мало кто будет спорить, что форматы .JPG и .GIF самые подходящие для публикации в WEB. Мол, «Отношение сжатие/качество у них самое оптимальное, а .GIF — так и вообще анимацию показывает. Кто-то может быть еще вспомнит про флеш…
В качестве контрпримера рассмотрим малоизвестный алгоритм фрактального сжатия:
Данный алгоритм известен тем, что в некоторых случаях позволяет получить очень высокие коэффициенты сжатия (лучшие примеры — до 1000 раз при приемлемом визуальном качестве) для реальных фотографий природных объектов, что недоступно для других алгоритмов сжатия изображений в принципе.
И действительно! Воспользовавшись программой Fractal Imager 1.1 Beta2 и фотографией леса Forest.jpg, входящей в стандартные обои ОС Windows Vista, я провел эксперимент, и получил практически трехкратное уменьшение занимаемого дискового пространства: 210 килобайт против 648.
Слева — оригинальное изображение. Справа — сжатое по фрактальному алгоритму.
1. Скриншот в оригинальном разрешении
2. Оригинальный Forest.jpg
3. Сжатый Forest.fif (в ZIP архиве)
Великолепно. Не правда-ли?
Но вместо того, чтобы внедрить формат .FIF, данная технология была спрятана «под сукно». Об истинных причинах можно только догадываться: Возможно, патентные проблемы; возможно — неудачный маркетинг. Но факт остается фактом: прогрессивная технология, использвание которой могло бы съэкономить экзабайты дискового постранства и терабиты пропускной способности, не используется.
Конечно, были попытки (Например Genuine Fractals 5.0 — плагин для Фотошопа, позволяющий масштабировать изображения практически без потери качества.), но широкого распространения технология так и не получила.
Сборник ссылок по данному вопросу:
http://www.masters.donntu.edu.ua/2006/fvti/avleeva/links/index.htm
7 Комментариев
Февраль 9th, 2008
Насколько мне известно, преобразование занимает кучу процессорного времени для генерации bitmap’а. Поэтому этот формат, как и векторный, мало используется.
Февраль 9th, 2008
Но сейчас вроде бы процессорное время не проблема…
Наверно не коректный пример, но я вседа использю NTFS-сжатие. Тоже как бы «лишняя нагрузка», но экономия до 30% дискового пространства боле ощутима.
Как вариант — распространение разных примочек для сжатия интернет-трафика. — Нагрузка на систему не идет ни в какое сравнение с увеличением скорости и экономией трафика.
Март 13th, 2008
Она не такая прогрессивная, как может показаться
Основная проблема — сильная зависимость от сжимаемого изображения [== типа сигнала], т.е. он не all-purpose и совершенно непредсказуем.
Большинство изображений для него будут «неудачными» и не дадут ощутимого прироста к сжатию, потому что сигналы, которые можно аппроксимировать фракталом — относительно редкий случай — собственно, только природные изображения и будут хорошо работать.
Это скорее может быть прикольной «фичей» к all-purpose алгоритму, специально для фрактально-представимых картинок (типа галочки «снимок природы»
В дело он не пошел не из-за коммерческих проблем, а именно в силу своей непредсказуемости и плохой эффективности, если оценивать масштабно.
Если взять много самых разных изображений, положить в папку, и сжать их и джипегом, и фрактально, то размер получишейся папки у джипега будет меньше — статистически джипег выиграет И именно это будет показателем, насколько эффективнее тот или иной алгоритм для «хранения информации вцелом», как и для передачи по сети.
P.S.
Если говорить о новых алгоритмах, то смотреть надо в сторону базирующихся на wavelet-теории (jpeg2000, например) которые основаны на красивой математической концепции, по сути, являющейся upgrad’ом к обычному преобразованию Фурье (которое, в свою очередь, юзается в обычном jpeg).
P.P.S.
Да, я математик %)
Март 13th, 2008
Убедительно.
Спасибо за комментарий.
Июнь 3rd, 2012
«Слева» и «справа» СЛИТНО
Декабрь 28th, 2013
Где взять эту программу? Нигде её нету…
Трэкбеки
Добавить комментарий