Кристоф Фек (Christoph Feck), разработчик из команды KDE, выпустил (http://kdepepo.wordpress.com/2012/01/30/fast-lossless-color-.../) предварительную реализацию кодека IZ (http://gitorious.org/imagezero) (ImageZero) для сжатия изображений без потерь. Причиной написания программы стала очень медленная работа PNG на изображениях очень большого размера (более 12-мегапикслей), а также сложности с патентами других существующих алгоритмов, таких как JPEG-LS. Код проекта распространяется (https://gitorious.org/imagezero) под лицензией BSD.В существующих кодеках основной упор делается на степень сжатия, часто в ущерб скорости. В итоге при открытии и сохранении файлов с разрешением уровня 4500×3000 процесс ожидания завершения операции начинает раздражать. При создании IZ основное внимание было сосредоточено на скорости сжатия и распаковки. На данном этапе разработки IZ сжимает в 30 раз быстрее PNG. Скорость распаковки в два раза быстрее PNG. С точки зрения эффективнос...
URL: http://kdepepo.wordpress.com/2012/01/30/fast-lossless-color-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=32940
Чёрт побери, а этот Кристоф молодец!
А кто-нить вааще заходил на оффсайт, читал описание?1. IZ - не поддерживает альфа канал!
ImageZero is a high-performance lossless _RGB_ color image compressor/decompressor.
...it compresses _24_ bit PPM files..2. IZ - не подходит для grayscale и для сгенерённых компьютерных изображений.
ImageZero is not suited for “flat” (computer generated) graphics or grayscale images.
Да, но это же только начало, не всё сразу.
Глядишь, ему помогут и получится конфетка.
Альфа канализация патентована, и тянет за собой ещё 13 патентовhttp://www.google.com/search?tbm=pts&tbo=1&hl=en&q=alpha+cha...
Ну да - специализированный кодек для сжатия фотографий без потерь. И что? В конце концов можно сделать контейнер,в котором это будет одним из вариантов сжатия. Или в TIFF совать - он разные методы умеет, будет ещё один.
Он, конечно, тоже нашел в чужих алгоритмах тот же фатальный недостаток что и все остальные, но он это сделал хорошо! :)
А lossy оно умеет?
Зачем?
Без lossy сравнение с jpeg не полно.
Группа экспертов в области фотографии (Joint Photographic Experts Group) в дополнение к известным форматам сжатия изображений JPEG и JPEG 2000, ориентированным прежде всего на сжатие с потерями, предложила также стандарт на сжатие без потерь — JPEG-LS (в котором, однако, предусмотрен также режим сжатия с ограниченными потерями).
Сделай resize перед сжатием - вот тебе и lossy. Неполным сравнение будет, надо же такое сморозить...
> Сделай resize перед сжатием - вот тебе и lossy.Ты это что, в сырце VP8 подсмотрел, читер? А то там есть такой режим :)
Вообще-то лучше чтобы "оно" его не умело - иначе начинаем сильноо путать пользователей, для большинства которых раширение файла (в крайнем случае - контейнер) эквивалентно алгоритму сжатия со всеми нюанасами. Если по отдельности - понятно: отдает фотоаппарат PNG - это никак не порченные фотографии, отдает JPEG - они заведомо с потерями. А если гибриды - маркетолухи не упустят шанс написать "высококачественный формат XYZ" и забыть сказать, что жато с потерями
нет, чтобы оптимизировать разжатие в png, обязательно нужно создать свой формат, с блекджеком и шлюхами, и, в последствии, проблемы совместимости
> нет, чтобы оптимизировать разжатие в png, обязательно нужно создать свой формат, с
> блекджеком и шлюхами, и, в последствии, проблемы совместимостиТам не разжатие, так сжатие ужасно и далеко не факт, что его вообще возможно оптимизировать больше, чем оно уже есть. libpng существует уже довольно давно и если сжатие там до сих пор такое медленное, то заметно лучше оно скорее всего уже не станет.
Вот именно.PNG существует давно.
Сжатие PNG хуже IZ.
Скорость работы PNG медленнее, чем IZ.
IZ разработан разработчиком (кодером) одной из ОС.Что-то терзают меня сомнения... Если бы могли сделать лучше - сделали бы уже давным давно.
> Что-то терзают меня сомнения... Если бы могли сделать лучше - сделали бы
> уже давным давно....пробурчал питекантроп, неувернно теребя древко копья, пятясь в сторону привычной пещеры...
Так вы возьмите deflate и улучшите!Только учтите, что алгоритму уже лет дцать.
вам нужно - вы и улучшайте. меня и png вполне устраивает, ничего я улучшать не буду
> Так вы возьмите deflate и улучшите!Откройте для себя LZMA...
Опять нет сравнения с WebP lossless. Неужели надо всё делать самому, чтобы найти истину :|.
Зачем же? Возьмите попкорн и залезайте на печь.
> Неужели надо всё делать самому, чтобы найти истину :|.А вы надеялись что все и вся за вас сделают другие? А вот и зря.
Всё хорошо, только сорцы в грёбаном с++. Ну да ладно, творчески переписать в более нормальном виде не проблема.
Вы ожидали увидеть Java? Я от неё в новостях, если честно, что-то подустал.
> Вы ожидали увидеть Java? Я от неё в новостях, если честно, что-то
> подустал.Чувак ожидает Си - истинно правильный выбор для подобных вещей, чтобы без траха можно было использовать в любых других языках.
Самый правильный способ - это либа на C++ с API на C (+ опционально API на C++).
Тогда будут и овцы целы, и волки сыты.
Ну если конечно такое добро кто в ядро не захочет встроить :-|.
> Ну если конечно такое добро кто в ядро не захочет встроить :-|.Вот поэтому лучше на чистом си сразу. А то будет как с LZMA, который один хрен прищлось на си переписывать по этим причинам.
Если подразумевать железные реализации - то чистый C был бы лучше. Хотя (сорцы не смотрел) есть варианты, когда именно использование плюсов дает преимущества - например, расчет каких-нибудь таблиц шаблонами на этапе компиляции. В этом плане весело когда-тобыло видеть библиотечку для AVR, писанную на плюсах - так она била по скорости и компактности руками писанный на ассемблере код - при том, что в AVR ассемблер очень простой, кода мало а люей, умсеющих на нем писать предостаточно. На сях аналог наворотить не смогли - ибо вся соль в шаблонах, подставляющих в каждом случае оптимальную реализацию.
> - так она била по скорости и компактности руками писанный на
> ассемблере код - при том, что в AVR ассемблер очень простой,... это означает лишь что ассемблерщик был весьма жопорукий или применял свое кунг-фу бездумно. Обычно сишный и тем более плюсатый компилер генерит довольно горбатый код, который можно существенно улучшить, если переписать на асме. То что это надо делать с задействованием головы и только там где это реально надо - факт.
IMHO: если вы не можете сделать си++ компилера на асме - идите лучше в дворники.
Могу ссылку дать - полюбуйтесь: http://easyelectronics.ru/rabota-s-portami-vvoda-vyvoda-mikr...
Да, да...А теперь скомпильте на С++ код поиска 4-байтной сигнатуры в массиве 4-байтных элементов на 28 кб.
Сравните с этим:
mov eax,'SIGN'
mov ecx,28*1024/4
rep scasdНикогда не видел чтобы из кода на С++ получался такой код :)
> Сравните с этим:
> mov eax,'SIGN'
> mov ecx,28*1024/4
> rep scasdЭто явно не AVRовский ассемблер... у того регистры 8-битные, для начала.
x86, сути это не меняет.
> x86, сути это не меняет.Меняет, вообще-то. x86 — это CISC, AVR — RISC. Генерировать оптимальный код для вторых гораздо легче, чем для первых.
В x86 предусмотрели костыль для ускорения операций с цепочками - отдельную команду для сканирования с префиксом повторения, которая почему-то быстрее, чем аналогичный цикл без использования этой команды. А компиляторы оказываются виноваты, что не знают всех граблей и "тонкостей" x86
медленнее.
компилятор правильно оптимизирует.
> Могу ссылку дать - полюбуйтесь: http://easyelectronics.ru/rabota-s-portami-vvoda-vyvoda-mikr...Угу, прикол состоит в том что
1) на си++ это в виде сырца вышло длиннее в три раза чем было бы асме. Ну нифига себе профит от высокоуровневого ЯП.
2) например инициализация LCD (void LCDinit(void)//Initializes LCD) является такой аццкой кашей что при взгляде на это глаза собираются в кучку и чего оно делает - без поллитра вообще не разберешься. Читабельность функции в полной Ж. Честно говоря, даже асмовая портянка выглядит менее жутко. Например LDP=0<<LCD_D7|0<<LCD_D6|1<<LCD_D5|1<<LCD_D4; //4 bit mode - ну да, совсем не похоже на брейнфак, особенно учтя что такое же << используется для сдвига влево. Веселее всего было бы скомбинировать сдвиг влево с выводом, чтобы совсем уж наверняка сломать мозг всем вокруг.
3) Тинька на плюсах... круто придумано, но какой смысл в плюсах на паре кило флеша? Боинг 767 - для похода в магазин?
4) Если честно я не понимаю на кой хрен умножать сущности сверх необходимого. Класс для пина GPIO? Насущная необходимость, конечно.Правда ради справедливости замечу что там все-таки приведены асмовые листинги и они довольно культурные (avr-gcc молодцом). Правда проблема в том что эта культурность - в сильно некоторых ситуациях и если хочется хоть какой-то оптимальности - придется в этом листинге дневать и ночевать, рассматривая что там накосячил компилер. Что вообще-то добавляет mindf*ck`а. Хотя по логике вещей высокоуровневый ЯП как раз для уменьшения оного.
Да, длиннее. Да, для тиньки. Профит наступает когда ты эту штуку начинаешь использовать в пачке проектов, которые должны еще и между Мк портироваться. Тогда есть смысл один раз проверить, что там генерится, и забыть - а ассемблерные опртянки каждый раз заново писать придётся, да ещё и править при малейших изменениях в используемых пинах.То есть оно для одного изделия (и даже для десятка) не нужно. А вот если больше - то такие изыски себя оправдывают.
> Да, длиннее. Да, для тиньки. Профит наступает когда ты эту штуку начинаешь
> использовать в пачке проектов, которые должны еще и между Мк портироваться.
> Тогда есть смысл один раз проверить, что там генерится, и забыть
> - а ассемблерные опртянки каждый раз заново писать придётся, да ещё
> и править при малейших изменениях в используемых пинах.
> То есть оно для одного изделия (и даже для десятка) не нужно.
> А вот если больше - то такие изыски себя оправдывают.И уж тем более они себя оправдывают если кто-то один это сделал, а другие - пользуются, т.е. в случае опенсорса - выгода прямая.
И, кстати, есть не только тиньки, а и меги с иксмегами - и там оно тоже работает.
> Да, длиннее. Да, для тиньки. Профит наступает когда ты эту штуку начинаешь
> использовать в пачке проектов, которые должны еще и между Мк портироваться.На мое имхо получился какой-то изврат,
- который объемистый в плане размера портянки,
- на мое имхо - малочитабельно,
- придется с лупой мониторить что там вывалит компилер, потому что когда пин объявляется классом - это конечно круто, но насколько оно оптимально будет сгорожено на вон той архитектуре вон тем компилером - большой вопрос (ну раз уж мы о портабельности). То что именно гцц на именно авр довольно круто заоптимизнул - факт.
- Я наверное извращенец, но мне иногда хочется изобразить GPIO лапками _очень_ быстрый дерг, когда последовательность буквально считается по тактам и формируется из команд меняющих состояние порта. Зато так можно сгенерить что-то довольно забористое чисто софтварно, вплоть до частот под несколько мегагерц (апофеозом таких извратов является например софтварный USB для аврок - там вообще высший пилотаж). В этом случае может потребоваться подгонка по тактам. Изврат, зато ядрена вошь и это вообще максимум из того что может камень в принципе показать ;]. Вообще, имхо если супербыстрый и детерминированный с точностью до тактов IO в таком стиле не нужен - так AVR вообще не сдался, 32-битники и дешевле и шустрее. Правда с I/O и прерываниями чуть менее радужно бывает.> Тогда есть смысл один раз проверить, что там генерится, и забыть
> - а ассемблерные опртянки каждый раз заново писать придётся, да ещё
> и править при малейших изменениях в используемых пинах.А зачем? Сделать какой-нибудь макрос, править только его. Хотя это наверное слишком просто, банально и как-то не по джедайски, чтоли. А при нужде сменить архитектуру или что там еще - переписать его. Програмить тиньку на плюсах - забористее, фиг оспоришь :)
> То есть оно для одного изделия (и даже для десятка) не нужно.
> А вот если больше - то такие изыски себя оправдывают.Честно говоря, по-моему плюсы в таком виде на этой мелочи - слегка изврат. Ну я понимаю когда гамеза с бинарем на 6 метров на плюсах, там и сущности на объекты хорошо ложатся, и кода дофига.
еще png не устаканился толком, уже новые поделки ) лучше бы потратили силы и время для продвижения png
это из какого времени сообщение? как везде только png и видно
Да ну :)Открываем opennet.ru, щёлкаем правой кнопкой на логотип - расово неверный GIF. Из PNG лишь иконка твиттера.
Открываем вики - сплошь одни jpeg'и и svg, для анимации gif.
Привет вам, из параллельной вселенной. Мы - люди. Жители планеты Земля.
Эта мода пошла из-за отсуствия в IE6 поддержки альфа-канала в PNG. И видимо эти устаревшие обычаи тяжело изгоняются из web...
> Эта мода пошла из-за отсуствия в IE6 поддержки альфа-канала в PNG. И
> видимо эти устаревшие обычаи тяжело изгоняются из web...Достаточно сходить на что-то менее некроманское, типа http://habrahabr.ru/ и просто посчитать число PNG файлов на главной странице.
> Эта мода пошла из-за отсуствия в IE6 поддержки альфа-канала в PNG.К счастью, эта поделка уже почти пропала с экранов радаров. Я про антикварный ие, разумеется.
Стоит ещё добавить, что если альфа-канал не нужен и хватает 256 цветов, то gif шустрее и меньше весит.
> то gif шустрее и меньше весит.При _равном_ качестве (число цветов, etc) png обычно меньше: zlib (lz+huffman) да еще с фильтрами - жмет эффективнее чем древненький LZW и словарик там побольше + ему еще и фильтры подыгрывают.
> При _равном_ качестве (число цветов, etc) png обычно меньше: zlib (lz+huffman) да еще с фильтрами - жмет эффективнее чем древненький LZW и словарик там побольше + ему еще и фильтры подыгрывают.Сходите ычан или 4gif. Возмите десяток-другой случайных гифок и сконвертируте в apng. Что-то не так, да? Почему-то, размер вдуг вырос… Ой-ой-ой. Не так хорош пинг, как его малюют.
Всему своё место и каждому своё © не помню.
Просто хорошим конвертором надо пользоваться:
http://gif2apng.sourceforge.net
Тогда размер не вырастет, а наоборот уменьшится.
про optipng благородный дон не слышал, видимо. а каким конвертером пользуется и с какими настройками — вообще военная тайна.
речь вообще не о тех гифках, а, например, о http://www.opennet.me/opennet2.gif - там всё, что можно, и lzw жмется, а оверхед у гифа меньше
opennet2.gif = 4415 байтов
opennet2.png = 3500 байтовэкономия 20%
> opennet2.gif = 4415 байтов
> opennet2.png = 3500 байтов
> экономия 20%а чем это ты 3500 получил? у меня меньше, чем 3846 никак не вышло.
> а чем это ты 3500 получил? у меня меньше, чем 3846 никак
> не вышло.хм. вышло 3704. но никак не 3500.
1. Упомянутый выше gif2apng (статические GIFы он тоже конвертирует)
2. Далее pngoutРезультат 3500 байт:
http://img843.imageshack.us/img843/7320/opennet2.png
> 2. Далее pngoutну, я примерно так и думал: что-то проприетарное. (это не в наезд, если что: просто у меня не было под рукой проприетарного инструмента, равно как и желания его скачивать; я думал, ты чем-то открытым этого добился)
хм. подозреваю, что можно попробовать попереть zip-пакер из 7z и вмонтировать в optipng. как-нибудь займусь, если делать совсем нечего будет.
Вот этот PNG-оптимизатор использует метод 7-zip:
http://advancemame.sourceforge.net/comp-readme.htmlС ним у меня получилось 3565 байтов, что тоже весьма неплохо.
> Вот этот PNG-оптимизатор использует метод 7-zip:
> http://advancemame.sourceforge.net/comp-readme.htmlблагодарю, как-то он мимо меня прошёл.
> речь вообще не о тех гифках, а, например, о http://www.opennet.me/opennet2.gif — там
> всё, что можно, и lzw жмется, а оверхед у гифа меньшеэ… э…
# wget http://www.opennet.me/opennet2.gif
gif-файл: 4415 bytes# convert opennet2.gif opennet2.png
png-файл: 3874 bytes# optipng -o9 opennet2.png
png-файл: 3846 bytesняу?
у гифа заголовок поменьше или структуры компактнее - хз, но на мелких/однородных картинках это очень хорошо заметно.
> у гифа заголовок поменьше или структуры компактнее — хз, но на мелких/однородных
> картинках это очень хорошо заметно.когда как. в общем случае у гифа есть ровно одна «killer feature»: анимация. изначальное нежелание авторов впилить её в png у меня до сих пор вызывает недоумение. прописать хотя бы как «опциональную» но таки *стандартную* фичу.
> PNG лишь иконка твиттера.А http://www.opennet.me/favicon.png - это ничего так?
Хотя опеннет довольно некроманский сайт. Делался во времена царя гороха и допотопных версий браузеров. С тех пор половина атавизмов так и осталась.....
> еще png не устаканился толком,Эээ, поздравляю с разморозкой, у нас на дворе 2012 год и png устаканился уже наверное как целое десятилетие.
Как бы интересно увидеть фотик с такой штукой
