[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

[Burichan] [Foliant] [Futaba] [Greenhell] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PNG
  • Maximum file size allowed is 20480 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1306823875543.png -(4547 B, 128x128) Thumbnail displayed, click image for full size.
4547 No.2178  

Мелочь конечно, но может отключить генерацию превьюшек для картинок меньше/равных 200х200? Можно будет png с прозрачностями вставлять маленькие, без проблем с фоном.

>> No.2179  

>>2178
Можно было бы даже первьюшки в png генерить, но они как правило в 2-3 раза больше места занимает при том же размере картинки, безлимитки же есть не у всех.

>> No.2180  
File: 1306825648113.png -(999 B, 128x128) Thumbnail displayed, click image for full size.
999

>>2179
На новере есть хоть один не безлимитчик? Просьба отписаться в треде.

>> No.2181  

>>2180
Да, есть.

>> No.2182  
File: 1306825948800.png -(2973 B, 128x128) Thumbnail displayed, click image for full size.
2973

>>2178
>>2180
Лол, превьюшка больше оригинала.

>> No.2183  
File: 1306826295237.png -(30904 B, 128x128) Thumbnail displayed, click image for full size.
30904

>>2181
Насколько всё плохо? Если ограничить помимо разрешения, ещё и размер, к примеру, в 30кб? Я не настаиваю, если что.

>> No.2184  

>>2183
Учитывая что средний размер тумбнейла в /b/ 11 кб, если это все пережать в png то получится 56 кб в среднем. Если не для кого не критичен такой размер тумбнейла то можно будет сделать их и в png.

>> No.2185  

Тумбнейлы теперь в png. Тестируем.

>> No.2186  
File: 1306853150961.png -(5081 B, 128x128) Thumbnail displayed, click image for full size.
5081

>>2185

>> No.2187  
File: 1306853564808.png -(596103 B, 600x450) Thumbnail displayed, click image for full size.
596103

>>2186
Тест с ресайзом

>> No.2188  
File: 1306853786960.png -(514214 B, 1510x1195) Thumbnail displayed, click image for full size.
514214

Здорово, работает. Спасибо.

>> No.2189  

так погодите, модкун, что ты запилил?

>> No.2190  

>>2189
Тумбнейлы теперь генерятся в png а не jpg.

>> No.2191  

>>2190
и что? прозрачность типа будет нормальная?

>> No.2192  

>>2191
Типа того.

>> No.2193  
File: 1306870744670.png -(199452 B, 1280x800) Thumbnail displayed, click image for full size.
199452

>>2191
Ну вот же например: >>2187 >>2188 >>2186

>> No.2194  
File: 1306872078369.png -(72209 B, 100x100) Thumbnail displayed, click image for full size.
72209
>> No.2196  

>>2194
бля. сделай апнг, модкун.

>> No.2197  

>>2196
Ни в коем случае. У некоторых не безлимит. Это только в случае мячика 70кб вместо 5, apng очень большие, да и постоянная анимация ни к чему.

>> No.2198  
File: 1306873669577.gif -(324933 B, 500x224) Thumbnail displayed, click image for full size.
324933

А можно в список допустимых форматов внести svg и webp?

>> No.2199  

>>2198
А еще pcx, bmp, psd, xcf, xpm, ico, pnm, cur, ani, avi, mkv, ogm, ogv, ts, exe, tiff, raw, psp, ai, swf, wmf, pns, jps, djvu, pdf, ps, img, bin, без них ведь просто невозможно жить!

>> No.2200  
File: 1306874967707.jpg -(230692 B, 600x800) Thumbnail displayed, click image for full size.
230692

Кстати превью в png это вин. Такой контраст ранее загруженных картинок и новых.

>> No.2201  

>>2199
Большая часть перечисленного не поддерживается браузерами.

>> No.2202  

>>2201
Если пропатчить самописным патчем то будет работать.

>> No.2203  
File: 1306875939317.png -(44379 B, 400x400) Thumbnail displayed, click image for full size.
44379

>>2202
svg и webp пропихиваются как будущий веб-стандарт от w3c и google. Впрочем ты прав, пока рано о них говорить, дождёмся когда станут популярны. Opera Turbo 11.10 уже конвертирует в webp вместо jpg http://news.softpedia.com/news/Opera-Turbo-Employs-Google-s-WebP-Image-Format-for-Faster-Load-Times-194902.shtml

>> No.4609  

SVG опасен тем, что может содержать JavaScript.

>> No.4611  

mp4 было бы неплохо добавить в связи с повальной конвертацией gif->mp4 на некоторых сайтах

>> No.4613  

В роли некоторых сайтов — imgur и Twitter и Telegram.

>> No.4614  
File: 1520597913116.webm -(3553148 B, 600x336) Thumbnail displayed, click image for full size.
3553148

>>4611

ffmpeg -i source.mp4 -b:v 5M destination.webm
>> No.4615  
File: 1520600933646.jpg -(113805 B, 599x715) Thumbnail displayed, click image for full size.
113805

>>4614
Может, мне ещё тамбнейлы к картинкам самому генерировать?

>> No.4616  

>>4614

Тогда уж «ffmpeg -hide_banner -i source.mp4 -c:v libvpx-vp9 -crf 18 -b:v 0 -tile-columns 2 -threads 8 destination.webm», для того чтобы и распараллеливалося, и новый высококачественный формат VP9, и контроль качества по CRF вместо битрейта.

Но, надо сказать, и это не слишком поможет, так как исходник MP4 на таких сайтах обыкновенно бывает преизрядно фиговатый (и потому, что из GIF сделанный, и потому ещё, что на качестве при этом экономили), так что в пользу разрешения размещать MP4 говорит то, что тогда не придётся домучивать такие видео перекодировкою.

>> No.4617  

>>4616
vp9 по дефолту в webm давно, распараллеливание на любителя, с одной стороны быстрее, с другой - увеличивает размер файла при тех же параметрах

> исходник MP4 на таких сайтах обыкновенно бывает преизрядно фиговатый

Всегда можно поискать оригинал

>> No.4619  

>>4617

> vp9 по дефолту в webm давно

А насколько давно FFmpeg начал по умолчанию использовать VP9 для WebM? (В их вики https://trac.ffmpeg.org/wiki/Encode/VP9 до сих пор предлагается вручную указывать этот кодировщик.)

>> No.4620  

>>4619
Неужели так сложно Changelog почитать?
https://github.com/FFmpeg/FFmpeg/blob/master/Changelog#L335

>> No.4623  
File: 1520648740303.webm -(1305873 B, 1920x1080) Thumbnail displayed, click image for full size.
1305873

>>4620

Понятно. Это отвечает на мой вопрос: так как правка https://github.com/FFmpeg/FFmpeg/commit/2392da164a02e4e4f7e1b933018d14afcb13ddc1 была внесена 28 августа 2015 года, то и VP9 действует по умолчанию с того же времени.

В свою очередь отвечу на заданный мне вопрос: разумеется, Changelog прочесть не так уж и трудно, вот только на него для этого надо каким-то образом наткнуться. Прямой ссылки с сайта FFmpeg на Changelog мне не попалось на глаза, а без неё пойти на Гитхаб я мог бы только в том случае, если бы настолько отчаялся найти ответ на свой вопрос, что начал бы дихотомировать коммиты — а до этого мне было ещё далеко.

>> No.4625  

>>4617

> распараллеливание на любителя: с одной стороны, быстрее, с другой — увеличивает размер файла при тех же параметрах

Это наблюдение совершенно справедливо, однако при наличии двадцати мегабайтов (как на Nowere) редкий видеофайл станет вплотную упираться в них, так что на первый план выходит ускорение кодирования, потому что это одна из важных частей удобства кодирования: она позволяет не утомлять себя сверх меры ожиданием до такой психологической крайности неуюта, за которою даже приступать к видеокодированию придётся без удовольствия, а не то и с надрывом, чего доброго.

>> No.4877  
File: 1542262009730.png -(1062065 B, 1031x1470) Thumbnail displayed, click image for full size.
1062065

Ѿдѣльно ѿмѣчу, что на сайтѣ https://animeloop.org/ предлагаютъ GIF и MP4, но не WebM.

>> No.4891  
File: 1552528327011.png -(2918656 B, 1920x1080) Thumbnail displayed, click image for full size.
2918656

Ещё раз подчёркиваю, что и Telegram поддерживает MP4, но не WebM, так что видео из Telegram (даже подходящие по размеру) нипочём нельзя будет класть на Nowere (без перекодировки) до тех пор, пока Nowere не начнёт поддерживать MP4.

То же самое касается и Твиттера.

>> No.4897  

>>4891
Проприентарно
@
ненужно

>> No.4899  
File: 1553872793252.jpg -(33128 B, 640x480) Thumbnail displayed, click image for full size.
33128

>>4897

Што проприетарно?

>> No.4901  
File: 1554119942148.png -(684 B, 229x19) Thumbnail displayed, click image for full size.
684

>>4899

>> No.4902  

>>4901

Чей сървъръ?

>> No.4903  
File: 1555245585965.jpg -(218254 B, 600x1111) Thumbnail displayed, click image for full size.
218254

>>4899
MP4 несвободен, поддерживать его на линукс-ориентированном ресурсе я считаю неправильным.

>> No.4904  
File: 1555325880581.png -(35547 B, 1200x674) Thumbnail displayed, click image for full size.
35547

По адресу https://bugs.chromium.org/p/chromium/issues/detail?id=746579 я вижу упоминание о том, что юристы Google сочли, что контейнер MP4 (MOV) перестал быть проприетарным.

Думаю, что смысл реплики >>4903 должен быть поэтому отнесён скорее к видеопотоку H.264 и аудиопотоку AAC внутри такого контейнера.

Пожалуй, в этом отношении указание на проприетарность справедливо.

Впрочем, ему недолго осталось быть таковым. На этот счёт по адресу https://people.xiph.org/~negge/NAB2019.pdf сорок пятый «слайд» обещает нам скорый приход видеопотоков AV1 в MP4. (Скриншот прилагаю.) Что же касается аудиопотоков, то формально списочек http://mp4ra.org/#/codecs на сайте MP4 Registration Authority довольно широк (и включает, например, Opus), так что недостаёт только некоего толчка для того, чтобы употребление их обрело силу обычая и перестало наталкиваться на «это не принято делать, так что такой файл не воспроизведётся».

Запасёмся терпением.

>> No.4905  

>>4904
Но ведь av1 можно и в webm заворачивать.

>> No.4906  
File: 1555330067964.webm -(1242553 B, 1920x1080) Thumbnail displayed, click image for full size.
1242553

>>4905

Нѣтъ, нельзя. В настоящее время по адресу https://www.webmproject.org/docs/container/ ясно сказано, что видеопотоком может быть только VP8 или VP9.

Ну то есть разработчики родительского формата (MKV) вроде бы родили по адресу https://matroska-org.github.io/matroska-specification/codec/av1.html документ о том, как можно засунуть AV1 в MKV (и, следовательно, в WebM — потому что WebM является переименованным MKV с ограничениями использованных возможностей MKV), но с этим две проблемы:

во-первых, никакой из поддерживаемых MKV видеокодеков не становится новинкою WebM до тех пор, пока не одобрен авторами WebM (то есть Гуглом) в явном виде, а пока что этого не произошло;

во-вторых, в Википедии по адресу https://en.wikipedia.org/wiki/AV1#Supported_container_formats сообщается (хотя и без приведения каких-либо ссылок на первоисточник этого мнения), что документ https://matroska-org.github.io/matroska-specification/codec/av1.html в действительности не был окончательным и что продолжается внесение потенциально обратно-несовместимых изменений в спецификацию, так что она далека ещё от окончательности. И если это википедическое сообщение соответствует действительности (а не представляет собою продукт беспочвенного викивандализма), то тогда, быть может, именно эта нефинальность и удерживает Google от одобрения новинки в WebM.

>> No.4907  

>>4906

> то тогда, быть может, именно эта нефинальность и удерживает Google от одобрения новинки в WebM.

Значит это просто вопрос времени.

>> No.4908  
File: 1555720725562.png -(2487236 B, 1920x1080) Thumbnail displayed, click image for full size.
2487236

Время покажет, было ли это в действительности вопросом времени.

>> No.5048  
File: 1583557402526.png -(4293609 B, 1920x2911) Thumbnail displayed, click image for full size.
4293609

Предлагаю посмотрѣть по адресу https://evilmartians.com/chronicles/better-web-video-with-av1-codec#how-to-use-av1-right-now на блогозапись с упоминанием того именно, что видеоролики AV1 слѣдуетъ засовывать в контейнер MP4 — именно это там называется поддерживаемым новѣйшими версіями браузера Chrome и браузера Firefox, число пользователей которых автор блогозаписи в августе 2019 года счёл равным 31%, а теперь их уж и 34%.

>> No.5049  

>>5048
Там он выбран как наиболее популярный.

>> No.5055  
File: 1584213771714.png -(3240441 B, 1920x1755) Thumbnail displayed, click image for full size.
3240441

Ну дык ить вот:

принимая во внимание наибольшую популярность размѣщенія видеопотока AV1 со звуком Opus в контейнере MP4,

и принимая во внимание то, что другой вариант: размѣщеніе видеопотока AV1 со звуком Opus в контейнере WebM — и менѣе популярен, и противоречит расположенному по адресу https://www.webmproject.org/docs/container/ требованию создателей стандарта WebM не совать в WebM никаких других видопотоков, кроме VP8 и VP9 (а требование это они с 2017 года не мѣняли, а если хотели бы — перемѣнили бы, включив в него AV1: раньше же перемѣнили, когда включили VP9),

и принимая во внимание то, что сомнения >>4897 и >>4903 о несвободе MP4 уничтожаются (для рассматриваемого частного случая) свѣдѣніями >>4904 о том, что контейнер MP4 (MOV) перестал быть проприетарным, а также изначальною свободою AV1 и Opus,

предлагаю администрации Nowere впредь допускать публикацию файлов MP4 с видеопотоком AV1 и со звуком Opus на имиджборде.

Если нужен наперёд технический совѣтъ о том, как такие файлы MP4 отличать от других файлов MP4, то пожалуйста: вызов команды «ffprobe -v error -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 имяФайла.mp4» для такого файла должен выводить (и выводит) ряд текстовых строк, одна из которых непремѣнно будет «av1» (без кавычек), а другая — «opus» (без кавычек же). При этом на остальных строках может быть что-нибудь ещё болѣе другое — напримѣръ, упомянутое по адресу https://trac.ffmpeg.org/ticket/2149 сообщение об ошибке «Referenced QT chapter track not found» с префиксом в квадратных скобках, шестнадцатеричное число внутри которого зависит от сборки FFprobe.

>> No.5056  

>>5055
Помоему проще будет av1 в стандарт webm протолкнуть.

>> No.5058  
File: 1584215459644.png -(3299714 B, 2351x1080) Thumbnail displayed, click image for full size.
3299714

Послѣдній ѳезисъ реплики >>5055 можно и усилить: вызов команды «ffprobe -v quiet -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 имяФайла.mp4» для такого файла должен выводить (и выводит) только двѣ текстовые строки, одна из которых (чаще всего — первая) непремѣнно будет «av1» (без кавычек), а другая — «opus» (без кавычек же).

>> No.5063  
File: 1584401008693.png -(2114107 B, 1920x1730) Thumbnail displayed, click image for full size.
2114107

Остаётся лишь порадоваться тому, что onus probandi по отношению къ ѳэзису >>5056 лежит не на мнѣ.

>> No.5064  
File: 1584484232490.png -(2007043 B, 1920x2198) Thumbnail displayed, click image for full size.
2007043

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

>> No.5065  

>>5064
Вот-вот, пихать AV1 в WebM — это проявление бесстыдного антисемитизма. А ты какой-то неправильный антисемит, раз этого делать не хочешь.

>> No.5066  
File: 1585007922212.png -(6187416 B, 1920x4763) Thumbnail displayed, click image for full size.
6187416

>>5065

Не надо словами «вот-вот» дѣлать вид, что этот странный тезис как-то слѣдуетъ из моего предшествующего рассуждения.

Рѣчь у меня прежде всего идёт о том, чтобы,

во-первых, использовать видеопоток AV1 наиболѣе общепринятым (наиболѣе популярным) способом, то есть внутри контейнера MP4,

во-вторых, дать возможность тѣмъ посетителям Nowere, которые раз за разом сѣтуютъ о невозможности открыть тот или иной файл WebM (потому что в нём находится AV1), простую и ясную возможность отличать видеофайлы AV1 по расширению файла, то есть создать правило: если на Nowere лежит файл MP4, то тогда видеопоток в нём — непремѣнно, непремѣнно AV1.

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

>> No.5350  
File: 1615000636504.png -(2085985 B, 2459x9261) Thumbnail displayed, click image for full size.
2085985

Впрочем, как я это по адресу https://t.me/ReadMithgol/330 наблюдаю (растровую копию сообщения прилагаю), в контейнере WebM видеозапись оказывается на пару-тройку килобитов в секунду покомпактнѣе, чѣмъ въ MP4.

(Доводов >>5055 это не ѿмѣняетъ, однако же. Просто помогает меньше досадовать по поводу того, что к ним не прислушалися.)

>> No.5351  
File: 1615027980795.jpg -(581807 B, 1000x777) Thumbnail displayed, click image for full size.
581807

В пользу mp4 могу сказать, что youtube-dl качает именно в него, вследствии чего приходится дополнительно переконвертировать как и в случае с >>4611 так что некоторый смысл добавить имеется, несмотря на мицгола

>> No.5352  

>>5351
youtube-dl качает в тот фотрмат, который ты выберешь.

>> No.5353  

>>5352
Нет, но он умеет сам конвертировать в выбранный формат после скачки.

>> No.5354  

>>5352
Возможность такая есть, но бывает так, что видеопоток лучшего качества в H.264 закодирован. Изредка натыкался ещё и на то, что VP версий вовсе нет.

>>5351
Ещё можно было бы упомянуть, что с некоторых других борд есть контент в MP4. Постить его, соответственно, будет проблема.

>> No.5365  
File: 1615672859863.jpg -(390957 B, 1350x1902) Thumbnail displayed, click image for full size.
390957

>>5354

> есть контент в MP4

Я был бы только рад его поддержке на Nowere.

Но увы: насколько я понимаю, выше в репликах >>4897 и >>4903 сообщалось, что видео AVC (H.264) поддерживаться не будет ввиду проприетарности, невзирая даже на объявление https://www.mpegla.com/wp-content/uploads/n-10-08-26.pdf (ещё 2010 года) о том, что MPEG LA не будет облагать платежами интернетовские видеозаписи AVC, бесплатныя для конечных пользователей (то есть, надо думать, для зрителей — но, может быть, непремѣнно и для выкладывающих также).

Реплики >>4897 и >>4903 поданы были без шапки администратора, но онѣ, и это по всему видать, дѣйствительно отражают собою направление администрирования сайта Nowere.

Сам-то я изложил (год назад и притом также 14 марта) компромиссный рецепт >>5058, позволяющий несложно узнавать, когда в контейнере MP4 (а этот контейнер вслѣдствіе >>4904 перестал быть проприетарным, так что вопросы теперь могут быть не к контейнеру, а только к содержимому) находится лицензионно чистый видеопоток AV1 со звуком Opus, «но воз и ныне там».

>> No.5367  
File: 1615675277984.webm -(5119976 B, 1920x1080) Thumbnail displayed, click image for full size.
5119976

Тѣмъ временем я повторил наблюдение >>5350, но на сей раз надъ тѣмъ видеофайлом, который по адресу https://410chan.org/b/src/161560781245.mp4 располагается — и вижу, что его WebM-вариант (который тут прилагаю) позволяет засунуть в одно и то же пространство (5000 килобайтов) всего-навсего на полкилобита в секунду больше, чѣмъ въ MP4 (при идентичном видеоряде AV1 прилагаемый файл WebM содержит звук Opus с битрейтом 81,43 килобита в секунду, тогда как в файле https://410chan.org/b/src/161560781245.mp4 всего лишь 80,93 килобита в секунду — и это опять же «десятичные килобиты» по счёту FFmpeg, то есть по 125 байтов в килобите).

Как нетрудно видѣть, это в 5½ раз меньше, чѣмъ наблюдавшийся въ примѣрѣ >>5350 выигрыш ѿ перемѣны форматов (там было 2¾ килобита в секунду, а тут — только половина килобита в секунду). И если по адресу https://twitter.com/FidonetRunes/status/1368009422275047426 я ещё мог рассуждать, что каждый килобит на счету, то вот полукилобитом я ужé готов пренебречь безъ малѣйшаго угрызенія совѣсти.

Ещё можно указать, что и объём файла также меньше ≈вчетверо (поскольку 410чан куда сильнѣе экономит дисковое пространство); но мнѣ очень трудно вообразить себе такой механизм, благодаря дѣйствію которого прибыток битрейта файла оказывался бы примѣрно прямо пропорционален объёму его (даже настолько примѣрно, насколько 4≈5½), так что я считаю это простым совпадением, а не свидѣтельствомъ зависимости битрейта ѿ объёма.

>> No.5368  

>>5367
Твои рассуждения об экономии позволю себе прервать единственным заявлением о том, что наибольшего эффекта можно достичь просто забанив мицгола, а поскольку этого не происходит рискну предположить, что дисковое пространство не является значимым ресурсом.

>> No.5370  
File: 1615698102550.gif -(1093 B, 35x19) Thumbnail displayed, click image for full size.
1093

>>5365
mp4 без h264 не нужен, потому что проебётся весь профит от его использования >>4611

ИМХО, уже поздно героически сдерживать распространение h264, он, сука, везде. Проблема поддержки в других контейнерах яйца выеденного не стоит: если вебм это часть от матрёшки, просто разрешить матрёшку https://bugzilla.mozilla.org/attachment.cgi?id=9079385&action=diff

>> No.5390  
File: 1618425566805.png -(121522 B, 1150x568) Thumbnail displayed, click image for full size.
121522

По-моему, в комментарии https://bugzilla.mozilla.org/show_bug.cgi?id=1562862#c12 насчёт идеи >>5370 ясно сказали (скриншот прилагаю), что впиливать в Firefox поддержку тѣхъ кодеков, за которые надо платить патентные отчисления, никто не собирается, поэтому поддержка MKV ограничится рамками WebM.

То и другое, впрочем, никак не мѣшаетъ поддержать на Nowere сочетание AV1 и Opus в контейнере MP4, так что тут угадывается единственно политическая воля администрации, как и в случае с неподдержкою WebP и AVIF.

>> No.5391  
File: 1618479642247.jpg -(295174 B, 1061x1500) Thumbnail displayed, click image for full size.
295174

>>5390
Хитрый мод просто ждёт, когда возня с форматами закончится и все перейдут на JPEG XL, поддержку которого добавлять не потребуется, так как он и так совместим с jpeg и отображается (в обычном jpeg-качестве) на любом устройстве.

>> No.5392  
File: 1618489388835.png -(308639 B, 768x1024) Thumbnail displayed, click image for full size.
308639

>>5391

JPEG XL совмѣстимъ съ JPEG только в том смысле, что для каждого JPEG существует способ преобразования в JPEG XL без потерь качества (и с экономией объёма файла).

Никакой возможности открыть произвольный JPEG XL в приложении, понимающем только JPEG, не существует, что нетрудно самостоятельно провѣрить на примѣрѣ семидесятидевятибайтового файла JPEG XL, по адресу https://twitter.com/jonsneyers/status/1382631163995512841 приведённого в формате data-адреса (RFC 2397).

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

>> No.5393  

>>5392
Блджад, развели жыпегов https://jpeg.org/jpegxt/ имелся в виду.

Мне лично http://ds.jpeg.org/whitepapers/jpeg-xs-whitepaper.pdf больше всего интересен в контексте стриминга на VR, но смысла поддерживать его на новере я не вижу.

>> No.5394  
File: 1618506763474.jpg -(67673 B, 1024x576) Thumbnail displayed, click image for full size.
67673

>>5393

JPEG XT не вызвал интереса браузеропроизводителей, так как не предлагал лучшего сжатия, чѣмъ предшествующий формат JPEG.

Источник: десятый кадр презентации https://www.slideshare.net/cloudinarymarketing/imagecon-2019-jon-sneyer

>> No.5401  
File: 1619359503650.png -(33810 B, 1234x640) Thumbnail displayed, click image for full size.
33810

Интерес же браузеропроизводителей вызывает JPEG XL — новая версия JPEG, которая способна обеспечивать пересохранение прежних JPEG без потерь с улучшенным сжатием. Те же изображения, которые никогда не были прежними JPEGами, а вместо того создаются в формате JPEG XL с сáмого начала, получают целую полудюжину возможностей:

① Поддержка не только канала прозрачности, но и дополнительных каналов различного предназначения (инфракрасность, показания дальномера, etc.).

② Поддержка повышенной битности цвета (не хуже, чем в AVIF).

③ Возможность сжатия без потерь, по силе сжатия оставляющего остальные форматы такого сжатия далеко позади, за исключением разве что WebP в некоторых частных случаях (прежде всего такими случаями являются скриншоты текста без цветных картинок).

④ Возможность сжатия с потерями, по силе сжатия при равном качестве опережающего прежний JPEG чуть более, чем в два раза, но отстающего от AVIF при сильном сжатии (особенно когда битов в файле становится меньше, чем пикселов).

⑤ Для всех тех блоков сжатия, на которые делится изображение (то есть для квадратиков 8×8 пикселов или более крупных), их значения усреднённого цвета хранятся в начале файла, поэтому размытое предпросмотровое изображение (уменьшенное по ширине и по высоте в восемь раз) поступает из Сети гораздо раньше остального файла, даже когда отображение файла задумано как построчное, а не как «progressive JPEG XL».

⑥ Progressive JPEG XL заметно распухает по объёму, зато позволяет использовать недокачанный файл как уменьшенный по размеру в два раза, в четыре раза и так далее. Экономия для тех, кто заботится об экономии траффика мобильных пользователей и умных часов, но не желает для этого напрягаться, создавая и храня отдельные файлы с версиями картинки, предназначенными для экранов QHD (1440p), HD (720p) и qHD (360p). Ну или для тех, кто закладывается на рост разрешения больших экранов, но не хочет отдельно создавать и хранить версии картинки для 8K (4320p), 4K (2160p) и FullHD (1080p).

На скриншотах по адресу https://i.redd.it/s3l1g2b40jt61.png и https://i.imgur.com/ezQPsaW.png ясно видно, что Google Chrome (в тестовой версии Canary) ужé содержит поддержку JPEG XL, просто сокрытую за флагом в настройках. Один из скриншотов прилагаю.



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]