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

"Разработчик Firefox провёл сравнительное тестирование форматов JPEG XL и AVIF"	+/–
Сообщение от opennews (?), 17-Окт-26, 00:33
Джейк Арчибальд (Jake Archibald), участвующий в разработке Firefox, провёл исследование, в котором сравнил форматы JPEG XL и AVIF, используя стандартный кодек libavif, стандартный кодек libjxl и новый кодек jixel, написанный на Rust и задействованный в Firefox и Chrome. Форматы тестировались в одинаковых условиях, которые включали кодирование с потерями, а для анализа результатов использовались показатели SSIMULACRA2, определяющие степень отличия от исходного изображения без потерь. В большинстве тестов формат AVIF  показал лучшие результаты и при аналогичном уровне качества позволял создавать файлы меньшего размера, которые требовали меньше процессорного времени для сжатия и распаковки... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66493
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Bottle (?), 17-Окт-26, 00:59	+12 +/–
Ну то есть JXL за счёт обратной совместимости и поддержки в PDF выигрывает все равно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3

3. Сообщение от Ivan_83 (ok), 17-Окт-26, 01:09	+3 +/–
Для AVIF/av1 будет только прирастать колличество аппаратных платформ которые могут кодить/декодить. Я бы сказал что это винрарное комбо: единый свободный кодек для фоток и видео да ещё и в железе, единственное что там AV2 вышел и не понятно насколько оно сможет переиспользовать эти блоки и формат. Притом учитывая что это всё гугловые поделки и их браузер меинстримный то его то они точно не забудут добавить и поддерживать. Пожалуй тот немногий случай когда гугл реально делает что то полезное всем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #6

4. Сообщение от Аноним (4), 17-Окт-26, 01:18	+12 +/–
Все лучше, чем недоразумение WebP и обвешанный патентами HEIF. JPEG в свое время стал значительно лучше с развитием кодировщиков и без нарушения совместимости. И вот интересно, насколько и JXL и AVIF есть потенциал для усовершенствования кодировщиков без изменения формата?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #27, #55, #90

5. Сообщение от Аноним (5), 17-Окт-26, 01:44    Скрыто ботом-модератором	–1 +/–
Всё это не нужно, есть просто jpeg.
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Смузихеб забывший пароль (?), 17-Окт-26, 02:15	+/–
гугол свои поделия запросто выкидывает на мороз и без всякого сожаления ввиду этого то, что упомянутое - гугловое поделие, едва ли аргумент
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #8, #16

7. Сообщение от Аноним (7), 17-Окт-26, 02:34	+2 +/–
> Как правило, AVIF быстрее производит кодирование и потребляет меньше памяти с учётом размера итогового файла. Кодировщик jixel работает быстрее AVIF и требует меньше памяти... Так я не понял, кто быстрее-то?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #53

8. Сообщение от Аноним (8), 17-Окт-26, 03:20	+5 +/–
Все эти форматы какие то нонеймы Базарю через лет 10 уже нечем это открывать будет. А jpg/png/bmp вечны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #10, #12, #52

9. Сообщение от Аноним (5), 17-Окт-26, 03:33	+/–
Обычного jpeg вполне достаточно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #22, #78, #89

10. Сообщение от Ivan_83 (ok), 17-Окт-26, 03:37	+1 +/–
ffmpeg открывает такие кодеки о которых вы поди и не слышали :) У меня в асусовском кодеке видосы есть, его походу забросили все давно уже и оно открывается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #28, #37, #41

11. Сообщение от Аноним (11), 17-Окт-26, 03:43	+2 +/–
комуто и лопухов в лесу достаточно чтобы подтираться, но нормальные люди предпочитают иные маретиалы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #47

12. Сообщение от Аноним (12), 17-Окт-26, 03:52	+/–
qoi
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

13. Сообщение от Аноним (13), 17-Окт-26, 03:57	+4 +/–
А чего с webp не сравнил, или что то что это одного сорта +\- 20% и всё на этом?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15

15. Сообщение от Норм (?), 17-Окт-26, 04:35	–2 +/–
Вебп такое дно что даже сравнивать не с чем. Стремная фигея шакалящая то что жпен не смог зашакалить. Типо как энтот самый, vp9 на ютубе. Трафик оно экономит канечно, в том плане что смотреть на это невозможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #24

16. Сообщение от Аноним (16), 17-Окт-26, 05:45	+3 +/–
> гугол свои поделия запросто выкидывает на мороз и без всякого сожаления Что такое "выкидывание на мороз" относительно открытого стандарта и опенсорсной либы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #19

17. Сообщение от Аноним (16), 17-Окт-26, 05:48	+/–
JPEG 👍
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

18. Сообщение от Аноним (18), 17-Окт-26, 06:24	+1 +/–
Во всех трех современных форматах (Jpeg XL, AVIF, WebP) упаковка сторонних данных не требует искажения пикселей (стеганографии). А значит там можно спокойно прятать код SkyNet'а.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50

19. Сообщение от Смузихеб забывший пароль (?), 17-Окт-26, 06:56	+3 +/–
самый простой вариант - просто выпуск очередной версии браузера, где поддержка формата по умолчанию убрана с перспективой полного выпиливания "для упрощения поддержки" и "избавления от старого ненужного функционала" формат вроде бы остался, не осталось лишь возможности его реального применения т.к нафиг никому не нужен даже даром
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #60, #63

22. Сообщение от St (??), 17-Окт-26, 08:20	–2 +/–
Он давно устарел, а я хочу фотки HDR рассматривать и показывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #48

23. Сообщение от Аноним (25), 17-Окт-26, 08:36	+4 +/–
Какие-то удивительные результаты, у avif сильное выцветание и размыливание деталей, дефекты краёв. Причём, на любом качестве. И тут чувак заявляет, что для графики и снимков экрана лучше всего. Одно это заставляет усомниться, видимо, нейронка всё делала, а метрики прямо скажем булшит -- считают видимые дефекты лучшим качеством. Мне больше интересно, как он получил "AVIF (без потерь)" потому что PAE=0 с ним не получить, а значит, исходное изображение навсегда утеряно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #65

24. Сообщение от Аноним (25), 17-Окт-26, 08:46	+/–
У вебп из основных минусов только лесницы на градиентах из-за вп8, у вп9 с бандингом лучше. Главное, что он позволяет лосслесс, да и с потерями качество с sharpyuv будет повыше жпег на одинаковом размере. Местами. В целом, я достаточно основательно сравнивал и не нашёл преимуществ у авиф по сравнению с вебп, кроме возможности сжать ещё сильнее и сохранить удобоваримое качество.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #26

25. Сообщение от Аноним (25), 17-Окт-26, 08:55	+/–
Ты хотел сказать HEIC, потому что AVIF это тоже HEIF. Видимо, опенсорсные кодировщики использовали не патентованные алгоритмы в libx265, и качество картинки по удивительному совпадению проигрывало проприетарным реализациям. В этом отношении av1 лучше, и что с того, что он такое убожество. Но реально, надо им покормить халявщиков и накидать не урезанный формат изображений с h266, почему то уверен, что результаты разом смоют гугл в унитаз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

26. Сообщение от _аноним_ (?), 17-Окт-26, 09:18	+1 +/–
Только лучше бы для лосслесс отдельное расширение файлов сделали. Если расширение png, то сразу понятно, что это лосслесс. А если webp или jxl, то ещё выяснять надо
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

27. Сообщение от Аноним (27), 17-Окт-26, 09:20	+/–
А почему WebP недоразумение?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #29, #31

28. Сообщение от Bottle (?), 17-Окт-26, 09:21	+1 +/–
Вот поэтому он их и открывает, что эти кодеки мертвы и пользуются ими изредка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

29. Сообщение от Аноним (25), 17-Окт-26, 09:30	+2 +/–
> А почему WebP недоразумение? Недостаточно мыльный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

30. Сообщение от Метрика (?), 17-Окт-26, 09:43	+3 +/–
Меряли как известно теплое с мягким и пофиг на отсутствие сжатие без потерь в AVIF, и пофиг на отсутствие RAW-данных в AVIF, а самое интересное как меряли и кто мерял, если я померяю то AVIF мылит сильно, вопрос как они определяют сопоставимое качество, на основании своих субьетивных ощущений и цветопередачи с резкостью конкректного разработчика мазилы
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42

31. Сообщение от Аноним (31), 17-Окт-26, 09:50	+3 +/–
Цвета шакалит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #36

32. Сообщение от Аноним (32), 17-Окт-26, 09:50	+/–
AV1 кодировались только на CPU? Или GPU тоже подключался?
Ответить | Правка | Наверх | Cообщить модератору

33. Сообщение от Аноним (31), 17-Окт-26, 09:51	+/–
Хорошая реклама, Джейк, но AVIF мы использовать всё равно не будем.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

34. Сообщение от Mik Foxi (ok), 17-Окт-26, 09:52	–2 +/–
Почему не сравнить с WebP, который для веба по прежнему выглядит сильно адекватнее по всем параметрам.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49

35. Сообщение от Аноним (35), 17-Окт-26, 09:58	+1 +/–
А че они APNG так и не реализовали? Мне больше PNG нравится, т.к. он без потерь.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #39, #44, #58, #72

36. Сообщение от Аноним (25), 17-Окт-26, 09:58	–3 +/–
> Цвета шакалит. sharpyuv не шакалит, ты не отличишь от стандартного жпег
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #64

37. Сообщение от Аноним (37), 17-Окт-26, 10:00	–1 +/–
А встроенный в Файрфокс Ффмпег тоже открывает всякие редкие штуки? Или, как обычно, нужно под каждый конкретный формат обвязку делать? Если чего-то нет в распространенной общедоступной реализации, то, можно считать, что этого нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

38. Сообщение от Аноним (31), 17-Окт-26, 10:07	+/–
В смысле не реализовали? Реализовали же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

39. Сообщение от Аноним (37), 17-Окт-26, 10:09	+1 +/–
Слишком хорош и прост, недостаточно поверхность атаки увеличивает. Нужно чтобы и avx, и gpu задействованы были.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #59

40. Сообщение от LaunchWiskey (ok), 17-Окт-26, 11:01    Скрыто ботом-модератором	+6 +/–
Странные какие-то эти луддиты. Тратят время на изобретение заведомо устаревших форматов. Вам же уже показали наше будущее - вместо гигантских бинарных файлов с изображениями или видео, с которыми мучались воспитанные на IBM-360 и EC-1007 неандертальцы, теперь у нас будут компактные изящные промпты, по которым нейросеть а лету сгенерирует нужное изображение или ролик, причём сразу в нужном разрешении.
Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от IdeaFix (ok), 17-Окт-26, 11:26	+/–
Эхх... а вот matrox avi...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

42. Сообщение от Karl Richter (ok), 17-Окт-26, 12:08	–1 +/–
Там есть сжатие без потерь и что оно там мылит? Как вы определили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #56, #57

43. Сообщение от Karl Richter (ok), 17-Окт-26, 12:09	–1 +/–
Я использую, так как мне место дорого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

44. Сообщение от Метрика (?), 17-Окт-26, 12:09	+4 +/–
JXL совмещает в себе JPEG, PNG, GIF в этом его универсальность и весит меньше чем вышеперечисленные
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

46. Сообщение от вах (ok), 17-Окт-26, 12:47	–3 +/–
Steam выбрал AVIF для сохранение скриншотов в HDR, значит наверное он лучше.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #74

47. Сообщение от Аноним (47), 17-Окт-26, 13:10	+/–
> предпочитают иные маретиалы Мухоморы, например :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #93

48. Сообщение от Аноним (47), 17-Окт-26, 13:11	+/–
На чём? На 6-битной матрице, аппроксимированной ШИМом до 8 бит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #61

49. Сообщение от Аноним (47), 17-Окт-26, 13:14	+/–
> WebP Недостаточно много ресурсов потребляет. Вот AV1 - это да! Сжирает всё и ещё просит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #54

50. Сообщение от Аноним (50), 17-Окт-26, 13:30	+/–
Есть способ и приложения санитарии?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

51. Сообщение от Аноним (51), 17-Окт-26, 14:37	+/–
под винду есть wic кодек jpegxl, который работает везде и все время. а с avif проблемы там постоянные. wic кодака нет совмем. а микрософтовсктй костыль из магазина не работает.  у меня к примеру на 10 iot фотографии этот формат не показывают, и превьюшки не работают тоже.
Ответить | Правка | Наверх | Cообщить модератору

52. Сообщение от черпало (?), 17-Окт-26, 14:53	+/–
pcx, tiff, tga...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

53. Сообщение от черпало (?), 17-Окт-26, 14:55	+1 +/–
avif -- второй, jixel -- предпоследний
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #88

54. Сообщение от черпало (?), 17-Окт-26, 14:57	+/–
доброму коню всё впрок! большому куску и рот радуется!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

55. Сообщение от Cykooz (ok), 17-Окт-26, 15:36	+2 +/–
Сам HEIF не обвешан патентами. Это просто контейнер на базе формата BMFF (MP4 на его же базе) для хранения медиаданных. Патенты есть на кодеки типа H264+. Но с HEIF можно любые кодеки использовать, тот же AV1 или JPEG. Но есть конечно и "подлянка" у этого контейнера. Его спецификация находится за ISO-шным пейволом с довольно не гумманым прайсом для "Васянов", которые хотят написать свою реализацию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

56. Сообщение от Метрика (?), 17-Окт-26, 15:47	+1 +/–
Определил я субьективно на глаз по гайду мозиллы AVIF не справляется с сжатием без потерь, файлы получаются больше чем в PNG которому уже лет 30 если не больше, это регресс в стиле битмапа, в тоже время JXL жмет без потерь лучше PNG
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

57. Сообщение от Метрика (?), 17-Окт-26, 15:49	+/–
Видеокодеками сжимать изображения идея достаточно очевидная, но увы не удачная, так же как и растровым кодеком сжимать видео, можно конечно но результат будет хуже чем у профильного кодека
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #94

58. Сообщение от уп (?), 17-Окт-26, 16:29	+/–
Почти ровно 10 лет назад реализовали. https://groups.google.com/a/chromium.org/g/blink-dev/c/KcMjm...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

59. Сообщение от dimasafonis (?), 17-Окт-26, 16:39	+/–
А вы думаете ваш PNG декодер не использует AVX?.. Смело конечно, особенно с учётом того, что его используют и zlib-ng и libdeflate, и даже нн igzip - все они используют AVX, и даже AVX512, и все они быстрее zlib, который не использует даже SSE.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #76

60. Сообщение от Bottle (?), 17-Окт-26, 16:48	+1 +/–
У нас есть великолепный пример с Паскалем и стандартом ISO на его спецификацию. Стандарт есть, но де-факто его нет, и та небольшая часть пользователей, что пишет на Паскале, применяет Дельфи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

61. Сообщение от Bottle (?), 17-Окт-26, 16:49	+/–
Товарищ, не все живут в нулевых, ох, трудно будет тебе рассказать, что произошло за всё это время...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #67

62. Сообщение от Bob (??), 17-Окт-26, 17:04	+1 +/–
Чёт как-то специфически тестил. Вот за лохматый 2023 сравнение https://tonisagrista.com/blog/2023/jpegxl-vs-avif/ 6.9 Mb в 146 Kb сжимают. Avif шакалит, JXL поближе к оригиналу, но чуть мылит. Киллер фича can shrink existing JPEGs with no quality loss at all
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #81

63. Сообщение от Аноним (16), 17-Окт-26, 17:30	+/–
> гугол свои поделия запросто выкидывает на мороз > самый простой вариант - просто выпуск очередной версии браузера И как это относится к твоему изначальному утверждению о "гугол свои поделия запросто выкидывает на мороз". Он может точно так же "выкинуть" из Хрома PNG с JPEG. И что дальше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #87

64. Сообщение от Аноним (16), 17-Окт-26, 17:31	+2 +/–
Отличишь, потому что там субдескритизация цвета сугубо 4:2:0.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #66

65. Сообщение от Аноним (16), 17-Окт-26, 17:37	+/–
> Какие-то удивительные результаты, у avif сильное выцветание и размыливание деталей, дефекты краёв. В оригинальной статье есть сравнения изображений, где невооруженным глазом видно, что, наоборот, у JPEG XL мыло несоизмеримо больше, чем у AVIF - да еще и при большем размере файла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #68

66. Сообщение от Аноним (25), 17-Окт-26, 17:43	–2 +/–
У типичного жпег тоже, дальше что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #70

67. Сообщение от Аноним (25), 17-Окт-26, 17:51	+/–
Емнип такие матрицы и сегодня сертифицируют на какой-то из hdr10, хоть это и редкость. Большинство 12 битных на деле 8 битные тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

68. Сообщение от Аноним (25), 17-Окт-26, 18:10	+/–
Зависит от размера. Jpegxl немного плывёт с увеличением DCT (во всяком случае так было лет 7 назад), меньше 1 это практически visually lossless (можно безопасно задействовать ~0.460 и ниже, оно и быстрее в 15 раз) и у avif на таком битрейте это уже мыло при близком рассмотрении и с каждым обновлением кодеков всё больше мыла и артефактов. У jpegxl есть хороше преимущество, он замазывает типичные артефакты кодирования (актуально, когда исходник не совсем исходник), и avif рассыпается на артефакты, которые забрают себе бюджет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #69

69. Сообщение от Аноним (16), 17-Окт-26, 18:54	+/–
> Зависит от размера Ну так я же говорю: большее мыло при большем же размере. Визуальная разница огромна. Но это если судить сугубо по картинкам из статьи - хз, может автор не шарит в параметрах кодирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #71

70. Сообщение от Аноним (16), 17-Окт-26, 18:59	+3 +/–
> У типичного жпег тоже Не нечи чушь. У JPEG субдескритезация настраивается, вплоть до полного отключения. А у WEBP же безальтернативный 4:2:0 с теми самыми шакальными цветами. > дальше что? Дальше предлагаю тебе перечитать изначальное утверждение, что WEBP шакалит цвета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #73

71. Сообщение от Аноним (25), 17-Окт-26, 19:08	+/–
Скорее всего. Я вообще ни разу не видел никакого мыла у jpegxl, но я никогда ниже q92 и не кодировал. И даже специально сравнивал проблемные места с 2000 кратным зумом. Зато прекрасно видел мыло у avif. Перегнал не один терабайт данных в лосси.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #95

72. Сообщение от уп (?), 17-Окт-26, 19:13	+/–
Почти ровно 10 лет назад реализовали. https://groups.google.com/a/chromium.org/g/blink-dev/c/KcMjm...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

73. Сообщение от Аноним (25), 17-Окт-26, 19:21	–3 +/–
Это ты перечитай. Не шакалит цвета в том смысле, в котором шакалят видео кодеки. Они буквально изменяют оттенки, в зависимости от выбранного битрейта: чем больше экономия, тем меньше цветов сохраняется. И sharpyuv решает этот вопрос (у avif такого переключателя кодера не обнаружилось). А большинство файлов в качестве для дистрибуции идут с применённым субсамблингом, это нормально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #77

74. Сообщение от Илья (??), 17-Окт-26, 20:10	+/–
Наверное, потому что морда у Steam сделана на Electron, но хромой браузер тогда не поддерживал формат JXL, а формат AVIF поддерживал. Всё же просто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

76. Сообщение от Аноним (76), 17-Окт-26, 21:27	–1 +/–
> А вы думаете ваш PNG декодер не использует AVX?.. Смело конечно, особенно с учётом того, что его используют и zlib-ng и libdeflate А вот это было действительно смело. Мы на опеннете, поэтому встречный вопрос-уточнение: каким макаром они могут использовать AVX на коре дуба?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

77. Сообщение от Аноним (16), 18-Окт-26, 00:14	+1 +/–
> Не шакалит цвета в том смысле, в котором шакалят видео кодеки Зато шакалит именно в смысле сравнения с Jpeg и Jpeg XL, о котором и шла речь. > sharpyuv не шакалит, ты не отличишь от стандартного жпег Второй раз повторяю: не неси чушь. Если ты реально не отличаешь цвета при 4:2:0 и 4:2:2 (и тем боле 4:4:4), то у тебя проблемы со зрением. И sharpyuv вообще никаким боком к ЦВЕТУ не имеет отношения: он улучшает лишь края изображенных объектов и градиенты, по сравнению с обычным преобразованием RGB -> YUV. > у avif такого переключателя кодера не обнаружилось Иди проспись. Опцию --sharpyuv в avifenc добавили еще в 2022 году.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #80

78. Сообщение от Bottle (?), 18-Окт-26, 00:27	+/–
Недостаточно. У JPEG одна из проблем — наличие зелёнки и грязи в сильно пожатых областях изображения, из-за чего какой-нибудь текст становится одновременно и мыльным, и шумным, а выглядит это, мягко говоря, мерзко. В JXL же принцип кодирования позволяет варьировать сетку детализации, и эвристические алгоритмы позволяют этим артефактам проявляться заметно реже. У JXL одна из фич компрессии похожа на аналитический подход в геймдеве, когда на диффузную текстуру низкого разрешения накидывают карту нормали в виде какого-то шума, чтобы лучше имитировать микрорельеф, в итоге сумма разделённых текстур оказывается меньше, чем исходная, потому что по отдельности сжать их проще. В частности, JXL денойзит исходник, а затем синтезирует шум отдельно. Это позволяет сжать ещё сильнее, чем прежде, при этом минимизировав ошибку. Разве это не чудо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

80. Сообщение от Аноним (25), 18-Окт-26, 10:05	+/–
Повсюду вебп и всех всё устраивает. Разницы реально около 0, зато без sharpyuv очень очевидно. Чёт ты гонишь. Вон даже специально тестовый файл нашёл https://www.ozone3d.net/public/jegx/201412/chroma-subsamplin... и с sharpyuv разницы по цветам особенной нет, если не приглядываться. Они только плывут. При этом без, все оттенки совершенно другие. Я, конечно же, каждый день переписываю все скрипты. Хоть какая-то от тебя польза https://github.com/ImageMagick/ImageMagick/pull/7095 Вот только imagemagic всё ещё не может сообщить, что в исходнике, а по умолчанию кодирует в 420, как с вебп. Только jpeg:sampling-factor имеется. Чтобы поддерживать конвертацию из avif мне пришлось обмазаться exiftool, и с jpeg это уже YCBCRSubSampling, даже для heic свой формат. И я так смотрю для jpeg imagemagic сам выбирает 444, это обясняет часть дефектов webp (в то же время у jpeg свои артифакты). К слову, из справки jxl следует, что по умолчанию "apply resampling only for very low quality", автор статьи случайно не обнаружил это?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

81. Сообщение от Аноним (81), 18-Окт-26, 11:27	+/–
> Вот за лохматый 2023 сравнение Ну так кодировщики авиф на месте не стояли и улучшили сжатие. Ещё одно недавнее сравнение: https://giannirosato.com/blog/post/case-against-jxl/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

82. Сообщение от Аноним (82), 18-Окт-26, 21:20	+1 +/–
Раньше был JPEG для фотографии и PNG для картинок без потерь. Теперь первое заменяет AVIF, а второе заменяет ...JPEG XL. Иронично.
Ответить | Правка | Наверх | Cообщить модератору

84. Сообщение от Аноним (84), 19-Окт-26, 00:06	+/–
С JPEG и PNG, конечно, уходить никто не собирался
Ответить | Правка | Наверх | Cообщить модератору

85. Сообщение от нитгитлистер (?), 19-Окт-26, 05:17	+/–
про степень шакальности пги высоких уровняфх сжатия он конечно же благополучно умолчал. главное ж доказать исклюбчительно плохоре инжирное решение гугла)) правда все люди как пользовались в быту простым жепегом да пнг так и будут пользоваться пока все производители не обявят этот формкат устаревшим и не начнут насильно пропихивать что-то посвежее
Ответить | Правка | Наверх | Cообщить модератору

87. Сообщение от Аноним (87), 19-Окт-26, 11:10	+/–
> Он может точно так же "выкинуть" из Хрома PNG с JPEG Не может, потому что нормисы знают оба эти формата как "вот в этом прозрачность есть и ничего не кукожится" и "в этом очень смешные кирпичи получаются, но зато фотки мало места занимают". Webp открывается только у людей, которые пользуются адекватным софтом, а не то что шло в комплекте с маздаем, плюс большинство сайтов в силу неизлечимого кретинизма вебдевелоперов воспринимают его в лучшем случае как иконку или "стикер", в худшем как "неправильный формат", а не как изображение. Чекай, ещё лет пять и webp выпишут в легаси, т.к. он нигде кроме как кнопок в вебе не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

88. Сообщение от vitektm (?), 19-Окт-26, 11:25	+/–
Почитал я оригинал в начале статьи думал что avif круче в конце статьи уже так не думал. во первых. Перевод на openNet уж больно срезал углы. Там почти на уровне архиваторов жать может хорошо, но жрать ресурсы как не в себя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

89. Сообщение от vitektm (?), 19-Окт-26, 11:46	+/–
Для Вовочек, для которых "И так сойдет" некоторые не заморачиваются кидают фото в 4к,  в пару мегабай на картинку ужатую в div 700px, ну браузер сам с масштабирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

90. Сообщение от Аноним (90), 19-Окт-26, 13:49	–1 +/–
Возможно, только почему-то в любом телефоне выбор у камеры - фоточки в JPEG (с ограничением по качеству и большими файлами) и HEIC, компактнее и выше качеством. Никакими WebP, AVIF или JPEG-XL даже не пахнет, в том числе в "свободном" андроиде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #91

91. Сообщение от Аноним (16), 19-Окт-26, 18:34	+/–
> Возможно, только почему-то в любом телефоне выбор у камеры - фоточки в JPEG [...] и HEIC, компактнее и выше качеством. Никакими [...] JPEG-XL даже не пахнет Ты из танка-то вылези. Айфоны уже несколько лет используют Jpeg XL для ProRAW.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #92

92. Сообщение от _ (??), 19-Окт-26, 22:26	+/–
Как убедится? Я чёто не обнаружил такого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

93. Сообщение от _ (??), 19-Окт-26, 22:27	+/–
Салага! НАЖДАЧКУ! 8-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

94. Сообщение от Karl Richter (ok), 20-Окт-26, 11:39	+/–
Вполне себе удачная. Сжимает замечательно без каких-то потерь в качестве.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

95. Сообщение от Obito (ok), 03-Ноя-26, 10:33	+/–
Предполагаю, что вы используете слишком большое качество, поэтому не видите разницы. q92 - это же около максимума. Я давно заметил, что все эти новые кодеки показывают лучше визуальное качество только когда стандартный jpeg уже рассыпается на квадратики, есть только некоторые исключения, когда новые кодеки лучше, например как написано в статье, av1 хорошо работает со скриншотами (текст/векторная графика), в отличие от жепегов. Самые обычные фотки, даже шумодавленные сток камерой смартфона, можно сказать никак не выигрывают при использовании новых кодеков. А если взять шумную фотку, которую сделал из raw, то новые кодеки вообще начинают косячить из-за шума. Новые кодеки как будто бы хорошо работают как раз таки только тогда, когда стандартный jpeg работает плохо, то есть с не шумными, не текстурными изображениями, с которыми jpeg выдаёт артефакты DCT. С низкокачественными ИИ картинками и видео новые кодеки работают отлично, тогда как с качественными они бесполезны, если вы не лютый шакал. jpeg xl кстати что-то среднее, он местами похож на стандартный jpeg, только за счёт этого он уже может казаться не таким мыльным как av1. И кстати, стандартный jpeg если что повышает резкость, не знаю это так задумано, или же это фотошоп так экспортирует, но из-за этого av1 кажется мыльным, а по факту он просто не накручивает резкость, а пытается быть как можно ближе к оригиналу, но визуально может показаться что стало мыльцо какое-то, может уже просто привычка к jpeg выработалась за столько то лет его использования. А ещё av1 сильно зависит от настроек. При желании можно сделать его и похожим на стандартный jpeg, но это нужно кодировать например в ffmpeg и потом паковать уже полученный кадр av1 в собственно avif контейнер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

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

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