The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Google представил библиотеку jpegli для более эффективного сжатия JPEG-изрбражений "
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Google представил библиотеку jpegli для более эффективного сжатия JPEG-изрбражений "  +/
Сообщение от opennews (??), 04-Апр-24, 11:50 
Компания Google представила новую открытую библиотеку jpegli с реализацией кодировщика и декодировщика изображений в формате JPEG. Библиотека включает дополнительные оптимизации для повышения эффективности кодирования, позволяющие на 35% увеличить степень сжатия высококачественных изображений, по сравнению с традиционными кодеками JPEG. В сравнении с  libjpeg-turbo  библиотека jpegli  позволяет добиться аналогичного уровня качества при снижении битрейта на 32%. На уровне API и ABI библиотека полностью совместима с  libjpeg62 и может применяться для её прозрачной замены. Код библиотеки написан на языке С++ и распространяется под лицензией BSD...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60921

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Google представил библиотеку jpegli для более эффективного с..."  –7 +/
Сообщение от Аноним (1), 04-Апр-24, 11:50 
Ни webp, ни avif, ни jpeg-xl до сих пор не зашли... Удивительно, почему сразу не могли улучшать обычный jpeg, с обратной совместимостью?
Ответить | Правка | Наверх | Cообщить модератору

4. "Google представил библиотеку jpegli для более эффективного с..."  –6 +/
Сообщение от Аноним (4), 04-Апр-24, 11:59 
Так потому и улучшают что альтернативно одарённые навязать не удаётся .
Ответить | Правка | Наверх | Cообщить модератору

30. "Google представил библиотеку jpegli для более эффективного с..."  +5 +/
Сообщение от Аноним (30), 04-Апр-24, 13:13 
> Так потому и улучшают что альтернативно одарённые навязать не удаётся .

Софт порой инерционен с поддержкой. Попробуйте анимированый webp вообще открыть чем?! Кроме хрома/файрфокса, конечно. И как, получается? Даже с анимацией? И всех версий webp? А чтоб еще и отредактировать анимаху и разобрать на фреймы - слабо?! Не, это даже ffmpeg не сожрет с его более 9000 форматов. Вот скроить это может - но билет в одну сторону! А потом это только в хроме и лисе и смотреть. И все, по сути. Write-only формат. Оказывается так можно было.

Ответить | Правка | Наверх | Cообщить модератору

32. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от Аноним (32), 04-Апр-24, 13:19 
В telegram же, ну
Ответить | Правка | Наверх | Cообщить модератору

45. "Google представил библиотеку jpegli для более эффективного с..."  –2 +/
Сообщение от 12yoexpert (ok), 04-Апр-24, 13:52 
это та социалочка, которая хранит переписку в открытом виде?
Ответить | Правка | Наверх | Cообщить модератору

63. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (63), 04-Апр-24, 15:55 
Сможешь прочитать мою переписку, раз она в открытом виде?
Ответить | Правка | Наверх | Cообщить модератору

66. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от 12yoexpert (ok), 04-Апр-24, 16:42 
паша сможет и фсб. тебе мало?
Ответить | Правка | Наверх | Cообщить модератору

80. "Google представил библиотеку jpegli для более эффективного с..."  –3 +/
Сообщение от Аноним (80), 04-Апр-24, 18:28 
В телеграмме ты сам можешь управлять уровнем приватности. Можешь пользоваться обычными чатами и иметь связанные с этим бонусы в виде сохранения истории, нормальной синхронизации между устройствами, возможности докачивания вложений и прочего.

Или можешь пользоваться секретными чатами. Протокол открыт, клиенты опенсорсны. Был публичный конкурс с предложением его взломать с большими призовыми. Никто, вроде, приз так и не взял.

Ответить | Правка | Наверх | Cообщить модератору

83. "Google представил библиотеку jpegli для более эффективного с..."  +2 +/
Сообщение от балдымалдыбар (?), 04-Апр-24, 18:39 
>Протокол открыт

может, скажем ему?...

Ответить | Правка | Наверх | Cообщить модератору

93. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от Аноним (93), 04-Апр-24, 20:08 
Протокол открыт и это факт. Мне как-то коллега по работе уши прожужжал о его безопасности. Протокол то хорош, но большинство людей не настолько умны чтобы его использовать.
Более того, вы уверены что прям ФСБ работает с телеграм? Я думаю это все слухи, потому что он не контролируется американскими силовыми ведомствами. Но помнится в скором времени владелец там что-то про IPO говорил, вот тогда его и возьмут за финансовые жабры. И судя по вашей логике ответов, вот тогда он станет демократичным и пригодным для использования. Какие же это двойные стандарты!
Ответить | Правка | Наверх | Cообщить модератору

112. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 04-Апр-24, 23:36 
> Протокол открыт и это факт. Мне как-то коллега по работе уши прожужжал
> о его безопасности. Протокол то хорош, но большинство людей не настолько
> умны чтобы его использовать.

Протокол никак не помогает - юзеров данонят кореляцией тележного ID <-> номер телефона и пробитием далее телефона по утекшам базам. И вот чем вам поможет хоть какой протокол от этого, если факап - в той логике?

Для майоров есть даже комплекс автоматизирующий это, недавно как раз засветился в закупках, но такой уровень атаки - даже и васян сможет, если захочет. Большая часть юзерей забывает скрыть номер телефона - за что и огребает сполна, наслушавшись булшита про "безопасный месенжер" - и сев на десяток лет и более.

Ответить | Правка | Наверх | Cообщить модератору

127. Скрыто модератором  +/
Сообщение от Аноним (127), 05-Апр-24, 00:47 
Ответить | Правка | Наверх | Cообщить модератору

136. Скрыто модератором  +/
Сообщение от Аноним (-), 05-Апр-24, 04:48 
Ответить | Правка | Наверх | Cообщить модератору

152. Скрыто модератором  +/
Сообщение от Аноним (127), 05-Апр-24, 12:44 
Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

185. Скрыто модератором  +/
Сообщение от Аноним (-), 07-Апр-24, 03:10 
Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

128. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (127), 05-Апр-24, 00:48 
Впрочем, как обычно, началось передёргивание. Кого-то сажали не за посты, а ЗА ПЕРЕПИСКУ?
Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

137. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 04:55 
> Впрочем, как обычно, началось передёргивание. Кого-то сажали не за посты, а ЗА ПЕРЕПИСКУ?

Легко. Примеры можно найти - вот прямо в той же телеге. Вооооон там господа прям с фоточками и скриншотиками показывают отловленных экземплярчиков - и что именно им инкриминируется. А чо, удобно же, подгрузка истории и все такое... осталось еще автоматические скриншоты запилить - и отсылку на товарищмайорский канал, чего майоры на кучу кликов время то тратят?! Уже б генералами были давно.

Ответить | Правка | Наверх | Cообщить модератору

85. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (85), 04-Апр-24, 19:14 
> В телеграмме ты сам можешь управлять уровнем приватности. Можешь пользоваться Телеграмом, а можешь - не пользоваться. А если нет опции жить и не польжоваться - то можешь и не жить.

Пофиксил.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

110. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 04-Апр-24, 23:30 
> В телеграмме ты сам можешь управлять уровнем приватности. Можешь пользоваться обычными
> чатами и иметь связанные с этим бонусы в виде сохранения истории,
> нормальной синхронизации между устройствами, возможности докачивания вложений и прочего.

Судя по количеству посаженных телеграмеров - с телеграмом ты можешь сам сесть на десять лет. Влегкую. А управление приватностью там в основном путем засовывания языка в ... и сидения тихо, судя по тому как телеграмеров пакуют в РАЗНЫХ юрисдикциях. Тенденция однако.

> Или можешь пользоваться секретными чатами. Протокол открыт, клиенты опенсорсны.
> Был публичный конкурс с предложением его взломать с большими призовыми. Никто, вроде,
> приз так и не взял.

А оно на практике нахрен не надо. Майор просто радостно загрузит историю. Не с девайса, так с сервера самодурова на соседнем девайсе. Синхра девайсов. Удобно же!

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

114. "Google представил библиотеку jpegli для более эффективного с..."  +2 +/
Сообщение от Аноним (127), 04-Апр-24, 23:54 
— покупаем симку у опсоса, подконтрольного майору;
— регистрируемся с этим номером в мессенджере;
— получаем срок за пост… кто виноват? ну конечно, мессенджер.
Ответить | Правка | Наверх | Cообщить модератору

119. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 00:26 
> — покупаем симку у опсоса, подконтрольного майору;
> — регистрируемся с этим номером в мессенджере;
> — получаем срок за пост… кто виноват? ну конечно, мессенджер.

Внезапно, да. Он это все затребовал от своих юзерей. Это он создал эту кореляцию. Он ее хранил. И же и слил ЭТО всем посторонним рожам, оптом, по дефолту! Так что - виноват. По полной программе. Эталонное создание юзерям подстав.

С таким же успехом - можно говорить что если вас размотало на мине на дорожке, виноваты - вы, потому что пошли гулять без миноискателя. А могли бы обучиться саперному делу и убрать ее с дорожки, "как нормальный человев". Что за лох такой - без миноискателя и саперного костюма?!

Ответить | Правка | Наверх | Cообщить модератору

125. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (127), 05-Апр-24, 00:45 
Если вас размотало на минном поле — да, сами виноваты.
Ответить | Правка | Наверх | Cообщить модератору

138. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (-), 05-Апр-24, 04:58 
> Если вас размотало на минном поле — да, сами виноваты.

Так паша самодуров из каждого рупора орал что все проверено, все безопасно, навесил табличку - мин нет. А виноват после этого пользователь. Логично, чо.

Ответить | Правка | Наверх | Cообщить модератору

120. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (120), 05-Апр-24, 00:32 
Ага, Паша так взял и дал ФСБ доступ, он не просто так отсюда уехал после истории с ВКонтакте. ФСБ последние кто сможет получить доступ к переписка телеграмма.
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

139. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 05:01 
> Ага, Паша так взял и дал ФСБ доступ, он не просто так
> отсюда уехал после истории с ВКонтакте. ФСБ последние кто сможет получить
> доступ к переписка телеграмма.

Это совершенно не помешало им провести закупки комплекса по данону телеграмеров - который маппит тележный ID в номер телефона ибо по дефолту это вывешено всей толпе, и нагрести эти данные оптом не вопрос. А потом они по утекшим у операторов сотовым базам - всей толпой лукапают без всяких глупых запросов операторам что сие за тушки. Удобно однако!

Вот вам и вся безопасность от паши самодурова. Все что о ней надо было знать. А ФСБ что, если оно вас за жабры возьмет, тут вот как раз история с сервака и подгрузитяс очень кстати. А после небольшого массажа почек - и всему отделу засинхронизируется.

Ответить | Правка | Наверх | Cообщить модератору

148. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от YetAnotherOnanym (ok), 05-Апр-24, 10:16 
> паша сможет и фсб

И что за проблема? Шифруешь текстовый файлик openssl'ем и отправляешь файлом, или шифруешь сообщение, тут же кодируешь его в base64 и отправляешь как текст.
Собеседник должен уметь в openssl? Ну дык, либо ты играешь в эти игры, и тогда ты играешь всерьёз, в том числе выбирая корреспондентов, с которыми можно вести тайные дела, либо не играешь вообще.

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

111. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 04-Апр-24, 23:32 
> В telegram же, ну

А что, он таки умеет анимаху на фреймы разбирать? Или что с ней там делать предлагается? Пойнт в том что после конверсии в этот формат - вы вообще ничего дальше с этим сделать особо уже не сможете. А постить ее можно и вебе.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

62. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (63), 04-Апр-24, 15:54 
> разобрать на фреймы - слабо?! Не, это даже ffmpeg не сожрет

Imagemagick может.
> If you have an old version of imagemagick the command is convert instead of magick

https://superuser.com/questions/1688850/how-do-i-convert-ani...
А потом я собираю фреймы в mp4 через ffmpeg. Получается скрипт по перекодированию анимированного webp в mp4.
Схема конечно муторнее, чем обычная ffmpeg команда перекодирования gif в mp4, но если надо, то сделать можно.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

91. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (91), 04-Апр-24, 20:07 
> Попробуйте анимированый webp вообще открыть чем?!

Viewnior (gtk2) и Loupe (gtk4) анимированный WEBP открывают, как минимум, уже года два.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

113. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 04-Апр-24, 23:51 
>> Попробуйте анимированый webp вообще открыть чем?!
> Viewnior (gtk2) и Loupe (gtk4) анимированный WEBP открывают, как минимум, уже года два.

Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть. А сколько лет этому формату, не напомните? Я уже со счета сбился.

...но отредактировать то эту байду по человечески, с нормальным workflow вы не сможете, и даже просто конвертнуть в что-то другое придется еще поплясать. Воооон там какой-то креативщик с imagemagic'ом и потом ffmpeg'ом. Вот такое вот хреновое лето^W конверсие в мувик получается. Уровень поддержки формата в софте!

И с каким-нибудь Jpeg XL врядли сильно лучше. А с хрена ли?

Ответить | Правка | Наверх | Cообщить модератору

115. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (127), 04-Апр-24, 23:57 
> Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть.

IrfanView (извините, что я с оффтопиком, да?) уже шесть лет умеет.

Ответить | Правка | Наверх | Cообщить модератору

121. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 00:33 
>> Зашибись! Целые 2 года - 2 программы про которые я впервые слышу. Чисто посмотреть.
> IrfanView (извините, что я с оффтопиком, да?) уже шесть лет умеет.

И там прямо анимации, v2 формата и проч норм работает во всех комбо? Но посмотреть то можно и в браузере накрайняк. А вот разобрать допустим на фреймы или в другой формат это переделать... ээээ... :))

Ответить | Правка | Наверх | Cообщить модератору

124. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (127), 05-Апр-24, 00:44 
Ещё я для такой мелочёвки софт искать буду. Давным-давно это через ezgif делается.
Ответить | Правка | Наверх | Cообщить модератору

179. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (179), 06-Апр-24, 15:33 
> А сколько лет этому формату, не напомните?

Не интересовался. Но когда столкнулся с изображениями этого формата, мне было их чем открыть.

> отредактировать

Там imagmagick уже предлагали.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

5. "Google представил библиотеку jpegli для более эффективного с..."  +8 +/
Сообщение от DZgas (?), 04-Апр-24, 12:00 
Потому что сначала надо было придумать эти avif webp jpeg XL что бы брать от туда технологии, которые можно применить в jpeg
Точно так же как с AQ-3 из HEVC в AVC
Или та же технология butteraugli придуманная для jpeg XL и далее используемая в другом гугл jpeg кодировщике guetzli
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

8. "Google представил библиотеку jpegli для более эффективного с..."  –4 +/
Сообщение от Аноним (4), 04-Апр-24, 12:04 
Фичи можно было изначально для джпега разрабатывать , без прокладок и памперсов .
Ответить | Правка | Наверх | Cообщить модератору

24. "Google представил библиотеку jpegli для более эффективного с..."  +4 +/
Сообщение от Аноним (24), 04-Апр-24, 13:00 
> без прокладок и памперсов

А как ты тогда тут комментить будешь?

Ответить | Правка | Наверх | Cообщить модератору

13. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (1), 04-Апр-24, 12:16 
> Точно так же как с AQ-3 из HEVC в AVC

Можно подробнее? В интернете мало инфы.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

69. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от DZgas (?), 04-Апр-24, 17:13 
инфы нет вообще, только документация и сами кодеки x264 x265 с всвроенными инструкциями. (в интернете реально просто не существует описания некоторыех параметров кодеков, например Deadzone в x264. Единственное описание на какой то мёртвой вики, на которую ссылается весь интернет, это дизинформация.. такие дела, тыкай сам.)
AQ-3 в AVC позволяет кодировать тёмные гардиенты (в темноте) без артефактов блочности
Ответить | Правка | Наверх | Cообщить модератору

92. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 04-Апр-24, 20:07 
> в интернете реально просто не существует описания некоторыех параметров кодеков, например Deadzone в x264

Да ну, про него говорят, но только с высоты двадцати лет кодекостроения и двадцати лет квантования DCT-коэффициентов, для тех, кто знает всю предысторию. Как для непосвящённого, параметр вроде означает "не лезь, оно тебя сожрёт".

В целом: "deadzone quantizer ... [какие-то нехорошие слова, дублирующие картинку]. It has the benefit during compression of ensuring that noisy low-level signals are not allocated bits unnecessarily" - https://www.sciencedirect.com/topics/engineering/quantizer

Разговор о том, как его отменяют другие параметры. По крайней мере, один параметр. По крайней мере, в 2006-2007:
https://forum.doom9.org/showthread.php?p=883221#post883221
https://forum.doom9.org/showthread.php?p=1072878#post1072878

Ответить | Правка | Наверх | Cообщить модератору

97. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 04-Апр-24, 20:19 
http://akuvian.org/src/x264/overview_x264_v8_5.pdf

Судя и по этому, --trellis 1 (пресет <=faster) или 2 (пресет <=slow) заменяет deadzone quantizer с его настройками (--deadzone-inter --deadzone-intra), поэтому ими не стоит забивать голову.

Ответить | Правка | Наверх | Cообщить модератору

107. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от DZgas (?), 04-Апр-24, 21:54 
Короче, алгоритм уменьшает коэффициенты, мыля картинку. Я это к чему говорю, в 2024 году можно обойтись без него, deadzone-inter=0 deadzone-intra=0 trellis=0
заместо этого алгоритма,
Используем пре-фильтр hqdn3d=luma_spatial=1:chroma_spatial=1:chroma_tmp=3:luma_tmp=3
либо намного более сложный nlmeans=3:7:7:5:5
параметры какие хочешь... к чему я это.
На тестах которые я проводил. AVC на разрешениях ниже чем 720p и при идентичном качестве картинки, работает быстрее и эффективнее чем HEVC, без проблем распараеливаясь на 12+ потоков (суммарно при 100%). Такие дела. (разрешения выше 720p не пригодны для avc. HEVC AV1 там это всё.)
Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

118. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от Аноним (118), 05-Апр-24, 00:14 
AVC абсолютно на любом разрешении и любых параметрах дно, не спорь. Во всяком случае, я могу утверждать это про x264. А вот x265 терпимо и на sd и на hd+. Но там это, новый босс качалки пришёл, h266 лишён буквально всех недостатков недокодеков вроде vp9/av1 и совершенно идеален.

>без проблем распараеливаясь

не без проблем, если ты кодируешь avc больше чем в ~4 потока на fullhd качество кодирования улетает в пол.

Ответить | Правка | Наверх | Cообщить модератору

142. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 06:16 
> AVC абсолютно на любом разрешении и любых параметрах дно, не спорь. Во
> всяком случае, я могу утверждать это про x264. А вот x265
> терпимо и на sd и на hd+. Но там это, новый
> босс качалки пришёл, h266 лишён буквально всех недостатков недокодеков вроде vp9/av1
> и совершенно идеален.

А, вот почему ISO так судорожно кодеки строгает? А чего у вашего босса поджилки трясутся и из носа сопля свисает? Неужто получше никого не нашли?! И вот это чмище теперь попробует устроить патентный рэкет всему раёну? :)

Ответить | Правка | Наверх | Cообщить модератору

145. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 05-Апр-24, 09:08 
Так реально vvc даёт совершенно минимальный битрейт (и не раздувает его на пустом месте как vp9/av1, толку от качества, если битрейт улетает в небеса, а без битрейта сыпет жуткими глитчами), не размывает картинку так сильно (av1 даже на медленнейшем качестве и неограниченном битрейте более мыльный, чем быстрый vvc), лучше держит края. И то, что av1 противопоставляют в лучшем случае hevc (а чаще всего avc) достаточно показательно. Победитель уже известен.
Ответить | Правка | Наверх | Cообщить модератору

186. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 07-Апр-24, 03:33 
> Так реально vvc даёт совершенно минимальный битрейт (и не раздувает его на
> пустом месте как vp9/av1,

Это все - абстрактные блабла. И вот что-что а AV1 в раздувании битрейта я бы уж точно не обвинил, а svt-av1 лично мне так очень понравился.

Да и VP9 субъективно - где-то на уровне x265 по битрейт-качество. При том что в массы пошел раньше. Одна из причин по которым H.265 непонятное бессмысленное УГ, с более плохими условиями использования, недопилеными реализациями, злыми условиями лицензинга, а с пришествием 266 это заодно еще - кидок тех кто все же развелся и заплатил, вынести лохов в obsolete с такой скоростью это круто придумано! А теперь их попытаются отрекетировать еще раз, объяснив что надо доплатить? Удачи! Думаю они будут в восторге, а у AOM чего может прибавиться участников :). Так можно дожать до этого даже и броадкомы с квалкомами пожалуй.

> толку от качества, если битрейт улетает в небеса,

У лично меня в AV1 и VP9 ничего никуда не улетает. Если вы не смогли в параметры кодирования - это не их баг.

> а без битрейта сыпет жуткими глитчами), не размывает картинку так
> сильно (av1 даже на медленнейшем качестве и неограниченном битрейте более мыльный,

Красивые сказки. Только вот у меня свое мнение о фраунхофере и софте который они изрыгают. Эти господа хотят много денег - и мало делать. Зачем они вообще с такими соотношениями нужны я не понимаю.

Для сравнения AOM создал - целую экосистему next gen. Когда даже хардварный декодер можно получить на довольно халявных условиях. И генерится это все - прямо из сорцов libaom, через high-level synthesis. Попробуйте с фраунхофера и прочих жуликов такое получить?! В AOM и вписались интел/амд/нвидия/арм и куча имен помельче. И теперь вот это все будет - практически во всех новых разработках. А вон те что предложут? А, рэкет за очередную пулю из непонятного материала, с почетным правом сделать ловомой объем самим? А оно точно в таком виде надо? :)

> чем быстрый vvc), лучше держит края. И то, что av1 противопоставляют
> в лучшем случае hevc (а чаще всего avc) достаточно показательно. Победитель
> уже известен.

HEVC едва-едва рубается с древним VP9, примерно на равных. Куды этой пакости до AV1, у него половины эффективных тулсов уменьшения битрейта на уровне формата потока нет. Отсталый прямо на момент дизайна формат. Потому исо и страгает новые в истеричном темпе, контроль над ситуацией утекает из их кривых лапок.

Ответить | Правка | Наверх | Cообщить модератору

190. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 07-Апр-24, 09:32 
Это всё хорошо, но hevc абсолютно повсюду уже 12 лет. Это вечность. И никуда уходить не собирается, это до сих пор единственный вариант для качественного контента до повсеместного распространения декодеров h266 ещё несколько лет пройдёт. А ты, наверное, хотел как с mpeg2? Так он лет 10 использовался, bd заменил dvd и до-свидания.
Ответить | Правка | Наверх | Cообщить модератору

123. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 05-Апр-24, 00:37 
Но это ведь не замена, это фильтры для удаления такого-то шума в таких-то исходниках. Плюс решение не тюнить качество/размер_файла до посинения.

Хз, должен ли deadzone с его обнулением коэффициентов бить именно по высоким частотам. Trellis должен, но против этого предлагается тюнить psy-rd'ы.

Как фанаты этого дела выбирают под себя глубину крольчьей норы?.. Субъективная оптимизация* упирается в человеческие возможности - человека хватит на отсматривание нескольких десятков наборов настроек. Объективная оптимизация по хорошей метрике вроде VMAF или SSIMULACRA2 упирается в несовершенство метрики, да и крутят на практике только один параметр: crf или qp для отрезка видео[1][2]. Что как бы намекает на рецепт хорошего качества - перейти на самый новый кодек (независимо от разрешения), а с его тормознутостью будет уже не до тестирования кучи настроек.

> без проблем распараеливаясь на 12+ потоков

А если x265 с проблемами, то можно пойти по пути гуглокодеков - смириться с плохим распараллеливанием на уровне энкодера и запускать их одновременно, скармливая им по куску из видео (заранее разрезать на сцены) (всё это кое-как автоматизировали в av1an).

* оптимизация в математическом смысле - как максимизация функции типа визуальное_качество(настройка_1, настройка_2, ...)

[1] https://netflixtechblog.com/dynamic-optimizer-a-perceptual-v...
[2] https://github.com/alexheretic/ab-av1

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

187. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 07-Апр-24, 04:16 
> А если x265 с проблемами, то можно пойти по пути гуглокодеков -
> смириться с плохим распараллеливанием на уровне энкодера и запускать их одновременно,
> скармливая им по куску из видео (заранее разрезать на сцены) (всё
> это кое-как автоматизировали в av1an).

На самом базовом уровне проблема примерно такая: анализ глобальной избыточности и еще ряд оптимизаций представления проседает от нарезки на тайлы. И чем больше тайлов тем хуже потери. На жирном контенте несколько тайлов которые жуются независимо сильной погоды не делают, но некие лимиты есть.

В случае h265 это впрочем не особая проблема - у этого крапа вообще нет толком глобальной коспенсации движения, CDEF и прочих продвинутостей - нельзя потерять то что у него никогда и не было. Однако при убогом формате потока еще и дополнительно нагнуть оптимизации кодирования спорное занятие.

Ответить | Правка | Наверх | Cообщить модератору

193. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 07-Апр-24, 15:11 
> На жирном контенте несколько тайлов которые жуются независимо сильной погоды не делают, но некие лимиты есть.

Но я не про тайлы (независимые части кадра для распараллеливания), а про "чанки", про видео, нарезанное по некоторым кадрам - по некоторым переходам между сценами. Если целиться на определённое качество, а не определённый битрейт, то особых проблем быть не должно. Может, есть смысл в гипотетической конструкции типа "2-й проход - параллельно по чанкам, 1-й - по всему видео, файл со статистикой как-то разрезать", но до такого никто не доходил.

> Однако при убогом формате потока еще и дополнительно нагнуть...

Я понимаю, что твоя вера сильна, но этот приём принят при кодировании не в H.265, а в гуглокодеках, из-за того, что они плохо параллелятся.

Ответить | Правка | Наверх | Cообщить модератору

10. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от нитгитлистер (?), 04-Апр-24, 12:10 
а разве только гугл причастна к разработке всех перечисленных вами форматов?
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

12. "Google представил библиотеку jpegli для более эффективного с..."  +3 +/
Сообщение от Аноним (127), 04-Апр-24, 12:15 
Почему сразу перешли на полупроводники, а не улучшали электронные лампы с обратной совместимостью?
Почему не взлетело — потому что не нужно уже. JPEG без цветовой субдискретизации и так покрывает 99% потребностей, а времена, когда размер картинок был так уж важен, прошли.
Впрочем, насчёт WEBP это зря. Его как раз гугл пропихнул.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

14. "Google представил библиотеку jpegli для более эффективного с..."  +3 +/
Сообщение от прохожий (?), 04-Апр-24, 12:22 
"времена, когда размер картинок был так уж важен, прошли"
Я что-то пропустил, или хранение данных резко подешевело?
Ответить | Правка | Наверх | Cообщить модератору

20. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 04-Апр-24, 12:44 
Да, подешевело.
Не так резко как хотелось бы, но с 2017 года примерно в 2 раза.
С 3 центов на гиг, до примерно 1.5

В 2005 average cost per gigabyte было 65 центов, а в 2000 вообще за гиг приходилось отдавать 12 баксов)

С другой стороны кол-во мегапикселей, телефонов с камерами и фотографий "я и моя сарная кошка" увеличилось, причем думаю не пропорцианально)

Ответить | Правка | Наверх | Cообщить модератору

22. "Google представил библиотеку jpegli для более эффективного с..."  +3 +/
Сообщение от Аноним (127), 04-Апр-24, 12:46 
Соцсеточки всё равно пережмут всё в хлам и уменьшат до пары мегапикселей.
Ответить | Правка | Наверх | Cообщить модератору

102. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (102), 04-Апр-24, 21:00 
Причем тут хранение, проблема в объемах передаваемых данных. А изображения, помимо огромного куска js кода, которая грузится в сингле пэдж аппликатион, одно из основных объемов по трафику.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

131. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (127), 05-Апр-24, 01:45 
Вы из какого года пишете? Основной объём трафика — это видео. Ну так о его ужатии как раз постоянно беспокоятся.
Ответить | Правка | Наверх | Cообщить модератору

116. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (127), 05-Апр-24, 00:00 
Как раз те, кто хранит гигантские объёмы контента (те же соцсети, например), от жпега отказываться не особо что-то спешат.
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

96. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (91), 04-Апр-24, 20:15 
WEBP умеет в сжатие без потерь (lossless) и на этом поле обыгрывает популярный PNG на 20-30%.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

134. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 04:41 
> WEBP умеет в сжатие без потерь (lossless) и на этом поле обыгрывает
> популярный PNG на 20-30%.

Не забыв при этом угробить цвета в скриншотах в хламину. Такой себе lossless, с subsampling'ом то.

Ответить | Правка | Наверх | Cообщить модератору

146. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 05-Апр-24, 09:17 
lossless WebP это по сути отдельный кодек, в нём нет chroma subsampling, он не YUV, он RGBA.

Но у него та же проблема, что и у lossy WebP - если уж слезать с jpg/png, то на jxl.

Ответить | Правка | Наверх | Cообщить модератору

188. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 07-Апр-24, 04:40 
> lossless WebP это по сути отдельный кодек, в нём нет chroma subsampling,
> он не YUV, он RGBA.

Изначально в первой версии это таки тупо I-frame от VP8. И тот чисто технически ничего кроме YUV с subsampling не умел. В версии 2 вроде попустило, но ее поддержка софтом - в еще большей ж... чем первой версии.

> Но у него та же проблема, что и у lossy WebP - если уж слезать с jpg/png, то на jxl.

PNG вообще не замена JPG и насколько JXL хорошо дружит с line art и способен в его lossless представление с минимальным размером и без артефактов - это мы еще будем посмотреть.

Ответить | Правка | Наверх | Cообщить модератору

192. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 07-Апр-24, 14:45 
Всё-таки первый WebP умеет в RGB+lossless и этот режим прикручен отдельно как раз потому что с I-фреймом от VP8 так бы не получилось. Про lossless-режим в первом WebP говорили за 10 лет до WebP2:
https://blog.chromium.org/2011/11/lossless-and-transparency-...

> PNG вообще не замена JPG и насколько JXL хорошо дружит с line
> art и способен в его lossless представление с минимальным размером и
> без артефактов - это мы еще будем посмотреть.

Но к чему это? Вот сравнимые кодеки:
JPG => lossy WebP => lossy JXL
PNG => lossless WebP => lossless JXL

Lossless-представление с артефактами - всё-таки оксюморон.

Ответить | Правка | Наверх | Cообщить модератору

46. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Барабас (-), 04-Апр-24, 13:53 
Знаю несколько сайтов, где выкладывали HD-фотки в обычном jpeg, а потом стали конвертить их в webp, качество стало заметно хуже. Не знаю, какой в этом смысл, фотки занимают не так много места, а webp портит качество.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

49. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (49), 04-Апр-24, 14:35 
Скилл ишью. webp жмет по качеству не хуже чем jpeg с таким же параметром качества. Видимо его выкрутили пониже, чтобы жать сильнее, от сайта с hd-фотками в jpeg другого не стоит ожидать.
Ответить | Правка | Наверх | Cообщить модератору

50. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 04-Апр-24, 14:45 
Вебп цвета прореживает.
Ответить | Правка | Наверх | Cообщить модератору

57. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Гость (??), 04-Апр-24, 15:21 
У WebP есть много опций сжатия, на которые большинство забивают, ограничиваясь одной цифрой "качества", которая работает совсем не как у jpeg.
Ответить | Правка | Наверх | Cообщить модератору

106. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 04-Апр-24, 21:29 
> У WebP есть много опций сжатия, на которые большинство забивают, ограничиваясь одной
> цифрой "качества", которая работает совсем не как у jpeg.

Примерно так же на самом деле. Ну, для хорошего результата я использую image-hint=picture alpha-filtering=2 alpha-quality=100 partition-limit=0 use-sharp-yuv=1

А вот pass=10 с target-psnr дают результат ощутимо хуже. В особенности, плохое качество получается без use-sharp-yuv, но, если тип контента не угадает, тоже может быть очень плохо

Только вебп не лучше жпег. Лестницы на градиентах, опять же (пожалуй, единственное, что лучше в av1 по сравнению с vp8/vp9).

Ответить | Правка | Наверх | Cообщить модератору

71. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (127), 04-Апр-24, 17:16 
Так жмёт-то он из JPEG. Любой супер-пупер лосси алгоритм на каждом шаге что-то да теряет.
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

81. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от namenotfound (?), 04-Апр-24, 18:36 
> а потом стали конвертить их в webp, качество стало заметно хуже

потому что дважды пережато

> фотки занимают не так много места

у тебя. а у них это сохранение денег на хранении и получении доступа к терабайтам данных

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

98. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (91), 04-Апр-24, 20:21 
> webp портит качество

Любое lossy-кодирование портит качество, включая JPEG. Пережимать лося в лося -- глупость. Нужно кодировать с одного RAW-источника в JPEG и WEBP, а затем сравнивать. Или не трогать лосей от греха. Не ходите на такие сайты, не пользуйтесь услугами идиотов, до добра это не доводит.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

104. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 04-Апр-24, 21:10 
Например, jpegxl убирает артефакты кодирования jpeg в режиме с потерями и делает картинку визуально чище и приятнее. Понятно, что из q60 скажем q95 уже не получится, но, если исходник больше q95, то иногда вполне применимо, судя по моему опыту. Лично я предпочитаю перепаковывать jpeg в jpegxl, как есть, без сжатия -- это быстрая операция, и позволяет сэкономить ~20-99.9%. А jpeg даже с качеством 100 уже слишком убитый файл, чтобы корёжить его дальше. Но если тебя не уважают и предоставили только файлы с потерями, то тут ничего не поделать.
Ответить | Правка | Наверх | Cообщить модератору

105. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 04-Апр-24, 21:19 
Кстати, если сравнивать jpegxl в режиме без потерь с типичным png, то, приняв размер файла png за 1, у jpegxl он будет 0.4 в среднем, и, кроме того он по-настоящему без потерь и не потеряет аттрибуты и экзотические цветовые пространства (png всё потеряет, да). Я не понимаю, какие конченные извращуги пропихнули avif в веб вместо него и кто им позволил -- он не конкурент даже webp.
Ответить | Правка | Наверх | Cообщить модератору

180. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (179), 06-Апр-24, 15:41 
Вы со своими файлами работаете, на свой страх и риск, вам и карты в руки. А там чужие пачками портят, не глядя.
Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

52. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от КО (?), 04-Апр-24, 14:51 
Ну-ну, сравни сжатую мангу в "webp-архиве" с остальными
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

79. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (79), 04-Апр-24, 18:22 
webp вполне себе зашел. Как минимум в тырнете его довольно прилично.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

198. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от GG (ok), 10-Апр-24, 11:58 
webp прекрасно зашли
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от нитгитлистер (?), 04-Апр-24, 11:56 
я правильно понимаю что эта технология сугубо для веба? или она всётаки в ближайшие полгода перекочует в графические проги?
Ответить | Правка | Наверх | Cообщить модератору

7. "Google представил библиотеку jpegli для более эффективного с..."  +3 +/
Сообщение от Аноним (4), 04-Апр-24, 12:02 
Картинкам надо откуда то браться - появится и в прогах .
Ответить | Правка | Наверх | Cообщить модератору

94. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (93), 04-Апр-24, 20:11 
А в поисковой системе Гугл нет картинок? Предполагаю что они это делали сугубо для себя, для экономии места под информацию. Может потому и поделились, чтоб себе любимым упростить работу с сайтами.
Ответить | Правка | Наверх | Cообщить модератору

157. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от microcoder (ok), 05-Апр-24, 14:31 
Во всех зеркалках и простых мыльницах используется JPEG, теперь есть возможность заменить
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

160. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от Аноним (127), 05-Апр-24, 15:23 
Кто-то покупает зеркалки, чтобы фотографировать в JPEG?
А мыльницы фактически вымерли, остались игрушки, там никому не надо заменять JPEG на что-то эффективное.
Ответить | Правка | Наверх | Cообщить модератору

162. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от microcoder (ok), 05-Апр-24, 15:35 
> Кто-то покупает зеркалки, чтобы фотографировать в JPEG?

Конечно, быстрый предпросмотр ещё никому не мешал. А RAW будет долго распаковывать и жрать аккум, что критично для фотика. Не таскать же за собой диз.станцию )))

+ Зеркалки могут снимать видосики в MJPEG


Ответить | Правка | Наверх | Cообщить модератору

163. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (127), 05-Апр-24, 15:50 
Для быстрого предпросмотра на трёхдюймовом экранчике в один мегапиксель эти нюансы пережатия совершенно несущественны.
Ответить | Правка | Наверх | Cообщить модератору

199. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от adolfus (ok), 10-Апр-24, 19:14 
Не на трехдюймовом, а на нормальном мониторе. Потому что, пока 20-и мегапиксельный файл на четыре 16-битных канала загрузится, пока из оригинального формата сгенерится тривосьмибитовый RGB для подачи в видеокарту, пройдет куча времени, а мы желаем листать отснятое без ощущаемых задержек в каталогах ФС с сотнями и более фото. Лично я могу с двухчасовой прогулки с детьми принести сотни три фото, которые нужно быстро просмотреть и существенно проредить¸ оставив дюжину, максимум полторы. Вот как раз для этого в RAW'ах (которые есть IFF) содержится чанк с джейпегом.
Ответить | Правка | Наверх | Cообщить модератору

184. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (184), 07-Апр-24, 03:04 
Для быстрого предпросмотра в RAW кодируют урезанный вариант в JPEG, thumbnail называется
Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

3. "Google представил библиотеку jpegli для более эффективного с..."  +3 +/
Сообщение от Аноним (3), 04-Апр-24, 11:57 
Просто праздник какой-то.
Ответить | Правка | Наверх | Cообщить модератору

6. "Google представил библиотеку jpegli для более эффективного с..."  +3 +/
Сообщение от Аноним (6), 04-Апр-24, 12:00 
> В частности, в jpegli задействован адаптивная эвристика квантования, используемая проектом JPEG XL…

Только что Гугл пищал, что там ничего интересного и вообще не нужно.

Ответить | Правка | Наверх | Cообщить модератору

9. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от IdeaFix (ok), 04-Апр-24, 12:07 
там же жпег2000 был и многие, очень многие решили форкаться...
Ответить | Правка | Наверх | Cообщить модератору

182. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от InuYasha (??), 06-Апр-24, 21:47 
Он был максимально проприетарным, емнип.
Ответить | Правка | Наверх | Cообщить модератору

11. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от Аноним (11), 04-Апр-24, 12:12 
Кто нибудь уже смотрел код? Интересно за счет чего бустится производительность, неужто SIMD используют?
Ответить | Правка | Наверх | Cообщить модератору

23. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (23), 04-Апр-24, 12:49 
SIMD не позволяет увеличить эффективность сжатия, он только скорость сжатия увеличивает
Ответить | Правка | Наверх | Cообщить модератору

15. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от Zenitur (ok), 04-Апр-24, 12:22 
Как знал, не переходил на libjpeg8 с libjpeg62! Сейчас заменю libjpeg62 на jpegli. Надеюсь, для сборки не потребуется какой-нибудь meson и llvm?

Upd: уже глянул - cmake и clang-7 или новее. Норм, на apt.llvm.org есть готовая сборка LLVM 7 даже для Debian 7. Так что проблем со сборкой не возникнет.

Ответить | Правка | Наверх | Cообщить модератору

17. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 04-Апр-24, 12:30 
Мань, сабж на плюсах написан. И ты каждый раз бежишь внедрять все сырые поделки корп? Тот же guetzli оказался весьма дорого и крайне не без потерь, libjpeg-turbo хотя бы предсказуема. А что касается jpegxl, то я очень доволен. Кроме того случая, когда все прошлые файлы внезапно оказались битыми (декодируются с зелёными артефактами местами) для всех новых версий библиотеки, совместимость-с.
Ответить | Правка | Наверх | Cообщить модератору

21. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Zenitur (ok), 04-Апр-24, 12:46 
> И ты каждый раз бежишь внедрять все сырые поделки корп

Я делаю домашние сборки некоторого ПО. Вот пример такой сборки:

https://github.com/OpenXRay/xray-16/files/14234005/S.T.A.L.K...

Свои сборки линкую с libpng12 и libjpeg62. Я выбрал их для совместимости: эти версии библиотек у всех есть (в отличие от libpng15, который сегодня заменили на libpng16, а завтра заменят на libpng17).

Однако хочется же с libjpeg8 слинковаться? Чтобы софтина работала быстрее. Но вдруг у юзера нет этой библиотеки? Я понимаю что "стандарт де-факто", но вдруг завтра поломают ABI и выпустят libjpeg9? Такое уже было с libjpeg7.

Поэтому я сейчас положу в архив с моей сборкой - сабж. Он такой же быстрый, как libjpeg8, но при этом имеет прежний ABI libjpeg62.

Ответить | Правка | Наверх | Cообщить модератору

28. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 04-Апр-24, 13:07 
У плюсов перечень забавных приколов с аби и библиотекой раскрутки стека, это ещё если исключения не используются, такая библиотека менее универсальна и переносима. Зачем тебе чтобы софтина работала быстрее, ценой замены аутентичного компонента на непонятно что с непонятно какими непредсказуемыми последствиями? Наоборот, стоит бороться за сохранение и презервацию аутентичного кода для будущих поколений и тут чем меньше васянства и отклонений от оригинала, тем лучше.
Ответить | Правка | Наверх | Cообщить модератору

29. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (29), 04-Апр-24, 13:12 
>libpng15, который сегодня заменили на libpng16

Очнись! Твое "сегодня" - это сентябрь 2017 года.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

31. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от Zenitur (ok), 04-Апр-24, 13:14 
В RHEL всё ещё libpng15
Ответить | Правка | Наверх | Cообщить модератору

33. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (33), 04-Апр-24, 13:24 
Потому что все остальные версии либы насквозь протроянены похуже xz.
Ответить | Правка | Наверх | Cообщить модератору

36. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Zenitur (ok), 04-Апр-24, 13:27 
> Потому что все остальные версии либы насквозь протроянены похуже xz.

Не, потому что последний RHEL релизнулся хрен знает когда. Я тут загуглил - оказывается, 9-й уже вышел... Я не знал.

Тогда в актуальном RHEL уже libpng16. Извиняюсь, был не прав.

Ответить | Правка | Наверх | Cообщить модератору

77. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от cheburnator9000 (ok), 04-Апр-24, 18:05 
Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь? Их же наверное уже не существует.
Ответить | Правка | Наверх | Cообщить модератору

88. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Зазнайка (?), 04-Апр-24, 19:42 
Зато существуют у него, у Вас от этого убыло что ли?
Ответить | Правка | Наверх | Cообщить модератору

129. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 01:10 
> Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь?
> Их же наверное уже не существует.

Пусть качнет, чтоли, archive.debian.org себе. Если получится, сможет mirror'ом подрабатывать.

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

153. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Zenitur (ok), 05-Апр-24, 12:56 
> Зенитурушка ты что все старые пакеты всех RPM дистрибутивов у себя хранишь?
> Их же наверное уже не существует.

От CentOS я нашёл архивные зеркала + RPMFusion. От SLES 11 бэкапил, но пока что бэкап не понадобился: в интернете всё ещё есть пакеты.

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

95. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (93), 04-Апр-24, 20:12 
А в чем проблема с llvm?
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

151. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Zenitur (ok), 05-Апр-24, 12:19 
Обычно я осуществляю сборку в старых дистрах, чтобы бинарник запускался в широком диапазоне Linux-систем, выпущенных за последние 10-15 лет.

А вот как собрать LLVM из исходников, мне неведомо. С GCC всё просто:

tar xf gcc-4.8.5.tar.bz2
cd gcc-4.8.5
mkdir build2
cd build2
../configure --prefix=/home/username/gcc-4.8 --enable-languages=c,c++
make -j7 // кол-во физических ядер +1
make install
export PATH=/home/username/gcc-4.8/bin:$PATH
export LD_LIBRARY_PATH=/home/username/gcc-4.8/lib:$LD_LIBRARY_PATH
gcc --version

Единственный минус такого GCC - бинарники, собранные таким компилятором, зависят от слишком новой libstd - новее, чем та, которая в /usr/lib. Как починить - не знаю! Наверное, надо смотреть devtoolset, там libstdc++.so заменён на какой-то текстовый файл - мне кажется, что разгадка скрыта где-то тут.

А вот с LLVM непонятно... В Debian DEB-SRC-пакет, который состоит из... шести архивов с исходниками... Их просто последовательно распаковать, или что? А собирать потом как? Дело в том, что идущий в комплекте debian/rules хрен распарсишь. Там ещё и stage-ы! Вот бы инструкцию - тогда бы я собрал любую версию LLVM, которая мне нужна. Чтобы просто в папке лежала, как вон выше пример с GCC...

Плюс ко всему, когда я собирал пакет LLVM 7 под Debian 7, я столкнулся с ошибкой, описанной тут:

https://www.linux.org.ru/forum/development/15941285

У автора треда Debian 10, но суть та же. Причём 64-битная сборка собралась без проблем! Ошибка только при сборке 32-битной сборки!

Хорошо что на сайте apt.llvm.org есть готовые пакеты с LLVM 7, и я смог установить их в 32-битную версию ОС Debian 7. А что если у меня не Debian, а что-то другое? Или Debian 6, например?

Ну и ещё при сборке Mesa 19.0.8 (последняя версия без Meson) возникла ошибка при сборке MesaOpenCL. Такая же ошибка возникла при сборке Beignet 1.3.2. Оказалось, что в binutils 2.26 прокралась регрессия, из-за которой LLVM генерирует неправильный код! Регрессию поправили в binutils 2.31.

А у меня в Debian 8 из коробки был binutils 2.25, который не был подвержен регрессии. Я зачем-то обновил binutils до более новой версии. А потом я потратил недели, чтобы понять, почему же я не могу собрать месу? Ведь предыдущая 18.3.6 собиралась без проблем... Ответ нашёлся, когда я попробовал пересобрать уже собранную у меня Mesa 18.3.6, и когда она не собралась, я понял, что я что-то запорол в своей системе - причём недавно. А значит, надо смотреть, какие пакеты я устанавливал в систему последними...

Ответить | Правка | Наверх | Cообщить модератору

18. "Google представил библиотеку jpegli для более эффективного с..."  +2 +/
Сообщение от uis (??), 04-Апр-24, 12:35 
Когда арифметическое кодирование?
Ответить | Правка | Наверх | Cообщить модератору

61. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (92), 04-Апр-24, 15:54 
>  Когда арифметическое кодирование?

a) Патенты истекли лет 15 назад, но уже никогда - решили, что распространение таких jpeg'ов вредно из-за несовместимости со старым софтом.

b) У себя лично можно давно использовать - пропустить файлы через jpegtran -arithmetic, это lossless-операция.

c) А для распространения... Проблема из (a) решается сменой формата файла, чтобы арифметический жипег не выглядел обычным жипегом, но тогда и арифметического кодирования придерживаться не обязательно. Перепаковщиков жипега, работающих таким образом, много: ...jojpeg, packJPG, brunsli, lepton, JPEG-XL.

Lossless-перепаковка jpeg'ов - одна из фич JPEG-XL, ему бы ещё поддержку в браузерах.

Ответить | Правка | Наверх | Cообщить модератору

19. "Google представил библиотеку jpegli для более эффективного с..."  –3 +/
Сообщение от Аноним (19), 04-Апр-24, 12:37 
С сегодняшними скоростями Интернет можно PNG использовать и не париться.
Ответить | Правка | Наверх | Cообщить модератору

26. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от нах. (?), 04-Апр-24, 13:04 
использовать можно, не париться не получится - гугль еще не написал для него "более эффективного кодировщика" (и, главное - декодировщика). А референсный - тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом со своими вейвлетами и прочей заумью)

Ответить | Правка | Наверх | Cообщить модератору

65. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 04-Апр-24, 16:22 
Не знаю, при чём тут вейвлеты из старых жипегостандартов, но png ещё можно ускорить распараллеливанием: https://github.com/w3c/PNG-spec/issues/54
Ответить | Правка | Наверх | Cообщить модератору

108. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от нах. (?), 04-Апр-24, 22:56 
Можно, но нельзя (потому что это w3c, они не умеют кодить)

Ждите пока гугель захочет в png (а он не захочет).

Ответить | Правка | Наверх | Cообщить модератору

122. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (127), 05-Апр-24, 00:37 
Там про декодирование, оно проблемой не является. «This would significantly reduce the wall-clock time involved in reading large (8k-32k) PNG files on modern machines» — прямо очень частый кейс, да.
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

132. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 05-Апр-24, 02:18 
Тем не менее, Apple такое реализовала. Картинки чаще просматривают, чем сжимают. Причём сжимать обычно нужно много за раз (и однопоточность не мешает), а просматриваются они по одной штуке. Ещё декодирование проблемнее, потому что только для него нужны новые стандартные метаданные.

Глядишь, для сканов пригодится. Или нет. Сначала надо убедиться, что скорость fpng и wuffs PNG недостаточна: https://github.com/nigeltao/qoir/blob/main/doc/full_benchmar...

Ответить | Правка | Наверх | Cообщить модератору

161. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (127), 05-Апр-24, 15:25 
Да пусть реализуют, спору нет. Просто 99,9% пользователей этого не заметит даже.
Ответить | Правка | Наверх | Cообщить модератору

126. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от Аноним (126), 05-Апр-24, 00:45 
> использовать можно, не париться не получится - гугль еще не написал для
> него "более эффективного кодировщика" (и, главное - декодировщика). А референсный -
> тот еще тормоз (и никогда, разумеется, не будет сопоставим с жпегом
> со своими вейвлетами и прочей заумью)

Они вообще разные. JPEG для фоточек, PNG для скриншотов, доков, схем, чертежей и проч - с контрастными четкими линиями, фонтами и проч.

Хранить фоту в PNG - можно, но это ж zlib с префильтрами. Сильно такое не ужмет. Зато line art и прочие скриншоты - вполне. При том lossless by design. Можно 20 раз редактировать и не париться. Это чуть более продвинутый вариант .bmp.gz - всего лишь. Оптимизаторы кстати есть, типа optipng, pngcrush, advpng и проч. В последнем, кстати, есть "zophli". Да, это - гугловая штука! Алго сжатия deflate на максималках. Жмет медленно - но лучше остальных, при 100% совместимости с форматом. Есть такая штука - "optimal parsing". Для двухфазных схем с huffman'ом внагрузку оно, правда, обречено быть "приблизительным" но остальные оптимизацией вариантов представления потока вообще не парились и жали еще хуже.

Сохранить вон то ("line art") в JPG можно - но DCT очень плохо реагирует на резкие перепады контраста, он под фотореалистику делался же. И там немеряно артефактов будет. Не для этого оно. А первая версия webp вообще только subsampled yuv умеет. Ибо i-frame от VP8. И для чего-то типа скрина с компа - капец полный по цветности.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

133. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 05-Апр-24, 02:34 
Среди оптимизаторов pingo и ECT лидировали. pingo и быстрый, и лучший по степени сжатия, ECT иногда вырывался вперёд на какое-то микроскопическое расстояние.

https://css-ig.net/benchmark/png-lossless

Ответить | Правка | Наверх | Cообщить модератору

140. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 05:15 
> Среди оптимизаторов pingo и ECT лидировали. pingo и быстрый, и лучший по степени сжатия,

С одним маленьким недостаточком - блоб онли варезок, под маздайку. В таком виде он мне нафиг не упал.

> ECT иногда вырывался вперёд на какое-то микроскопическое расстояние.

С PNG все не так просто: там кроме супер-сжатия еще префильтры есть и в зависимости от его выбора - optipng периодически показывает продвинутым пакерам с ломовым zlib'ом мастеркласс подыскав более удачный префильтр.

Разумеется упомянуть этот тонкий момент авторы того блобика немного постеснялись. А суперкомбо ака подобие optimal parsing + брут префильтра таки займет весьма нетривиальное время, и вот нафиг кому пнг на 3% меньше - путем нагрева проца полдня? :)

> https://css-ig.net/benchmark/png-lossless

Сейчас бы, блин, на сайте автора того блоб онли варезка - смотреть объективные результаты бенчмарков то. Сразу после того как Get The Facts на сайте корпорации Майкрософт дочитаю.

Ответить | Правка | Наверх | Cообщить модератору

147. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 05-Апр-24, 09:17 
Не знаю, чего тебя так раскукожило, но:
- мне запомнились именно эти две софтины, раньше у меня они показывали себя лучше, чем zopfli и optipng
- из png в одном солидном бенчмарке[1] выжимали все соки именно связкой pingo+ECT. Наверное, ECT обгоняет pingo не "иногда", но "Generation 12562..." спустя часы в консоли напоминает, почему я предпочёл об этом забыть.
- optipng -o7 уже включает перебор всех фильтров (-f0-5)
- (ещё одна ошибка - с lossless WebP в другом комменте, под ним ответил)

[1] https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_.../

Ответить | Правка | Наверх | Cообщить модератору

155. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 05-Апр-24, 13:03 
Так avif вроде и не лосслесс ни в одном из смыслов. Ну, во всяком случае, libaom говорит, что лосслесс с нужными флагами, но просто раздует файл до невозможности и выдаст очень даже лосси под видом лосслесс (в частности, проредит цвета). Чё они там сравнивали?
Ответить | Правка | Наверх | Cообщить модератору

166. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от анонимус (??), 05-Апр-24, 17:25 
Вот не надо, очень даже lossless, а цвета у тебя ломаются потому что надо было читать спецификацию, avif умеет в 8,10 и 12 битность и 400, 422 и 444 сабсэмплинг.
Ответить | Правка | Наверх | Cообщить модератору

167. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 05-Апр-24, 18:00 
Неа, я прошёлся по всем параметрам кодера. А теперь рассказывай, как у тебя получился lossless avif? Сравнить соответствие оригиналу можешь с magick "${fsrc}" "${file}" -metric PAE -compare -format '%[distortion]' info: и цвета искажает даже со всеми дополнительными параметрами вроде -L -p chroma=444 --matrix_coefficients=0 (что заявлено как лосслесс с rgb).
Ответить | Правка | Наверх | Cообщить модератору

173. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от анонимус (??), 05-Апр-24, 21:58 
>что заявлено как лосслесс с rgb

вот тут и собака зарыта. avif не умеет в RGB, только в YUV, поэтому и потери в цвете. У jpeg xl этого недостатка нет.

Ответить | Правка | Наверх | Cообщить модератору

174. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 06-Апр-24, 05:22 
Проблема в твоих руках. Lossless-режим в AV1 сделан для галочки, пользоваться им не надо и раньше баги в реализациях были, но сейчас проблема только в твоих руках.

Посмотри на вывод ffprobe, в lossless-режиме yuv444p(бла-бла-бла) должен смениться на gbrp(бла-бла-бла), закодируй правильно, правильно сверь картинки.


avifenc --lossless in.png out1.avif
ffmpeg -i in.png -aom-params lossless=1 out2.avif

ffmpeg -loglevel error -i in.png    -pix_fmt rgb24 -f md5 -
ffmpeg -loglevel error -i out1.avif -pix_fmt rgb24 -f md5 -
ffmpeg -loglevel error -i out2.avif -pix_fmt rgb24 -f md5 -

-f md5 считает хэш от bitmap'а после декодирования, -pix_fmt rgb24[*] приводит bitmap'ы к единому формату (interleaved/planar, rgb/bgr...), а то avif и png по умолчанию декодируются в разные форматы - "rgb24" и "gbrp".

* для картинок с альфа-каналом и с не-8-битами на канал нужен другой общий знаменатель, очевидно

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

175. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (118), 06-Апр-24, 08:06 
Отмазки пошли. Какой же, к чёрту, это лосслесс тогда? Получается, проблема и не в моих руках вовсе.
Ответить | Правка | Наверх | Cообщить модератору

176. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 06-Апр-24, 09:40 
...в твоих руках, а ещё глазах (и руках соседнего анонимуса).

Если протереть глаза, то там описан процесс для исходника в RGB с 8 битами на канал. Lossy его превратит в YUV. Lossless - нет. Подходящий общий формат для битмапов: "-pix_fmt rgb24".

Ответить | Правка | Наверх | Cообщить модератору

177. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 06-Апр-24, 10:09 
И смотри какие чудеса, название забагованного энкодера не указываешь ты, а баг в нём вижу я.

https://github.com/strukturag/libheif/issues/62#issuecomment...

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

189. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от Аноним (-), 07-Апр-24, 04:48 
> Не знаю, чего тебя так раскукожило, но:

То что совать непонятную проприетарь под винду на ресурсе про открытое ПО - это немного невежливо. И может крепко промазать с адресатом.

> - мне запомнились именно эти две софтины, раньше у меня они показывали
> себя лучше, чем zopfli и optipng

Мои эксперименты с оптимизаций PNG показали что таки - весьма контентозависимо, иногда optipng подбирает более удачный префильтр и остальные напрягаются его побить.

И кстати да, ниоткуда не следует что это же комбо фильтров - столь же оптимально для более сильного zlib пакера. Откуда и идея что полный брут

> pingo+ECT. Наверное, ECT обгоняет pingo не "иногда", но "Generation 12562..."

Ну я и намекал что в какой-то момент таки - и хрен с ним на целые 3% большей PNG'шкой. Убиваться ради нее имеет смысл только если делается "на века" а проц нагрузить совсем нечем.

> - optipng -o7 уже включает перебор всех фильтров (-f0-5)

Угу. Вот это бы с продвинутым пакером скрестить... но тогда все придет к вооон тому, и через полдня этого - захочется ctrl+c вкатить. И черт с ними с 3% улучшений.

> - (ещё одна ошибка - с lossless WebP в другом комменте, под ним ответил)

IIRC таки изначально он был с subsampling и YUV. В v2 вроде что-то более приличное сделали.

> [1] https://www.reddit.com/r/AV1/comments/fjddcj
> /lossless_image_formats_comparison_webp_jpeg_xl/

Ну просто не в обиду ISO но их рабочая группа по видео - себя дискредитировала в хлам. Видимо в целом индустрия не очень доверяет и этой группе, хоть они и другие.


Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

191. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (92), 07-Апр-24, 14:37 
Но тебя перераскукожило до ошибок. С обсуждаемой проприетарью optipng сравнить не можешь, но отвечаешь; свободный fhanau/ECT тоже внимания заслуживает. WebP2 у гугла до сих пор называется "WebP 2: experimental successor" и в сравнении по ссылке с реддита обе версии протестированы же.

> Ну просто не в обиду ISO но их рабочая группа по видео - себя дискредитировала в хлам. Видимо в целом индустрия не очень доверяет и этой группе, хоть они и другие.

Эта в целом индустрия называется Google и доверяет, конечно, своим WebP, WebP2, AVIF, AVIF@AV2. Но Google ещё, видимо, самодискредитацией занимается, принимая участие в разработке JXL.

Ответить | Правка | Наверх | Cообщить модератору

43. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от 12yoexpert (ok), 04-Апр-24, 13:49 
согласен, сейчас основной объём - это джаваскрипт
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

53. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от КО (?), 04-Апр-24, 14:51 
Вы не хотите поработать маркетологом?
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

74. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (74), 04-Апр-24, 17:29 
Разработчиком сайтов.
Ответить | Правка | Наверх | Cообщить модератору

55. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Гость (??), 04-Апр-24, 15:11 
Сегодня пользователей тоже очень много, с PNG кэши браузеров быстро заполнятся и терабитные каналы забьются. Было бы иначе, всякие инстаграмы не жали бы картинки до предела худшего качества.
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

25. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (25), 04-Апр-24, 13:04 
Пытаются оптимизировать йобибайты 100-мегапиксельных селфи в гуглофото... 35% от йобибайта это пара датацентров.
Ответить | Правка | Наверх | Cообщить модератору

35. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (35), 04-Апр-24, 13:26 
Почему jpegli, а не jpeglib?
Ответить | Правка | Наверх | Cообщить модератору

51. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от google (??), 04-Апр-24, 14:49 
> Почему jpegli, а не jpeglib?

у нас в rsx11m имена не 8.3 а только 6.3 (зато 6.3;1 !)

Ответить | Правка | Наверх | Cообщить модератору

68. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Самый умный аноним (?), 04-Апр-24, 16:54 
Суффикс li не имеет никакого отношения к lib
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

70. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (35), 04-Апр-24, 17:16 
А к чему имеет?
Ответить | Правка | Наверх | Cообщить модератору

84. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Самый умный аноним (?), 04-Апр-24, 19:06 
Такое же как в brotli и zopfli
Ответить | Правка | Наверх | Cообщить модератору

89. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Зазнайка (?), 04-Апр-24, 19:45 
library interface?
Ответить | Правка | Наверх | Cообщить модератору

100. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 04-Апр-24, 20:39 
уменьшительно-ласкательный суффикс из швейцарско-немецкого диалекта - https://news.ycombinator.com/item?id=39923731
Ответить | Правка | Наверх | Cообщить модератору

101. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Максим (??), 04-Апр-24, 20:59 
А Гугл разве немецкая или швейцарская компания?
Ответить | Правка | Наверх | Cообщить модератору

103. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (92), 04-Апр-24, 21:07 
Там отсылают к "In Zürich arbeiten über 5’000 Googler*innen"
Ответить | Правка | Наверх | Cообщить модератору

130. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 01:12 
> А Гугл разве немецкая или швейцарская компания?

Не, там Jirki Alakuyala (надеюсь правильно написал) - ключевой чувак по компрессии в гугле - откуда-то оттуда. Ну и пошла такая традиция. Вообще что-то типа сортов хлебушков так то.

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

37. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (37), 04-Апр-24, 13:28 
Не очень понял. Если это новая разработка гугла, почему они её написали на загибающихся плюсах?
Ответить | Правка | Наверх | Cообщить модератору

40. "Google представил библиотеку jpegli для более эффективного с..."  +8 +/
Сообщение от Аноним (35), 04-Апр-24, 13:45 
Наверно потому что С и С++ на данный момент единственные универсальные языки, с помощью которых можно просто сделать свою работу, а не заниматься "высшей алгоритмической акробатикой". А то, что кто-то там загибается - это сказки для Васянов в шортиках на гироскутерах.
Ответить | Правка | Наверх | Cообщить модератору

144. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от laindono (ok), 05-Апр-24, 08:37 
Это два разных языка, которые на текущий момент имеют лишь историческую связь. Это во первых. А во вторых они как минимум с появления Java перестали быть универсальными.

На чистом няшном си всерьёз сейчас пишут только под сильно нестандартные архитектуры.

На крестах пишут всякую системную требуху или числодробилки.

Это если мы говорим о новых проектах. Разумеется что на одном, что на другом куча готового кода. Переписывать его на другой язык не имеет смысла, кроме случая, когда переписывание требуется само по себе.

Ответить | Правка | Наверх | Cообщить модератору

156. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (35), 05-Апр-24, 13:26 
> На чистом няшном си всерьёз сейчас пишут только под сильно нестандартные архитектуры

Не смеши) На Си и плюсах сейчас дохрена всего пишется. Во-первых, тонны существующих проектов, которые будут существовать ещё минимум лет 50, и это нельзя не учитывать. Во-вторых, новые проекты. Вот пожалуйста, сам ультрапрогрессивный Гугл выкатил абсолютно новый проект на старом-добром С++, а не на каком-нибудь "модном-молодёжном".

Ответить | Правка | Наверх | Cообщить модератору

170. "Google представил библиотеку jpegli для более эффективного с..."  –1 +/
Сообщение от laindono (ok), 05-Апр-24, 18:56 
Речь о том, что сишечка с крестами являются нишевыми языками по состоянию на 2к24 год. Если ты боишься, что вот прям всё-всё-всё перепишут и у тебя работы не останется, то могу тебя успокоить. С другой стороны яб не назвал всякие Java/C#/Python/JS и кучу другого "модным-молодёжным". Но кучу задач с C/C++ они определённо сняли. Согласись, несколько непродуктивно писать на них, скажем, веб-бекенд или что-то вроде того. Хотя каких-то лет 30 назад это было по крайней мере одним из вариантов.
Ответить | Правка | Наверх | Cообщить модератору

169. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (169), 05-Апр-24, 18:20 
ну так libjpeg это и есть числодробилка
Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

42. "Google представил библиотеку jpegli для более эффективного с..."  +4 +/
Сообщение от 12yoexpert (ok), 04-Апр-24, 13:48 
просто гугл из загнивающего запада. логично, что они используют загибающиеся плюсы
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

58. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Аноним (11), 04-Апр-24, 15:22 
Загибающихся? Лол, уже минимум лет 20 слышно что вот вот и все, выкинем эту вашу сишку с плюсами, ведь буквально завтра придумали новый языкнейм!
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

60. "Google представил библиотеку jpegli для более эффективного с..."  +2 +/
Сообщение от Аноним (35), 04-Апр-24, 15:46 
Самое интересное, почему не на Go? Пилили-пилили свой новый язык, который должен был исправить все недостатки языков программирования XX века, а в итоге выкатили новый проект на старом языке :/
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

158. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от microcoder (ok), 05-Апр-24, 14:37 
> Самое интересное, почему не на Go?

А почему не на Rust? )))

Ответить | Правка | Наверх | Cообщить модератору

159. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (35), 05-Апр-24, 14:55 
Потому что на нём с Си переписывают, а это новая библиотека, исходников на Си нет)
Ответить | Правка | Наверх | Cообщить модератору

168. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (169), 05-Апр-24, 18:19 
Go пилили не для того, чтобы исправить все недостатки всех языков, а для того, чтобы был узкоспециализированный язык для удобного написания i/o-bound сервисов с event loop. Чтобы по простоте как nodejs, но по производительности близко к C.

В libjpeg это вообще не надо.

"Исправить все недостатки" - это к анонимам с опеннета :-)

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

171. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (35), 05-Апр-24, 18:57 
Из Википедии: "Go может рассматриваться как попытка создать замену языкам С и C++ с учётом изменившихся компьютерных технологий и накопленного опыта разработки крупных систем[15]. По словам Роба Пайка[15], «Go был разработан для решения реальных проблем, возникающих при разработке программного обеспечения в Google»"

Выходит, что всё-таки хотели создать свой универсальный язык на замену С и С++, но что-то пошло не так...

Ответить | Правка | Наверх | Cообщить модератору

82. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от namenotfound (?), 04-Апр-24, 18:38 
потому что там разные команды работают? кому-то проще/привычнее на плюсах писать, наверное
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

87. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (35), 04-Апр-24, 19:29 
Так зачем было давать новый проект староязыковой команде? Пусть они поддерживали бы легаси код. А новую библиотеку можно было бы начать с чистого листа на новом современном языке.
Ответить | Правка | Наверх | Cообщить модератору

90. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Зазнайка (?), 04-Апр-24, 19:48 
> Так зачем было давать новый проект древнеязычной команде?

//fixed

Ответить | Правка | Наверх | Cообщить модератору

178. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от namenotfound (?), 06-Апр-24, 12:37 
> Так зачем было давать новый проект староязыковой команде? Пусть они поддерживали бы
> легаси код. А новую библиотеку можно было бы начать с чистого
> листа на новом современном языке.

почему вы думаете, что у них разделение по языкам? есть команда по кодекам (а скорее даже конкретно по фотокодекам), там в основном людям комфортно писать на плюсах, скорее всего

надо будет - перепишут хоть на расте, хоть на жабе, была бы необходимость/желание

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

39. "Google представил библиотеку jpegli для более эффективного с..."  +2 +/
Сообщение от Аноним12345 (?), 04-Апр-24, 13:38 
а нет ли тут бэкдора ?
Ответить | Правка | Наверх | Cообщить модератору

54. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (54), 04-Апр-24, 15:03 
> Повышение уровня сжатия достигается применением продвинутых технологий для сокращения шумов на изображении и увеличения качества, использующих более эффективные методы психовизуального моделирования для уменьшения возникающих артефактов.

Перевожу: у вас будут рисунки вместо фотографий. Ведь вы этого достойны...

Ответить | Правка | Наверх | Cообщить модератору

64. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от DEF (?), 04-Апр-24, 16:22 
MozJPEG больше не нужен?
Ответить | Правка | Наверх | Cообщить модератору

86. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от Анонимemail (86), 04-Апр-24, 19:16 
Так jpegli входит в jpeg-xl
Ответить | Правка | Наверх | Cообщить модератору

109. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от голос из леса (?), 04-Апр-24, 23:06 
>> методы психовизуального моделирования для уменьшения возникающих артефактов.

А можно вообще ИИ генерить, пофигу что там в исходнике было. Пользователь только спасибо скажет и еще с лопаты слижет.

Ответить | Правка | Наверх | Cообщить модератору

117. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (127), 05-Апр-24, 00:03 
Ну да, в стандартной-то жпеговской мазне любой пользователь с ходу определяет, что там было.
Ответить | Правка | Наверх | Cообщить модератору

141. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (-), 05-Апр-24, 05:24 
> Ну да, в стандартной-то жпеговской мазне любой пользователь с ходу определяет, что
> там было.

А что, нет чтоли? Это тебе любой фильм про шпионов подтвердит! Видишь - там за километр авто, номер размером с прыщик? А вот раз, раз, раз, digital enhancement - и вот уже вместо мазни вполне себе како-нибудь х123ер. Правда, злые языки поговаривают что секретная экспериментальная технология недопилена - и работает почему-то только в фильмах :)

Ответить | Правка | Наверх | Cообщить модератору

143. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от penetrator (?), 05-Апр-24, 08:14 
протестил я алгоритм на реальных картинках для сайта, мыло мыльное даже на большем размере, чем то что пожато другим энкодером
Ответить | Правка | Наверх | Cообщить модератору

149. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от devl547 (ok), 05-Апр-24, 11:31 
>мыло мыльное

Зато от артефактов классического жипега ушли, да.
Это собственно особенность всех современных форматов - они дают мыло вместо блоков, это хорошо видно на всяких сравнениях.

Ответить | Правка | Наверх | Cообщить модератору

154. "Google представил библиотеку jpegli для более эффективного с..."  +2 +/
Сообщение от Аноним (35), 05-Апр-24, 13:02 
Лучше уж артефакты, чем мыло. К артефактам глаз уже привых и они особо не мешают, а когда мыло, то кажется, что у тебя или с глазами, или с монитором что-то - нечёткое изображение.
Ответить | Правка | Наверх | Cообщить модератору

194. "Google представил библиотеку jpegli для более эффективного с..."  +1 +/
Сообщение от penetrator (?), 08-Апр-24, 17:24 
на тех размерах что тестировал, артефактов нет или они незаметны без увеличения, а вот потеря деталей на новых алгоритмах очень сильно заметна, картинка получается "мертвая", пластиковая, так мало того, еще и выходной файл больше получался чем у прошлого моего энкодера на 10-20%, а иначе еще больше несоотвествий с оригиналом и проигрыш предыдущему энкодеру

так что очень советую тестировать самому, а не хайп ловить, энкодер неплох, но есть лучше

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

183. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от InuYasha (??), 06-Апр-24, 21:49 
Интересно. А со старымы декомпрессорами оно, кстати, совместимо?
Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

150. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Scondo (?), 05-Апр-24, 12:02 
Меня одного пугает указание на "использование собственного декодировщика приводит к снижению артефактов"?

Или EEE только от микрософт проблема?

Ответить | Правка | Наверх | Cообщить модератору

164. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Аноним (164), 05-Апр-24, 16:08 
Зачем гугля возится с жыпег-XL? Есть же типа "преемники" - WebP и AVIF - с ними чо, ОПЯТЬ какие-то проблемы?
Ответить | Правка | Наверх | Cообщить модератору

172. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от DZgas (?), 05-Апр-24, 20:43 
мы живём в мире, когда скриншоты смартфонов делают в JPEG по той причине, что они 2к в высоту, и при открытии предпросмотра галереи должны мгновенно декодироваться и отображаться

ни один формат этого не может. Apple в свои HEIF вшивают привью предпросмотра отдельной кртинкой

Ответить | Правка | Наверх | Cообщить модератору

165. "Google представил библиотеку jpegli для более эффективного с..."  –2 +/
Сообщение от Аноним (165), 05-Апр-24, 16:53 
Корпоративная шизофрения. Один отдел развивает JPEG XL, второй - выпиливает его отовсюду, дабы подгадить первому.
Ответить | Правка | Наверх | Cообщить модератору

181. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Sylvia (ok), 06-Апр-24, 20:20 
31368 resave-png.png  20196 orig.jpg  19128 jpegoptim.jpg  17344 gimp-resave.jpg   5496 guetzli.jpg   3004 jpegli.jpg   1092 test_heic.heic    412 test_avif.avif

это успех, превзошли Guetzli по сжатию, при этом это все еще обычный прогрессивный JPEG для декодера.

AVIF конечно круче, но это уже друой формат.

PS: гусля час пыхтел сожрав 12 гигов памяти

Ответить | Правка | Наверх | Cообщить модератору

195. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от devl547 (ok), 08-Апр-24, 22:29 
>PS: гусля час пыхтел сожрав 12 гигов памяти

Просто надо было guetzli-cuda-opencl собирать и запускать, она достаточно быстро работает.

Ответить | Правка | Наверх | Cообщить модератору

197. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от Sylvia (ok), 09-Апр-24, 22:54 
в то время как обычный даже многопоточность не умеет и в принципе заброшен,
ведь в гугле занимаются всем подряд и бросают без сожаления, хотя некоторые наработки интересны. Возможно и JPEGLI ждет та же судьба
Ответить | Правка | Наверх | Cообщить модератору

196. "Google представил библиотеку jpegli для более эффективного с..."  +/
Сообщение от MihaNixemail (ok), 09-Апр-24, 03:49 
Как правильно использовать эти утилиты?
Я решил проверить это на фотографиях и сканах документов.
Из формата png конвертировал в jpeg. Был удивлен, что у меня после обработки libjpeg-62 файлы имеют меньший объем, чем после сжатия с помощью данной библиотеки от гугла. Это касается практически всех проверенных файлов.
Ожидаемого результата не достиг.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру