Опубликована третья редакция формата PNG

Мало аналитики. Какие последствия в мире принесёт это новшество?

Когда APNG-анимации заполонят всю планету, климат станет теплее из-за более сложного алгоритма.

Webp, как и AV1 — это просто какая-то возня, связанная с американскими патентными разборками. И желанием набить карманы.

Конечно AV1 даёт сравнимое качество видео. При меньшем размере. В сравнении с H.264. Но и алгоритм там более сложный. Какая-нибудь ГоПро со своим перегревом и с H.264 справляется так себе.

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

А вывод простой:

• H.264,
• JPEG,
• PNG.

Вот три столпа современного медиа. А надолго ли, неизвестно.

Но APNG сколько не было видно (а только слышно, что он вроде существует), так и не видно. И ничего не изменится. Уж будьте уверены.

Если будешь писать либу для работы с PNG, то будет на что смотреть. То есть последствия исключительно положительные. А если ты в любом прогрессе видишь угрозу, то тут можно много чего придумать. Многие даже карьеру на этом строят.

Еще бы написали, как вот так APNG на кадры разобрать.

В apngasm 3.1.10 вот так: $ apngasm -o output_dir -D <file.png> -j (или -x)?

Почему deflate а не zstandard?

В apngasm 3.1.10 вот так

https://github.com/pnggroup/pngcheck

pngcheck 4.0.0
This version was derived from pngcheck 3.0.3 (see 3.0.3 README) and adds the following new features from PNG Third Edition:

• Coding Independent Code Points cICP
• Mastering Display Color Volume mDCV
• Content Light Level Information cLLI
• Animated PNG acTL, fcTL and fdAT

It also warns if eXIf is found after the image data IDAT, which will be ignored by web browsers and is no longer valid in PNG Third Edition.

Для файла apngasm/test/samples/penguins.png $ pngcheck -c -p -v penguins.png выводит:

File: penguins.png (5753 bytes)
  chunk IHDR at offset 0x0000c, length 13
    76 x 76 image, 8-bit palette, non-interlaced
  chunk acTL at offset 0x00025, length 8
    Animated PNG, 6 frames, plays continuously
  chunk PLTE at offset 0x00039, length 48: 16 palette entries
     0:  (  0,  0,  0) = (0x00,0x00,0x00)
     1:  (255,255,255) = (0xff,0xff,0xff)
     2:  (214,214,214) = (0xd6,0xd6,0xd6)
     3:  (204,217,239) = (0xcc,0xd9,0xef)
     4:  ( 91, 92, 93) = (0x5b,0x5c,0x5d)
     5:  (159,183,220) = (0x9f,0xb7,0xdc)
     6:  (208,235,251) = (0xd0,0xeb,0xfb)
     7:  (  2,  2,  2) = (0x02,0x02,0x02)
     8:  (183,199,226) = (0xb7,0xc7,0xe2)
     9:  (232,238,247) = (0xe8,0xee,0xf7)
    10:  (221,228,241) = (0xdd,0xe4,0xf1)
    11:  (243,246,249) = (0xf3,0xf6,0xf9)
    12:  (132,136,139) = (0x84,0x88,0x8b)
    13:  (119,120,121) = (0x77,0x78,0x79)
    14:  ( 49, 50, 50) = (0x31,0x32,0x32)
    15:  (156,157,158) = (0x9c,0x9d,0x9e)
  chunk tRNS at offset 0x00075, length 1: 1 transparency entry
    0:    0 = 0x00
  chunk fcTL at offset 0x00082, length 26
    Frame, sequence number 0
    Width 76, height 76 starting at (0, 0)
    Frame delay 0 (12 / 100) sec
    No disposal before next frame
    Frame overwrites buffer
  chunk IDAT at offset 0x000a8, length 1137
    zlib: deflated, 8K window, maximum compression
  chunk fcTL at offset 0x00525, length 26
    Frame, sequence number 1
    Width 58, height 65 starting at (1, 9)
    Frame delay 0 (12 / 100) sec
    No disposal before next frame
    Frame composites (source over) with buffer
  chunk fdAT at offset 0x0054b, length 748
    Frame data, sequence number 2
  chunk fcTL at offset 0x00843, length 26
    Frame, sequence number 3
    Width 59, height 68 starting at (1, 5)
    Frame delay 0 (12 / 100) sec
    No disposal before next frame
    Frame composites (source over) with buffer
  chunk fdAT at offset 0x00869, length 682
    Frame data, sequence number 4
  chunk fcTL at offset 0x00b1f, length 26
    Frame, sequence number 5
    Width 72, height 71 starting at (3, 2)
    Frame delay 0 (12 / 100) sec
    Reverts to previous contents before next frame
    Frame composites (source over) with buffer
  chunk fdAT at offset 0x00b45, length 918
    Frame data, sequence number 6
  chunk fcTL at offset 0x00ee7, length 26
    Frame, sequence number 7
    Width 74, height 68 starting at (1, 5)
    Frame delay 0 (12 / 100) sec
    Reverts to previous contents before next frame
    Frame composites (source over) with buffer
  chunk fdAT at offset 0x00f0d, length 880
    Frame data, sequence number 8
  chunk fcTL at offset 0x01289, length 26
    Frame, sequence number 9
    Width 73, height 69 starting at (2, 5)
    Frame delay 0 (12 / 100) sec
    No disposal before next frame
    Frame composites (source over) with buffer
  chunk fdAT at offset 0x012af, length 914
    Frame data, sequence number 10
  chunk tEXt at offset 0x0164d, length 24, keyword: Software
  chunk IEND at offset 0x01671, length 0
No errors detected in penguins.png (18 chunks, 0.4% compression).

Какие последствия в мире принесёт это новшество?

Когда APNG-анимации заполонят всю планету, климат станет теплее из-за более сложного алгоритма.

Наоборот, распаковка уже распространившегося WebP требует больше энергии, а 256-цветные GIF обычно больше размером за счёт псевдосмешения цветов. Экономия будет.

Почему deflate а не zstandard?

Потому, что когда стандарт PNG писали, энтропийное кодирование было закрыто патентами. А APNG, насколько я знаю, сохраняет частичную совместимость с PNG — не знающие про него обработчики PNG должны показать 1-й кадр.

Отсутствие сжатия с потерями это не обязательно минус. Ты всегда знаешь что .png ничего не испортит.

https://github.com/facebook/zstd/wiki/Using-libzstd-in-a-memory-constrained-environment

Спасибо, но конкретных величин там нет.

Но кое-что нашёл в man zstd. По умолчанию обещает укладываться в 128M, видимо, для режимов сжатия 1-19, а для требующих особый ключ 20-22 требуется больше. matching distance можно увеличить до 2G, видимо, такого порядка максимальное потребление памяти для распаковки.

Вот бенчмарки: https://morotti.github.io/lzbench-web/
Оказалось, выше я писал про результаты для синтетического теста.
В бенчмарке для словаря Вебстера степень сжатия и скорость сжатия zstd 19, lzma 9 и xz 9 примерно одинаковая. Уровни ниже несильно меняют скорость lzma/xz, но степень сжатия падает с 5 до 3, почти до уровня zlib. Для zstd сжатие падает аналогично, но скорость возрастает до 200 раз.
А вот с изображениями у zstd значительно хуже. Для одного (рентгеновский снимок) сжатие zlib — 1.4, zstd — 1.25-1.65, lzma/xz — 1.6-1.9; умолчальный zstd -3 сжимает хуже zlib, но быстрее всех — 50 lzma или 3 zlib; на высоких степенях выигрыша в скорости у zstd нет. Для другого (ЯМР-томограмма) zlib — 2.6-2.7, zstd — 2.5-3.2, lzma/xz — 3.2-3.7; и опять zstd -3 сжимает хуже zlib. Скорость распаковки изображений zstd в 2-3 раза выше zlib и в 60-90 lzma/xz.

То есть, для использования ZSTD в PNG нужно подобрать другие рекомендуемые параметры, чтобы сжимать не хуже Deflate. Сколь-нибудь заметный выигрыш в сжатии сильно снизит скорость сжатия. И даже так другие алгоритмы сжимают лучше.

А вот для текстов ZSTD хорош.

Отсутствие сжатия с потерями это не обязательно минус. Ты всегда знаешь что .png ничего не испортит.

Да, это полезно для промежуточных результатов. Или когда нужно точно сохранить каждый пиксел. Но потери дают сжатие в десятки раз вместо 2-3 при незаметном снижении качества.

Deflate на современных процессорах работает практически мгновенно.

Ещё через 20 лет ждём исправление этой ключевой баги

При незаметном снижении - всего в пару раз если аккуратно. Но и точное сохранение - тоже важно, как и apng для видео. Формат просто не пытается усложнять и делает своё маленькое нужное дело.

Ужас. Когда-то в далеком прошлом, будучи школотой, я делал записывалку экрана в текстовом режиме для доса. Работать это должно было на страшно древних машинах (аля Искра 1 МГц). Мне это удалось, и даже удалось изобрести быстрое сжатие как последовательностей (одинаковых символов), так и видеоряда (если символ не сменился то мы его не пишем). Получилось компактно и быстро.

Удивительно что APNG с подобной задачей не справляется :-(

анимированные изображения APNG.

Не прошло и 20 лет… Быстро ребята управились.

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

А вот нужен ли он сейчас, это конечно большой вопрос.

Хорошая вещь, была 30 лет назад. Почему сейчас её до сих пор не заменили на flif или jpeg xl для меня загадка.

jpeg xl лучше всех 3 вариантов, но один из разрабов хромого является автором avif.

При незаметном снижении - всего в пару раз если аккуратно.

Зависит от изображения и наблюдателя. Для WebP я экспериментально установил, что при разрешении 1920x1080 для качественных фотографий и сложных 3D рендеров не могу отличить от оригинала качество 76% (на 75% уже вижу артефакты). Это 50-150 килобайт на файл WebP или 2-3 мегабайта в PNG. Для отсканированных чёрно-белых страниц книги — допустимы ещё большие потери.

Не прошло и 20 лет… Быстро ребята управились.

Несколько конкурирующих стандартов. Кто-то двигал MNG, кто-то — тег <video>.

https://www.linux.org.ru/images/22059/original.png

Подумалось сейчас, что этот логотип отлично иллюстрирует компьютерную графику середины 1990-х.

Страннно, практически в любых веб-П в интернете я вижу блюр мелких деталей. Хотя да, размеры картинки радуют.

не знаю по каким закаулкам интернета ты там бродил чтобы обнаружить скример в апнг

у меня виртуалка с ие есть чтоб всякие видеокамеры и регистраторы работали.

а что с ISO OSI не так? вроде все как есть

Вот например сделал скрин ЛОРа в .пнг и перекодировал гимпом в .джипег 95% и .вебп 95%. Исходный 257Кб, джипег 408кб (wtf?!) и вебп 174Кб. Исходник максимально чистый, джипег самый грязный по артефактам, вебп имеет размытие и неточности на острых границах, но почти незаметно. Без приближения да, на глаз и не зная что и где искать - все три не отличить.

А вот если сжимать в качество 70%, то .джпег становится 193кб, а .вебр 95Кб. Первый весьма характерно шакалит шумом, а второй блюрит, пастелит цвета и внекоторых местах появляются вполне конкретные артефакты.

скрин ЛОРа в .пнг

Не считая аватаров, очень небольшое число цветов. Думаю, в 16-цветный GIF сжалось бы ещё лучше :)

Действительно, для скриншотов без фотографий PNG лучше JPG. Знаю фирму, где за скриншоты в JPG угрожали лишить премии :)

пастелит цвета

Что я совершенно не замечаю. Это и имел в виду "зависит от наблюдателя.

вебп имеет размытие и неточности на острых границах

Которые на фотографиях большая редкость. Особенно, если фотография была 95% JPEG-ом :)

Знаю фирму, где за скриншоты в JPG угрожали лишить премии :)

И правильно делали! Текст на скринах частый гость, а фотографии - нет. Так что .пнг монжо считать официальным форматов для скриншотов.

Которые на фотографиях большая редкость. Особенно, если фотография была 95% JPEG-ом :)

Нет, они там всегда есть, только без увеличения и первым пережатием не ловятся взглядом, а в случае сложной фотографии - вообще хрен разберёшь где текстура а где артефакты. Но .пнг гарантирует что и через 1000 последовательных пережатий исходное изображение не изменится, а вот форматы с потерями даже в качестве 100% оставят пространство для сомнений.

а что с ISO OSI не так? вроде все как есть

Ethernet ещё конкурировал с Token Ring и оба были избыточны для диалапа, TCP/IP уже вышел из ARPANET и захватывал академический мир, но компании ещё суетились с IPX/STX и прочими стеками, разработчики реализовывали согласование представления между клиентом и сервером прямо в коде прикладного уровня, довольствуясь обычными программистскими абстракциями, а не возможностями стека, которых обычно и не было. Когда были нужны сеансы, они уже были в TCP. И тут пришли стандартизаторы и придумали идеальную семиуровневую матрёшку в вакууме.

Академическая ценность у модели OSI есть: надо же уметь соотносить стеки других с другом, отличать биты в PPP от причуд и хитростей двух общающихся модемов, данные от представления. Но это даже не стандарт в привычном смысле, где любая домохозяйка может сварить дома докторскую по ГОСТу, а оторванный от практики и потребностей индустрии стандарт по написанию стандартов. Эталонной реализации OSI, насколько мне известно, так и не случилось, ибо оказалось ненужно.

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

Поэтому сжатие с потерями должно применяться всего один раз, к окончательному результату.

Но это даже не стандарт в привычном смысле

Сам придумал, сам опроверг.

То есть, для использования ZSTD в PNG нужно подобрать другие рекомендуемые параметры, чтобы сжимать не хуже Deflate. Сколь-нибудь заметный выигрыш в сжатии сильно снизит скорость сжатия. И даже так другие алгоритмы сжимают лучше.
А вот для текстов ZSTD хорош.

Снимок экрана сохраненный в .bmp zstd сжимает чуть лучше чем gzip
Большую фотографию сохраненную в .bmp (50мб) сжимает чуть хуже(на 40кб из 25мб) но зато в 3 раза быстрее и это заметно на глаз.

Если использовать степень сжатия -6 на фотографию то у gzip получается 25мб а у zstd 22мб и примерно вдвое быстрее отрабатывает.
На скриншот 5.2мб gzip-234kb zstd-208kb

То есть zstd -6 по скорости в 2 раза лучше, по сжатию несильно но заметно лучше.

-9 (zstd всё ещё заметно быстрее)
gzip=224kb 24.7mb
zstd=157kb 21.2mb

-19e
zstd=133kb 18.4mb но очень долго, раз в 10 дольше чем gzip на -9


xz=123kb 17.2mb (очень долго, примерно как zstd -19e)
xz -9=123kb 17mb(чуть дольше)

А как же x265 и heic соответственно?

Тоже вполне популярный формат, проприетарный но поддерживается везде, айфончики вот в него снимают, а их много.

Heic это если что контейнер (без лицензионных ограниченрй) в котором и av1 может быть, речь именно о нём с hevc внутри

h265 разве проприетарный?

По-моему у него проблема в том что поддерживается он как раз далеко не везде, тормозное декодирование на проце конечно везде можно всунуть (это любого формата касается), но это не полная поддержка.

Если ты крошишь в лапшу и сшиваешь скриншоты или сканы - следить за этим отдельно не интересно. А так всё что в .пнг без потерь, всё что не в .пнг - финальный результат.

Проприетарный не в том смысле что отсутствуют декодеры с открытым (и даже свободным) исходным кодом, а в том что требует лицензионных отчислений.

Та же история что и с MP3 до относительно недавнего времени.

Даже с реализацией h264 вроде есть подобные проблемы, в Федоре например он отдельной репой идёт от cisco.

Raspberry pi вон отдельные ключи продаёт лицензионные для удешевления стоимости железки.

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

сысле не случилось? оно работало отлично уже с выходом винды 95 когда ресурсов наконец хватило всем чтобы это реализовать. а сейчас даже сверху оси уже успели накидать.

через 1000 последовательных пережатий исходное изображение не изменится, а вот форматы с потерями

сжатие с потерями и деградация при пересжатии не всегда связаны. есть форматы с потерями позволяющие пересжимать без деградации, то есть повторное сжатие становится no-op действием, правда я не помню что за формат и в каких обстоятельствах для него это работает. кстати у jpeg если я не путаю возможно как бы редактирование с образованием нового jpeg без деградации: вроде бы кадрирование выравненное на 8 и поворот на 90 градусов.

сысле не случилось? оно работало отлично уже с выходом винды 95 когда ресурсов наконец хватило всем чтобы это реализовать.

В Windows 95 отлично работали сетевые карточки и модемы, поверх них - TCP/IP, при желании данные прикладного уровня пихались в NetBIOS, который, вроде как, сеансовый.

Итого, 5–6 уровней, из которых сеансовый почти не нужен. Где эталонная реализация, в которой прикладной уровень складывается в уровень представления, уровень представления всегда пакуется в сеансовый, и только сеансовый - в транспортный и так далее по списку?

Оно бы, может, и хорошо было. Допустим, мы бы не имели проблем с кодировками задолго до изобретения Юникода, многие серверы сжимали бы трафик с потерями под узкий канал, как прокси в Opera. Или даже разжимали бы условный flac в условный waw для тупых устройств на широком канале. Прикладной стек (в понимании TCP/IP) был бы более свободный, открытый, взаимосовместимый вместо растущего зоопарка замкнутой на себя проприетарщины. Но не сложилось.

а сейчас даже сверху оси уже успели накидать.

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

сысле сеансовый почти не нужен? а как же диалап? а как же впны?

сысле сеансовый почти не нужен? а как же диалап?

У тебя диалап поверх TCP/UDP работает, как положено протоколу сеансового уровня? Нет. Просто модем звонит модему, оба договариваются о режиме передачи на физическом уровне, все вышестоящие уровни видят просто канал.

а как же впны?

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

Давай тогда везде, где есть сеанс, видеть протокол сеансового уровня. Ethernet воткнул, произошло согласование режима - сеанс. В ARP-таблице существует запись - сеанс. Выданы по DHCP и действуют сетевые настройки - сеанс. VoIP своими силами умеет определять начало и конец звонка - сеанс.