Дополняя предшествующій абзацъ, растровую копію сообщенія https://t.me/ReadMithgol/492 также прилагаю тутъ, чтобъ не осталася одна она неприложенною.

Если отрывок аниме хочется процитировать не в форме видеозаписи, а в форме анимированного графического файла, то высшей формою такого цитирования со временем сдѣлается, безспорно, анимированный файл 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-сжимаемости.

Версия анимации >>/dev/26098, созданная вызовом gifski и gif2webp с указанными выше параметрами, при прежнем размѣрѣ кадра (fullHD 1920×1080) оказывается меньше на 25,07% по объёму файла.

Растровая копия сообщения 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килобайтового предѣла объёма файла.

Если же прибѣгнуть ко сжатию с потерями, то анимированный WebP, к сообщению >>175636 приложенный, становится меньше на 0,70% (результат прилагаю) при прежнем размѣрѣ кадра (fullHD 1080p) и прежнем качестве (87 баллов).

>>186616
Как измерять качество (в баллах) картинки?

>>186617

Тут рѣчь идёт не объ измѣренномъ качестве, а о заданном качестве (от 1 до 100 баллов), от которого зависит уровень потерь (командная строка начиналася словами «gifski --extra --quality 87»).

Сообщение >>186616 мне следовало бы начинать не словами «Если же прибѣгнуть ко сжатию с потерями…», а поподробнѣе: «Если же провѣрить, как с параметрами min_size и extra, в сообщении >>186531 упомянутыми, ведёт себя результат сжатия с потерями…» — получилось бы многословнѣе, но и однозначнѣе.

>>186619
А, блин.

>>186617
Для видео VMAF довольно популярная метрика, для статичных картинок работают старые SSIM и PSNR, но результат этих двух баллами не является.

>>186621

>>186624
А почему нос в саже?

>>186627
маскируеца

>>186654
Не пойми не правильно, я просто первую понравившуюся картику по тегу chibi.

Прежде упомянутое мною в сообщении >>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.

>>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 понижает днище, а не повышает потолок, потому что "плоскота" матрицы увеличивается по мере увеличения уровня матрицы квантования, как в том коммите и и записано.

14 июля по адресу https://webkit.org/blog/12998/release-notes-for-safari-technology-preview-149/ сообщили (скриншот прилагаю) о том, что поддержка просмотра графических файлов AVIF обеспечена во браузере Safari в операционных системах macOS 13 (Ventura) и iOS 16.

Пока что рѣчь идёт только о предпросмотровой версии браузера (Safari Technology Preview 149).

Но не спѣшите затаить дыхание в предвкушении: тѣ обстоятельства, которыя в сообщении >>/dev/26279 упомянуты, помѣшаютъ нам тотчас же воспользоваться новинкою (то есть обеспечить поддержку AVIF на 410чане).

А теперь к другим новостям. Вышла новая версия libwebp (версия 1.2.3), отличающаяся повышенною точностью препроцессора sharp_yuv, болѣе постепенным отображением числа процентов законченности работы в ходе сжатия, совершаемого без потерь, а также исправлением цѣлаго ряда ошибок. Обновляйтеся.

Не прошло и двух мѣсяцевъ опосля предшествующего сообщения (>>188016), а поддержка AVIF ужé вчера (12 сентября) была объявлена в релизе (то есть в окончательной, ужé не в тестовой версии) браузера Safari на iOS 16.

По адресу https://www.apple.com/newsroom/2022/09/ios-16-is-available-today/ сообщается о выпуске iOS 16, а по адресу https://webkit.org/blog/13152/webkit-features-in-safari-16-0/ сообщается о поддержке AVIF в релизе Safari на этой системе (скриншот прилагаю).

Там же пишут, что въ слѣдующемъ мѣсяце (в октябре) поддержка AVIF в Safari 16 появится и на macOS 13 (Ventura), и на новой версии системы iPadOS.

В этом объявлении видно, что поддержка анимированных AVIF не заложена в Safari 16, так что вмѣсто анимированных AVIF будет показываться только первый кадр.

Это соѿвѣтствуетъ поведению браузера Firefox, который также не поддерживает анимированные AVIF и показывает поэтому только первый кадр.

Судьба анимированных AVIF отчасти должна напомнить нам о судьбе анимированных PNG, поддержка которых появилась в Firefox 3 в 2008 году, в Safari 8 в 2014 году, в Chrome 59 в 2017 году, то есть без мáлого на девять лѣтъ позже Файерфокса. Но разница теперь противоположна: в случае с анимированными AVIF браузер Chrome первым реализовал поддержку, тогда как Firefox и Safari медлят.

Другая и болѣе мрачная разница состоит в том, что к 2022 году достаточно широкое употребление в WWW приобрёл элемент picture языка HTML5, посредством которого автор сайта может предложить браузеру нѣсколько форматов одной и той же иллюстрации, а браузер должен выбрать первый им поддерживаемый формат файла, скачать его и показать. Но увы! — к сожалению, провѣрка поддерживаемости реализована «спустя рукава»: Firefox считает, что поддерживает AVIF, поэтому скачает анимированный AVIF (и покажет только первый кадр его) там, гдѣ слѣдовало бы скачать болѣе ранний формат анимации (анимированный GIF, анимированный PNG, анимированный WebP — смотря что было указано в теге picture) и показать всю анимацию цѣликомъ. Пользовательский опыт в силу этого страдает, так что по сути такое поведение — это баг (по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1739210 в Багзилле). И вот теперь по адресу https://github.com/Fyrd/caniuse/pull/6448#issuecomment-1245020390 упоминается, что совершенно на эти же грабли наступили и разработчики браузера Safari!

(А для удобства тѣхъ, кто пожелает репостнуть в Телеграме всё сказанное выше, я загодя приготовил сообщения https://t.me/ReadMithgol/524 и https://t.me/ReadMithgol/525 на моём канале — можете их теперь репостнуть.)

Компания Apple сошла съ тѣхъ грабель, которые в сообщении >>193168 были упомянуты въ предпослѣднемъ абзацѣ: по адресу https://webkit.org/blog/13399/webkit-features-in-safari-16-1/#animated-avif объявлено 24 октября, что браузер Safari (начиная от версии 16.1) теперь поддерживает оба варианта графических файлов стандарта AVIF: и статические, и анимированные AVIF — во всѣхъ новѣйшихъ эппловских операционных системах (iOS 16, iPadOS 16, macOS Ventura).

Скриншот прилагаю.

Разработчики Google Chrome готовятся депрекейтнуть JPEG-XL

Собственно, сабж: https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL

Google Chrome has offered JPEG-XL (JXL) image support via a feature flag (chrome://flags/#enable-jxl) since Chrome 91 while with Chrome 110, Google is looking at deprecating this still-fresh-and-new image format.

Теги: всё пропало

https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reasons

Following yesterday's article about Google Chrome preparing to deprecate the JPEG-XL image format, a Google engineer has now provided their reasons for dropping this next-generation image format.

As noted yesterday, a patch is pending for the Google Chrome/Chromium browser to deprecate the still-experimental (behind a feature flag) JPEG-XL image format support from their web browser. The patch marks Chrome 110 and later as deprecating JPEG-XL image support.

No reasoning was provided for this deprecation, which is odd considering JPEG-XL is still very young in its lifecycle and has been receiving growing industry interest and support. Now this evening is a comment from a Google engineer on the Chromium JPEG-XL issue tracker with their expressed reasons:

"Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons:

― Experimental flags and code should not remain indefinitely
― There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
― The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
― By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome"

>>196519
Обиделись, что вебп не взлетел?

>>196520
Просто корпоративные баки, занимающиеся фигнёй в своих офисах с безлимитным овсяно-шоколадным печеньем: захватом власти над вебом (и безуспешно - другими рынками), вместо того чтобы чтобы настройку для убирания раздражающей всех панельки файлов сделать.
https://bugs.chromium.org/p/chromium/issues/detail?id=8966
> So 6 years in couple of days for this issue! A single checkbox! Happy birthday! This issue is all grown up and going to school soon!

Там, кстати, внезапно ПНГшники зашевелились: https://www.w3.org/blog/news/archives/9718

>>196520
WebP — это давно прошлый век уже.
Скорее обиделись, что у ихнего AVIF есть вполне уделывающий этот AVIF конкурент, который — в отличие от — поддерживает сжатие даже уже пожатых JPEGом JPEGов без потерь и реконструкцию обратно в обычный JPEG.

>>196536
А, ну тем более.

> www.phoronix.com
Ололо.

Попытка рационализации «Google предпочитает собственный формат AVIF чужому формату JPEG XL», сообщениями >>196536 и >>196538 предпринятая, может и должна считаться беспочвенною, потому что JPEG XL — это не менѣе, а болѣе гугловский формат графических файлов, чѣмъ AVIF.

AVIF является гугловским только на треть, потому что основан на формате AV1, совмѣщающемъ идеи VP10 (Google) с идеями Thor (Cisco) и Daala (Фонд Xiph.Org, Фонд Мозиллы).

JPEG XL же является гугловским наполовину, потому что совмѣщаетъ идеи формата PIK (Google) и формата FUIF (Cloudinary).

Так что даже мысль про сверхъестественные причины происходящего (скажем, «один из ключевых разработчиков в микроблоге https://twitter.com/jyzg открыто выступает на стороне Украины против России и за то его Бог наказал неудачею формата») имѣла бы под собою чуть больше почвы и чуть меньше противорѣчія дѣйствительности.

Чтобы вѣрно сохранить файл, к сообщению >>196585 приложенный, поневоле пришлось прибавить параметр «-metadata icc» к той командной строке, с которою вызывается кодировщик cwebp, входящий в состав пакета libwebp.

Пришлось это потому, что первоисточник (PNG, по адресу https://www.pixiv.net/artworks/77713849 или https://danbooru.donmai.us/posts/4464772 находимый) содержал ICC-профиль с указанием цвѣтового пространства Adobe RGB (1998), а не того цвѣтового пространства sRGB, которое по умолчанию принято в Интернете — слѣдовательно, насыщенные тёмно-голубые и зелёно-голубые цвѣта превратились бы въ сѣро-стальные и тёмно-зелёные, если ICC откусить.

Затѣмъ я пошёл по адресу https://en.wikipedia.org/wiki/Adobe_RGB_color_space и https://www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm (скриншот прилагаю) и прочитал про цвѣтовое пространство Adobe RGB (1998) и про его отличия от sRGB.

Отличия там два:

① Из тройки цвѣтовъ RGB средний (G, зелёный) отодвинут в Adobe RGB (1998) в область болѣе насыщенного зелёного цвѣта. Поэтому в Adobe RGB (1998) зелёный цвѣтъ является болѣе «голубовато-зелёным», чѣмъ в sRGB — или, что то же сáмое, зелёный цвѣтъ в sRGB является болѣе «желтовато-зелёным», чѣмъ в Adobe RGB (1998). Также поэтому Adobe RGB (1998) охватывает на ≈40% больше цвѣтовъ — или, что то же сáмое, sRGB занимает ≈70% пространства Adobe RGB (1998).

② Нарастание яркости в Adobe RGB (1998) происходит нелинейно, тогда как в sRGB околонулевое нарастание яркости в небольшой околонулевой области пропорционально значению пиксела, и только затѣмъ нелинейно.

Получается, что Adobe RGB — своего рода «WCG для бѣдныхъ»; иными словами, переключив свой монитор в режим Adobe RGB (1998), я получил бы возможность видѣть такие картинки так, как их задумывал их автор, но въ обмѣнъ получил бы два недостатка, каждый из которых порождается только малым и недостаточным количеством битов въ цвѣтахъ TrueColor:

➊ Каждый из трёх цвѣтовыхъ компонентов останется восьмибитным, но плавные переходы зелёного цвѣта будут растягивать 2⁸=256 ступеней такого перехода на большее межцвѣтовое разстояніе. Слѣдовательно, возможна болѣе явная постеризация, чѣмъ была бы в sRGB.

➋ При просмотре иллюстраций будут попадаться большей частью иллюстрации въ цвѣтахъ sRGB (а картинки вроде >>196585 будут попадаться рѣдко), при просмотре видео будут попадаться большей частью видеозаписи либо въ цвѣтахъ BT.709 (тот же диапазон, что и sRGB, но другая кривая яркости), потому что это стандарт для HDTV, либо (много рѣже) въ цвѣтахъ нѣкоей WCG (широкой цвѣтовой гаммы), но не такой, как Adobe RGB (1998) — напримѣръ, въ цвѣтахъ BT.2020 (принятых, вопреки номеру, десять лѣтъ тому назад в 2012 году для WCG в UHDTV). То есть бóльшую часть времени придётся ограничивать себя использованием только 70% от доступного широкого цвѣтового пространства, да ещё и непрестанно видѣть цвѣта с ошибками округления (неизбѣжными при преобразовании из одного цвѣтового пространства в другое), наиболѣе крупными въ тѣняхъ, хотя там и без них каждый бит на счету.

Переход от TrueColor к повышенной битности цвѣта позволил бы поправить дѣло: и ошибки округления сократились бы многократно, и плавность цвѣтовых переходов возросла бы многократно — но въ нынѣшнихъ обстоятельствах на такой переход трудно рѣшиться (или, рѣшившись, трудно осуществить его) раздѣльно от других улучшений, так что, по-видимому, рано или поздно придётся обзавестись и новым монитором, и новою видеокартою, и новою операционною системою, и новым компьютером.

Ну то есть формально мой монитор (NEC MultiSync PA241W) по адресу https://www.ixbt.com/monitor/nec-pa241w.shtml назван способным воспроизводить десятибитный цвѣтъ, но мнѣ неоткуда подать его; а уж если приобретать новый комплект монитора и видюхи и системы и остального компá, то тогда он должен, уж конечно, наращивать не одну только битность и цвѣтовую гамму, но и достигать HDR, а не то затѣмъ вдругорядь придётся потратить деньги — и окажется, что напрасно прежде были потрачены на рост битности, отдѣльный от роста яркости и вообще от HDR.

В свою очередь, слѣпо руководиться соображениями, изложенными въ двухъ послѣднихъ абзацах сообщения >>196588, и на этом основании кидаться на покупку какого-нибудь варианта поддержки HDR не кажется разумным до тѣхъ пор, пока нынѣшній зоопарк вариантов (по адресу https://en.wikipedia.org/wiki/High-dynamic-range_television#Formats обнажённый) не смѣнится каким-нибудь состоянием большей ясности того, к какому выбору склонилися создатели и поставщики контента (а по адресу https://twitter.com/DanRayburn/status/1521140335459680256 я узнал, и копию прилагаю: позапрошлым лѣтомъ создатели и поставщики контента поддерживали всё ещё от одной до трёх систем HDR, причём болѣе или менѣе разных) — или пока не явятся универальные системы (подобно тому, как появление приводов DVD±RW покончило с войною форматов записываемых и перезаписываемых дисков DVD болѣе 15 лѣтъ тому назад).

А пока что тупик, тупик! — поневоле придётся сидѣть и дальше на SDR, а оттого и на TrueColor, и на sRGB.

См. также: https://twitter.com/FidonetRunes/status/1588526911915196416

Тем временем, на неупоминаемом хотят WebP.

>>196781
На ычане?

>>196782
Другой, который серо-оранжевый.

Пруфлинк или не хотят.

>>196814

>>196825
Тем временем, на следующем в ад хотят 仮名キャプチャ.

Притом же в сообщении >>196825 мы видим никакой не пруфлинк, а всего только скриншот, который по итогам поиска https://www.google.com/search?q=site:2ch.hk "где webp" может ещё оказаться и нарисованным.

Компания Apple обнажила своё намѣреніе прибавить операционные системы macOS 12 (Monterey) и macOS 11 (Big Sur) к числу тѣхъ систем (>>196497), в которых браузер Safari может открывать файлы AVIF.

Эта поддержка AVIF появилась в Safari Technology Preview 158, как это по адресу https://webkit.org/blog/13584/release-notes-for-safari-technology-preview-158/ было объявлено позавчера (16 ноября).

Скриншот прилагаю.

Не прошло и двухъ недѣль, как поиск >>196830 настолько очистился, что начал выдавать желаемый пруфлинк, а именно https://2ch.hk/hw/res/6276443.html#6283393

Сарказм >>196827 оказался совершенно справедливым: по ссылке видна единственность желающего WebP, и нецензурную рѣчь его никто не поддержал одобрительным словом.

https://twitter.com/FidonetRunes/status/1605539320349147136

Обратите внимание на то, что при помощи libjxl можно изготовить такой файл JPEG, пикселы которого вмѣсто RGB располагаются в том цвѣтовомъ пространстве XYB, которое по адресу https://en.wikipedia.org/wiki/XYB объясняется как содержащее результат простого сложения да вычитания, операндами которого служат непосредственно уровни отклика цвѣточувствительных клеток сетчатки (колбочек), а не уровни воспринимаемого красного-зелёного-синего цвѣта.

В таком JPEG можно сильнѣе сжимать третий компонент (B), опираясь на физиологически нѣсколько бóльшую рѣдкость клеток, чувствительных к коротковолновому компоненту видимого свѣта. Получается рѣзкій рост отношения воспринимаемого качества к объёму файла.

Примѣръ того, как такой файл выглядит (на примѣрѣ >>199137) прилагаю.

Так как преобразование из XYB в RGB полагается на цвѣтовой профиль в формате ICCv4, то пользователи Firefox раньше версии 108 (или в любой нынѣшней версии мобильнаго Файерфокса) будут видѣть цвѣта искажёнными в таком JPEG, так как с поддержкою ICCv4 разработчики Firefox медлили изрядно долго.

Миниатюра изображения >>199138 также подаётся в искажённых цвѣтахъ, так как FBE настроен безусловно выкусывать цвѣтовые профили перед миниатюризацией.

Быть может, настала пора пересмотрѣть эту настройку.

Выкусил цветовой профиль и вышла картинка на 5,1 Мб. Пришлось ужать ещё cjpeg с -quality 92.

А мои просмотрщики отображают webp из >>199137
и jpg из >> 199138 в зримо отличающихся цветах.
https://slow.pics/c/N7Hg2hcY
FM также превьюшку зеленит.

>>199143

Значит, просмотрщик этот не способен извлекать ICC из WebP.

(Таким дефектом https://www.bandisoft.com/honeyview/ обладает, напримѣръ.)

Упомянутая в сообщении >>198254 неприятность ушла в прошлое с выходом новой версии oxipng, опосля чего я обнаружил, что сила сжатия файлов PNG была улучшена разработчиком oxipng.

По адресу https://t.me/ReadMithgol/556 и https://t.me/ReadMithgol/557 и https://t.me/ReadMithgol/558 я изложил подробности своих наблюдений и приложил примѣры таких файлов PNG, которые в 2020 году не могли быть сильнѣе сжаты в oxipng, а теперь могут (и таких, какие всё ещё не могут).

Эти наблюдения я тотчас использовал практически: сшивки >>/a/18953 всѣ выложены сжатыми новой версией oxipng (даже и тѣ сшивки, которые создавалися въ іюлѣ 2019 года).

Скриншот сообщения https://t.me/ReadMithgol/556 прилагаю.

Скриншот сообщения https://t.me/ReadMithgol/557 также прилагаю.

Тот файл, который к сообщению прилагался, забирайте в Телеграме. (Разумѣется, въ раздѣлѣ b/ на 410чанѣ этого файла не будет, потому что прикладывание архивов 7-Zip к сообщениям тут не поддерживается, да и объём архива болѣе чѣмъ на порядок превосходит 5000 килобайтов.)

Скриншот сообщения https://t.me/ReadMithgol/558 также прилагаю.

Обратите внимание на очередное упоминание того обстоятельства, что теперь я использую oxipng для переужатия только чересстрочных файлов PNG (то есть с пикселами, по алгоритму https://en.wikipedia.org/wiki/Adam7_algorithm уложенными), а для сжатия нечересстрочных PNG я теперь использую https://github.com/fhanau/Efficient-Compression-Tool (потому что убедился в большей эффективности этого средства).

Напримѣръ, то изображение, которое к сообщению https://410chan.org/b/arch/res/158687.html#171743 приложено, я бы теперь не в oxipng переужимал.

Впрочем, слово «скриншот» тут использовано метонимически для простоты, но по сути к сообщениям >>199597 и >>199598 и >>199599 приложены не скриншоты сообщений, по адресу https://t.me/ReadMithgol/556 и https://t.me/ReadMithgol/557 и https://t.me/ReadMithgol/558 расположенных, а растровые копии их.

Чтобы сдѣлать послѣдній абзац сообщения >>199599 ещё болѣе наглядным примѣромъ, я прилагаю тут результат переужатия (утилитою https://github.com/fhanau/Efficient-Compression-Tool совершённого) того файла PNG, который к сообщению https://410chan.org/b/arch/res/158687.html#171743 прилагался.

Нетрудно видѣть, что файл получается на 365 байтов короче (состоялась экономия ≈полутора процентов его объёма).

Дополнительно сообщаю, что даже послѣдняя версия oxipng создаёт в этом примѣрѣ файл большего объёма (хотя и всего-навсего на 20 байтов большего).

У меня в кои-то веки дошли руки выкачать все свои закладки с Пиксива, в связи с чем хочу вбросить небольшую статистику.

Из 5659 выкачанных файлов 347 не пролезают в 5120000 файлолимит Чиочана. То бишь, для каждого 20-ого файла при постинге необходимо перекодирование.

Общий объём 8504667148 (8110 MiB), объём после cjxl стал 5723435301 (5458 MiB), став меньше на 32%.
Кодировалось с cjxl --num_threads 0 -q 100 --brotli_effort 11 -e 9 -I 100 -E 3
https://410chan.org/b/arch/res/156266.html#164349
Я совсем забыл, зачем я в скрипт тогда запихал -E 3. Информация об этом number of extra MA tree properties to use гуглится плохо и скрыта за несколькими -v. Печатается по -h без указания предельных и дефолтных значений, как впрочем, и для много чего там. В девелоперской документации удалось это дело откопать, рекомендуют ставить от 0 до 3, предельное значение 11. Влияет на скорость декодирования. Потестил, с -E 3 файлы всё-таки меньше, чем без него. Оставил.
https://files.catbox.moe/bi920s.jxl
Кстати о скорости декодирования. Вот рекордный экземпляр из этой партии. На 8-ядерном AMD Ryzen 7 5800H djxl'ем, который (теперь?) пытается задействовать весь проц, он декодируется за 1 секунду. Но если декодировать в 1 поток, как делает gpicview, например, то где-то за ~8 секунд. А за сколько секунд он декодируется у вас? Для больших PNG картинок, эдакий 7z получается. Жрёт память при кодировании эта штука тоже как 7z с большим словарём. Зафиксированный максимум - где-то до 10 GiB на одну большую (~7000x3000) PNG картинку.

Но это максимумы. Так-то с dxl вся эта партия в 5659 декодируется за 315 секунд, то бишь где-то 0.06 секунды на картинку в среднем. Так что с ristretto и с современным процем оно всё-таки удовлетворительно, хотя проблема есть и оригинальный lossless формат по-прежнему не для кофеварок. Хотя, может быть, есть какие-нибудь настройки, которые позволяют за счёт сжатия похуже сильно улучшить скорость декодирования.

>>199642
Я однажды тоже решил схоронить Пиксив, и вот что получилось.
du -sL pixiv
> 676241856 pixiv
du -shL pixiv
> 645G pixiv
find -L pixiv/ | wc -c
> 20420025
Зачем я это сделал и как теперь с этим жить?

>>199657
Двадцать миллионов картинок схоронил пассажир. Пятьдесят миллионов девочек проживает в одной только Японии.
Только вдумайся, какой большой мир! Сколько времени ты на Пиксив с бурами убил, сколько картинок с девочками на борды отправиил, как тщательно картинки с ними к постам подбирал. И сколько бы ты картинок с девочками за свою жизнь ни видел, а в Японии их больше, и все разные и настоящие. Среди них и твоя единственная ламповая няша, которую можно потрогать и погладить. Так что ищи и дерзай, анон-сан!

>>199657
Ты можешь стать картинкопостером. Вперёд >>199029!

>>199659
>>199660
Я неправильно подcчитал, wc -c это не то что нужно.
> This option displays count of bytes present in a file
Сначала показалось, что там 200 тыщ, поэтому не вчитываясь отправил. Но 20 миллионов - это перебор.

find -L pixiv/ -type f| wc -l
500521
Вот реальное количество изображений с Пиксива.
И то там дубликатов гигов на 10 с него. Когда-нибудь с ними разберусь. И ведь не Пиксв же один сайт с картинками.

>>199659

>>199657
Аплоадь на панду для фарма поинтов, выводи на деньги, являйся владельцем картинок с потёртых аккаунтов и до изменений контентополитики.

>>199717
Какой такой вывод? Максимум голдстар купить. Девочке нашептали, что для голдстаров доступно больше галерей.

>>199718
>баунти за галереи в hath/gold
Люди не глупыя, где-то сканлейтеры эти фантики в реальные денежные знаки всё-таки переводят.

Во браузере Mozilla Firefox версии 111 ожидается возможность смотрѣть анимированные AVIF.

По адресу https://t.me/ReadMithgol/572 я разсмотрѣлъ это обстоятельство в ряду других улучшений той же версии.

(Растровую копию прилагаю.)

По адресу https://twitter.com/FidonetRunes/status/1627660168119869442 я сообщил (скриншот прилагаю) о том, что теперь формат JPEG XL располагает кодировщиком, способным (с параметрами «--allow_expert_options --effort=10») сжать без потерь даже такие файлы PNG, которые прежде не были для него сжимаемыми, но что всё же для этих файлов lossless WebP достигает ещё меньшего объёма.

По адресу https://t.me/ReadMithgol/587 я помѣстилъ краткое пояснение того, каким образом учёт рѣдкости тѣхъ клѣтокъ сѣтчатки, которыя ѿкликаются на синий цвѣтъ, позволил создателям формата JPEG XL (и кодировщика jpegli) сильнѣе сжимать изображения за счёт перехода к использованию цвѣтового пространства XYB.

Скриншот сообщения прилагаю совмѣстно с копиями скриншотов, к нему прилагавшихся в Телеграме.

Кто пожелает ретвитнуть, тому предлагаю https://twitter.com/FidonetRunes/status/1629019451487035394 ретвитнуть.

Прилагаемый GIF (результат работы gifski) не желает циклически воспроизводиться у меня в Mozilla Firefox версии 110.0.1, хотя в IE11 всё в порядке.

Казалось бы, GIF как GIF, просмотрщиками (и XnView, и Honeyview) просматривается циклически, чего же недостаёт Файерфоксу, мать его, а?

>>200485
Эта штука валится на JPEGах.

Похоже, что эту фичу в общем случае смысла использовать нет. Даже такую вот маленькую картинку cjxl, с прочими настройками из >>199642, кодирует 30 минут, в то время как с -e 9 та же картинка кодируется за 8 секунд. C --effort 10 картинка получается в 90991 байт, то бишь на 616 байт меньше, чем с -e 9.

Когда Мицгол пересядет на десятку? Хотя бы LTSC 2021?

И да, Precure — дойная корова, не имеющая культурной ценности

>>185114
Чё там с новерью?

>>201039
Аватарки и суицид.

>>201046
Но там же не только Уютный есть, в /b тоже какой-то актив наблюдается.

>>201050
Это из /b как раз.

>>201057
(0_0) Впрочем, Лина там завсегдатай, так что ничего нового.

По адресу https://t.me/ReadMithgol/601 и https://t.me/ReadMithgol/602 и https://t.me/ReadMithgol/603 и https://t.me/ReadMithgol/604 и https://t.me/ReadMithgol/605 и https://t.me/ReadMithgol/606 я разсмотрѣлъ начало истории формата GIF и употребление средства animeloop для автоматического поиска таких сцен в видеозаписях (прежде всего в аниме), которые годятся для сохранения в виде бесшовных зацикленных анимаций.

Примѣръ такой анимации прилагаю.

Растровую копию упомянутого сообщения https://t.me/ReadMithgol/602 прилагаю.

Растровую копию упомянутого сообщения https://t.me/ReadMithgol/603 прилагаю.

Растровую копию упомянутого сообщения https://t.me/ReadMithgol/604 прилагаю.

Растровую копию упомянутого сообщения https://t.me/ReadMithgol/606 прилагаю.

💢 Если изобилие таких прикладываний кого-нибудь бѣситъ и выглядит почти как флуд, то мягко напомню: пять послѣднихъ сообщений могли бы невозбранно смѣниться единственным, если бы 410чанъ поддерживал прикрѣпленіе нѣсколькихъ иллюстраций к одному сообщению.

>>200808

https://youtu.be/sxXs0Yy5-0Y

>>201143
Всё плохое можно выключить в групповых политиках и службах (даже сторонний софт не понадобится), даже "назойливое по сравнению с прошлыми виндами" скачивание заплаток.

P.S.

Обновления на Винду выходят каждый второй вторник месяца (иногда первый). Это не так уж сложно проконтролировать.
А так, если уж он до сих пор сидит на 7, то может досидеть до конца её поддержки в Файрфоксе, а потом уже решать, что дальше делать.

Главное верить.

>>199139

> Быть может, настала пора пересмотрѣть эту настройку.

И пересмотрѣлъ: >>/dev/27058.

Сегодня и впредь 410чан не искажает цвѣта пикселов при миниатюризации изображений, находящихся не въ цвѣтовомъ пространстве sRGB.

Реальными примѣрами таких изображений могут быть:

① Иллюстрации, созданные въ болѣе широком цвѣтовомъ пространстве Display P3 (прежде всего на современной эппловской технике). Дѣвочка в затопленном городе https://danbooru.donmai.us/posts/5826911 может считаться примѣромъ этого.

② Иллюстрации, созданные въ болѣе раннем широком цвѣтовомъ пространстве Adobe RGB 1998 года (на подобных https://www.ixbt.com/monitor/nec-pa241w.shtml#color японских дисплеях). Дѣвочка перед грозою https://danbooru.donmai.us/posts/4464772 может считаться примѣромъ этого.

③ Иллюстрации, изначально не помѣщавшіяся на 410чан, но переужатые современным кодировщиком jpegli съ помѣщеніемъ ихъ въ цвѣтовое пространство XYB (чтобы ещё на ≈10% опередить MozJPEG по соѿношенію качества и объёма файла, как это по адресу https://twitter.com/jyzg/status/1622979449900740611 обѣщано). Дѣвочка https://danbooru.donmai.us/posts/5942697 в первоисточнике занимает 18,9 мегабайта — результат ея XYB-переужатия прилагаю.

Иными словами, проблема >>199139 устранена.

Обладателям мобильных версий Файерфокса (или предшествующих Firefox 108) соболезную.

Я попробовал повторить результат https://410chan.org/b/arch/res/158687.html#158731 (чуть болѣе, чѣмъ двухлѣтней давности) при помощи современной версии libwebp (версии 1.3.0) и увидал четыре обстоятельства:

① При тогдашнем качестве («-q 1.186») файл получается чуть больше (19 940 байтов, а было 19 696 байтов).

② Такая точность качества не очень нужна, потому что при «-q 1.18» и даже при «-q 1.2» файл получается того же объёма (и внутренне тот же самый).

③ По всей видимости, этот объём предшествует волне обратной зависимости объёма файла от показателя качества, потому что при «-q 1.25» файл получается меньшего объёма (19 782 байта).

④ Слѣдовательно, ещё далѣе наращивая качество картинки и достигнув того момента, когда эта волна заканчивается, можно получить файл WebP съ замѣтно бóльшим показателем качества («-q 1.34»), но по своемý объёму (20 244 байта) этот WebP (который прилагаю) всё ещё будет меньше, чѣмъ шакальный JPEG https://410chan.org/b/arch/res/158687.html#158719

⑤ Притом же этот WebP по своемý показателю качества (1,34) оказывается идентичен примѣру https://410chan.org/b/arch/res/158687.html#164965 и отличается от него только номером препроцессора (тут 5, а там 4, то есть простой «sharp_yuv») и немного объёмом файла (тут 20 244 байта, а там 20 200 байтов), так что визуальное сравнение того и другого позволяет наглядно оцѣнить (при отсутствии других важных отличий) только пользу того дополнительного сглаживания сегментов (segment-smoothness), которое отличает пятый препроцессор от четвёртого, да ещё и цѣну этой пользы (то есть не похѣрились ли нѣкоторые области картинки тѣмъ сглаживанием).

Достижение >>201744 притом позволяет невозбранно показать на 410чане, чего достигает при сжатии того же исходного изображения кодировщик jpegli, работающий в режиме создания файлов JPEG въ цвѣтовомъ пространстве XYB.

Вызов команды «cjpegli --xyb --distance=18.03 --chroma_subsampling=420» (дополненной через пробѣлъ именами исходного файла и результата) создаёт XYB JPEG объёмом 20 261 байт, который прилагаю.

По сравнению с шакальным JPEG https://410chan.org/b/arch/res/158687.html#158719 получилось на байт больше, а по сравнению с MozJPEG https://410chan.org/b/arch/res/158687.html#158729 получилось на два байта меньше.

Сравнение с MozJPEG показывает громадный рост качества большинства мелких деталей и плавных цвѣтовыхъ переходов, достигнутый при ≈равном объёме файла.

Естественно, при таком сильном сжатии качество WebP (не говоря уж об AVIF) по-прежнему остаётся недосягаемым для формата JPEG, однако в рамках этого формата создатели jpegli бесспорно достигли новой вершины соѿношенія качества и объёма файла.

Посмотрел, как замечательно сжимает https://avif.io/ в лосслесс режиме (rav1e в браузере через WASM), решил почитать подробнее.

Во-первых, оказалось, что rav1e в принципе не поддерживает lossless-сжатие, несмотря на вводящую в заблуждение галочку https://github.com/xiph/rav1e/issues/151
>avif.io does not actually produce lossless AVIF images, as its rav1e encoder doesn't currently support lossless mode, so it employs chroma subsampling which has the effect of producing a much smaller image

А во-вторых, узнал, что lossless-режим у AVIF-формата весьма специфичный: иногда сжимает хуже, чем lossless у WebP, а кроме того, он ещё и не настоящий – для тех случаев, когда на вход подаётся картинка в цветовом пространстве RGB, т.к. происходит конвертация в YUV с неизбежными потерями.
https://github.com/AOMediaCodec/av1-avif/issues/111#issuecomment-717710961

тл;др:
>Neltulz:
>AVIF lossless isn't even true lossless, since it requires the image be converted to yuv4:4:4 or yuv4:2:0, which means if your image is originally RGB, you're incurring a lossy conversion just by changing from RGB to YUV. I've heard of ways in which the image can be losslessly converted between RGB and YUV, but that is unorthodox and I do not recommend it.

>leo-barnes:
>You may want to take a look at issue https://github.com/AOMediaCodec/av1-avif/issues/89
>With that fix in place, doing fully lossless coding with a modest compression ratio gain should be possible.

>Neltulz:
>What AVIF needs, is a way for it to detect input colorspace, and store the image losslessly in that color space. Pick the right lossless compression format that best suits the job. That means, that AVIF is going to bloat in complexity as it tries to please every color space possibility. At that point, we need a dedicated lossless image format that isn't AVIF to avoid AVIF ballooning into an even bigger kitchen sink format than WebP. Adding support for all of this is just going to add complexity to decoding and make it difficult for developers to keep up with the advancements of AVIF.
>It's my opinion that AVIF should have the lossless compression method removed completely (since it's stupid and encourages people to waste a bunch of time encoding in an inferior lossless format), and make room for an actual lossless image format that supports multiple color spaces and picks the best lossless compression method for the job, supports multiple bit depths, and HDR.

>>201781

По-моему, идея «lossless AVIF в принципе никогда не lossless» слишком далеко уклонилася ѿ дѣйствительности.

(Если желаете неопровержимо доказать правоту этой идеи хотя бы в одном частном случае, не говоря уж про «никогда», то тогда попробуйте обнаружить такой исходный файл, который не выдержит провѣрку «magick compare -metric ae исходный.png результат.avif nul» опосля преобразования «avifenc --jobs 8 --codec aom --speed 0 --lossless исходный.png результат.avif», напримѣръ.)

Словосочетание «происходит конвертация в YUV» обычно означает «из значений RGB по опредѣлённымъ формулам получают значения YUV — съ нѣкоторою неточностью, если при этом не наращивать разрядность», это я понимаю.

Однако в случае AVIF это скорѣе означает «значения RGB тупо засовывают в алгоритм, предназначенный для сжатия значений YUV без потерь — на выходе получают значения RGB, сжатые без потерь, однако степень сжатия хѣровенькая, потому что алгоритм разрабатывался не для RGB».

По крайней мѣрѣ, именно так я понял словосочетание «lossless RGB today sends the color channels through a video format designed for YCbCr» и дальнѣйшее объяснение пользы YCgCo-R в комментарии https://old.reddit.com/r/AV1/comments/kupvvl/firefox_will_support_the_avif_image_format_based/givfb5h/ (автор которого представился экс-сопредседателем группы разработчиков формата, и вроде как с начала 2021 года никто его там не успѣлъ обвинить в самозванстве — должно быть, и впрямь экс-сопредседатель).

С точки зрения формата такое засовывание (RGB на мѣсто YUV) выглядит как употребление нулевого номера матричных коэффициентов (из числа тѣхъ номеров, которые приводятся в таблице №4 на странице №12 в документе Rec. ITU-T H.273 июльской версии 2021 года, со страницы https://www.itu.int/rec/T-REC-H.273-202107-I/en скачиваемой). Этот номер означает «ваши координаты пикселов — это не YUV, а RGB или XYZ».

Автор комментария https://github.com/AOMediaCodec/av1-avif/issues/129#issuecomment-1206821544 утверждал даже, что новые кодовые номера (среди которых и номер для YCgCo-R) непремѣнно вскорѣ одобрены будут ко включению в ту таблицу. (Вот только утверждал он это в августе прошлого года — а воз, говоря словами баснописца Крылова, и нынѣ тамъ.)

На всякий случай напоминаю, что YCgCo-R является трёхмерным пространством яркости-зелёности-оранжевости, преобразование из которого в RGB и обратно не приводит к потерям, однако для той безпотерьности требуется минимальный (однобитовый) рост размѣрности зелёности и оранжевости по отношению к остальным координатам. (То есть если координаты RGB восьмибитны, то яркостная координата Y также может быть восьмибитною, а вот координаты Cg и Co должны быть девятибитными, поскольку могут быть отрицательными. Напримѣръ, если R=10 и B=220, то тогда Co = R−B = −210.) Корпорация Microsoft по адресу https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/2008_ColorTransforms_MalvarSullivanSrinivasan.pdf излагает всю необходимую математику. По адресу https://spie.org/Publications/Proceedings/Paper/10.1117/12.797091 сказано, что это изложение впервые опубликовано в сентябре 2008 года, так что въ нынѣшнемъ (2023) году это пространство сможет справлять пятнадцатилѣтіе.

Польза использования YCgCo-R в AVIF заключается в том, что это пространство гораздо болѣе YUV-подобно, так что алгоритм сжатия, совершаемого без потерь, должен лучше работать в нём по сравнению съ нынѣшнею обработкою сырых RGB, которая обеспечивает очень малое и недостаточное сжатие. Таблица https://docs.google.com/spreadsheets/d/1DHJ0TajtxWDV6bfLwIZPHztxDuB3x3SS-HZ2Yi3sbRc (которую автор вышеозначенной реплики, в сабрэддите /r/AV1 выложенной, привёл с упоминанием неназванной подгруппы разработчиков, работу которой подытоживал Derek Buitenhuis из Vimeo), вроде бы подтверждает собою утверждение «должен лучше работать». Диаграммы из этой таблицы прилагаю скриншотом. (Внимание в них надо обращать на величину зелёного столбика.)

Само по себе наращивание битности на один бит, необходимое для YCgCo-R, не сдѣлается помѣхою для роста степени сжатия, потому что нынѣшній алгоритм сжатия без потерь, заложенный в AVIF (и ниже в AV1), сам по себе вроде бы предусматривает наращивание битности на один бит, по крайней мѣрѣ, при нѣкоторыхъ операциях. (Такое впечатление создаётся при чтении https://aomediacodec.github.io/av1-spec/av1-spec.pdf на странице 296 из 669.)

Сразу скажу ещё, что есть и альтернативное мнѣніе https://twitter.com/jyzg/status/1477305288961282058 о том, что алгоритм сжатия в AVIF в принципе не очень годится для сжатия статических изображений (даже совершаемого с внесением потерь).

Опосля правок, внесённых в исходный код cjpegli 12 мая, результат >>201776 достигается при «--distance=18.11» вмѣсто «--distance=18.03».

Анимированные AVIF теперь поддерживаются во браузере Mozilla Firefox (начиная с версии Firefox 113).

Нетрудно видѣть, что ожидание >>199930 подходит к концу только теперь.

По адресу https://t.me/ReadMithgol/628 я сообщаю нѣкоторыя подробности этого, а тут прилагаю растровую копию этого сообщения.

По адресу https://github.com/ImageOptim/gifski/issues/298 явствуетъ (скринъ-шотъ прилагаю), что авторъ gifski умудрился собрать очередную версію такимъ образомъ, чтобы она не работала на процессорахъ ранѣе Haswell, да ещё и не пересобиралъ двѣ недѣли опосля того, какъ ему сообщили объ этомъ — можетъ быть, и не пересоберётъ никогда, никогда.

Ѽ, етить.

>>202084
Ну, в первом мире процессор из 20-х, который мощнее твоего IvyBridge, наверняка стоит меньше, чем один тамошний МРОТ. А один Haswell-овский i7 даже до российского МРОТа не дотягивает по цене.
https://www.ozon.ru/product/protsessor-intel-core-i7-4790-haswell-3600mhz-lga1150-l3-8192kb-oem-oem-bez-kulera-280710291
Возможно, и тебе настала пора обновиться.

>>202085

Да-да, разумѣется, цѣна обновленія равняется стоимости новаго чипа Haswell — зачѣмъ же учитывать то обстоятельство, что чипы Haswell (и затѣмъ Broadwell) нуждаются въ сокетѣ LGA 1150, тогда какъ чипы Ivy Bridge (и до нихъ Sandy Bridge) использовали сокетъ LGA 1155, что исключаетъ простую возможность втыканія одного вмѣсто другого, так что придётся поневоле перемѣнять и процессоръ, и материнскую плату, и оперативную память, и видеокарту, и дисплей, и операціонную систему, и всё это въ обстоятельствахъ дѣятельнаго вооружённаго международнаго противостоянія (силою котораго настала полная жопа и съ цѣнами, и съ ассортиментомъ, и съ покупательною способностью денегъ, и съ гарантіей производителей, и съ побужденіемъ производителей дистанціонно отключать свои продукты или заставлять ихъ «работать» вредоносно) и притомъ ещё при отсутствіи ясности по вопросу о томъ, какая система WCG и особенно HDR восторжествует (всё равно что покупать приводъ HD DVD въ 2006 году, который въ 2008 году пришлось бы выбросить и покупать блюрэевый, или всё равно что до появленія приводовъ DVD±RW купить аппаратную реализацію только одного формата — но разница въ томъ, что хорошій комплектъ монитора и видюхи неизбѣжно тогда обойдётся гораздо дороже любого оптическаго привода и притомъ потребует, можетъ быть, очередного обновленія операціонной системы, во всёмъ подобнаго послѣдствіямъ прежняго рѣшенія Корпораціи Microsoft не притащить HDR въ семёрку), и при почти полной гарантіи черезъ пару лѣтъ остаться за порогомъ новыхъ техническихъ требованій не только игровой, но и всякой другой виртуальной реальности или какихъ-нибудь стереопанорамныхъ видеозаписей 8K, ёптъ.

>>202096
размазывает_по_стенке.гиф

>>202096
> и оперативную память
Haswell поддерживает DDR3.
> и видеокарту
Тоже не факт. Но мне это лень гуглить.
> и дисплей
Это-то почему? VGA провод в новый комп тык, HDMI провод в новый комп тык, и готово.
> и операціонную систему
Можно старый диск в новый комп воткнуть, хотя, возможно, винда будет ругаться про активацию из-за другого отпечатка устройства, а дополнительные дрова через прокси придётся качать.
> всё это въ обстоятельствахъ дѣятельнаго вооружённаго международнаго противостоянія (силою котораго настала полная жопа и съ цѣнами, и съ ассортиментомъ, и съ покупательною способностью денегъ, и съ гарантіей производителей, и съ побужденіемъ производителей дистанціонно отключать свои продукты или заставлять ихъ «работать» вредоносно)
Цена того цп на ОЗОНе говорит, что жопа, к счастью, частично продолжает оставаться по-детски сексуальной.
> и при почти полной гарантіи черезъ пару лѣтъ остаться за порогомъ новыхъ техническихъ требованій не только игровой, но и всякой другой виртуальной реальности или какихъ-нибудь стереопанорамныхъ видеозаписей 8K, ёптъ
Ну, ты уже за порогом. Первые звоночки, во всяком случае, явно есть. Так что смотри. Жопа в любой момент может стать по-настоящему взрослой, жирной и толстой. Может быть, стоит сменить шило на чуть более свежее мыло. Может, (спустя какое-то время) стоит на что-то действительно хорошее раскошелиться.

>>202099

Поясняю: видеокарту и оперативную памѧть (и всё прочее въ этомъ спискѣ) понадобится перемѣнить потомý, что ужъ если достигнута необходимость вмѣстѣ съ процессоромъ замѣнить и материнскую плату, то тогда получается, что вмѣшательство въ аппаратное обеспéченіе выглядит такъ значительно, что ужъ почему бы и не перескочить сразу на сáмыя новыя модели ихъ.

А не то получается вздоръ: купить Haswell и мать его только для того, чтобы работала новая версія gifski? — она того не стóитъ по величинѣ своихъ новинокъ, такъ что можно и на 1.10.0 далѣе сидѣть.

Остановитесь.

>>202137
Сколько времени на замазку-то ушло. Тяжело тебе, поди, на Чиочане сидеть.

>>202137

Вы пользуетеся ядрами Yonah пятнадцатилѣтней давности? — очень сочувствую, но ориентироваться на их возможности при создании видеороликов я не буду, потому что тогда в 410чановские 5000 килобайтов ни одной сколько-нибудь продолжительной видеоцитаты не помѣщу, поневоле пришлось бы самоограничиваться двузначным числом секунд.

Очень далёкими от дѣйствительности выглядят процитированные на этом же скриншоте воззрѣнія человѣка, который очень сильно сконцентировался на произвольных алфавитных ассоциациях: ранѣе усвоенное название формата TIFF (с двумя «F») мѣшаетъ ему правильно записать название формата «AVIF» (с одной «F»), ранѣе усвоенное сокращение «WP9» принуждает его всякий раз при виде названия формата «VP9» вспоминать и упоминать Windows Phone 9, причём непремѣнно записывая с нарочно внесёнными ошибками («шиндуспхоне9») под давлением окружающей его на Абучане массы быдла, а формат WebP он называет не иначе как «вебрепа» или «вебрепка» (я даже не собираюсь формулировать и высказывать догадку о причинах этого), однако при этом нифигушеньки не понимает, как работает механизм патентных отчислений и почему крупные сайты отказываются от поддержки HEVC.

За предѣлами этого скриншота он же пишет «HEIFF» с двумя «F», всерьёз считает анимированные PNG неподдерживаемым форматом, опосля появления gifski создаёт GIF другими средствами и вообще ведёт себя как человѣкъ совершенно невежественный и даже с лёгкою припиздью. Беспрерывною нецензурщиною он стремится замаскировать разрыв между дѣйствительностью и собою, но тот слишком значителен для этого устремления.

19 мая и 21 мая по адресу https://t.me/ReadMithgol/629 и https://t.me/ReadMithgol/630 и https://t.me/ReadMithgol/631 и https://t.me/ReadMithgol/632 и https://t.me/ReadMithgol/633 и https://t.me/ReadMithgol/634 и https://t.me/ReadMithgol/635 и https://t.me/ReadMithgol/636 я выложил своё собственное пространное рассуждение о том, как сайты иногда перегибают палку в ограничении качества изображений, и вслѣдствіе того перегиба их борьба против пользователей, движимая стремлением к экономии объёма файлов, заканчивается печальной ситуацией взаимного проигрыша.

Сообразуясь с нуждами тѣхъ тутошних читателей, которые воздерживаются от чтения Телеграма, растровую копию сообщения https://t.me/ReadMithgol/629 прилагаю.