[Назад] [Вся нить] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Animapcha image [@] [?]
Тема   ( ответ в 185114)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов GIF, JPG, MP4, OGV, PNG, WEBM, WEBP размером до 5000 кБ.
  • Ныне 2937 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 получаетъ, по моему мнѣнію, въ общей исторіи подходовъ ко сжатію видеокадров и въ исторіи развитія графическихъ форматовъ для храненія изображеній. Ясно вижу, что подобное достиженіе могло явиться на цѣлое десятилѣтіе ранѣе (предпосылки были), однако же не явилося.
9 сообщений пропущено. Показаны 50 последних сообщений
No. 186623  
84192411_p11.jpg - (130.34KB, 1000×750)
186623
>>186617
Для видео VMAF довольно популярная метрика, для статичных картинок работают старые SSIM и PSNR, но результат этих двух баллами не является.
No. 186624  
>>186621
No. 186627  
>>186624
А почему нос в саже?
No. 186654  
>>186627
маскируеца
No. 186659  
>>186654
Не пойми не правильно, я просто первую понравившуюся картику по тегу chibi.
No. 186720  
Прежде упомянутое мною в сообщении >>186640 появление настройки матриц квантования в кодировщике SVT-AV1 (состоявшееся 19 июня) обратило собою моё внимание на тот факт, что аналогичная настройка (также выключенная по умолчанию) не первый год существует и в кодировщике libaom-av1.

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот коммит был аж в 2018 году. Вы должны были бы без труда догадаться, что эти "математики" под плоской матрицей (простаковатое название, если честно, но что самое главное — нигде в то время не документируемое {во всяком случае, я ничего не нашел} и в математике, насколько я могу судить по выдаче разных поисковиков, не слишком популярное) имеется ввиду, что коеффициенты матрицы квантования мало отличаются друг от друга (а что еще это могло бы значить?), а стало быть, на разных частотах отрезания качества будет более ровным, так что и вправду, qm-min=0 понижает днище, а не повышает потолок, потому что "плоскота" матрицы увеличивается по мере увеличения уровня матрицы квантования, как в том коммите и и записано.
No. 188016  
screenshot.webp - (54.51KB, 900×430)
188016
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, болѣе постепенным отображением числа процентов законченности работы в ходе сжатия, совершаемого без потерь, а также исправлением цѣлаго ряда ошибок. Обновляйтеся.
No. 193168  
screenshot.webp - (49.08KB, 900×282)
193168
Не прошло и двух мѣсяцевъ опосля предшествующего сообщения (>>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 на моём канале — можете их теперь репостнуть.)
No. 196497  
screenshot.webp - (45.15KB, 900×272)
196497
Компания 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).

Скриншот прилагаю.
No. 196519  
Разработчики 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"
No. 196520  
>>196519
Обиделись, что вебп не взлетел?
No. 196523  
>>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!
No. 196525  
Там, кстати, внезапно ПНГшники зашевелились: https://www.w3.org/blog/news/archives/9718
No. 196536  
>>196520
WebP — это давно прошлый век уже.
Скорее обиделись, что у ихнего AVIF есть вполне уделывающий этот AVIF конкурент, который — в отличие от — поддерживает сжатие даже уже пожатых JPEGом JPEGов без потерь и реконструкцию обратно в обычный JPEG.
No. 196537  
>>196536
А, ну тем более.
No. 196538  
> www.phoronix.com
Ололо.
No. 196547  
screenshot.webp - (173.99KB, 600×656)
196547
Попытка рационализации «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 открыто выступает на стороне Украины против России и за то его Бог наказал неудачею формата») имѣла бы под собою чуть больше почвы и чуть меньше противорѣчія дѣйствительности.
No. 196588  
Чтобы вѣрно сохранить файл, к сообщению >>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.
No. 196589  
В свою очередь, слѣпо руководиться соображениями, изложенными въ двухъ послѣднихъ абзацах сообщения >>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.
No. 196652  
screenshot.webp - (70.04KB, 1071×1069)
196652
См. также: https://twitter.com/FidonetRunes/status/1588526911915196416
No. 196781  
Тем временем, на неупоминаемом хотят WebP.
No. 196782  
>>196781
На ычане?
No. 196783  
>>196782
Другой, который серо-оранжевый.
No. 196814  
Пруфлинк или не хотят.
No. 196825  
image.png - (38.43KB, 554×277)
196825
>>196814
No. 196827  
пруфлинк.png - (31.58KB, 938×162)
196827
>>196825
Тем временем, на следующем в ад хотят 仮名キャプチャ.
No. 196830  
Притом же в сообщении >>196825 мы видим никакой не пруфлинк, а всего только скриншот, который по итогам поиска https://www.google.com/search?q=site:2ch.hk "где webp" может ещё оказаться и нарисованным.
No. 196910  
screenshot.webp - (45.90KB, 900×274)
196910
Компания 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 ноября).

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

Сарказм >>196827 оказался совершенно справедливым: по ссылке видна единственность желающего WebP, и нецензурную рѣчь его никто не поддержал одобрительным словом.
No. 198254  
screenshot.webp - (11.08KB, 600×180)
198254
https://twitter.com/FidonetRunes/status/1605539320349147136
No. 199138  
Обратите внимание на то, что при помощи libjxl можно изготовить такой файл JPEG, пикселы которого вмѣсто RGB располагаются в том цвѣтовомъ пространстве XYB, которое по адресу https://en.wikipedia.org/wiki/XYB объясняется как содержащее результат простого сложения да вычитания, операндами которого служат непосредственно уровни отклика цвѣточувствительных клеток сетчатки (колбочек), а не уровни воспринимаемого красного-зелёного-синего цвѣта.

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

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

Так как преобразование из XYB в RGB полагается на цвѣтовой профиль в формате ICCv4, то пользователи Firefox раньше версии 108 (или в любой нынѣшней версии мобильнаго Файерфокса) будут видѣть цвѣта искажёнными в таком JPEG, так как с поддержкою ICCv4 разработчики Firefox медлили изрядно долго.
No. 199139  
кот зажрался.jpg - (27.61KB, 500×375)
199139
Миниатюра изображения >>199138 также подаётся в искажённых цвѣтахъ, так как FBE настроен безусловно выкусывать цвѣтовые профили перед миниатюризацией.

Быть может, настала пора пересмотрѣть эту настройку.
No. 199142  
cloud_xyb.jpg - (4.40MB, 4500×2532)
199142
Выкусил цветовой профиль и вышла картинка на 5,1 Мб. Пришлось ужать ещё cjpeg с -quality 92.
No. 199143  
А мои просмотрщики отображают webp из >>199137
и jpg из >> 199138 в зримо отличающихся цветах.
https://slow.pics/c/N7Hg2hcY
FM также превьюшку зеленит.
No. 199156  
>>199143

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

(Таким дефектом https://www.bandisoft.com/honeyview/ обладает, напримѣръ.)
No. 199597  
quote1.webp - (409.60KB, 1175×4096)
199597
Упомянутая в сообщении >>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 прилагаю.
No. 199598  
quote2.webp - (356.59KB, 1931×4096)
199598
Скриншот сообщения https://t.me/ReadMithgol/557 также прилагаю.

Тот файл, который к сообщению прилагался, забирайте в Телеграме. (Разумѣется, въ раздѣлѣ b/ на 410чанѣ этого файла не будет, потому что прикладывание архивов 7-Zip к сообщениям тут не поддерживается, да и объём архива болѣе чѣмъ на порядок превосходит 5000 килобайтов.)
No. 199599  
quote3.webp - (453.90KB, 1306×4096)
199599
Скриншот сообщения 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 переужимал.
No. 199600  
Впрочем, слово «скриншот» тут использовано метонимически для простоты, но по сути к сообщениям >>199597 и >>199598 и >>199599 приложены не скриншоты сообщений, по адресу https://t.me/ReadMithgol/556 и https://t.me/ReadMithgol/557 и https://t.me/ReadMithgol/558 расположенных, а растровые копии их.
No. 199603  
Adult Quote-tan_pq39.png - (23.40KB, 556×526)
199603
Чтобы сдѣлать послѣдній абзац сообщения >>199599 ещё болѣе наглядным примѣромъ, я прилагаю тут результат переужатия (утилитою https://github.com/fhanau/Efficient-Compression-Tool совершённого) того файла PNG, который к сообщению https://410chan.org/b/arch/res/158687.html#171743 прилагался.

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

Дополнительно сообщаю, что даже послѣдняя версия oxipng создаёт в этом примѣрѣ файл большего объёма (хотя и всего-навсего на 20 байтов большего).
No. 199642  
sample_78839932_p0.webp - (4.64MB, 7738×4531)
199642
У меня в кои-то веки дошли руки выкачать все свои закладки с Пиксива, в связи с чем хочу вбросить небольшую статистику.

Из 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 формат по-прежнему не для кофеварок. Хотя, может быть, есть какие-нибудь настройки, которые позволяют за счёт сжатия похуже сильно улучшить скорость декодирования.
No. 199657  
faptcha.png - (8.69KB, 90×50)
199657
>>199642
Я однажды тоже решил схоронить Пиксив, и вот что получилось.
du -sL pixiv
> 676241856 pixiv
du -shL pixiv
> 645G pixiv
find -L pixiv/ | wc -c
> 20420025
Зачем я это сделал и как теперь с этим жить?
No. 199659  
1674644310890557m.jpg - (96.44KB, 1024×987)
199659
>>199657
Двадцать миллионов картинок схоронил пассажир. Пятьдесят миллионов девочек проживает в одной только Японии.
Только вдумайся, какой большой мир! Сколько времени ты на Пиксив с бурами убил, сколько картинок с девочками на борды отправиил, как тщательно картинки с ними к постам подбирал. И сколько бы ты картинок с девочками за свою жизнь ни видел, а в Японии их больше, и все разные и настоящие. Среди них и твоя единственная ламповая няша, которую можно потрогать и погладить. Так что ищи и дерзай, анон-сан!
No. 199660  
>>199657
Ты можешь стать картинкопостером. Вперёд >>199029!
No. 199667  
literally me rn.jpg - (184.56KB, 1920×1080)
199667
>>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 с него. Когда-нибудь с ними разберусь. И ведь не Пиксв же один сайт с картинками.
No. 199716  
>>199659
No. 199717  
>>199657
Аплоадь на панду для фарма поинтов, выводи на деньги, являйся владельцем картинок с потёртых аккаунтов и до изменений контентополитики.
No. 199718  
>>199717
Какой такой вывод? Максимум голдстар купить. Девочке нашептали, что для голдстаров доступно больше галерей.
No. 199720  
>>199718
>баунти за галереи в hath/gold
Люди не глупыя, где-то сканлейтеры эти фантики в реальные денежные знаки всё-таки переводят.
Удалить сообщение []
Пароль  
[Mod]