[Назад]
Ответ в нить
Animapcha image [@] [?]
Тема   ( ответ в 185114)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов GIF, JPG, MP4, OGV, PNG, WEBM, WEBP размером до 5000 кБ.
  • Ныне 3075 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 375
quote1.webp - (757.85KB, 2458×9088)
185114
No. 185114  
На 410чанѣ съ начала апрѣля 2021 года и по вторую половину января 2022 года совершалося цѣнное обсужденіе многихъ вопросовъ о томъ, какъ умѣстно сохранять изображенія въ графическихъ файлахъ. Его архивъ https://410chan.org/b/arch/res/158687.html донынѣ хранитъ и наглядные примѣры сильнаго сжатія изображеній, и подробные списки достоинствъ нѣкоторыхъ форматовъ графическихъ файловъ, и образцы иллюстрацій, способныхъ помѣщаться на 410чанъ только послѣ переужатія, а не механическаго копированія ихъ изъ первоисточника.

Не мало тамъ было сказано и словъ о томъ, слѣдуетъ ли для сохраненія кадровъ видео прибѣгнуть къ формату, предусматривающему сжатіе съ потерями (какъ JPEG или lossy WebP), или же умѣстно потратить большій объёмъ файла (въ форматѣ PNG или въ lossless WebP), но той цѣною достигнуть неизмѣнности пикселовъ.

Желая возобновить тутъ обсужденіе графическихъ файловъ, я радъ видѣть для того вѣскій поводъ: въ FFmpeg въ нынѣшнемъ мѣсяцѣ появилась возможность сохранять какой угодно ключевой кадръ из видео AV1 въ файлѣ AVIF, но при этомъ зря не тратится объёмъ файла (какъ было бы при перекодированіи въ форматъ безъ потерь), зря не тратится качество кадровъ (какъ было бы при перекодированіи съ потерями), зря не тратится и то время, которое уходило бы на перекодированіе, а вмѣсто того всѣ свѣдѣнія о пикселахъ ключевого кадра сохраняются «какъ есть» безъ перекодированія, то есть точно въ томъ же прежде сжатомъ видѣ, какой онѣ ужé имѣли въ видеопотокѣ AV1, и снабжаются только новымъ заголовкомъ, приличествующимъ файлу AVIF.

Сохранить ключевой кадръ этимъ способомъ можно одною командою:

ffmpeg -hide_banner -i имяФайлаAV1 -ss времяКадра -frames:v 1 -c:v copy кадръ.avif

Въ сообщеніи по адресу https://t.me/ReadMithgol/491 (растровую копію котораго я прилагаю и тутъ для наглядности) и затѣмъ ещё по адресу https://t.me/ReadMithgol/492 я поподробнѣе разсмотрѣлъ то мѣсто и значеніе, которое эта новинка FFmpeg получаетъ, по моему мнѣнію, въ общей исторіи подходовъ ко сжатію видеокадров и въ исторіи развитія графическихъ форматовъ для храненія изображеній. Ясно вижу, что подобное достиженіе могло явиться на цѣлое десятилѣтіе ранѣе (предпосылки были), однако же не явилося.
No. 185115  
quote2.webp - (753.15KB, 2459×8656)
185115
Дополняя предшествующій абзацъ, растровую копію сообщенія https://t.me/ReadMithgol/492 также прилагаю тутъ, чтобъ не осталася одна она неприложенною.
No. 186531  
Если отрывок аниме хочется процитировать не в форме видеозаписи, а в форме анимированного графического файла, то высшей формою такого цитирования со временем сдѣлается, безспорно, анимированный файл AVIF, который по сути будет содержать видеодорожку AV1 съ измѣнённымъ заголовком файла, не болѣе.

Но AVIF пока ещё не поддерживаются на 410чанѣ и во многих других мѣстахъ (в частности, браузер Firefox ещё не научили показывать анимированные AVIF, а браузер Safari не способен показывать вообще никакие AVIF).

Появлению AVIF предшествовало появление WebP, и этот чуть болѣе ранний формат (много шире сейчас поддерживаемый) также способен хранить анимации, но гораздо менѣе эффективно, чѣмъ видеодорожка, да притом ещё алгоритм сохранения анимаций с внесением потерь в формате WebP не свободен от упоминаемой по адресу https://bugs.chromium.org/p/webp/issues/detail?id=523 ошибки, приводящей к накоплению артефактов сжатия, имѣющихъ блочный вид.

Альтернативным путём создания WebP с внесением потерь может поэтому быть сочетание двух шагов:

① Сперва при помощи https://gif.ski/ создаётся анимированный GIF, что сопровождается внесением потерь цвѣтности (не болѣе 255 цвѣтовъ в одном кадре) и может сопровождаться внесением дополнительных потерь (через значение параметра «--quality» при вызове gifski).

② Затѣмъ утилитою gif2webp (имѣющеюся в составе libwebp) этот GIF преобразуется в формат WebP без внесения дополнительных потерь.

Два знания способны улучшать собою отношение качества кадров к объёму анимированных WebP:

⓵ По адресу https://twitter.com/PascalMassimino/status/1199942743998574592 справедливо подмѣчено, что по умолчанию gif2webp работает с расчётом на то, чтобы анимированный WebP поменьше жрал память браузера и побыстрѣе проматывался к нужному кадру (на случай возобновления анимации), поэтому может создавать больший объём файла (при равном качестве кадров), чѣмъ даже APNG иногда — а вот если вызвать gif2webp с параметром «-min_size», то объём файла будет минимизирован.

⓶ Но и у gifski, начиная с вышедшей въ нынѣшнемъ мѣсяцѣ версіи 1.7.0, появился параметр «--extra», употребление которого в два раза замедляет работу, но очень немного улучшает качество кадров.

Сочетание того и другого параметра позволяет нарастить высоту кадров анимации >>167983 (кодируя тот же отрывок аниме «Accel World», взятый на сайте Animeloop до его закрытия, и по-прежнему при 100% качества gifski, то есть без нарочного внесения потерь) до 797 пикселов (а в сообщении >>167983 высота была 762 пиксела), оставаясь в рамках 410чановского 5000килобайтового ограничения объёма файла. (Файл прилагаю.)

Роль параметра «--extra» в этом тридцатипятипиксельном нарастании высоты кадров очень невелика и равняется примѣрно двум пикселам — это меньше ⅓% высоты кадра. Приходится умозаключить, что обещанное благотворное влияние этого параметра на качество кадров GIF не сопровождается ни существенным сокращением объёма файла, ни крупным ростом его WebP-сжимаемости.
No. 186533  
Версия анимации >>/dev/26098, созданная вызовом gifski и gif2webp с указанными выше параметрами, при прежнем размѣрѣ кадра (fullHD 1920×1080) оказывается меньше на 25,07% по объёму файла.
No. 186551  
Растровая копия сообщения https://t.me/ReadMithgol/478 (к сообщению >>/dev/26120 прилагаемая) завершалася (въ предпослѣднемъ абзацѣ) упоминанием о том, что освоение gifski позволяет отойти от употребления байеровских узоров в GIF (при всѣхъ их достоинствах, перечисленных в предшествующем там сообщении), так как gifski может в случае нужды сохранять GIF ещё меньшего объёма (но и меньшего качества) и подбирает новую палитру для каждого кадра.

В сочетании с дополнительным WebP-сжатием GIF-файлов это приводит, напримѣръ, к тому, что GIFка с байеровскими узорами, к сообщениям >>/a/14604 (в 2018 году) и https://410chan.org/b/arch/res/158687.html#158964 (в 2021 году) прилагавшаяся с высотою кадра 312 пикселов, приобретает в формате gifski-в-WebP высоту кадра 339 пикселов без узорчатости (результат прилагаю) и всё ещё с максимальным качеством («gifski --extra --quality 100»), то есть безъ намѣреннаго внесения потерь, которое позволило бы ещё далѣе наращивать высоту кадра, оставаясь внутри 410чановского 5000килобайтового предѣла объёма файла.
No. 186616  
Если же прибѣгнуть ко сжатию с потерями, то анимированный WebP, к сообщению >>175636 приложенный, становится меньше на 0,70% (результат прилагаю) при прежнем размѣрѣ кадра (fullHD 1080p) и прежнем качестве (87 баллов).
No. 186617  
>>186616
Как измерять качество (в баллах) картинки?
No. 186619  
>>186617

Тут рѣчь идёт не объ измѣренномъ качестве, а о заданном качестве (от 1 до 100 баллов), от которого зависит уровень потерь (командная строка начиналася словами «gifski --extra --quality 87»).
No. 186620  
Сообщение >>186616 мне следовало бы начинать не словами «Если же прибѣгнуть ко сжатию с потерями…», а поподробнѣе: «Если же провѣрить, как с параметрами min_size и extra, в сообщении >>186531 упомянутыми, ведёт себя результат сжатия с потерями…» — получилось бы многословнѣе, но и однозначнѣе.
No. 186621  
>>186619
А, блин.
No. 186623  
84192411_p11.jpg - (130.34KB, 1000×750)
186623
>>186617
Для видео VMAF довольно популярная метрика, для статичных картинок работают старые SSIM и PSNR, но результат этих двух баллами не является.
No. 186624  
>>186621
No. 186627  
>>186624
А почему нос в саже?
No. 186654  
>>186627
маскируеца
No. 186659  
>>186654
Не пойми не правильно, я просто первую понравившуюся картику по тегу chibi.
No. 186720  
Прежде упомянутое мною в сообщении >>186640 появление настройки матриц квантования в кодировщике SVT-AV1 (состоявшееся 19 июня) обратило собою моё внимание на тот факт, что аналогичная настройка (также выключенная по умолчанию) не первый год существует и в кодировщике libaom-av1.

Слѣдовательно, эта настройка имѣетъ практический смысл при кодировании изображений в формате AVIF.

Я критически пересмотрѣлъ содержимое командной строки, ≈год назад (27 июня 2021 года) в сообщении https://410chan.org/b/arch/res/158687.html#162187 составленной на основании прочитанных по адресу https://old.reddit.com/r/AV1/comments/o7s8hk/high_quality_encoding_of_avif_images_using/ совѣтовъ — и тотчас же убедился, что отбросил рекомендуемый там параметр «-a color:enable-qm=1» (потому что автор совѣтовъ не объяснил его необходимость, как объяснял суть большинства других параметров) и тѣмъ привёл рекомендуемый там параметр «-a color:qm-min=0» к неработоспособности.

Но похоже и на то, что не один я, но ещё и автор тѣхъ совѣтовъ мало и недостаточно разбирался тогда с матрицами квантования. Параметр «-a color:qm-min=0» он рекомендует словами «provides a higher quality ceiling» (то есть «обеспечивает болѣе высокий потолок качества»), тогда как реальный смысл этого параметра противоположен (значение параметра qm-min задаёт собою не потолок, а днище качества ѿдѣльныхъ блоков изображения).

Сейчас (через год) я могу предположить, что автора тѣхъ совѣтовъ сбило с толку внешнее сходство сокращений «qm» и «qp», первое из которых означает матрицу квантования, а второе — параметр квантования, уменьшение которого реально повышает точность квантования и оттого наращивает качество кадров. С матрицами квантования (нумеруемыми от нуля до 15) положение дѣлъ противоположно: чѣмъ ближе номер матрицы к нулю, тѣмъ хуже качество кадра ввиду подавления короткопериодических пространственных компонентов.

Вооружённый этим новым пониманием, я вызвал кодировщик avifenc свѣжей сборки версии 0.10.1 (использующей libaom-av1 версии 3.3.0) с параметрами «--jobs 8 --codec aom --speed 0 --depth 10 --minalpha 0 --maxalpha 0 --min 0 --max 63 --advanced end-usage=q --advanced tune=ssim --advanced color:enable-qm=1 --advanced color:qm-min=0 --advanced color:qm-max=8 --advanced cq-level=42».

Вы можете видѣть, что эти параметры используют как тридцатибитность пикселов (то есть ту десятибитную цвѣтовую глубину компонентов цвѣта, благотворность которой я упоминал в сообщении https://410chan.org/b/arch/res/158687.html#165230 6 октября прошлого года), так и загрубление мелких деталей цвѣтовыхъ каналов (не только днище качества достигнуто параметром «qm-min=0», но и потолок понижен почти вдвое параметром «qm-max=8», значение которого по умолчанию равнялось бы 15), значение же cq-level уменьшилось на единицу, достигнув 42 (связанный с этим рост качества и объёма файла компенсируется замѣною матриц квантования цвѣтовыхъ каналов, ухудшающею качество этих послѣднихъ).

Результат работы этой команды я вынужден расположить не на 410чане, а по адресу https://z.zz.fo/8aILh.avif (поскольку 410чан, как я в сообщении >>/dev/26279 упоминал, не имѣетъ никакой надежды получить поддержку AVIF в 2022 году), но тут я приложу результат декодирования этого файла в PNG.

Вы можете видѣть, что результат (файл AVIF) занимает 20243 байта, оставаясь чуть меньше расположенного по адресу https://410chan.org/b/arch/res/158687.html#158719 шакального JPEG с его 20260 байтами. Сравнение этого результата с показанным 6 октября в сообщении https://410chan.org/b/arch/res/158687.html#165230 позволяет увидѣть, что сегодняшний файл лучше передаёт полосчатость борта судна и содержит много меньше шумов квантования («мыльных волн») вокруг объектов, освѣщённыхъ (или свѣтлыхъ въ тѣни) на носу судна. Остальные улучшения незначительны и малозамѣтны (только быстрое переключение между изображениями способно открыть их зрителю).

Всѣ эти улучшения я отношу единственно на счёт уменьшившегося cq-level, так как они имѣютъ яркостную (а не цвѣтностную) природу и оттого не могли быть порождены подавлением короткопериодических пространственных компонентов въ цвѣтовыхъ каналах.

Дальнѣйшее же развитие этого успѣха в том же направлении оказывается невозможным: снижение величины cq-level до 41 не позволяет файлу AVIF быть меньше шакального JPEG, даже если qm-max обнулить вслѣдъ за qm-min.
No. 186736  
disappointment.png - (8.04KB, 90×50)
186736
>>186720
Хотя задокументировано это было совсем недавно, вы, как люди столь просвещенные, могли бы и

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9363937
[страница 14, F. Quantization]

а потом, к примеру,

https://aomedia.googlesource.com/aom/ /f7a1242075b91e2c8ae922278e0170a3780bbcd3^!/#F0
[в самом верху, предложение, начинающееся на "AOM can operate with"]

Этот коммит был аж в 2018 году. Вы должны были бы без труда догадаться, что эти "математики" под плоской матрицей (простаковатое название, если честно, но что самое главное — нигде в то время не документируемое {во всяком случае, я ничего не нашел} и в математике, насколько я могу судить по выдаче разных поисковиков, не слишком популярное) имеется ввиду, что коеффициенты матрицы квантования мало отличаются друг от друга (а что еще это могло бы значить?), а стало быть, на разных частотах отрезания качества будет более ровным, так что и вправду, qm-min=0 понижает днище, а не повышает потолок, потому что "плоскота" матрицы увеличивается по мере увеличения уровня матрицы квантования, как в том коммите и и записано.
Удалить сообщение []
Пароль  
[Mod]