Дополняя предшествующій абзацъ, растровую копію сообщенія 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 прилагаю.

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

5 июня компания Apple, открывая свою конференцию WWDC 2023, в докладе https://youtu.be/GYkq9Rgoj8E примѣрно на пятьдесят четвёртой минуте упомянула (видеоцитату прилагаю, но и гиперссылку на первоисточник https://youtu.be/GYkq9Rgoj8E?t=53m11s прилагаю) о том, что браузер Safari будет теперь способен показывать на web-страницах изображения, хранимые в формате JPEG XL.

Конкретное упоминание JPEG XL можете видѣть либо въ лѣвой части пятой строки перечисления новинок Safari въ послѣднихъ кадрах видеоцитаты >>202358, либо по адресу https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes#Images въ болѣе подробном списке новинок Safari 17 Beta (скриншот прилагаю).

По адресу https://t.me/ReadMithgol/639 и https://t.me/ReadMithgol/640 и https://t.me/ReadMithgol/641 и https://t.me/ReadMithgol/642 и https://t.me/ReadMithgol/643 и https://t.me/ReadMithgol/644 и https://t.me/ReadMithgol/645 и https://t.me/ReadMithgol/646 я изложил в Телеграме свою оцѣнку той новости, которую теперь в сообщениях >>202358 и >>202359 пересказал, а также практически разсмотрѣлъ превосходство формата AVIF над форматом JPEG XL в области сильного сжатия (около полубита на пиксел в среднем).

Скриншот https://t.me/ReadMithgol/639 и https://t.me/ReadMithgol/640 прилагаю.

Скриншот https://t.me/ReadMithgol/641 также прилагаю.

Скриншот https://t.me/ReadMithgol/642 и https://t.me/ReadMithgol/643 и https://t.me/ReadMithgol/644 и https://t.me/ReadMithgol/645 также прилагаю.

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

В этом сообщении я не только посѣтовалъ на невозможность использования файлов AVIF в качестве иллюстраций в Телеграме, но и предложил обходной путь, реализуемый принудительным засовыванием AVIF в контейнер MP4 под видом однокадровой видеозаписи AV1.

Невозможность использования файлов AVIF в качестве иллюстраций существует, окромя Телеграма, также и на 410чане, причём и тут можно обойти её аналогичным способом, как в сообщении >>202356 видно.

Не так давно открыл для себя JPEG XL. Это потрясающий формат позволяющий заэнкодить старые jpeg в меньший размер без потери не только качества, но и даже каждого бита. Новость пришла с тем что из Хрома удалили поддержку jpeg xl. Да и какая разница, я всё равно им не пользуюсь и выкладывать свои запасы архивов не собирался. Локальные просмотрщики все показывают нормально. Но вот будущее формата пока открыто, какой бы он не был "L for long-term".
Пока только перекодировал один из моих архивов фотографий. И уменьшение размера просто потрясающее. Картинки становятся меньше на 20-25%, из 10ГБ я получил 8ГБ. Заодно с этим перекодировал теперь уже полностью устаревшие gif в наиболее близкий webm. На выходе получается 5МБ гифка превращается в 500КБ webm видео. Считаются ли теперь короткие webm изображениями с анимацией или видео - вопрос философский.

>>200762
libjxl пока ещё сырой в версии 0.8.1 и не выводит причины ошибки даже если указать -v дважды. У меня на одном изображении была такая ошибка, оказалось что jpeg был битый с повреждённой таблице Хаффмана. Но все просмотрщики его отображают нормально, и только libjxl подавай идеально правильные jpeg. Если это та же проблема, то можно попытаться перекодировать без потерь в новый файл с помощью jpegtran.

Зайголовок даннага тхреда сподвигает меня на вапрос. А как сахранить изабражение в текставамъ фармате? Спрашиваю ни для сибя, Рицу папрасила.

>>202446

cp картинка.jpg таблетки.txt

>>202447
Таблетки могут получиться нечитаемыми.
>>202446

base64 картинка.jpg > таблетки.txt

>>202446
https://github.com/hpjansson/chafa например!

>>202447
Кого я вижу! Это же Оказаки Юмеми, да ещё и тут, на форуме для девочек-волшебниц и не только.
Про неё помнят!!
прикладываю нейросетошную Оказаки Юмеми со вкусом космоса - у неё же есть что-то вроде корабля космического, который Probability Space Hypervessel.

>>202451
Оказаки Юмеми - распутная аспирантка.

>>202453
Я думаю, что если ты открываешь портал в другой мир, то распутство или простительно, или меркнет на фоне других твоих грехов.
Ну и стандартная фраза "сейчас бы в 2к23 обращать внимание на распутство других".

>>202363
Ты же сдох.
Исправляйся, соответствуй.

Это ты сдох, >>202455-кун.

По возможности избегайте гибнуть.

OMG, сжатие picture убивает?!

>>202458
Ловушка Мицгола о которой никто не подозревал! Тысячи пассажиров убились об жипегксель! Читайте дальше...

>таблетки
А по сути ответил только пассажир, давший ссылку на чафу. Все остальное - преобразование сжатого графического файла в текстовый формат. А я спрашивал именно сжатие изображения в виде текста. Иначе заголовок даннага тхреда самнителен!

>>202459
> Иначе заголовок даннага тхреда самнителен!
Не могу не поинтересоваться любите ли вы Катю Самбуку?

>>202459
Фармат заказал, фармат получил.

В 2123-ем году все мы мертвы.
Я гарантирую это.

Вы не 未来人、 чтобы гарантировать это.

>>202460
https://ru.wikipedia.org/wiki/Самбука,_Катя
???

Что если во всёмъ мірѣ одинъ >>202459-кунъ только любитъ Катю Самбуку, а остальные люди его эпохи — всѣ, какимъ-нибудь наплывнымъ вѣтромъ, на время почему-то отъ него оторвались…

И понятно почему.

>>202466
Катя Самбука зовется так потому что любит и саму самбуку, а ведь если ее правильно употреблять, с огоньком, то соответственно, какое-то время придется разговаривать в основном с помощью заднеязычных согласных!

Чистейшая шизофрения. Ради такого я плачу за интернет.

>>202469
> Что если во всёмъ мірѣ одинъ >>202459-кунъ только любитъ Катю Самбуку

Она на ПМЭФ приезжала в этом году. Знают и любят!

И откуда во мне столько злобы. Периодически.

>>202480
Лол, правда?
А на следующем будет Альбина Сексова?

>>202484
Там каждый год кокаиновые оргии с приглашенными знаменитостями.

Чивоч, что за формат такой heic, старый он новый? Что мы знаем об инновациях в форматах картинок? Что самое лучшее для долгосрочного хранения?

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

>>202743
Конечно, дружочек! Чтобы увеличить шансы на то, чтобы ваши работы стали фильмом в будущем, я дам тебе несколько советов:

1. Храни кадры цифрово: Используй высокое разрешение и храни файлы на внешних дисках или облачных сервисах.

2. Добавь метаданные: Опиши и дай контекст своей работе, чтобы люди поняли, что она значит.

3. Используй онлайн-платформы: Размещай свои кадры на сайтах, где люди могут увидеть их, например Behance или ArtStation.

4. Знакомься и сотрудничай: Посещай выставки и фестивали, чтобы завести контакты со схожими творческими людьми.

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

>>202744
Но вообще надо освоить софт по сортировке кадров для этой профессии, вроде бы Kyno есть такое. Есть ещё некий аналог, я спросил у профессионала, может ответит.

>>202741

HEIC — это хранимое в контейнере HEIF (High Efficiency Image File Format) изображение, кодированное по правилам видеоформата HEVC (High Efficiency Video Coding — то же сáмое, что и формат ITU-T H.265).

На скриншоте >>202359 видно, что с недавних пор изображения в формате HEIC невозбранно открываются во браузере Safari 17, пока ещё находящемся на стадии бета-версии (официальный же выпуск семнадцатой версии его, вѣроятно, произойдёт осенью).

Так как AVIF — это хранимое в таком же контейнере HEIF изображение, кодированное по правилам видеоформата AV1, то AVIF лучше.

(Насколько лучше? — настолько же, насколько AV1 лучше HEVC, то есть примѣрно в √2 раз в зависимости от настроек кодировщика.)

>>202746
> во браузере
Ну ёптель-моптель. В браузере же!

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

>>202781

От ёптель-моптеля слышу. Если можно записывать «во браке», то можно записывать и «во браузере», потому что падеж точно тот же (предложный), ударный слог точно тот же (первый), количество первых согласных точно то же (два), первый гласный звук точно тот же («а»), предшествующие согласные звуки точно тѣ же («бр»), выбор самих предлогов точно тот же («в» или «во» в пользу «во»).

По адресу https://t.me/ReadMithgol/707 я опроверг нѣкоторые примѣры неэффективности формата анимированных WebP по сравнению с форматом анимированных GIF, популяризированные создателем утилиты gifski.

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

По адресу https://webkit.org/blog/14445/webkit-features-in-safari-17-0/ видно, что фича >>202359 (поддержка графических форматов HEIC и JPEG XL) успѣшно прошла стадию бета-версии и близится к официальному выпуску во браузере Safari 17 черезъ недѣлю (26 сентября) на Маках, тогда как на iOS и на iPadOS эта версия Safari ужé вышла и поддержка этих форматов ужé работает со вчерашнего дня (18 сентября).

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

Интриги, скандалы, грязные подробности форматной войны.

Допустимо ли?
https://www.pcworld.com/article/2083926/highest-alert-level-security-vulnerability-affects-apps-like-telegram-and-1password.html

>>203166
https://www.opennet.ru/opennews/art.shtml?num=59746
Да, забавно.
К тому же шебп и в Tor Browser пришел из лисицы, и вот это вот совсем эпично.

Просто обновите libwebp до версии 1.3.2, обновите Firefox до версии, по адресу https://www.mozilla.org/en-US/security/advisories/mfsa2023-40/ указанной (или новѣе, потому что ужé есть новѣе), обновите Telegram Desktop до версии 4.9.7 (или новѣе, потому что ужé есть новѣе), etc.

Пользователям версий Windows, предшествующих десятой, неплохо бы заодно обновить и браузер Edge, как это по адресу https://www.neowin.net/news/microsoft-releases-update-for-edge-on-windows-7-and-8/ сообщают.

Послѣдняя версія Tor Browser (версия 12.5.6) на своей странице «about:tbupdate» сообщает нам, что содержит бэкпорт фич безопасности из Firefox 115.3.1. И так как по адресу https://www.mozilla.org/en-US/security/advisories/mfsa2023-40/ было сказано, что версия Firefox ESR 115.2.1 ужé содержала исправление ошибки в libwebp, то пользователям Tor Browser можно насчёт неё не напрягаться (а также и насчёт ошибки https://www.mozilla.org/en-US/security/advisories/mfsa2023-44/ в libvpx). Если же нѣкто использует Tor Browser, но не обновляет, то соболезную.

Вдвойне соболезную тѣмъ, кого задѣло зеродэем до его исправления. Но опосля обнаружения и исправления теперь всё хорошо.

>>203183
Тут больше интересно
>Does anyone know if CVE-2023-4863 has been used to exploit people in the wild or is it just a feasible possibility?

Вопрос: Сколько времени TB оставался уязвим?

По источникам
[1] https://www.cve.org/CVERecord?id=CVE-2023-4863
[2] https://security-tracker.debian.org/tracker/CVE-2023-4863
[3] https://www.mozilla.org/en-US/security/advisories/mfsa2023-40
[4] https://www.mozilla.org/en-US/firefox/102.15.0/releasenotes/
[5] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/maint-12.5/projects/browser/Bundle-Data/Docs-TBB/ChangeLog.txt
[6] https://chromium.googlesource.com/webm/libwebp.git/ /902bc9190331343b2017211debcec8d2ab87e17a^!/
[7] https://tracker.debian.org/news/1463551/accepted-libwebp-132-01exp1-source-amd64-into-experimental/
[8] https://www.mozilla.org/en-US/firefox/102.15.1/releasenotes/
[9] https://chromium.googlesource.com/webm/libwebp.git/ log/refs/tags/v1.3.2/
[10] https://chromium.googlesource.com/webm/libwebp.git/ log/refs/tags/v1.3.1/

2023-06-23: выпуск libwebp1.3.1 [10] (уязвима)
2023-07-04: выпуск FF 102.13.0esr (уязвима [2])
2023-08-29:&выпуск FF 102.15.0esr [4] (уязвима)
2023-08-28:&TB 12.5.3 переходит на FF 102.15.0esr [5] (уязвима)
2023-09-07: коммитом исправляется libwebp [6]
2023-09-09: резервируется CVE номер CVE-2023-4863 [1]
2023-09-12: анонсируется уязвимость CVE-2023-4863 [1] и публикуются новости в интернетах [3]
2023-09-12: выпуск FF 102.15.1esr [8] (исправлен [2][3])
2023-09-12: TB 12.5.4 переходит на FF 102.15.1esr [5] (исправлен [2][3][5])
2023-09-13:#выпуск libwebp-1.3.2 [9] (исправлена [9])
2023-09-15: пакет libwebp1.3.2 приходит в debian [7]
& time paradox, да
＃ 2023-09-12 из-за разницы в измерении времени этими сайтами/системами?

Ответ:
Если допустить, что весь месяц (с потолка) до того, как она была пофикшена в libwebp (2023-09-07), она уже эксплуатировалась хацкирами разного рода, нашедшим её самим, то выйдет, что с 2023-08-07 по 2023-09-12 (1 месяц) пользователи TB не были защищены никак.
Обновившись 2023-08-28, все равно 15 дней они не были защищены никак.
Если допустить, что хацкеры узнали о ней из коммита в libwebp (2023-09-07), то выйдет что c 2023-09-07 по 2023-09-12 (5 дней) пользователи TB не были защищены никак.

Напоминаю, что при виде сокращения «TB» типичный читатель сперва пробует прочесть его как «телевизор», затѣмъ как «terabyte» и наконец как «Thunderbird».

Вам хочется использовать это сокращение для слов «TOR Browser»? — поздравляю, это прочтение будет минимум четвёртым из приходящих на ум, да и то может быть отодвинуто словами и словосочетаниями «tomboy», «Taco Bell», torrentbytes.net, «turd bucket», «total bullshit», «tuberculosis», «true bro» и им подобными ещё подалѣе.

Сколько и каких будет таких? — это зависит только от величины активного словаря читателя.

>>203188
Нельзя же так игнорировать контекст!

Вот как важно перейти на graphicsmagick, ежели кто-то ещё не сделал этого (хоть и некоторые дистрибутивы директивным решением могли перевести насильно).

Скриншот >>203207 ничего особенного не говорит умý, так как ужé от момента «если в системе до сих пор сохраняется libwebp 0.4.4, не обновлявшийся с октября 2015 года…» большинство читателей сознаёт, что это не про них.

>>203210
Новый cwebp сжимает лучше?

>>203213

Ну да, если судить по тому, как нерѣдко в подписях к коммитам (по адресу https://chromium.googlesource.com/webm/libwebp/ /ca332209cb5567c9b249c86788cb2dbf8847e760/ChangeLog лежит нынѣшній сборник их) встрѣчается слово «improve» (и его производныя) по отношению к силе сжатия.

Послѣдній абзац скриншота, к сообщению >>202879 прилагаемого, также относил часть успѣха на счёт болѣе новой версии кодировщика.

Автор рассуждения >>203187 болѣе или менѣе явно (хотя и оговаривается: «с потолка», то есть беспочвенно) ведёт отсчёт уязвимых версий libwebp, начиная от версии libwebp 1.3.1, которую называет вышедшею 23 июня (датируя по репе), хотя вообще-то доступные для скачивания по адресу https://storage.googleapis.com/downloads.webmproject.org/releases/webp/index.html сборки этого выпуска датируются 29 июня.

Необходимость этакого гадания выглядит изрядно странно на фоне того, что первою же из гиперссылок, в сообщении >>203187 приведённых, оказывается гиперссылка, по адресу https://www.cve.org/CVERecord?id=CVE-2023-4863 ведущая. Если по ней перейти, то тогда немедленно становится видно на первом же экране (скриншот прилагаю), что уязвима не одна только предпослѣдняя версия libwebp, но и каждая из очень многих предшествующих версий, начиная от версии 0.5.0 (которая по адресу https://storage.googleapis.com/downloads.webmproject.org/releases/webp/index.html датируется 23 декабря 2015 года).

Мы смотрим не на недѣлю, не на мѣсяцъ, даже не на десяток мѣсяцевъ, а на без мáлого восемь лѣтъ непрестанной уязвимости, которая (согласно истории, по адресу https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/ изложенной) обнаружена была на недѣлѣ, прошлой по отношению к 7 сентября, и обнаружена была ужé используемою как вектор доставки программного средства шпионажа (израильского происхождения), извѣстнаго под названием Pegasus.

По адресу https://www.nytimes.com/2022/01/28/magazine/nso-group-israel-spyware.html можно прочесть в «The New York Times», что Pegasus употребляется с 2011 года. Может быть, дыра в libwebp оперативно передана была евреям (или даже запроектирована и создана в еврейских расовых интересах с сáмого начала, так как Google — это также еврейская компания) ещё в 2015 году и эксплуатировалася всѣ эти ≈восемь лѣтъ наряду со многими другими уязвимостями, нам ещё не извѣстными, но им очень хорошо извѣстными.

>>203227
Спасибо за анализ и исправления!
Однакоже это крайне забавно, что тот, у кого "в системе до сих пор сохраняется libwebp 0.4.4, не обновлявшийся с октября 2015 года" оказался в безопасности.
(хотя не совсем конечно, торобраузер же свою несет)

https://www.youtube.com/watch?v=JehEh7i1PIE

Какая интересная программа, а есть ли такое же, но чтобы бесплатно?

https://youtu.be/P8t_Fx5dcC4

По адресу https://t.me/ReadMithgol/823 и затѣмъ ещё по адресу https://t.me/ReadMithgol/827 я сообщил про близящійся успѣхъ формата AVIF (на будущей недѣлѣ он будет поддерживаться ужé каждым из популярных браузеров), перечислил достоинства и недостатки.

Сшивку скриншотов своих сообщений прилагаю.

По адресу https://t.me/ReadMithgol/828 я прибавил к >>205509 болѣе подробный разсказъ об анимированных AVIF.

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

То событие, которое я прежде в сообщении >>205509 мог без труда предвидѣть, и впрямь произошло 25 января.

По адресу https://t.me/ReadMithgol/840 я изложил основные подробности и свои мысли на этот счёт.

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

Также процитирую основную мысль:

> …если прежде для сжатия иллюстраций, совершаемого с внесением потерь, формат WebP оказывался очевидным выбором, если выбирать в логике «это сáмое мощное средство из числа поддерживаемых послѣдними версиями каждого из сколько-нибудь популярных браузеров», то в 2024 году таким средством сдѣлается AVIF.

> Впредь формат WebP будет восприниматься в качестве прошлого такого средства, а формат JPEG — позапрошлого.

Под конец позавчерашнего вторника (30 января 2024 г.) на Ычане появилася поддержка WebP, как о том по адресу https://iichan.hk/n/ сказано.

В обсуждении этого события, по адресу https://iichan.hk/b/res/5326636.html случившемся (скриншот прилагаю), раздаются как здравые голоса (напримѣръ, то наблюдение, согласно которому поддержка WebP на чане появилась только тогда, когда впору уж призадуматься о поддержке AVIF), так и не очень здравые (напримѣръ, один странный любитель ImageMagick устроил демонстрацию того, до какой крайности может постепенно дойти человѣкъ, не желая использовать команду «cwebp -m 6 -q числоБалловКачества -pre 5 имяИсходногоФайла -mt -v -metadata icc -progress -o имяФайлаРезультата.webp» по нелѣпой причине «это ниже моего достоинства»).

По наводке https://iichan.hk/b/res/5326636.html#5326804 обратил внимание на параметр «-pass 10» при кодировании WebP.

В справке (скриншот прилагаю) говорится, что значением этого параметра является число шагов анализа, а по адресу https://developers.google.com/speed/webp/docs/cwebp прибавляют: «при дихотомии в режимах -size или -psnr».

Однако и не в этих режимах я вижу параметр «-pass 10» оказывающим влияние на объём файла, сжимаемого с внесением потерь, а также на расположение и характер артефактов в нём.

Не могу однозначно рассудить, к лучшему эти измѣненія или нѣтъ.

Ещё одна недокументированная функция на мою голову, да что ж такое.

>>205779
https://litter.catbox.moe/6uqbhz.png
Возможно, что -q внутри превращается в -psnr, или между ними какая-то другая связь, и таким образом -pass работает и с -q тоже. cwebp мне часто показывает значения PSNR не выше где-то 55 с -m 6 -pass 10 -q 100. Если для 103993299_p0.png попытаться поставить -m 6 -pass 10 -psnr 100, ничего не выходит, получаются Y-U-V-All-PSNR 51.52 51.17 51.22. Если же вместо -psnr 100 поставить -q 100, то для исходника этой картинки PSNR в графе Output будет почти идентичный, даже незначительно хуже: одинаково квантизаторы по сегментам 0, задействован только 1-ый сегмент, но количества блоков разные и у файлов разный размер. Output -psnr 100 идентичен output-у -psnr 52. А вот с -psnr 51, который меньше PSNR-а из предыдущих output-ов, уже появляется разница в количестве блоков.

Кстати, короткий -longhelp просто говорит "analysis pass number". А man упоминает, что если не пользоваться ни -size, ни -psnr, то default'ное значение 1.

>>205779

> Однако и не в этих режимах я вижу параметр «-pass 10» оказывающим влияние на объём файла, сжимаемого с внесением потерь, а также на расположение и характер артефактов в нём.

Однако не всегда, то есть не каждого файла.

Скажем, результаты эксперимента >>201775 не перемѣняются от употребления параметра «-pass 10».

Ѽ, етить.

>>205793

> https://litter.catbox.moe/6uqbhz.png

404 Not Found

>>205796
>https://litterbox.catbox.moe/
>Temporary uploads (max 3 days)

Через 1⅚ года опосля сообщения >>186720 (про возможность подбирать матрицы квантования, употребляемыя форматом AVIF) и через год опосля сообщений >>201775 (про новый libwebp) и >>201776 (про XYB JPEG из jpegli) настаёт время вдругорядь навѣстить челлендж 2021 года, по адресу https://410chan.org/b/arch/res/158687.html#158725 начатый — иными словами, вновь разсмотрѣть итог сжатия тутошнего мема «NICE BOAT» до величины чуть меньше 20 260 байтов.

Откройте архив >>/dev/27447 да и рассмотрите.

Содержащийся там файл AVIF («NICE BOAT noalpha.420yuv10bit42qm0-5.avif») демонстрирует собою достоинства версии 1.0.4 библиотеки libavif, о которых я рассказывал своим читателям в сообщении https://t.me/readMithgol/852 (сшивку скриншота сообщения со скриншотами, в нём приводящимися, прилагаю). Использование новой возможности яркостно-контролируемой субдискретизации цвѣта позволило сохранить значение CRF на уровне 42 (как было и в сообщении >>186720) и удержать матрицы квантования в сходном диапазоне (0—5; было 0—8) одновременно с сохранением объёма файла и нѣкоторымъ нарастанием его качества (особенно видным въ полутѣняхъ на носу судна), принесённым новым кодировщиком.

Вы можете видѣть в том же архиве два файла JPEG XL.

На примѣрѣ первого из них («NICE BOAT noalpha-d16.412.jxl») можно видѣть, что кодировщик JPEG XL за три года, со времени сообщения https://410chan.org/b/arch/res/158687.html#158734 прошедших, нарастил соѿношеніе качества и объёма файла: если въ апрѣлѣ 2021 года желаемого объёма можно было достигнуть только указанием параметра качества («-q 0.777»), то теперь годится и параметр расстояния («-d 16.412»), выражаемого въ безразмѣрныхъ единицах и обеспечивающего, по идее, болѣе равномѣрное ухудшение картинки.

Сразу скажу ещё, что прежде эти безразмѣрные единицы считались величиною расстояния между картинками, измѣреннаго по метрике Butteraugli. Теперь они считаются единицами JND (то есть https://en.wikipedia.org/wiki/Just-noticeable_difference по смыслу). Я считаю, что авторы наконец признали (в такой странноватой форме) существование значительной разницы между расстоянием, указуемым кодировщику, и расстоянием, измѣряемымъ по метрике Butteraugli между исходною картинкою и итогами кодирования. (Отношусь к этому я спокойно, потому что на примѣрѣ звукового кодека Opus давно привык к тому, что указуемый битрейт звука никогда не равен результирующему. С картинками JPEG XL получилось, надо думать, примѣрно то же сáмое, что и со звуком Opus.)

Визуальное сравнение этого нового файла («NICE BOAT noalpha-d16.412.jxl») с итогами трёхлѣтней давности (по адресу https://410chan.org/b/arch/res/158687.html#158734 видными) показывает, что авторы кодировщика совершили мощное перераспредѣленіе информации в сторону долгопериодических колебаний, жертвуя короткопереодическими, так что картинка выглядит гораздо болѣе размытою — но зато возросло количество диагональных линий, цѣликомъ (а не прерывисто) видных сквозь эту новую муть (оформилося, в частности, туловище Аккарин).

На примѣрѣ второго файла («NICE BOAT noalpha-d20.17-g3mod.jxl») я хочу показать, что использование альтернативного способа кодирования (режим Modular вмѣсто VarDCT, то есть использование двумѣрнаго вейвлетнаго преобразованія Альфреда Хаара вмѣсто дискретнаго косинуснаго преобразованія) также способно давать небезынтересные результаты. Снова подавленными оказываются нѣкоторыя важныя границы (как туловище Аккарин, так и нѣкоторые межконтейнерные промежутки), зато общая рѣзкость изображения бесспорна и проявляются многія линіи, в файле «NICE BOAT noalpha-d16.412.jxl» размытыя до полной неясности.

Сравнение этого второго файла с итогами трёхлѣтней давности (по адресу https://410chan.org/b/arch/res/158687.html#158734 видными) обнаруживает настолько близкое сходство, что впору начинать подозрѣвать, что при контроле по качеству вмѣсто контроля по расстоянию (ну или при указании качества слишком небольшого) тогдашний кодировщик каким-то образом переходил именно в модульный режим, а режим VarDCT (то есть дискретное косинусное преобразование) отключал.

ImageMagick вновь работает на Windows 7.

Скриншот подробностей, по адресу https://t.me/ReadMithgol/914 изложенных, прилагаю.

Компания Apple по адресу https://developer.apple.com/documentation/safari-release-notes/safari-18-release-notes#Images сообщила в сáмом начале прошлой недѣли (10 июня 2024 г.) о том, что прекращает поддержку открытия формата графических файлов JPEG 2000 во браузере Safari, начиная от бета-версии Safari 18.

(Скриншот сообщения прилагаю.)

Окончательный выпуск Safari 18 ожидается осенью нынѣшняго года.

Напоминаю (а кое для кого и впервые сообщаю), что поддержка JPEG 2000 считается (как это по адресу https://caniuse.com/jpeg2000 пишут) впервые появившеюся в пятой версии браузера Safari, то есть с марта 2012 года она появилася на iOS, а ещё раньше (с июня 2010 года) — на десктопах (окромя Windows).

Слѣдовательно, всѣ такие сайты, которые вовремя не среагируют на новость об исчезновении поддержки JPEG 2000 из Safari, а за прошедшую дюжину лѣтъ въ полной мѣрѣ воспользовалися этой поддержкою в том смысле, что настроены были «на лету» распознавать посѣтителей, пришедших посредством Safari, и затѣмъ скармливать им JPEG 2000 вмѣсто болѣе ранних форматов картинок (разумная мѣра, позволявшая экономить траффик! — но понятно, что эта экономия достигалася не сама собою, а цѣною роста объёма хранимых файлов, поскольку рядом с каждой картинкою понуждала на сёрверной стороне хранить копию в формате JPEG 2000 для Safari) — всѣ, всѣ они, всѣ эти сайты к осени окажутся для таких посѣтителей безкартиночными, если только эти сайты въ послѣдніе годы заодно не отреагировали и на приход поддержки WebP во браузер Safari в 2020 году (что сдѣлало поддержку WebP всеобщею во браузерах, окромя системы macOS 10 и болѣе ранних версий macOS) и не отказалися от употребления JPEG 2000 хотя бы во браузерах, поддерживающих WebP.

Если же JPEG 2000 подсовывался браузеру не посредством распознавания «на лету», а посредством HTML-тега <picture> (которым перекладывается на сам браузер принятіе рѣшенія о том, какой изъ имѣющихся форматов картинок использовать), то этот формат отключится без проблем (Safari найдёт и использует другой формат, указанный внутри того же тега).

>>208136
>Слѣдовательно, всѣ такие сайты, которые вовремя не среагируют на новость об исчезновении поддержки JPEG 2000 из Safari, а за прошедшую дюжину лѣтъ въ полной мѣрѣ воспользовалися этой поддержкою в том смысле, что настроены были «на лету» распознавать посѣтителей, пришедших посредством Safari, и затѣмъ скармливать им JPEG 2000 вмѣсто болѣе ранних форматов картинок (разумная мѣра, позволявшая экономить траффик! — но понятно, что эта экономия достигалася не сама собою, а цѣною роста объёма хранимых файлов, поскольку рядом с каждой картинкою понуждала на сёрверной стороне хранить копию в формате JPEG 2000 для Safari) — всѣ, всѣ они, всѣ эти сайты к осени окажутся для таких посѣтителей безкартиночными, если только эти сайты въ послѣдніе годы заодно не отреагировали и на приход поддержки WebP во браузер Safari в 2020 году (что сдѣлало поддержку WebP всеобщею во браузерах, окромя системы macOS 10 и болѣе ранних версий macOS) и не отказалися от употребления JPEG 2000 хотя бы во браузерах, поддерживающих WebP.
А такие сайты вообще были? Это же просто бессмысленное расходование дискспейса, ибо любителей огрызков не так уж много, а у других поддержка этого формата в полной мере почти у всех отсутствует. Да и даже если она есть в браузере, то редакторов графики с поддержкой этого формата изображений почти нет, а это означает, что какого либо (заметного без микроскопа) объёма картинок в этом формате попросту не делалось.

>>208143

> любителей огрызков не так уж много

Господин Соусов так не считал, однако же, когда он откладывал на 410чане поддержку WebP (>>/dev/20916) и затѣмъ ещё поддержку AVIF (>>/dev/25134) под предлогом того, что в Safari не увидят.

Прямо сейчас по адресу https://caniuse.com/jpeg2000 поддержка формата JPEG 2000 считается имѣющеюся у 17¾% пользователей (скриншот прилагаю).

Мысль >>208136 я болѣе подробно изложил у себя на канале в Телеграме по адресу https://t.me/ReadMithgol/953 и затѣмъ ещё по адресу https://t.me/ReadMithgol/954

Сшивку скриншотов сообщений прилагаю.