https://opennet.ru/openforum/vsluhforumID3/130721.html Компания Apple включила по умолчанию в бета-версии браузера Safari 17 и движке WebKit поддержку формата изображений JPEG XL, от поддержки которого в Chrome в прошлом году отказалась компания Google. В Firefox поддержка формата JPEG XL доступна в ночных сборках (включается через image.jxl.enabled = true в about:config), но Mozilla пока сохраняет нейтральную позицию в вопросе продвижения этого формата...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59276<br> https://opennet.ru/openforum/vsluhforumID3/130721.html#147 Fri, 16 Jun 2023 14:34:50 GMT &gt;А тут прикиньте - транскодить не надо будет каждому клиенту (умножайте на количество клиентов например у гугла). Один раз перегнать надо только. Экономия места, экономия ширины канала, экономия процессорного времени. Берёте гугл как пример и представляете экономию ресурсов (и денег).<br><br>Оно и сейчас так происходит &#8212; перекодированные изображения кэшируются, конечно; их не перекодируют при каждом запросе. Проблема в том, что пока таких лосси форматов нужно больше одного, но если победит условный AVIF или JXL, то он и будет один, пока не появится следующее поколение форматов (а оно неизбежно появится) &#8212; не важно кто, среднестатистического пользователя устроит любой, потому что он не разглядывает пиксели.<br><br>&gt;Про редкие случаи - это вы щас , например, про любое изображение в инете, например, с мелким текстом? Громкое заявление.<br>&gt;Просто для примера: логотип опеннета из шапки сконверченный в jxl на 25% меньше становится. Без потери качества. Отмасштабируйте эффект какую-нибудь соцсеточку или фотохостин https://opennet.ru/openforum/vsluhforumID3/130721.html#146 Fri, 16 Jun 2023 14:21:50 GMT &gt;Вы пытаетесь сказать, что в интернете не особо-то и нужен формат изображений, который лучше JPG, PNG, GIF и по сжатию и по совокупности?<br><br>Давайте остановимся на том, что из моей аргументации в ответ будет только : ха-ха-ха.<br>На такое даже отвечать серьезно нет смысла. Гугль вот считает иначе - там вон собственный WebP изобретали только ради этого, а вы тут вердикт вынесли: "нинужон". На этом лучше остановиться.<br><br>Вы передёргиваете моё высказывание. Я говорил лишь про лосслесс форматы &#8212; они действительно не очень нужны в вебе, где есть векторная графика и &lt;video&gt;. Расцвет GIF и PNG пришёлся на те времена, когда ничего этого в вебе не было. Сейчас это есть повсеместно. <br><br>Насчёт JPG &#8212; да, ему нужна замена, но для этого не нужен уберформат, который умеет всё, включая то, что не нужно, а нужен только дешёвый в реализации формат, которого будет достаточно. Гугл так решил. <br> https://opennet.ru/openforum/vsluhforumID3/130721.html#145 Fri, 16 Jun 2023 14:15:49 GMT &gt;В рамках текущей дискуссии - вполне себе играет. Вы ведь на этом аргументе строите свою позицию.<br><br>Нет, не играет &#8212; пожалуйста, не сводите разговор к обсуждении моей объективности, потому что если вы считаете, что объективность существует, то это свидетельство удивительной наивности. А если мы принимаем, что её не существует, то и обсуждать такие вопросы бессмысленно.<br><br>Моя позиция &#8212; это предположение, которой пытается объяснить, почему Гугл отказался от JXL. В его пользу говорит то, что сравнительные тесты, которые они использовали основывались на MS-SSIM. SSIM &#8212; это тоже старая метрика, по которой написано много peer-reviewed статей, чего, повторюсь, по Butteraugli нет. Более ничего мне прошу не приписывать.<br><br>&gt; Дело не в авторстве, просто есть метрика, которая существует давно и с использованием которой написаны горы научных статей и есть Butteraugli, который &#171;хороший, потому что&#8230; потому что сделали в Гугле&#187; (хотя ирония судьбы сами знаете какая).<br>&gt;Чаще всег овсё ровн https://opennet.ru/openforum/vsluhforumID3/130721.html#144 Fri, 16 Jun 2023 12:56:29 GMT &gt; Онлайн сервисы уже очень давно транскодят JPG в новые лосси форматы для отдачи клиентам<br><br>А тут прикиньте - транскодить не надо будет каждому клиенту (умножайте на количество клиентов например у гугла). Один раз перегнать надо только. Экономия места, экономия ширины канала, экономия процессорного времени. Берёте гугл как пример и представляете экономию ресурсов (и денег).<br><br>&gt; Для тех редких случаев, когда фото надо передать клиенту без изменений, поддержка браузером конечного формата, по большому счёту, не требуется.<br><br>Про редкие случаи - это вы щас , например, про любое изображение в инете, например, с мелким текстом? Громкое заявление.<br>Просто для примера: логотип опеннета из шапки сконверченный в jxl на 25% меньше становится. Без потери качества. Отмасштабируйте эффект какую-нибудь соцсеточку или фотохостинг.<br> https://opennet.ru/openforum/vsluhforumID3/130721.html#143 Fri, 16 Jun 2023 12:39:35 GMT &gt; Мне кажется, что JXL силён в том, что в интернете особо и не нужно.<br><br>Вы пытаетесь сказать, что в интернете не особо-то и нужен формат изображений, который лучше JPG, PNG, GIF и по сжатию и по совокупности?<br>Давайте остановимся на том, что из моей аргументации в ответ будет только : ха-ха-ха.<br>На такое даже отвечать серьезно нет смысла. Гугль вот считает иначе - там вон собственный WebP изобретали только ради этого, а вы тут вердикт вынесли: "нинужон". На этом лучше остановиться.<br> https://opennet.ru/openforum/vsluhforumID3/130721.html#142 Fri, 16 Jun 2023 12:31:47 GMT &gt; Я не соглашусь, интернет всё ещё с нами &#8212; размеры изображений и других загружаемых ресурсов растут, а кое-где всё ещё ловится только EDGE. Иногда приходится впихивать в жёсткий лимит.<br><br>И много вы знаете рельаных сценариев в инете, где картинки жмут специально под "а вдруг там только EDGE"? Такое, конечно, бывает в редких случаях, типа полярники и т.п. но это не массовые сценарии. Повторюсь: такие сценарии в дикой среде редкий.<br><br>&gt; Моя (не)объективность тут никакой роли не играет.<br><br>В рамках текущей дискуссии - вполне себе играет. Вы ведь на этом аргументе строите свою позицию.<br><br><br>&gt; Дело не в авторстве, просто есть метрика, которая существует давно и с использованием которой написаны горы научных статей и есть Butteraugli, который &#171;хороший, потому что&#8230; потому что сделали в Гугле&#187; (хотя ирония судьбы сами знаете какая).<br><br>Ага... Деды тыще лет без этих ваших инторнетов жили и ничаво...<br>Второй раз вам говорю: тот факт, что PSNR долго использовался сам по себе не является аргументов в https://opennet.ru/openforum/vsluhforumID3/130721.html#141 Thu, 15 Jun 2023 21:28:23 GMT Пардон, нашёл это сравнение и там речь про MS-SSIM, а не PSNR. Это не так уж и важно, так как MS-SSIM &#8212; тоже старая метрика, хорошо исследованная в академических источниках. <br> https://opennet.ru/openforum/vsluhforumID3/130721.html#140 Thu, 15 Jun 2023 21:05:34 GMT &gt;Как метрика он достаточно паршивый.<br><br>Вопрос немного не об этом. Непонятно почему я должен принимать то, что Butteraugli непаршивый. Этих метрик полным полно было, что мешало взять какую-то готовую от сторонних авторов, а не придумывать свою? Откуда я могу быть уверен, что оптимизация на эту метрику, чьи свойства (в отличие от имеющегося PSNR, по которому куча peer-reviewed статей написано) не особенно хорошо изучены и описаны &#8212; это правильно? Почему в Гугле посмотрели на этот Butteraugli и решили, что на выбор того, какие кодеки оставить, а какие выкинуть, он влиять не должен, а должен влиять PSNR, который использовался в том самом отчёте, на основании которого было принято решение выкинуть JXL из хрома?<br> https://opennet.ru/openforum/vsluhforumID3/130721.html#139 Thu, 15 Jun 2023 20:59:42 GMT &gt; Ну и чё, кто-нибудь уже засунул наверно, да? Неужели нет, а почему?<br><br>Может кто и засунули. Основная трабла с TIFF - это поддержка софтом ВСЕХ фич. Это как с AVI, можно скачать мувик, а там что угодно. Может xvid, а может и cinepak какой-нибудь. Потому что .avi мало что говорит что за кодек внутри. Да любой, даже h.264 в принципе можно.<br><br>Аналогично - никогда не видали AV1 сунутый в BMFF? Это такое суперкомбо, когда AV1 затолкан в контейнер известный большинству как "mp4". Ну вот такой вот "mp4" - который внутрях AV1. Это кстати в ISO'шный стандарт на BMFF вроде бы даже уже и внесли.<br><br>&gt; У каждого вендора свой форк этой дряни, а сжатия не завезли.<br><br>Там чертова куча сжатий как раз. Просто из-за форков не все программы умеют все фичи. Если JXL станет популярным, его туда <br> <br>&gt; Ещё внезапно окажется, что это раздутый контейнер.<br><br>Сам по себе ему не с чего быть раздутым. Хотя если напихать всяких EXIF и XMP расписывающих все вплоть до числа пятен на солнце в момент съемки, даже мелкая картинка может стать н