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

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

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

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

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

Въ сообщеніи по адресу https://t.me/ReadMithgol/491 (растровую копію котораго я прилагаю и тутъ для наглядности) и затѣмъ ещё по адресу https://t.me/ReadMithgol/492 я поподробнѣе разсмотрѣлъ то мѣсто и значеніе, которое эта новинка FFmpeg получаетъ, по моему мнѣнію, въ общей исторіи подходовъ ко сжатію видеокадров и въ исторіи развитія графическихъ форматовъ для храненія изображеній. Ясно вижу, что подобное достиженіе могло явиться на цѣлое десятилѣтіе ранѣе (предпосылки были), однако же не явилося.
122 сообщений пропущено. Показаны 50 последних сообщений
No. 202458  
OMG, сжатие picture убивает?!
No. 202459  
>>202458
Ловушка Мицгола о которой никто не подозревал! Тысячи пассажиров убились об жипегксель! Читайте дальше...

>таблетки
А по сути ответил только пассажир, давший ссылку на чафу. Все остальное - преобразование сжатого графического файла в текстовый формат. А я спрашивал именно сжатие изображения в виде текста. Иначе заголовок даннага тхреда самнителен!
No. 202460  
faptcha_php.png - (8.17KB, 90×50)
202460
>>202459
> Иначе заголовок даннага тхреда самнителен!
Не могу не поинтересоваться любите ли вы Катю Самбуку?
No. 202461  
75232234_p0.jpg - (0.98MB, 996×1400)
202461
>>202459
Фармат заказал, фармат получил.
No. 202462  
В 2123-ем году все мы мертвы.
Я гарантирую это.
No. 202464  
Вы не 未来人、 чтобы гарантировать это.
No. 202466  
faptcha_php.png - (8.83KB, 90×50)
202466
>>202460
https://ru.wikipedia.org/wiki/Самбука,_Катя
???
No. 202469  
Что если во всёмъ мірѣ одинъ >>202459-кунъ только любитъ Катю Самбуку, а остальные люди его эпохи — всѣ, какимъ-нибудь наплывнымъ вѣтромъ, на время почему-то отъ него оторвались…

И понятно почему.
No. 202476  
faptcha_php.png - (8.98KB, 90×50)
202476
>>202466
Катя Самбука зовется так потому что любит и саму самбуку, а ведь если ее правильно употреблять, с огоньком, то соответственно, какое-то время придется разговаривать в основном с помощью заднеязычных согласных!
No. 202478  
Чистейшая шизофрения. Ради такого я плачу за интернет.
No. 202480  
>>202469
> Что если во всёмъ мірѣ одинъ >>202459-кунъ только любитъ Катю Самбуку

Она на ПМЭФ приезжала в этом году. Знают и любят!
No. 202482  
58602286eba717149b1f4ffb99a7ec8e.jpg - (213.99KB, 1500×1250)
202482
И откуда во мне столько злобы. Периодически.
No. 202484  
>>202480
Лол, правда?
А на следующем будет Альбина Сексова?
No. 202487  
>>202484
Там каждый год кокаиновые оргии с приглашенными знаменитостями.
No. 202741  
photo_2023-07-24_15-21-56.jpg - (77.24KB, 800×600)
202741
Чивоч, что за формат такой heic, старый он новый? Что мы знаем об инновациях в форматах картинок? Что самое лучшее для долгосрочного хранения?
No. 202743  
hytryi plan.jpg - (59.13KB, 435×300)
202743
キタ━━━(゚∀゚)━━━!!
No. 202744  
>>202743
Конечно, дружочек! Чтобы увеличить шансы на то, чтобы ваши работы стали фильмом в будущем, я дам тебе несколько советов:

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

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

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

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

Вспомни, что успех не гарантирован, но активное продвижение и хранение работ могут открыть двери для будущих возможностей. Продолжай творить и делись своим искусством!
магическое сияние
No. 202745  
>>202744
Но вообще надо освоить софт по сортировке кадров для этой профессии, вроде бы Kyno есть такое. Есть ещё некий аналог, я спросил у профессионала, может ответит.
No. 202746  
SVT-AV1 BD-rate.webp - (128.17KB, 1288×747)
202746
>>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 раз в зависимости от настроек кодировщика.)
No. 202781  
>>202746
> во браузере
Ну ёптель-моптель. В браузере же!
No. 202783  
manifesto.png - (470.07KB, 793×731)
202783
キタ━━━(゚∀゚)━━━!!
No. 202787  
>>202781

От ёптель-моптеля слышу. Если можно записывать «во браке», то можно записывать и «во браузере», потому что падеж точно тот же (предложный), ударный слог точно тот же (первый), количество первых согласных точно то же (два), первый гласный звук точно тот же («а»), предшествующие согласные звуки точно тѣ же («бр»), выбор самих предлогов точно тот же («в» или «во» в пользу «во»).
No. 202879  
screenshot.webp - (271.60KB, 888×1455)
202879
По адресу https://t.me/ReadMithgol/707 я опроверг нѣкоторые примѣры неэффективности формата анимированных WebP по сравнению с форматом анимированных GIF, популяризированные создателем утилиты gifski.

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

Скриншот прилагаю.
No. 203033  
formattalks.png - (1.19MB, 1903×4478)
203033
Интриги, скандалы, грязные подробности форматной войны.
No. 203175  
>>203166
https://www.opennet.ru/opennews/art.shtml?num=59746
Да, забавно.
К тому же шебп и в Tor Browser пришел из лисицы, и вот это вот совсем эпично.
No. 203183  
Просто обновите 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, но не обновляет, то соболезную.

Вдвойне соболезную тѣмъ, кого задѣло зеродэем до его исправления. Но опосля обнаружения и исправления теперь всё хорошо.
No. 203187  
>>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 не были защищены никак.
No. 203188  
Напоминаю, что при виде сокращения «TB» типичный читатель сперва пробует прочесть его как «телевизор», затѣмъ как «terabyte» и наконец как «Thunderbird».

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

Сколько и каких будет таких? — это зависит только от величины активного словаря читателя.
No. 203189  
>>203188
Нельзя же так игнорировать контекст!
No. 203207  
Screenshot_2023-10-03_05-20-48.png - (592.14KB, 1920×1054)
203207
Вот как важно перейти на graphicsmagick, ежели кто-то ещё не сделал этого (хоть и некоторые дистрибутивы директивным решением могли перевести насильно).
No. 203210  
Скриншот >>203207 ничего особенного не говорит умý, так как ужé от момента «если в системе до сих пор сохраняется libwebp 0.4.4, не обновлявшийся с октября 2015 года…» большинство читателей сознаёт, что это не про них.
No. 203213  
>>203210
Новый cwebp сжимает лучше?
No. 203214  
>>203213

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

Послѣдній абзац скриншота, к сообщению >>202879 прилагаемого, также относил часть успѣха на счёт болѣе новой версии кодировщика.
No. 203227  
screenshot.webp - (75.07KB, 1280×1046)
203227
Автор рассуждения >>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 году и эксплуатировалася всѣ эти ≈восемь лѣтъ наряду со многими другими уязвимостями, нам ещё не извѣстными, но им очень хорошо извѣстными.
No. 203228  
>>203227
Спасибо за анализ и исправления!
Однакоже это крайне забавно, что тот, у кого "в системе до сих пор сохраняется libwebp 0.4.4, не обновлявшийся с октября 2015 года" оказался в безопасности.
(хотя не совсем конечно, торобраузер же свою несет)
No. 203253  
https://www.youtube.com/watch?v=JehEh7i1PIE
No. 205381  
Какая интересная программа, а есть ли такое же, но чтобы бесплатно?

https://youtu.be/P8t_Fx5dcC4
No. 205509  
smush.webp - (746.80KB, 888×4245)
205509
По адресу https://t.me/ReadMithgol/823 и затѣмъ ещё по адресу https://t.me/ReadMithgol/827 я сообщил про близящійся успѣхъ формата AVIF (на будущей недѣлѣ он будет поддерживаться ужé каждым из популярных браузеров), перечислил достоинства и недостатки.

Сшивку скриншотов своих сообщений прилагаю.
No. 205522  
screenshot.webp - (342.18KB, 888×2690)
205522
По адресу https://t.me/ReadMithgol/828 я прибавил к >>205509 болѣе подробный разсказъ об анимированных AVIF.

Скриншот прилагаю.
No. 205757  
screenshot.webp - (316.41KB, 888×2682)
205757
То событие, которое я прежде в сообщении >>205509 мог без труда предвидѣть, и впрямь произошло 25 января.

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

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

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

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

> Впредь формат WebP будет восприниматься в качестве прошлого такого средства, а формат JPEG — позапрошлого.
No. 205762  
screenshot.webp - (455.44KB, 888×4268)
205762
Под конец позавчерашнего вторника (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» по нелѣпой причине «это ниже моего достоинства»).
No. 205779  
screenshot.webp - (52.40KB, 843×1143)
205779
По наводке https://iichan.hk/b/res/5326636.html#5326804 обратил внимание на параметр «-pass 10» при кодировании WebP.

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

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

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

Ещё одна недокументированная функция на мою голову, да что ж такое.
No. 205793  
103993299_p0_m6_pass10_q99.webp - (4.83MB, 3840×2160)
205793
>>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.
No. 205795  
>>205779

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

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

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

Ѽ, етить.
No. 205796  
>>205793

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

404 Not Found
No. 205797  
>>205796
>https://litterbox.catbox.moe/
>Temporary uploads (max 3 days)
No. 207717  
smush.webp - (1.17MB, 1280×6609)
207717
Через 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 (то есть дискретное косинусное преобразование) отключал.
No. 207821  
screenshot.webp - (354.39KB, 1032×1080)
207821
ImageMagick вновь работает на Windows 7.

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