https://www.opennet.ru/openforum/vsluhforumID3/133309.html Компания Google представила новую открытую библиотеку jpegli с реализацией кодировщика и декодировщика изображений в формате JPEG. Библиотека включает дополнительные оптимизации для повышения эффективности кодирования, позволяющие на 35% увеличить степень сжатия высококачественных изображений, по сравнению с традиционными кодеками JPEG. В сравнении с libjpeg-turbo библиотека jpegli позволяет добиться аналогичного уровня качества при снижении битрейта на 32%. На уровне API и ABI библиотека полностью совместима с libjpeg62 и может применяться для её прозрачной замены. Код библиотеки написан на языке С++ и распространяется под лицензией BSD...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60921<br> https://www.opennet.ru/openforum/vsluhforumID3/133309.html#199 Wed, 10 Apr 2024 16:14:33 GMT Не на трехдюймовом, а на нормальном мониторе. Потому что, пока 20-и мегапиксельный файл на четыре 16-битных канала загрузится, пока из оригинального формата сгенерится тривосьмибитовый RGB для подачи в видеокарту, пройдет куча времени, а мы желаем листать отснятое без ощущаемых задержек в каталогах ФС с сотнями и более фото. Лично я могу с двухчасовой прогулки с детьми принести сотни три фото, которые нужно быстро просмотреть и существенно проредить&#184; оставив дюжину, максимум полторы. Вот как раз для этого в RAW'ах (которые есть IFF) содержится чанк с джейпегом. <br> https://www.opennet.ru/openforum/vsluhforumID3/133309.html#198 Wed, 10 Apr 2024 08:58:42 GMT webp прекрасно зашли<br> https://www.opennet.ru/openforum/vsluhforumID3/133309.html#197 Tue, 09 Apr 2024 19:54:56 GMT в то время как обычный даже многопоточность не умеет и в принципе заброшен,<br>ведь в гугле занимаются всем подряд и бросают без сожаления, хотя некоторые наработки интересны. Возможно и JPEGLI ждет та же судьба<br> https://www.opennet.ru/openforum/vsluhforumID3/133309.html#196 Tue, 09 Apr 2024 00:49:30 GMT Как правильно использовать эти утилиты?<br>Я решил проверить это на фотографиях и сканах документов. <br>Из формата png конвертировал в jpeg. Был удивлен, что у меня после обработки libjpeg-62 файлы имеют меньший объем, чем после сжатия с помощью данной библиотеки от гугла. Это касается практически всех проверенных файлов.<br>Ожидаемого результата не достиг.<br> https://www.opennet.ru/openforum/vsluhforumID3/133309.html#195 Mon, 08 Apr 2024 19:29:51 GMT &gt;PS: гусля час пыхтел сожрав 12 гигов памяти<br><br>Просто надо было guetzli-cuda-opencl собирать и запускать, она достаточно быстро работает.<br> https://www.opennet.ru/openforum/vsluhforumID3/133309.html#194 Mon, 08 Apr 2024 14:24:27 GMT на тех размерах что тестировал, артефактов нет или они незаметны без увеличения, а вот потеря деталей на новых алгоритмах очень сильно заметна, картинка получается "мертвая", пластиковая, так мало того, еще и выходной файл больше получался чем у прошлого моего энкодера на 10-20%, а иначе еще больше несоотвествий с оригиналом и проигрыш предыдущему энкодеру<br><br>так что очень советую тестировать самому, а не хайп ловить, энкодер неплох, но есть лучше<br> https://www.opennet.ru/openforum/vsluhforumID3/133309.html#193 Sun, 07 Apr 2024 12:11:14 GMT &gt; На жирном контенте несколько тайлов которые жуются независимо сильной погоды не делают, но некие лимиты есть.<br><br>Но я не про тайлы (независимые части кадра для распараллеливания), а про "чанки", про видео, нарезанное по некоторым кадрам - по некоторым переходам между сценами. Если целиться на определённое качество, а не определённый битрейт, то особых проблем быть не должно. Может, есть смысл в гипотетической конструкции типа "2-й проход - параллельно по чанкам, 1-й - по всему видео, файл со статистикой как-то разрезать", но до такого никто не доходил.<br><br>&gt; Однако при убогом формате потока еще и дополнительно нагнуть...<br><br>Я понимаю, что твоя вера сильна, но этот приём принят при кодировании не в H.265, а в гуглокодеках, из-за того, что они плохо параллелятся.<br> https://www.opennet.ru/openforum/vsluhforumID3/133309.html#192 Sun, 07 Apr 2024 11:45:52 GMT Всё-таки первый WebP умеет в RGB+lossless и этот режим прикручен отдельно как раз потому что с I-фреймом от VP8 так бы не получилось. Про lossless-режим в первом WebP говорили за 10 лет до WebP2:<br>https://blog.chromium.org/2011/11/lossless-and-transparency-encoding-in.html<br><br>&gt; PNG вообще не замена JPG и насколько JXL хорошо дружит с line <br>&gt; art и способен в его lossless представление с минимальным размером и <br>&gt; без артефактов - это мы еще будем посмотреть.<br><br>Но к чему это? Вот сравнимые кодеки:<br>JPG =&gt; lossy WebP =&gt; lossy JXL<br>PNG =&gt; lossless WebP =&gt; lossless JXL<br><br>Lossless-представление с артефактами - всё-таки оксюморон.<br> https://www.opennet.ru/openforum/vsluhforumID3/133309.html#191 Sun, 07 Apr 2024 11:37:26 GMT Но тебя перераскукожило до ошибок. С обсуждаемой проприетарью optipng сравнить не можешь, но отвечаешь; свободный fhanau/ECT тоже внимания заслуживает. WebP2 у гугла до сих пор называется "WebP 2: experimental successor" и в сравнении по ссылке с реддита обе версии протестированы же.<br><br>&gt; Ну просто не в обиду ISO но их рабочая группа по видео - себя дискредитировала в хлам. Видимо в целом индустрия не очень доверяет и этой группе, хоть они и другие.<br><br>Эта в целом индустрия называется Google и доверяет, конечно, своим WebP, WebP2, AVIF, AVIF@AV2. Но Google ещё, видимо, самодискредитацией занимается, принимая участие в разработке JXL.<br>