https://opennet.dev/openforum/vsluhforumID3/86246.html Представлен (http://googledevelopers.blogspot.com/2012/08/lossless-and-transparency-modes-in-webp.html) релиз библиотеки libwebp 0.2 (http://code.google.com/p/webp/) с реализацией функций кодирования и декодирования изображений в формате WebP (https://developers.google.com/speed/webp/), продвигаемом компанией Google. Используемые в WebP технологии сжатия с потерями позволяют добиться сокращения размера файла на 25%-34%, по сравнению с файлами JPEG аналогичного качества, и на 26% в режиме кодирования без потерь по сравнению с максимальным уровнем сжатия PNG.<br><br><br>Новая версия библиотеки примечательна обеспечением поддержки прозрачности (альфа-канал) и режима сжатия без потерь. Указанные возможности были предложены для внесения в спецификацию в конце прошлого года, сейчас же в спецификацию внесён финальный вариант новых возможностей и представлена их стабильная реализация, готовая для повсеместного внедрения. Поддержка сжатия без потерь и прозрачности WebP также добавлена в последнюю бета-версию браузера Chrome https://opennet.dev/openforum/vsluhforumID3/86246.html#23 Sun, 02 Sep 2012 18:43:48 GMT &gt;&gt; Оно вышло из разряда "сжимаю файл 6 часов, а потом Oooops, assert!", <br>&gt; Это что за файл оно жало 6 часов? Это точно была картинка? <br>&gt; oO <br><br>Самые обычные фото, вот здесь человек описывал подобную проблему:<br>https://extrememoderate.wordpress.com/2011/11/20/webp-lossless-first-impressions/<br><br>Пару месяцев назад я решил прикрутить webp/webpll к своему вьюверу и тоже пытался сжать пару картинок с разными параметрами. Часами я не ждал, но 20-40 минут сжатия и регулярные обломы были в порядке вещей.<br><br>Время декодирования было также много больше того же файла, сжатого в PNG. Конечно степень сжатия в webpll была повыше, но от "убийцы" PNG (для которого большое время декодирования файлов высокого разрешения остаётся существенной проблемой) я ожидал большего.<br> https://opennet.dev/openforum/vsluhforumID3/86246.html#22 Sun, 02 Sep 2012 14:22:44 GMT &gt; Оно вышло из разряда "сжимаю файл 6 часов, а потом Oooops, assert!", <br><br>Это что за файл оно жало 6 часов? Это точно была картинка? oO<br> https://opennet.dev/openforum/vsluhforumID3/86246.html#21 Sun, 02 Sep 2012 14:21:23 GMT &gt; Просто в некоторых случаях он им выгоден, <br><br>Как ни странно, это одна из основных причин интереса к опенсорсу. И да, глупо плевать на то что тебя поддерживает на плаву.<br> https://opennet.dev/openforum/vsluhforumID3/86246.html#20 Sun, 02 Sep 2012 14:20:14 GMT &gt; vobris <br><br>Так он и так всеми браузерами нынче поддерживается вроде. Opus просто лучше жмет на битрейтах порядка 64Кбит и на совсем низких скоростях. <br> https://opennet.dev/openforum/vsluhforumID3/86246.html#19 Sat, 01 Sep 2012 18:19:50 GMT Кто-нибудь пробовал lossless кодек на этой версии?<br>Оно вышло из разряда "сжимаю файл 6 часов, а потом Oooops, assert!", как было с прошлой версией, из-за чего сравнение с альтернативными кодеками было попросту невозможно?<br> https://opennet.dev/openforum/vsluhforumID3/86246.html#18 Sat, 01 Sep 2012 17:28:52 GMT &gt;Зато сколько бы сделали для OpenSource.<br><br>Им плевать на OpenSource. Просто в некоторых случаях он им выгоден, и они используют его до тех пор, пока он им нужен. Становится не нужен - забивают, и мнение &#171;сообщества&#187; не учитывается.<br> https://opennet.dev/openforum/vsluhforumID3/86246.html#17 Sat, 01 Sep 2012 09:11:32 GMT вас двое<br> https://opennet.dev/openforum/vsluhforumID3/86246.html#16 Sat, 01 Sep 2012 05:03:33 GMT &gt; а что гуглу мешает выкупить патент? копейки. Зато сколько бы сделали для <br>&gt; OpenSource.<br><br>наверное, они просто забыли спросить у тебя совета.<br> https://opennet.dev/openforum/vsluhforumID3/86246.html#15 Sat, 01 Sep 2012 05:03:04 GMT &gt; rangecoder существенно шустрее, а в степени сжатия проигрывает не сильно. Что с <br>&gt; патентами - не в курсе.<br><br>его и придумывали как непатентованую замену арифметике.<br>