The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Google представил библиотеку jpegli для более эффективного сжатия JPEG-изрбражений , opennews (??), 04-Апр-24, (0) [смотреть все]

Сообщения [Сортировка по времени | 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ообщить модератору

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

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




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

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