На 410чанѣ съ начала апрѣля 2021 года и по вторую половину января 2022 года совершалося цѣнное обсужденіе многихъ вопросовъ о томъ, какъ умѣстно сохранять изображенія въ графическихъ файлахъ. Его архивъ https://410chan.org/b/arch/res/158687.html донынѣ хранитъ и наглядные примѣры сильнаго сжатія изображеній, и подробные списки достоинствъ нѣкоторыхъ форматовъ графическихъ файловъ, и образцы иллюстрацій, способныхъ помѣщаться на 410чанъ только послѣ переужатія, а не механическаго копированія ихъ изъ первоисточника. Не мало тамъ было сказано и словъ о томъ, слѣдуетъ ли для сохраненія кадровъ видео прибѣгнуть къ формату, предусматривающему сжатіе съ потерями (какъ JPEG или lossy WebP), или же умѣстно потратить большій объёмъ файла (въ форматѣ PNG или въ lossless WebP), но той цѣною достигнуть неизмѣнности пикселовъ. Желая возобновить тутъ обсужденіе графическихъ файловъ, я радъ видѣть для того вѣскій поводъ: въ FFmpeg въ нынѣшнемъ мѣсяцѣ появилась возможность сохранять какой угодно ключевой кадръ из видео AV1 въ файлѣ AVIF, но при этомъ зря не тратится объёмъ файла (какъ было бы при перекодированіи въ форматъ безъ потерь), зря не тратится качество кадровъ (какъ было бы при перекодированіи съ потерями), зря не тратится и то время, которое уходило бы на перекодированіе, а вмѣсто того всѣ свѣдѣнія о пикселахъ ключевого кадра сохраняются «какъ есть» безъ перекодированія, то есть точно въ томъ же прежде сжатомъ видѣ, какой онѣ ужé имѣли въ видеопотокѣ AV1, и снабжаются только новымъ заголовкомъ, приличествующимъ файлу AVIF. Сохранить ключевой кадръ этимъ способомъ можно одною командою: ffmpeg -hide_banner -i имяФайлаAV1 -ss времяКадра -frames:v 1 -c:v copy кадръ.avif Въ сообщеніи по адресу https://t.me/ReadMithgol/491 (растровую копію котораго я прилагаю и тутъ для наглядности) и затѣмъ ещё по адресу https://t.me/ReadMithgol/492 я поподробнѣе разсмотрѣлъ то мѣсто и значеніе, которое эта новинка FFmpeg получаетъ, по моему мнѣнію, въ общей исторіи подходовъ ко сжатію видеокадров и въ исторіи развитія графическихъ форматовъ для храненія изображеній. Ясно вижу, что подобное достиженіе могло явиться на цѣлое десятилѣтіе ранѣе (предпосылки были), однако же не явилося.
Вы не 未来人、 чтобы гарантировать это.
>>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 Сшивку скриншотов сообщений прилагаю.
В течение трёх мѣсяцевъ с половиною (с середины августа и по конец ноября) я пересохранил больше сотни различных изображений, придавая им формат AVIF с обеспéчением достаточно высокого качества (показатель CRF в районе первого-второго десятка) и оттого не очень большого сжатия файла (что-то около 2½ бита на пиксел в среднем). Обобщая накопленный за это время опыт, я пришёл к выводу, что в этой области сжатия уровни матриц квантования в libavif (значения параметров «--advanced color:qm-min=…» и «--advanced color:qm-max=…» в командной строке при вызове avifenc) не могут считаться таким же ползунком «меньше качество изображения, но меньше и объём файла», каким служит, напримѣръ, величина CRF (значение параметра «--advanced cq-level=…»). Если оставить максимальный уровень матрицы по умолчанию равным 15 и постепенно понижать минимальный, то снижение качества изображения сперва сопровождается снижением объёма файла, но затѣмъ объём файла снижаться перестаёт и начинает даже нарастать. Если затѣмъ оставить минимальный уровень на нуле и начать понижать максимальный уровень от 15 до нуля, то объём файла существенно не перемѣняется при этом. Кто по адресу https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md смотрѣлъ параметры кодировщика SVT-AV1 по умолчанию, тот увидал уж у параметра «--qm-max» значение 15 по умолчанию, а у параметра «--qm-min» значение 8 по умолчанию. Я догадываюсь теперь, что это значение отражает собою такое же, как и моё, понимание того, что понижать минимальный уровень до нуля малоэффективно (и даже контрпродуктивно) и что поэтому лучше оставить его посредине — стало быть, около восьми. Это наблюдение можно противопоставить тому, как при сильном сжатии (как в опыте >>207717 с достижением объёма файла чуть меньше 20 260 байтов) минимальный уровень матрицы есть смысл доводить до нуля и есть смысл затѣмъ понижать максимальный уровень, потому что монотонное убывание объёма файла продолжается. Так как в июле появилась новая версия кодировщика (libavif 1.1.1), то опыт >>207717 можно повторить с её участием. По адресу https://qu.ax/ypUoN.avif я выложил результат такого повторения. (Господин Соусов в настоящее время продолжает противиться появлению поддержки AVIF на 410чане, поэтому непосредственное прикладывание файла AVIF к сообщению здѣсь невозможно.) Бóльшая эффективность новой версии приводит к тому, что объём 20 167 байтов достигается (при прочих равных) ужé при qm-max=11, тогда как 16 мая сходный объём (20 023 байтов) достигнут был уменьшением qm-max гораздо далѣе — до пяти.
