Двач.hk не отвечает.
Вы видите копию треда, сохраненную позавчера в 20:21.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
logo.jxl.png528 Кб, 1000x1000
JPEG XL [JXL] Thread Windows 10: Firefox based 3213710 В конец треда | Веб
JPEG XL - Новый свободный формат изображений, который мы заслуживаем.

Из распространённых форматов на сегодняшний день мы имеем старый добрый JPEG, который немного омолодила Mozilla, когда выпустила кодировщик MOZ JPEG; PNG (для изображений без потерь) и GIF, который давно пора отправить на свалку истории.

Также есть несколько относительно свежих форматов изображений, которые являются побочным продуктом, полученным при разработки видеокодеков. К примеру HEIС (HEIF) который так любит Apple происходит из видеокодека HEVC. Та же история с форматами WebP и AVIF, которые произошли из VP9 (VP8) и AV1 соответственно.
Но так как эти кодировщики делались изначально для видео, они концептуально не настолько эффективны для хранения изображений.

Джва года назад собрались компании Google и JPEG и решили, что так дальше дела не могут идти и создали новый свободный формат, который должен стать новым мировым стандартом, как когда-то стал JPEG. И у него есть все шансы. Он одновременно может заменить JPEG, в случаях сжатия с потерями (например фотки), PNG, в случаях сжатия без потерь (скриншоты), GIF (коротенькие анимации), ведь он может это всё гораздо лучше их самих.

Основные фичи формата:
- Сжимает на 60% лучше, чем JPEG.
- Сжимает без потерь на 35% лучше, чем PNG.
- Он может транскодировать jpeg изображение без потерь туда и обратно. Транскодированное JPEG XL изображение весит на ~20% меньше оригинала. Это значит, что можно спокойно пережать все свои фотки, не потеряв ни бита информации. Таким больше никто не может похвастаться.
- Поддержка прогрессивного декодирования (актуально для веба. Наполовину загруженная пикча уже выглядит хорошо)
- Анимации (замена гифок).
- Почти полнота по Тьюрингу (если бы не ограничения на максимальный размер обрабатываемых пикселей). Это позволит почти бесконечно оптимизировать формат. Пикрил в формате JPEG XL весит всего 117 байтов! И по факту является программой по его генерации, написанной вручную. Больше подобных пикч можно найти в комьюнити Discord сервере.
- Свободный формат, а это значит, что его может использовать кто и как угодно. Его уже можно активировать в Chrome, если включить флаг enable-jxl, и в ночных сборках Firefox. Также его поддержка уже добавлена в Gnome. Для винды тоже есть вьюеры. Про Plasma вообще без понятия (скорее всего тоже есть).

Сайт сообщества: https://jpegxl.info/
Там все нужные ссылки, картинки и более подробное объяснение всего.
Android: Mobile Safari 2 3213713
Референсный энкодер, декодер и транскодер для тех, кто хочет поиграться с форматом.
https://github.com/libjxl/libjxl

ImageMagick тоже поддерживает JXL, но когда я в последний раз его тыкал, он это делал хреново. Возможно сейчас уже лучше.
Windows 7: Firefox based 3 3213719
>>213710 (OP)

> - Почти полнота по Тьюрингу (если бы не ограничения на максимальный размер обрабатываемых пикселей). Это позволит почти бесконечно оптимизировать формат. Пикрил в формате JPEG XL весит всего 117 байтов! И по факту является программой по его генерации, написанной вручную.


Время вирусни в картинках.
Android: Mobile Safari 4 3213721
>>213719
Да, это теоретически может быть проблемой при использовании кривых декодеров.

Но в целом предпосылок не должно быть. Коммент с HackerNews:
https://news.ycombinator.com/item?id=27577447

> It’s not a security risk though: the decode computation per pixel is still bounded, so there is no way to make the decoder go into an infinite loop or anything like that. In that respect it’s (intentionally) not Turing complete, unlike some other image formats like PostScript and SVG that do have actual programming languages in them that can cause a decoder/interpreter to go into an infinite loop (safe handling of such files does require sandboxing and time-outs).

Android: Mobile Safari 5 3213724
>>213723 (Del)
У меня пока нет потребности в свободном месте, да и галерея не такая большая. Торопиться не надо. Но когда появится повсеместная поддержка, то почему нет?
Linux: Chromium based 6 3213733
>>213710 (OP)

> - Свободный формат, а это значит, что его может использовать кто и как угодно. Его уже можно активировать в Chrome, если включить флаг enable-jxl, и в ночных сборках Firefox. Также его поддержка уже добавлена в Gnome. Для винды тоже есть вьюеры. Про Plasma вообще без понятия (скорее всего тоже есть).


mpv, который работает везде, тоже открывает jpeg xl.
Windows 10: Chromium based 7 3213735
>>213733

>mpv


хуета, разработчики-инвалиды даже настроек в нормальном виде не завезли.
Android: Mobile Safari 8 3213736
Generation loss у разных форматов:
https://youtu.be/w7UDJUCMTng

Сравнение прогрессивного декодирования:
https://youtu.be/inQxEBn831w

На канале ещё много подобных видосов.
Но они относительно старые, по идее, сейчас кодировщик и декодировщик могли стать ещё лучше.
Windows 10: Firefox based 9 3213738
>>213733
Только его бетатестерские сборки. Stable старый, 0.34.1, не поддерживает.
Linux: Chromium based 10 3213739
>>213738
Если собрать стабильную версию со свежим ffmpeg'ом, то должно открывать, но я не пробовал.
09uib46kogh0rt98y.jpeg14 Кб, 225x225
Linux: Firefox based 11 3213745
>>213710 (OP)
Это называется контейнер. И пошли они в пень. Знать о формате изображения только на этапе декодирования - удобно только для "листальщиков картинок".
Android: Mobile Safari 12 3213748
>>213745
Кто контейнер?
Windows 7: Firefox based 13 3213806
>>213710 (OP)
Когда будет поддержка в HoneyView, XnView Cassic или хотя бы в FastStone, то можно пользоваться.
sage Windows 10: Firefox based 14 3213885
>>213710 (OP)

>Он одновременно может заменить JPEG, в случаях сжатия с потерями (например фотки), PNG, в случаях сжатия без потерь (скриншоты)


И как тогда различать пережатые картинки от непережатых? Никак? Нахуй следуйте.

>Почти полнота по Тьюрингу


>картинка по факту является программой


Круто, теперь вирусы/майнеры в картинках. Нахуй следуйте.
Windows 10: Firefox based 15 3217318

> Сжимает на 60% лучше, чем JPEG


А по сравнению с вебп?
Windows 10: Firefox based 16 3217375
>>213710 (OP)
Помнится, когда появился jfif, тоже было визгу. И где оно теперь?
Linux: Firefox based 17 3217379
>>213710 (OP)

А инфу в нем можно хранить, как в раржпег например?
Android: Firefox based 18 3217393
>>217375
Оно и нинужно было никогда. Опус взлетел, джхл тоже летит.
rarjxl.png504 Кб, 968x776
Linux: Chromium based 19 3217396
>>217379
Можно.
Linux: Firefox based 20 3217420
Короче, нинужно.
Windows 10: Firefox based 21 3217574
>>217393
Ну, удачного полёта. Может, и до меня долетит. А я капризный.
Apple GayiPhone: Safari 22 3218687

>Пикрил в формате JPEG XL весит всего 117 байтов! И по факту является программой по его генерации


Ждем когда вместо любого хайрез изображения будет промпт для генерации на аппаратно реализованном Stable Diffusion.
Linux: Chromium based 23 3219040
НИНУЖНО, ибо в png анимацию завезут
https://www.opennet.ru/opennews/art.shtml?num=57977
Linux: Firefox based 24 3219045
>>218687
Это, кстати, хорошее ожидание. Появление аппаратной реализации dpi-независмой модели Continuous Image Representation существенно перезапустит взгляды и на сжатие, и на рендер.
Android: Mobile Safari 25 3220573
https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL
Они убили jxl, сволочи!
Windows 10: Firefox based 26 3220694
>>220573
Вот так оно иметь монополиста. А кто-то за него ещё и бесплатно топит прямо на этой доске.
Android: Mobile Safari 27 3221017
Гуглохрому и мобилкам нужно просто перестать поддерживать жипег для того, чтобы сдвинуть дело с мёртвой точки
Apple Mac: Safari 28 3221066
>>220573
Google и Apple похоже решили сделать AVIF дефолтным next-gen форматом для изображений.
IOS 16 например уже поддерживает AVIF, в то время как у них ушло 10 лет, чтобы добавить поддержку WEBP.
image.png4 Кб, 167x46
Fedora: Chromium based 29 3221071

>.png



Проиграл
Apple Mac: Safari 30 3221073
>>221071
С чего? Двач до сих пор в webp не может, чего уж говорить о jxl, разумеется картинку нужно было конвертировать в пнг или в жпег.
Windows 10: Firefox based 31 3221252
>>213710 (OP)

>- Он может транскодировать jpeg изображение без потерь туда и обратно.


a PNG?
Windows 10: Firefox based 32 3221257
>>213806
Поддержка есть в windows - следовательно везде, гугли WIC decoding
Windows 10: Firefox based 33 3221260
>>218687
Вам смешно, а я б был рад еслиб waifu2x встроили б в мозиллу для апскейла картинок

мимо читаю комиксы от ебучих шакалов постоянно
Apple Mac: Safari 34 3221280
>>221252
C jpeg -> jxl -> jpeg ты получишь в точности тот же самый файл.
С пнг ты получишь другой файл другого размера в байтах, но с теми же пикселями.
Windows 10: Firefox based 35 3221283
>>221280

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



А почему тогда файл будет другой если пиксели те же?

Я про перегонку loseless JXL - > PNG и обратно конечно же
Apple Mac: Safari 36 3221285
>>221283
jxl -> png -> jxl даст одинаковые файлы.
png -> jxl -> png необязательно, так как оригинальный пнг неизвестно чем создан и с какими опциями.
Windows 10: Firefox based 37 3221291
>>221285

>так как оригинальный пнг неизвестно чем создан и с какими опциями.


Если ты про всякие хуептимизации - так и хуй с ним, ведь на картинку не влияет же, разве нет?
Android: Mobile Safari 38 3221310
>>221291

> на картинку не влияет


Всё так
Android: Mobile Safari 39 3221583
Стоит конвертировать форточки из jpeg в jxl? Существенная экономия будет?

>мимо

Android: Mobile Safari 40 3221586
>>220694
Каким боком тут монополия? Они этот формат разрабатывают, они и могут его убить.
Windows 10: Firefox based 41 3221593
>>221586
Ты новость-то читал?
Монополия — на браузерный движок. Разрабатывают, именно что за пределами гугла, и конкурироет с домашним гугловским webp.
Windows 10: Chromium based 42 3221596
>>220694
Создайте своего монополиста, чо.
Windows 10: Firefox based 43 3221598
>>221596

>Создайте своего монополиста, чо.


Это не решит проблему монополистов, очевидно же?
Windows 10: Firefox based 44 3221602
Исходный код пердоформата есть, в чём похороны заключаются?
Некоторые кодеки вроде TAK вообще одним васяном пилятся и вполне себе живут, бгг
Android: Mobile Safari 45 3221618
>>221602
Мы живëм в мире вытесняющей товарности. Но я в этом не уверен.
Android: Mobile Safari 46 3221671
>>221593
Тогда непонятно почему гугл указан как один из разработчиков на педивикии.
Linux: Firefox based 47 3221881
>>221602

>вроде TAK


>вполне себе живут


Этот ТАК один шизик на весь /с/ форсит. Не удивлюсь что это и есть тот самый один васян.
FLIF is dead, and JPEG XL has killed him is this true · Issue #549 · FLIF-hubFLIF.png302 Кб, 1837x561
Apple Mac: Safari 48 3221886
>>221671
Потому что кто-то из гугла пилил PIK, который впоследствии слился с FUIF в jxl.

https://github.com/google/pik
https://github.com/cloudinary/fuif
https://github.com/FLIF-hub/FLIF/issues/549#issuecomment-912335312
Apple Mac: Safari 49 3221889
>>221671>>221886
Ну и теперь эти люди из гугла пилят jxl, например:
https://github.com/jan-wassenberg
https://github.com/mo271
Android: Mobile Safari 50 3221937
>>221881
Что за ТАК то вообще?? Есть годные аудиоформаты типа wavpack и musepack, которым уже сто лет, но их мало кто поддерживает, что впрочем не мешает их использовать. Именно поэтому я все фоточки давно корветнул в jxl, а что там хипстеры ебаные о себе возомнили мне похуй. Ещё бы на мнение FAGMAN равняться.
Windows 10: Firefox based 51 3221958
>>221937

> Что за ТАК то вообще??


Формат кодирования аудио без потерь, обеспечивающий максимальную степень компрессии по сравнению с другими lossless-кодеками.
Причаститься: http://thbeck.de/Tak/Tak.html
Автор всё хочет в Open Source своё детище перевести, но пока не получается особо.
Windows 10: Firefox based 52 3221960
>>221881

> Linux


Тебе просто обидно, что тебя ниопустили совсем, обойдя стороной прошивку для роутера, бгг. А TAK пилит немец, он не может здесь его форсить.
Android: Mobile Safari 53 3221973
>>221958
>>221960
Как у нас на ЛОРе говорят, НИНУЖНО!!111
Снимок экрана от 2022-11-02 20-45-38.png185 Кб, 1800x698
Linux: Firefox based 54 3221974
>>221958

>максимальную степень компрессии


Мало того, что не максимальную. Так ещё и компрессию примерно на 2..3% отличающуюся от любого распространённого опенсорсного формата.
Android: Mobile Safari 55 3221979
>>221977 (Del)
Два самых нинужных кодека, согласно этой таблице, т.к. даже software support хромает. Про hardware молчу.
Linux: Firefox based 56 3221981
>>221977 (Del)

> Более уплотнённо сжимает только OptimFROG, Monkey's Audio и Lossless Audio


> все находятся в вилке 49..52%


Ты только что тупо повторил моё утверждение.
Android: Mobile Safari 57 3221986
>>221983 (Del)
Все, устал тебя кормить, иди своё нинужно свидетелям фубара форси. Неудивительно, что проприетарное говно, которое даже рокбокс не умеет, никто не хочет использовать. Да и вообще все проприетарные форматы через лет 50 превратятся в тыкву.
jpeg.png642 Кб, 1212x1741
Apple Mac: Safari 58 3224550
Похоже из стандартного жпега можно выжать еще больше сжатия при том же качестве картинки.
Android: Mobile Safari 59 3224684
>>224550

>28%


Звучит слишком хорошо, я фотки перевёл в jxl получил где то так же. Зачем тогда изобрели jxl?
Apple Mac: Safari 60 3224701
>>224684
Я так это понимаю:
100 png->jpg (baseline)
80% png->jpg->jxl (lossless transcoding)
72% png->jpg+ (кодек из скриншота)
40% png->jxl (lossy jxl)
Android: Mobile Safari 61 3224715
>>224701
jxl жмёт аж на 60% лучше jpg (обычного)?
Apple Mac: Safari 62 3224723
>>224715
Это то, что указано в оп посте.

>Основные фичи формата:


>- Сжимает на 60% лучше, чем JPEG.

Linux: Firefox based 63 3224743
>>213710 (OP)
Только проблема сайтов не в дохуя тяжелых картиночках, а в ебучих скриптах по несколько мегабайт.
Android: Mobile Safari 64 3224745
>>224743
Это понятно, но если на сайтах и в браузерах не будет jxl, его нигде не будет, где он нужен.
Windows 10: Chromium based 65 3224755
>>224743
то-то они глубоко прожаривают пользовательские картинки
UkkrbzjyiJe3RtiH8vArpN.png63 Кб, 561x1260
Windows XP: Firefox based 66 3224823
>>224550
Во-первых, JPEG делали в те времена, когда просто декодировать фото 640×480 и вывести его на экран, преобразовав в текущую 256-цветную палитру или подобрав оптимизированную (что совсем не мгновенно), было проблемой для домашних систем. Даже с тех времён, как графика стала более-менее ворочаться, производительность одноядерных систем выросла примерно на два порядка (плюс ещё где-то порядок в следующие пятнадцать лет и плюс многоядерность). Логично эту лишнюю производительность использовать для того, что в начале девяностых годов было за гранью практически осуществимого. Формат RAR5 был добавлен для ориентации на современные системы, например.

Во-вторых, если мы можем терять данные, ограничиваясь только визуальным (акустическим, …) сходством, то возникает простор для всевозможной предобработки, предсказания и подтасовки данных, даже если базовый алгоритм не меняется и совместим с существующими декодерами. Какой-то из компрессоров на соревнованиях по сжатию картинок без потерь, помню, оказался с потерями, но оптимизированным так, чтобы на большинстве типичных данных генерировать не отличающуюся копию. Действительно, мы же обычно не разглядываем сгенерированный случайный шум (забудем сейчас про модные нейросетевые картинки). А от фото в JPEG мы небольшой деградации качества ожидаем, так что какая именно она будет, может решать кодировщик.

В общем виде на графике отношения объёма сжатых данных к затратам времени на сжатие у нас всё та же гипербола (удобно продемонстрированная на страничке zpaq), форма и расположение которой зависит от алгоритма, данных и компьютера. После какого-то момента маленький шажок для уменьшения объёма требует всё больше и больше работы.
http://www.qlic.altervista.org/LPCB.html
http://mattmahoney.net/dc/zpaq.html

Ну а если набор данных ровно один, оптимизироваться под него можно до посинения.
http://mattmahoney.net/dc/text.html
Windows 10: Chromium based 67 3224832
>>224823

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


а вот это очень интересно. зачем? нахуя? не можешь вспомнить что это было?
Windows XP: Firefox based 68 3224850
>>224832
Это могла быть просто не отлаженная программа. Если ты посмотришь, в тестах кучу строчек занимают программы, которые поддерживают только часть форматов изображений или специально написаны для сжатия конкретного набора данных, даже не пытаясь работать с остальными. Смысл в том, что это опорные точки для оптимизации, на которые можно ориентироваться при оценке общих алгоритмов.

> зачем? нахуя?


Ну так если у тебя программа на миллионе прочих данных работает некорректно, а с тестовыми всё хорошо, и это позволяет улучшить результат, то ты просто получил некий алгоритм генерации именно этих данных. См. пример сжатия цифр числа пи.
Windows 10: Firefox based 69 3224851
>>224745
Ну хром (90% юзеров на нём) сказал "НЕТ, будем делать СВОЁ", - так что хороним.
Windows 10: Chromium based 70 3224853
>>224850
понятно, ну это уже совсем другое соревнование получается, к сжатию изображений отношения не имеющее,
Windows XP: Firefox based 71 3224865
>>224853
Ага, люди годами что-то обсуждают, статьи в научные журналы пишут, а потому приходишь ты и говоришь, что это всё чепуха какая-то. Ты понимаешь, что вон те результаты нейросеточек, на вычислительных кластерах подбирающих алгоритм, возникли по следам ковыряния вот этих маленьких программ и их обобщения?

Наконец, можно оценить общую картину. Вон строчка с результатами обычного PNG, что мы понимаем, глядя на неё? Во-первых, что стандартный zlib что-то как-то медленно работает (а это не новость, всем известные проекты предлагают сравнимый результат с теми же принципами сжатия за меньшее время). Во-вторых, что от современного формата сжатия без потерь общего назначения мы можем ожидать улучшения в 20-25% относительно PNG. А кому это надо? Если ты строишь три датацентра вместо четырёх и заказываешь на столько же меньше грузовиков с дисками, сумма экономии выходит внушительная. Если же у тебя картинки занимают четыре гигабайта вместо пяти, ты этого просто не заметишь на фоне всей прочей скачанной порнухи с пенсионерками.
Android: Mobile Safari 72 3224866
>>224851
Пока просмотрощики и редакторы его поддерживают, можно продолжать фотки в него пережимать. Ну а инстабляди пусть сосут.
Windows 10: Firefox based 73 3224893
>>224866

>просмотрощики


Сам создал изображение, - сам посмотрел, - ЗАЕБИСЬ какой нужный формат.
Android: Mobile Safari 74 3224895
>>224893
Нужный. Почему меня должно волновать место на серверах гугля или яндекса? Мне jxl моё место экономит.
Apple Mac: Safari 75 3224896
>>224865

>Вон строчка с результатами обычного PNG, что мы понимаем, глядя на неё? Во-первых, что стандартный zlib что-то как-то медленно работает


Кстати, натыкался на прототип пнг, в котором заменили zlib на zstandard.
https://github.com/catid/Zpng
Судя по ридми работает гораздо быстрее и дает файлы меньшего размера.
Windows 10: Chromium based 76 3225066
>>224865
извиняюсь перед учеными.
и все же, на реальных данных, а не на заранее известном бенчмарке, программы-рекордсмены все еще показывают лучший результат? может бы я описал не текущую ситуацию, а будущую, но она явно случится - когда переоптимизация под кокретные картинки перестанет нести поелзные на практике идеи. что-то типа оп-пика.
>>224895
вот кстати перевод из жпега и обратно в жпг без потерь реально киллер фича. только удобный пользовательский интерфейс чтобы картинки из своего хранилища постить в интернет современные оси и браузеры даже не позволят сделать нормально.
Windows 10: Chromium based 77 3225067
>>224893

>Сам создал изображение


>сам посмотрел


в том-то и дело что нет и нет. ты описал любой рандомный кодек, а jpeg xl может пережать без потерь существующий жпег, причем не только без потери пикселей но и без потери самого жпега!

вот бы для h264 сделали оптимизатор, там как и в любом кодеке есть беспотерьная часть, и реалтаймовые кодеры использующиеся при съемке явно не оптимальны.
Windows 10: Chromium based 78 3225069
а ведь сделали, только за каким-то хером оно заброшено...
https://encode.su/threads/3213-Is-there-an-MP4-optimizer
Android: Mobile Safari 79 3225085
>>225066

> вот кстати перевод из жпега и обратно в жпг без потерь реально киллер фича.


Как правило, если не инстаблядь, то фотки и нет необходимости постить.

>>225067

>без потери самого жпега


И зачем это нужно, jpeg же говно.
Windows 10: Chromium based 80 3225088
>>225085
а как же мемы и реакшнфейсы?
Android: Mobile Safari 81 3225106
>>225088
Если ты коллекционируешь это говно, значит ты слишком много времени проводишь онлайн и вообще лазер...
Windows 10: Firefox based 82 3225385
>>225085

>И зачем это нужно


Сегодня придумали JPEX XL - ты перегнал в него всё, завтра JPEG XXL - опять перегнал, JPEX XXXL - опять - и вот у тебя бы уже были одни шакалы видны если после каждого шага был было бы перекодирование перекодированного
Android: Firefox based 83 3225391
>>217316 (Del)
А гугель против что ли?
bWVkaWEvRmhLS0x1ZldJQUVnRFBqLmpwZw==.jpeg81 Кб, 960x540
Apple Mac: Safari 84 3225437
>>225391
Да, против.
Android: Mobile Safari 85 3225440
>>225437
Вся надежда на лису, сафари и эдж.
Android: Mobile Safari 86 3225465
>>225440
А что, Edge уже не на хромиуме?
Android: Mobile Safari 87 3225467
>>225465
Ну добавить поддержку они могут, наверное.
Android: Mobile Safari 88 3225468
>>225467
Если добавят, то сразу в хромикм закинут. От совсем халявы там не откажутся.
Android: Mobile Safari 89 3225469
>>225468
Если согласятся поддерживать, то да. Именно из-за недостатка интереса её и убрали оттуда недавно.
Windows 10: Firefox based 90 3225480
>>225469
все так просто? а я думал политические интересы
Android: Mobile Safari 91 3225481
>>225480
Да, скорее ты прав. Вот поэтому я надеюсь, что в edge быстрей добавят. Не хочется уж больно юзать webp2 или как его там.
Apple Mac: Safari 92 3225482
>>225481
avif, webp2 тоже отменили
nitter.png899 Кб, 1231x2055
Apple Mac: Safari 93 3225684
Google продолжает настаивать на их решении:
https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/0XA-0G6hBgAJ

Тем, кто хочет пользоваться форматом в хроме, предлагают wasm версию.

>For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward.

Linux: Firefox based 94 3226179
>>213710 (OP)
и чем сабж лучше чем AVIF?

я столько крутил вертел и всё равно результат хуже чем у avif
Android: Mobile Safari 95 3226196

>Эпоха ссд накопителей


>Средний сайт занипер в памяти 5 мегабайт


>Средняя программа минимум 200 мегабайт


>Уии, новый формат позволяет сократить размер картинки на 50 килобайт, уряяя, перемога, срочна начинаем его форсить вместо старых добрых jpg, gif и bmp

Android: Mobile Safari 96 3226197
>>226196

>занипер


Занимает
Android: Mobile Safari 97 3226207
>>226196
Зачем жрать говно если можно не жрать? Перегнал все свои jpeg и png в jxl без потерь в качестве. Единый формат, который меньше их обоих.
Windows 10: Firefox based 98 3226211
>>226207
Зачем мне пердолиться ради 0.001% экономии места на диске?

Отправить фотку кому-нибудь показать? - Нет, я ведь пердольщик

Выложить в интернет показать? - Нет, я ведь пердольщик

Сохранил картиночку из инета, что дальше? - Да, пердолиться!
Android: Mobile Safari 99 3226219
>>226211
Всего то скриптик запустить.

> Отправить фотку кому-нибудь показать? - Нет, я ведь пердольщик


На переходном этапе, а если поддержка будет везде, то эта проблема отпадает сама собой.
Android: Mobile Safari 100 3226589
>>226219
Напомнить сколько переходной этап у webp был? 12 лет прошло, а двач до сих пор не осилил.
Или напомнить сколько этот переходный период был у jpg2000?
Windows 7: New Opera 101 3226680
>>226656 (Del)
УРРЯЯЯ, АЖ НА ПИТЬСОТ КИЛАБАЙТ МЕНЬШЕ МЕСТА, ПЕРЕМОГА
@
IШТО ЗНАЧИТ , ГЕНШИН ИМПАКТ ЗАНИМАЕТ 228 ГИГАБАЙТ (ПРИ ГРАФИКЕ ХУЖЕ ЧЕМ В КРУЗИС 1), ТЫ ЧО РЕТРАГРАД ИЗ ПРОШЛОГО ВЕКА ШТО ЛИ, ПРОСТА КУПИ НОВЫЙ СОСОДИ НА 100500 ТБ
image.png464 Кб, 1332x850
Windows 7: New Opera 102 3226683
>>226680
Отклеилось
image.png1,1 Мб, 1164x873
Windows 7: New Opera 103 3226698
>>226687 (Del)

>Геншин


Он идет даже на пука времен Windows XP с соответствующей видеокартой
Windows 10: Chromium based 105 3226902
>>226698
>>226699
Автор темы писал, что загрузка застревает на 13%. Возможно из-за отсутствия SSE4.
Android: Mobile Safari 106 3226955
>>226902
Суть не в этом. Главное что сама игра не особо требовательная, но при этом занимает даже больше места чем гта 5.
Windows 10: Chromium based 107 3232389
>>226955
Ну так в обоих этих играх половину объёма занимает озвучка.
Windows 10: Firefox based 108 3233574
>>226196

>Уии, новый формат позволяет сократить размер картинки на 50 килобайт


А вот и нихуя, больше. Если lossless в png весит 19,7 мегабайт, то математический lossless (-d 0) jxl весит 9,64 мегабайта. Если брать почти lossless (-d 0.3 -e 9 --brotli_effort 11), то он весит 3,88 мегабайта, и отличий от png вообще нет, даже если в прильнуть лицом к экрану и заняться охотой на пиксели.
Windows 7: Firefox based 109 3233598
>>233574

> "почти lossless"


> Продолжает сравнивать с .png


А ты хорош. У тебя еще и .png поди не оптимизированный?
Android: Mobile Safari 110 3233599
>>233598
А с чем сравнивать, с jpg или gif что ли?
Windows 7: Firefox based 111 3233602
>>233599
А почему нет то? Потерьное с потерьным. Сравнивай с оптимизированным jpeg'ом на максималке.
Android: Mobile Safari 112 3233606
>>233602
Потому что любой жпег визуально гораздо хуже nearly-lossless jxl.
Windows 7: Firefox based 113 3233608
>>233606
Ты просто не умеешь делать хорошие jpeg'и.
Apple Mac: Safari 115 3233626
>>233611
Для тех, кто не хочет переходить по ссылке. Там пишут, что jxl в среднем примерно на 48% и 37% меньше, чем png и оптимизированный png соответственно.
Windows 7: Firefox based 116 3233627
>>233626
И кодируется в 35 раз дольше, ога.
Android: Mobile Safari 117 3233628
>>233627

> И кодируется в 35 раз дольше, ога.



> These tests have also been done at the lowest possible speeds

Windows 7: Firefox based 118 3233629
>>233628
И? На быстрых прирост сжатия будет - копейки.
Apple Mac: Safari 119 3233630
>>233629
25% будет по сравнению с оптимизированным пнг.
Android: Mobile Safari 120 3233643
>>233627
Во первых, эти тесты не учитывают скорость кодирования PNG, а только скорость оптимизации. Так что некорректно делить 25 на 0.7, как ты сделал.
Во вторых, от oxipng толку мало, какой смысл с ним сравнивать? Этак можно вообще без оптимизацией сравнить будет 0 сек, лол.
13A6FC86-2DBB-44BD-9070-459E9729C038.png260 Кб, 3016x1394
Apple Mac: Safari 121 3233654
Вот еще любопытные графики, fjxl и fpng были написаны в ответ на qoi, автор которого заявлял, что пнг слишком медленно кодируется, из-за чего он решил запилить свой простой 300 строк кода на си и быстрый формат без бэкджека и шлюх.
Android: Mobile Safari 122 3233655
>>233654
fjxl годнота походуа fpng все равно сосет
Windows 10: Firefox based 123 3233656
>>213710 (OP)
Ёбаный рот луддитов на разработчике. Нет адекватных вьюверов, которые бы поддерживали jxl. HoneyView - годнота как вьювер, но не поддерживает, XnView - открывает jxl файлы очень медленно, IrfanView - говнище без возможности поменять хоткеи, отчего скроллить масштабированные изображения можно только клавиатурой но не мышью. Есть ещё mpv, но он предназначен для видео, и во вьювер картинок его превращает набор скриптов.
Android: Mobile Safari 124 3233657
>>233656
Ставь линукс с кде
Android: Mobile Safari 125 3233658
>>233655
Хотя, с другой стороны, fjxl и жмёт хреново, чуда не произошло
Windows 10: Firefox based 126 3233659
>>233657
Не буду я ради одного кодека отказываться от большей части софта. Вон, аудиоплеера нормального под прыщами до сих пор нет - foobar2000 вин-онли, фотошопа нет, игры (по крайней мере пиратские, без зависимости от барского стима) запускаются через костыли и с меньшей производительностью. У файрфокса нет отдельного хранилища сертификатов, а линукс позиционирует себя как ОС для продвинутых пользователей. Вся эта возня с пакетными менеджерами, репозиториями, зависимостями, ну его на хуй короче.
Windows 10: Chromium based 127 3233661
>>233659

>foobar2000 вин-онли


На него похож Deadbeef, но он и без протествари не славится адекватной работой.
Android: Mobile Safari 128 3233662
>>233659
Я на винде chocolatey лет пять использовал, а ты говоришь с репозиьориями ебаться ;-)
Apple Mac: Safari 129 3233664
>>233658
Ну на уровне пнг, согласно тем графикам, при этом намного быстрее.
Android: Mobile Safari 130 3233667
>>233664
Ну кому надо побыстрее те и на fpng перейдут, а кому больше размер важен, не думаю, что станут на fjxl смотреть.
Windows 10: Firefox based 131 3233671
>>233661

>На него похож Deadbeef


Именно что похож, а нужных плагинов нет. Я их много использую.

>>233657
Ради смеха спрошу, какой дистрибутив линукса ставить? Они все или почти все - крайности определённых недостатков, и если спросишь на форуме (не на форуме дистрибутива, где мынивиноваты, софт ненужон и используй аналоговнет, а на форуме разработчика какого-нибудь софта) "как решить эту проблему с вашим софтом?", то в ответ получишь "пок-пок-пок, скачай другой дистрибутив", с которым тебя пошлют нахуй уже на другом форуме. Лебедь, рак и щука в жму/пениксе.
Linux: Firefox based 132 3233676
>>213710 (OP)

>Сжимает на 60% лучше, чем JPEG.


>Сжимает без потерь на 35% лучше, чем PNG.


В итоге такой же обсер как и у WebP - А КАК ИХ РАЗЛИЧАТЬ-ТО В ИТОГЕ?
Apple Mac: Safari 133 3233686
>>233676
На самом деле различать лосслесс и лосси не тривиальная задача. Вот у тебя похоже убеждение, что раз пнг значит очевидно лосслесс, но ведь есть пнг сконвертированные из жпегов, а еще есть утилиты, которые делают сразу лосси пнг, например pngquant, как ты различаешь такие пнг от Ъ-лосслесс?

В libjxl гитхабе есть утилита jxlinfo, которая пытается детектить лосси:

> info.uses_original_profile ? "(possibly) lossless" : "lossy");


Помимо этого можешь ориентироваться на размер файла, лосси файлы обычно на порядок меньше занимают места.
Windows 10: Firefox based 134 3234645
Apple Mac: Safari 135 3234700
>>234645
Люди продолжают сравнивать lossy jxl и avif на низких битрейтах и делать вывод, что avif лучше. Ответа одного из авторов jxl на подобное сравнение, сделанное разработчиками хрома:

Also the bitrate range that was selected (going as low as 0.1 bpp) for computing BD rates, leads to an overemphasis on codec performance at fidelity ranges nobody uses in practice. The median AVIF image on the web is around 1 bpp, not 0.1 bpp.

For example, on this plot (пик 2) you see that their data confirms and even exceeds my estimate that JXL compresses 10-15% better than AVIF in the range that is relevant for the web. However by putting a lot of weight on the < 0.4 bpp range, this plot is averaged to "JXL is 3% better".
Android: Mobile Safari 136 3234841
>>234700
Если даже в таком варианте, jxl все равно лучше на 3%, нахуя выпилили то ебланы
Windows 10: Firefox based 137 3234957
>>221257
Honeyview jxl картинки так и не открывает, несмотря на установленный в системе wic кодек для jxl.
Windows 10: Firefox based 138 3235053
>>234957

>Honeyview, pictus, qview


Столь мелкие поделки может вполне заменить всеядный mpv и даже лучше их быть. Смысла нет в них.
Android: Mobile Safari 139 3235080
Проблемы негров-виндузятников. Жрите баренский jpeg и png
Android: Mobile Safari 140 3250018
Появилось расширение для браузеров, которое через wasm декодирует jxl:
https://github.com/zamfofex/jxl-crx
Пока что находится в ранней стадии разработки.
Android: Mobile Safari 141 3254770
>>213710 (OP)

> Он одновременно может заменить JPEG, в случаях сжатия с потерями (например фотки), PNG, в случаях сжатия без потерь (скриншоты


И как отличать изображение со сжатием от изображения без сжатия? Когда я вижу пнг я сразу понимаю, что картинка не сжималась, а тут что?
Android: Mobile Safari 142 3254899
>>254770
Можно и jpeg переконвертировать в png и не всегда легко будет заметить разницу. Но в общем случае, согласен, это неудобно и у webp та же проблема.
Windows 10: Firefox based 143 3254950
>>254899

>JPEG XL


>собрались компании Google и JPEG и решили


>WebP


>is an image file format developed by Google


>та же проблема


И имя ей Google

Отдельно кринжую к кукареков про "швабодный" формат, в одном предложении с Google. Жидорабы пердососки не палятся.
Android: Mobile Safari 144 3254990
>>254950
Таблетки прими, шизло, может речь связной хоть будет.
Android: Mobile Safari 145 3256031
Если я jpeg преобразуются в png, а затем png в jxl (lossless), то размер будет равен прямому преобразованию того же самого jpeg в jxl (lossless)? Если нет, то почему.
Android: Mobile Safari 146 3256147
>>256031
Не будет равным.
Потому что транскодирование jpeg без потерь выполняется особым образом.

Как я это понимаю: при обычном транскодировании сначала декодируется изображение, из которого мы получаем набор пикселей. Этот набор кодируется в другой формат.

А при транскодировании jpeg, дополнительно используется информация из оригинального jpeg вроде того, как на какие блоки было поделено изображение и как они были закодированы. Кодировщик jxl использует эту информацию для создания новой пикчи, где используются точно такие же блоки, но хранятся они более эффективно.

Я далёк от процесса транскодирования, это лишь предположение.
Android: Mobile Safari 147 3256157
>>256147
Тогда в чем смысл конвертации из jpeg напрямую, кроме возможности восстановить исходный jpeg, если можно потенциально достичь меньшего размера при том же качестве, закодировав сперва в png.
Android: Mobile Safari 148 3256163
>>256157
При конвертации из jpeg в png крайне сильно раздуется формат файла. Потому что png будет вынужден хранить все эти артефакты компрессии jpeg как отдельные странные последовательности пикселей, которые сложно эффективно закодировать.

При перекодировании из png в jxl, последний тоже будет вынужден хранить все эти артефакты как последовательности пикселей, которые сложно эффективно закодировать. У jxl кодировщика не будет информации о том, что эти артефакты компрессии на самом деле являются наложением разных градиентов, соответственно он не сможет использовать такие же градиенты для создания jxl изображения.
Linux: Firefox based 149 3256351
>>256157

>если можно потенциально достичь меньшего размера при том же качестве


В твоей схеме он будет потенциально большего размера. В этом проблема.
Android: Mobile Safari 150 3256398
>>256351
Проверю, доложу. Я почему этой темой заинтересовался, многие png - по сути пересжатые jpg, а не с нуля созданные изображения. Вот и пытаюсь понять, что делать в таких случаях, конвертировать из png или брать jpg источник.
Linux: Firefox based 151 3256504
В общем расклад такой, да действительно, если jpeg файл сконвертировать в png, а затем в jxl, то размер получится больше (716K против исходных 387K в моем примере), но это при использовании -d 0 (математический лосслесс), если же получившийся png закодировать с -d 1 (визуальный лосслесс), а jpeg напрямую с -d 1 и --lossless_jpeg=0, то размер уменьшится одинаково (до 135K) без видимой потери качества в теории. Значит преобразовывать предварительно в png смысла нет, если можно закодировать напрямую.
Android: Mobile Safari 152 3256679
>>256504

> без видимой потери качества в теории



Попробуй поперекодировать скрины png'шные с текстом, охуеешь от этих теорий
Android: Mobile Safari 153 3256690
>>256679
Так самое смешное, что когда я кодировал с -d 0 (для jpeg по умолчанию), то выигрыш был всего несколько десятков килобайт. То есть смысла нет на моём примере.
1608275801755.webm1,9 Мб, webm,
768x576, 0:07
Windows 10: Chromium based 154 3257158
>>233676
>>233686

> есть пнг сконвертированные из жпегов


Двачую, заебали пидорасы, которым лень сохранить файл или поставить куклу, и они постят из буфера своё мыло в пнг, и оно со всеми шакалами весит 8 метров блять.
1572693528357.png4,1 Мб, 1920x1200
Windows 10: Chromium based 155 3257160
>>254770
Ты свечку держал что ли, мразь? Я блять копирую из гугла жипег и вставляю тебе из буфера в пнг, отчего он раздувается в 7.6 раз нахуй. Твои действия, чмо?
Android: Mobile Safari 156 3257646
>>233676
Что не так с webp?
Android: Mobile Safari 157 3257822
>>257782 (Del)
Тем, что разширкние не отличается, был бы webp (lossless) и webj какой-нить, тут бы всем было ясно.
изображение.png140 Кб, 834x1053
Linux: Firefox based 158 3257866
>>233676
В метаданных всё написано.
z9.webp15 Кб, 834x1053
Linux: Firefox based 159 3262216
>>257866
Я тут обнаружил, что двач теперь может в webp.
Linux: Firefox based 160 3262225
>>262216
Ебать разродились, когда уже в .avif уметь надо.
Windows 10: Firefox based 161 3262238
>>262225
Не нужен. В jxl.
Linux: Firefox based 162 3262317
>>262225
Lossless webp сжимает значительно лучше png, особенно скриншоты с текстом, lossless avif совершенно бесполезен.
Как замена jpeg'у avif действительно был бы лучше.

JXL мог бы заменить все упомянутое, конечно.
Android: Mobile Safari 163 3283442
подскажите аноны, тот факт что гуголь бросил играться с jpegxl что-то значит для его будующего и поддержки? я не планирую никуда постить свои фоточки, но вот потерять возможность перекодировать всё обратно в png/jpeg лет через 5-10 не хотелось-бы
Android: Mobile Safari 164 3283488
>>283442
Ты не потеряешь возможность перекодировать обратно без потерь даже через 100 лет. Даже если jxl вообще перестанут развивать при условии, что человечество каким-то образом не проебёт исходные коды/бинарники.

Скорее ты проебёшь свои фотки, так что не переживай.
Apple Mac: Safari 165 3283534
>>283488
Причем уже есть 3 альтернативных декодера разной степени готовности:
https://github.com/tirr-c/jxl-oxide
https://github.com/thebombzen/jxlatte
https://github.com/lifthrasiir/j40
Windows 10: Chromium based 166 3283561
>>213710 (OP)

> - Почти полнота по Тьюрингу


Открыл картинку - а она начала майнить. Круто!
Linux: Firefox based 167 3283588
>>283561
Опять эта чушь про майнеры.
Ты бы хоть посмотрел на этот их тьюринг полный язык и его ограничения.
Android: Mobile Safari 168 3283646
>>283561
SVG тоже почти тьюринг комплит, но ты почему-то не выёбываешься на это.

Ах, да, всё от невежества.
Windows 10: Chromium based 169 3283684
>>283646
Сравни лучше с PDF, который из-за сложности исторически являлся источником кучи дырок, как в логике обработки так и самих либах.
Windows 10: Chromium based 170 3283763
В jxl можно встроить wishmaster?
Android: Mobile Safari 171 3283771
>>262317
Пидарасы какие то продвигают ебучий avif.

>>283488
Даже если не проебет (фоточки и исходники), то все равно скорее всего все уже перестанут пользоваться лосси форматами, и даже jpeg будет нечем открыть. Но это явно не перспектива ближайших 5-10 лет.
Linux: Firefox based 172 3283808
>>283588
Для форк-бомбы достаточно
Android: Mobile Safari 173 3283821
>>283763
Лучше сразу встроить в сракло софтошиза для лучшего расширения™
jxl.webp47 Кб, 770x775
Apple Mac: Safari 174 3283924
>>283808
Я слишком тупой, покажи мне, как у тебя получилось сделать форк-бомбу на пикриле.
ungoogled-chromium.png489 Кб, 1474x1559
Linux: Firefox based 175 3290227
User: хэй, не могли бы вы вернуть поддержку jxl?
Devs: слишком сложно, мы не осилим
User: вот есть уже готовый патч от Васяна
Devs: мм, там лицензия не та
Васян: я сменил лицензию на совместимую с вашим проектом

Интересно, какие отговорки сейчас пойдут.
Android: Mobile Safari 176 3290237
>>290227
Хоть какая то польза от васянов.
Android: Mobile Safari 177 3291572
аноны, поскольку в jxl нельзя транскодировать jpeg изображения с CMYK, то возникает вопрос: а как нахуй узнать, какие изображения у меня имеют cmyk? в ручную проверять вообще не вариант, слишком много их
Android: Mobile Safari 178 3291585
>>291572
Посмотри в сторону imagemagick, а именно identify. Почти на 100% уверен, что там должна быть эта инфа.
Windows 7: Firefox based 179 3291610
>>217396
Какой красивый терминал. Что за шрифты и реленватнтые настройки?
Windows 7: Firefox based 180 3291624
>>221066
А зачем нужен авиф, если есть webp?

Я вообще-то даже в нужности jxl сомневаюсь, на фоне вебп
Windows 7: Firefox based 181 3291627
>>283684
А какая годная альтернатива кроме djvu? Планирую OCRить отсканенные книги.
Linux: Chromium based 182 3291643
>>291610
Liberation Mono
fish + https://github.com/pure-fish/pure до этого был zsh+pure, можешь еще посмотреть в сторону https://starship.rs
Android: Mobile Safari 183 3291691
>>291624
JXL лучше webp и для lossy и для lossless, и позволяет jpeg изображения в него конвертировать без потерь. Таким образом потенциально можно будет от jpeg вообще отказаться в будущем.
Windows 7: Firefox based 184 3291703
>>291691

> и позволяет jpeg изображения в него конвертировать без потерь


С аж 25% сжатием. Ну охуеть теперь.

> JXL лучше webp и для lossy и для lossless


Ну лучше и лучше, стандарт лучше тот, который широко применяется и имеет максимальную поддержку, это очевидно. С нишевым же адопшеном - это сугубо локаьлное баловство, личную коллекцию пикч с двачей пережать, если сохранюх
image.png784 Кб, 1200x464
Windows 7: Firefox based 185 3291704
Gigachad-av1.webm13 Кб, webm,
1051x633, 0:10
Windows 10: Chromium based 186 3291726
>>213710 (OP)
Зачем jpeg xl, когда есть avif?
Android: Mobile Safari 187 3291764
>>291703

> С аж 25% сжатием. Ну охуеть теперь.


Дело не в процентах, а в том, что это позволяет отказаться от устаревшего формата (jpeg). Если в качестве альтернативы продвигать webp, то jpeg никуда не исчезнет.

>стандарт лучше тот, который широко применяется и имеет максимальную поддержку


Тогда это jpeg и png и не надо никуда переходить? Или все таки надо? И если переходить, то может не стоить менять шило на мыло?
Android: Mobile Safari 188 3291765
>>291726
Он только для сжатия с потерями хорош, для lossless он ужасен.
Windows 10: Firefox based 189 3291766
>>291765
Почему ужасен?
Windows 10: Firefox based 190 3297671
>>291726
Сравнил дефолтные настройки avif в ffmpeg с -q 6 jpg. Разница 439 против 691 кб в пользу avif, но у него шум, который является частью картинки, замылен. А у джипега деталей больше, хоть и шум сыпится большими квадратами. Но на кодирование avif ушло несоизмеримо больше времени чем на jpg, а ещё я не нашёл ни одну программу кроме ffplay, которой я мог бы его открыть.
image.png560 Кб, 1280x770
Windows 10: Firefox based 191 3297673
>>297671
mpv, jpegview, xnview
Windows 10: Firefox based 193 3297702
image.png1,2 Мб, 980x500
Windows 10: Firefox based 194 3297880
Кто-то выкладывал тут в прошлом году батник https://paste.debian.net/plain/1277842 . Создайте его там же, куда распаковали это https://github.com/libjxl/libjxl/releases и сделайте батнику ярлык, положите ярлык в Windows SendTo и сжимайте в один клик jpg в jxl его киллер фичей без потерь. Смотрим этим: >>297673

>>213710 (OP)
В шапку не хватает: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html
OnePhotoViewerLjeC99zlV10.jpg66 Кб, 1325x730
Windows 10: Chromium based 195 3297884
>>297671
Да после установки расширения https://apps.microsoft.com/store/detail/av1-video-extension/9MVZQVXJBQ9V?hl=be-by&gl=by все просмотрщики вроде как открывают только полосы какие-то зеленые иногда по краям вылезают.
Windows 10: Chromium based 196 3297890
>>297880

>Windows SendTo


О, удобно
Windows 10: Firefox based 197 3297898
>>213736
Зачем вы тащите этот плесневелый кал, когда есть официальная страница тестов у гугла. 🤔
>>221974
Судя по скорости декодирования - это вообще дефолтные префы, а не максы. Так в максах снижает ~ до 20% +- в сравнении с -8 у флак. Сам проверяй, лучше всего эмбиент. Даже free-dl wav подкину, чтоб потестить https://asurarevolver.bandcamp.com/album/rainforest-hill-i-ii
>>226179
Пруфы?
>>233656
Одного zones lua достаточно, лол.
.png8 Кб, 590x343
Windows 10: Firefox based 198 3297985
>>233656

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


Почему каждый ебаный раз, когда читаешь инфантильное нытьё софтошизов, за ним скрывается тупой мудак, неспособный зайти в настройки?
image.png663 Кб, 1254x795
Windows 10: Firefox based 199 3298018
Сложности с сайтами, как единственный аргумент невозможностью пикчу залить/поделиться - хуйня и не всех задевает неудобствами. Если JXL у анона в первую очередь с целью личной коллекции и лично приобщиться к использованию со всеми фичами экономии/скоростью/етк, а не холиварной массовой поддержкой веба/пиписитарных гуглоподелок-браузеров , то смотреть формат можно в своём уютненьком просмотрщике/редакторе. А если нужно вкинуть онлайн, то копировать пикчу в clipboard и вставить на сайте - всё подтянется в простом формате. Лол, неудобств вы с этим получается избежали. Тогда какие аргументы не перекатиться с вашим архивом фото, если нёрф так легко обойти (за исключением древних веб помоек со старым методом ручной вставки пикчей, возможно мессенджеров, что без веб версий и всяких веб макак). Остальных как это задевает вообще? В том и забава >>225437 , что один только гугл не видит "потенциал", но на самом деле видит скорее нелепый обсер, что не успев вложиться в потуги авифа, не успев толком вкусить фидбэека в статусе топ1 формат - уже вынуждены признать пук, среньк, уже есть что-то получше, лол.
Windows 10: Firefox based 200 3298024
>>221881
Лол, даже не знал что список шизов пополнил. Быть может пару лет назад спалил плюсы, дак до сих пор рвутся 🤣
Android: Mobile Safari 201 3298028
>>298018
соглы, на винде jxl даже как обои не поставить
Windows 10: Firefox based 202 3298166
Побаловался в Krita. Там давно реализован.
Жмёт хреново. Мало где поддерживается.
Android: Mobile Safari 203 3299520
>>298166
Жмёт хорошо. Много где поддерживается.
Windows 10: Firefox based 204 3299989
>>213710 (OP)

>GIF, который давно пора отправить на свалку истории.

изображение.png108 Кб, 816x736
Linux: Firefox based 205 3300015
>>299989
пора
Windows 10: Firefox based 206 3303593
Бамп
Windows 10: Firefox based 207 3303594
Vimeo оказывается все картинки в avif держит 😳
mSjxPnWd.webp107 Кб, 1280x720
Apple Mac: Safari 208 3316201
JPEG XL coming to Safari

It looks like Apple just announced that MacOS/Safari will be supporting JPEG XL. And that means that the likelihood that Chrome (and Firefox) will follow just increased by an order of magnitude. So it's a very big milestone for jxl adoption and the utility it will be able to bring to the web in particular.
Android: Mobile Safari 209 3316348
>>213710 (OP)
feh откроет?
Apple Mac: Safari 210 3316351
>>316348
Да, если поставить:
https://github.com/alistair7/imlib2-jxl
image.png601 Кб, 1280x800
Android: Mobile Safari 211 3316352
Windows 10: New Opera 212 3316402
Какой наиболее качественный на текущий момент инструмент для конвертации и сжатия в jxl?

Пока как просмоторщик использую XnView и у них есть встроенные конвертер насчет которого не уверен.
В треде пчелы активно работают с ffmpeg и imagemagick
Так что прошу рекомендации, какие стоит попробовать и где читать, как с ними работать
Windows 7: Firefox based 213 3316454
>>316402
Не поверишь, официальный. Сделай батники по типу этого >>298018 и всё станет максимально просто. Ни один конвертер не может в перепаковку jpg в jxl без потерь, а это важная фича у сабжа, так-то. Вьюверы да, xnview, jpegview и mpv >>297673 - лучшие для jxl, во всяком случае пока.
Apple Mac: Safari 214 3316457
>>316454

>Сделай батники по типу этого >>298018


Мне кажется ты промахнулся.
Windows 10: Chromium based 215 3317994
>>291764
Ну так новый стандарт - это webp, если так дело пойдёт и дальше. Для любителей огромных паков, это вообще идеальный формат. И размер как у jpg и даже меньше иногда и поддержка прозрачности.
Можно вообще в хуй не дуть и всё в него перегонять не боясь.
image.png663 Кб, 1254x795
Windows 7: Firefox based 216 3318045
>>317994

>Ну так новый стандарт - это webp


В твоём мирке? Или гугла? Или ты из началов десятых капчуешь. Вебп уже давно доживает и проигрывает всем актуальным, если дескать вообще был в чьих-то глазах живым, лол.

>Для любителей огромных паков, это вообще идеальный формат.


В твоём мирке? Мыло сраное, а не идеальный формат, лол. Этот тред обсуждения сабжа, а не мыльных форматов конца нулевых.

Обязательно в шапку треда ссылку, чтоб больше такой чуши не писали (для приватопердолей: для просмотра сравнений нужен включенный WEBGL и разрешенные workers api): https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html
Windows 10: Chromium based 217 3318108
>>318045

>в твоём мирке!


>мыло!


>доживает!


По теме то, есть что сказать? 10 лет назад те же вскукареки слышал, какой webp не нужный и плохой, а по итогу и поддержку везде добавили и массово он начал пнг заменять, ибо легче. Да и с жпг нормально справляется.
Сегодня это самый лучший формат, если у тебя тонны пикч которые нужно быстро подогнать под один формат без проёбов. Сожрёт и пнг и жпг и везде залезет без танцев с бубном.
Windows 10: Firefox based 218 3318227
>>213710 (OP)

>GIF, который давно пора отправить на свалку истории.


Иди нахуй
Гифки с котиками форевер
Windows 10: Firefox based 219 3318229
>>318108

>По теме то, есть что сказать?


>https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html


Глаза протри.
Windows 10: Firefox based 220 3318232
>>318227
Отправляют на свалку формат, а не сами анимации, тугосеря.
Windows 10: Firefox based 221 3318237
>>318232
Мне похуй
Windows 10: Firefox based 222 3318249
>>318045

> для просмотра сравнений нужен включенный WEBGL и разрешенные workers api


Угу, спасибо, что предупредил о ботнете.
sage Windows 10: Firefox based 223 3318921
>>318249
Так тема треда и есть троян. Встраивать программный код в картинки, ты буквально вирусню качаешь под видом картинок, классический троянский конь, еще и название маскируется под JPEG, всем известный и безопастный. Прям комбо малвари, наебать и пропихнуть вирус.
Android: Mobile Safari 224 3318962
>>318921
Знал бы ты как SVG работает, вообще бы комп включать побоялся.
Windows 10: Firefox based 225 3318988
>>318962
То есть, про ЖПЕГ ТРОЯН прокомментировать нечего, так и знал что во всём прав.
Android: Mobile Safari 226 3320314
>>318921
Таблетки прими, а то шутки про уязвимые картинки уже доебали.
Там троян на уровне шрифтов true type. То есть запускается в своей винтуалке по стандарту. Если кто-то и додумается запихнуть туда код, он сработает только внутри картинки и хуй вылезет дальше.
Максимум скример сделает из картинки, что конечно смешно но троянить что-то из файлов пикча не сможет.
Windows 10: Firefox based 227 3325201
Этому треду требуется бамп.
Linux: Chromium based 228 3325204
1688147992670.png29 Кб, 480x620
Windows 10: Firefox based 229 3325206
>>325204
А что, идея здравая. Компрессия на уровне операционной системы это тема.
Windows 10: Firefox based 230 3325208
>>325206

>операционной


Файловой, имеется в виду.
1678577293274.jpg34 Кб, 367x367
Windows 10: Chromium based 231 3325782
>>325206
>>325208
Что это значит?
Windows 10: Chromium based 232 3325793
>>325204
Ну это не трудно, можно самому модуль сделать и перехватывать запись/чтение всех жпегов. Только может что-нибудь отвалится
Windows 10: Firefox based 233 3325960
>>325782
>>325782
Это значит, что ты пидор файлы занимают на диске меньше физического пространства, чем их фактический размер
1557785675638.jpg68 Кб, 750x750
Windows 10: Chromium based 234 3326032
>>325960
Как это относится к jxl?
Windows 7: Chromium based 235 3327293
>>297880

>Кто-то выкладывал тут в прошлом году батник


Что-то он у меня перестает работать при превышении какого-то определенного количества выделенных файлов - окно cmd моргнет просто на 10 мс и все. Пока не смог понять закономерность, т.к. в одном случае работает со 129-ю файлами, а со 130-ю уже не хочет, а в другом - со 150-ю все ок, а со 151-м уже нет.
Может, есть какие-то лимиты на кол-во аргументов для батников или что-то около того?
Android: Mobile Safari 236 3327299
>>327293
Исполни его из cmd, а не мышкой и покажи что он выдаст. Может какой анон исправит.
Windows 7: Chromium based 237 3327306
>>327299
Короче, погуглил и думаю, причина в этом
https://learn.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/command-line-string-limitation

Т.е. пока строчка с аргументами из путей до файлов вида
cmd.bat "D:\folder\file1.jpg" "D:\folder\file2.jpg" ...
не превышает 8191 символ, то все работает. Хз так же на десятке или нет.
Android: Mobile Safari 238 3327312
тред мельком посмотрел, вроде не поднималось такого вопроса

дано: папка с jpg, png, gif огромного размера (15к+ файлов). надо: одной комадной затранскодить в jpg, на ляликсе
Android: Mobile Safari 239 3327313
>>327312

>затранскодить в jpg


jpegxl, конечно же

быстрофикс
Linux: Chromium based 241 3327317
>>327312
https://github.com/sharkdp/fd

fd -e png -e jpg -e jpeg -e gif -x cjxl <opts> {} {.}.jxl
По умолчанию запускает параллельно по количеству ядер, можно ограничить с помощью -j <N>.

>>327306
Тебе тоже пригодится, с fd нет ограничения по количеству аргументов.
Windows 7: Chromium based 242 3327475
>>327317

>Тебе тоже пригодится, с fd нет ограничения по количеству аргументов.


Спасибо, конечно, но я не совсем понимаю, как fd можно применить, если в условной папке нужно переконвертить некоторое большое кол-во пикч, кот. я могу выделить вручную, но не все из них. В варианте с >>297880 понятно: выделил нужные - отправил в батник (и только 8191-лимит тут поднасрал). А с fd как быть?
Linux: Chromium based 243 3327509
>>327475
Понятно, тебе не подойдет fd.
Подозреваю, что с выделением в проводнике любой скрипт или консольная программа будет натыкаться на ограничение длины аргументов.
В терминале можно было бы что-нибудь соорудить с выделением файлов с помощью какого-нибудь fzf и записи их во временный файл, потом для каждой строки в нем запускать cjxl.
Windows 7: Firefox based 244 3327763
У меня есть каталог с 10к файлов cjxl
Как я могу их пролистать?
Ирфан открывает их исключительно пофайлово, а при попытке листать предлагает перейти в следующую папку.
ОС - винда.
Windows 7: Chromium based 245 3327875
>>327763

>Как я могу их пролистать?


Ты имеешь ввиду листание "колесиком" или "через пробел"?
Накидал 12к мелких jxl в папку и у меня все нормально листает и миниатюры через T работают. Хз, обнови ирфан.
image.png13 Кб, 598x141
Windows 7: Firefox based 246 3327880
>>327875
Нашёл причину своих страданий. Я при конвертации присваивал расширение cjxl

Большое спасибо тебе, добра. А то я уже начал ебаться с AHK, чтобы рекурсивно по PageDown каждый раз новое окно ирфана вызывать.
Android: Mobile Safari 247 3335256
Нужен совет по конвертации
Есть несколько папок в пнг
Перегон в jxl loseless съэкономит место или наоборот?
Windows 10: Firefox based 248 3335325
>>335256
Сэкономит.
image.webp21 Кб, 354x140
Linux: Chromium based 249 3335397
>>335256
Неоптимизированные пнг сжимаются на 40-50%.
Для изображений преимущественно с текстом, то есть для скриншотов приложений без картинок, lossless webp cwebp -z 9 нередко сжимает лучше, чем jxl, и при этом быстрее. На всякий случай, webp не поддерживает больше 8-бит и молча конвертирует в 8 бит с потерями.

Если ты пользуешься cjxl и тебе важна дата модификации файлов, на никсах можно восстановить ее с помощью touch -cr file.png file.jxl.
Linux: Firefox based 250 3335402
>>335397

> lossless webp cwebp -z 9 нередко сжимает лучше, чем jxl, и при этом быстрее


Крутяк, как раз хотел свою коллекцию скриншотов перекодировать в лузлесс webp, благо макака завезла наконец поддержку.
Мимо
Windows 7: Chromium based 251 3336335
Хм, почему при попытке конверта пик1 с дефолтными настройками получается пик2 с поехавшей гаммой?
Windows 10: Firefox based 252 3336415
>>335397

>lossless webp


>молча конвертирует в 8 бит с потерями


Ебало lossless представили?
Windows 10: Firefox based 253 3336418
>>336335
Так даже лучше
Android: Mobile Safari 254 3336472
>>336335
Похуй, тебе все равно не светит
ntzSHZL.png69 Кб, 1111x855
Linux: Chromium based 255 3346571
1693060908576.jpeg2 Кб, 220x229
Android: Mobile Safari 256 3349106
>>336335
Хочу тяночку
Android: Mobile Safari 257 3349109
>>213710 (OP)
Н
Е

В
З
Л
Е
Т
И
Т


Запомните этот твит.
BSD: Firefox based 258 3349251
Нормально без возьни смотреть такие картинки на Линухе можно только в браузере PaleMoon? Со стандартными настройками без всяких экспериментальных флагов и прочей фигни.
Linux: Chromium based 259 3349346
>>349251
Из браузеров еще Thorium.
Из остального софта много что поддерживает. Весь кутешный и гткшный софт должен поддерживать, если поставить нужные плагины.
Apple Mac: Chromium based 260 3349357
>>349109
Уже взлетело, эпл впилили в последний сафари, а остальные как все мы знаем, повторяют за эпл
Linux: Chromium based 261 3349362
>>349251
В самом конце есть список софта:
https://jpegxl.info/why-jxl.html
Android: Mobile Safari 262 3349370
>>349357
Хуело.
Абу поддержку .webp впилил буквально лет через 10 после того, как оно «взлетело».
Apple Mac: Chromium based 263 3349380

>Абу


Кто-то важный наверное)
Android: Mobile Safari 264 3349386
>>349380
Да не, так, хуёк. Буду пересылать всем неподдерживаемый формат, убеждая «ну чё вы, пацаны, эпол же уже одобрил, пользуйтесь! Нужно всего лишь скачать специальное приложение с его поддержкой, скачивать файлы и открывать в нём, ну. Удобно же!».
Apple Mac: Chromium based 265 3349390
>>349386
Ты даже не заметишь переход, ебанашка, если не будешь одним из этих фриков треда, которые сами все конвертируют. Просто сиди дрочи дальше на картинки в интернете и не забивай голову
1693128112913.jpg18 Кб, 500x269
Android: Mobile Safari 266 3349391
>>349390

> Ты даже не заметишь переход

BSD: Firefox based 267 3349412
>>349362

>В самом конце есть список софта:


GIMP и Krita это всё-таки не программы для просмотра фоток. Признаем очевидное, что в большинстве дистрибутивов Linux нет самого новейшего Ffmpeg, в котором добавлена поддержка этого формата для кодирования и декодирования. XnView поддерживает просмотр этого формата только на винде. Не зачет.
BSD: Firefox based 268 3349413
>>349346

>Весь кутешный и гткшный софт должен поддерживать, если поставить нужные плагины.


Интересно... вот у меня в среде рабочего стола родной просмотрщик фоток это Xviewer. Где плагин найти?
image.webp331 Кб, 537x640
Linux: Chromium based 269 3349436
>>349413
https://github.com/linuxmint/xviewer/issues/162

Для дебиана libjxl-gdk-pixbuf я беру отсюда:
https://artifacts.lucaversari.it/info.txt

Для freebsd я вижу нужную so'шку в списке тут:
https://www.freshports.org/graphics/libjxl

>>349412

> GIMP и Krita это всё-таки не программы для просмотра фоток.


Ты видимо пропустил строчку со списком просмотрщиков изображений и прочим после иконок.
Android: Mobile Safari 270 3349576
>>213710 (OP)

>>213710 (OP)

> Также есть несколько относительно свежих форматов изображений, которые являются побочным продуктом, полученным при разработки видеокодеков. К примеру HEIС (HEIF) который так любит Apple происходит из видеокодека HEVC. Та же история с форматами WebP и AVIF, которые произошли из VP9 (VP8) и AV1 соответственно.



> Но так как эти кодировщики делались изначально для видео, они концептуально не настолько эффективны для хранения изображений.



Зато есть аппаратное декодирование.
Apple Mac: Safari 271 3349632
>>349576
А оно вообще используется для декодирования изображений?
Linux: Firefox based 272 3349662
>>349436

> мазня с энтропией уровня хлебушка


> 4000х4000


> 15Мб


Формат будущего прост, моё почтение.
Linux: Chromium based 273 3349689
>>349662
Судя по тому как ты пишешь, ты явно умный парниша и разбираешься в теме, до тебя должно быть сразу дошло, что картинка сжата в лосслесс режиме.
Можешь порекомендовать лосслесс формат, который сожмет значительно лучше?
Linux: Firefox based 274 3349715
>>349689

>лосслесс формат, который сожмет значительно лучше?


bmp в архиве, и это не шутка: http://qlic.altervista.org/
Серьёзно, лослесс сжатие - это идея из 80х. Со времён арифметического кодирования там ничего принципиально не меняется. Что звук, что изображение устаканились в нулевых и сейчас ты можешь только сжигать терафлопсы ради призрачной прибавки в 5-10%.
А вот лосси - это действительно вызов. Поиск избыточности, модель восприятия, психоакустика, разные способы оценки, генеративные модели. Вот где жизнь бьёт ключом и останавливаться не собирается. Лосси в эти твои 15Мб целый артбук упаковать может, а ты разницы и не увидишь.
image.webp17 Кб, 336x118
Linux: Chromium based 275 3349720
>>349715

> bmp в архиве, и это не шутка: http://qlic.altervista.org/


zpaq действительно сжал лучше, но всего лишь на 5% по сравнению с jxl.
Для gralic и bmf я не нашел исходный код, paq8px и cmix слишком медленные, судя по твоей ссылке.
И ничего из этого не поддерживается обычным софтом.

> ради призрачной прибавки в 5-10%.


На подобных картинках скорее 20-30% по сравнению с оптимизированным png.

> А вот лосси - это действительно вызов.


И какие у тебя претензии к lossy jxl?
Android: Mobile Safari 276 3349730
>>349632
Если там сжатие такое же как в видеокодеках то по идее может, как на самом деле - не знаю. Но жпег устарел и сильно.
Критическая уязвимость сразу во всех браузерах Linux: Firefox based 277 3357512
Компания Google опубликовала информацию и уже закрыла уязвимость в библиотеке libwebp, которая могла приводить к удалённому выполнению кода, когда пользовать просто открывает сайт. Библиотека libwebp используется во всех браузерах на движке Chromium, а также в приложениях на базе electron, в браузере Mozilla Firefox, Gimp, Inkscape, LibreOffice, Telegram, Thunderbird, ffmpeg и другом программном обеспечении. Затронуты также и другие операционные системы.

Суть уязвимости в переполнении буфера, которая позволяет злоумышленнику подготовить специальное WebP изображение, при открытии которого на машине пользователя выполнится код. Google не раскрывает подробности механизма эксплуатации уязвимости, но утверждает, что в сети уже доступны рабочие эксплоиты, основанные на ней.

https://www.linux.org.ru/news/security/17351631

Что с ебалом, шлюхи гугловские? Не зря поддержку вашего кала отовсюду выпиливал!
Windows 8: Firefox based 278 3357524
>>357512
Скажу тебе по секрету, такие CVE есть для PNG\JPEG-JPG-JPEG2000\TIFF\BMP\GIF\PSD. Все графические файлы имеют проблемы с библиотеками или исполнителями. И что теперь, всю графику резать? Нет, просто используй вылеченное.
Windows 10: Firefox based 279 3357544
>>357524
Скажу тебе по секрету, такого пиздеца нет нигде, когда никому больше не нужное проприетарное картинкоговно от гугла оказывается дырявое, и в результате всё на свете оказывается дырявым, начиная с браузеров и заканчивая всевозможным софтом, и даже не софтом, а библиотеками вшитыми в систему как webview. Всё потому, что все сидят на игле монополиста с гуглозондом в жопе. Итоги блять.
Windows 8: Firefox based 280 3357551
>>357544
У mp3 тоже есть проблема с интеграцией тега и возможностью поднять права программного плеера. Четверть века прошло, никто не орет особо, mp3 везде.
Вы крикуны обычные, разделяйте данные, которыми можно делиться и данные, которые private\own, и не давайте данным вылазить в СЕТЬ. Подцепил сеть к гаджету - твои данные не твои, а СЕТИ, иного не дано.
Windows 10: Firefox based 281 3357552
>>357551
У mp3 нет проблем, потому что это не гуглозонд от одного производителя впердоленный везде где надо и не надо, просто патамушта, чтобы бэкдоры гугла были во всём.

mp3 реализуется разными библиотеками от разных разработчиков, и в большинстве софта вообще не встроено. Если даже в одной какой-то библиотеке есть уязвимость, это капля в море, вообще не проблема.

А гуглопараша одна на весь мир, и встроена во всё на свете, все под гуглодырами. И как только дыру опубликовали, любой васян уже может ломать всё на свете. Какая красота. Спасибо монополии, гулагу барина гугла, хозяина интернета и всего софта во всём мире.
Windows 8: Firefox based 282 3357554
>>357552

> это не гуглозонд


Чел, пойми. У тебя проблема с расставлением границы между нашим, твоим и общим. Если ты не желаешь полного деанона и взлома всего и вся - сиди оффлайн или в тайгу беги.
Или учись и повышай шкиллы защиты, сиди за аппаратным файером на фряхе, и изучай каждый пук нотиков и алерты этого файрлола. Просто сейчас ты смешон очень, ты предельно параноидален, ты даже не понимаешь, что компы придумывали как сетевые клиенты для сервака, и ко всему, что в них есть, можно механистически получить доступ, и это ВПОЛНЕ НОРМАЛЬНАЯ СИТУАЦИЯ, это же парадигма компа такая. И в мобильных осях также, ты доверяешь гуглу все свои данные, или эплл свои данные, и так далее. И когда ты начинаешь параноить и ныть, это вызывает непонимание. Ты похож на ребенка, который ест говно из подгузника, мажет его везде в хате и орет, что невкусно. Ты или вырастай и умней, или прекращай пользоваться ВСЕМ софтом, потому что он ВЕСЬ имеет ошибки, и 1% из этих ошибок позволяет получать права на доступ к твоим данным.
Всё, можешь не ррякать мне в ответ, просто прочитай и осмысли.
Windows 10: Firefox based 283 3357565
>>357554
Не сри дебил.
- Гуглодыры везде, потому что гугл охуел и везде.
- И это не теоретические дыры на словах, а реальные дыры исполнения кода от любой картинки в интернете.
- Картинки это не шутки, картинки везде. Дыра в картинках, это значит ты подключился в интернету и всё, пизда тебе, это даже хуже чем WannaCry.
- Толще дыры нельзя придумать, и она везде, в любом софте использующем интернет, на любой платформе, потому что мистер гугл везде, вместе со своими дырами.

>ВПОЛНЕ НОРМАЛЬНАЯ СИТУАЦИЯ


Не сри тупостью, дебил.
изображение.png1,3 Мб, 900x1080
Windows 8: Firefox based 284 3357567
>>357565
Ты качал, тебя ломали...
ГУГЛАГ ВПЕРДЕ, ВСЕМ КРЫШ!
Кодь сам, или слабачок-дурачок?
Linux: Chromium based 285 3357608
>>349436

>Для дебиана libjxl-gdk-pixbuf я беру отсюда:


https://artifacts.lucaversari.it/info.txt

Так это сами библиотеки и кодировщик.
Это я просто установил всё одной командой?
apt install libjxl-tools

Но это не заставит GTK-программы просмотра фото поддерживать формат JPEG-XL. Вот установка jxl-pixbuf-loader должны это сделать в теории. Только под всякие Ubuntu его пока нет готового собранного. Для Федорки есть. Может там более модная версия GTK нужна х.з.
Linux: Chromium based 287 3358271
>>357671

>Тут тоже есть внутри тар архивов:


Скачал архив jxl-debs-amd64-ubuntu-22.04-v0.8.1.tar.gz и там нет

>jxl-pixbuf-loader

gdk.png177 Кб, 693x404
Apple Mac: Safari 288 3358380
>>358271
Там есть libjxl-gdk-pixbuf, он и нужен.
Linux: Firefox based 289 3360505
>>357512
Там же в этих браузерах песочница в песочнице песком песочит. Да так, что элементарные действия лагают как по времен пенька. Неужели всё это не помогает?
Android: Mobile Safari 290 3360797
>>360505
Ты не понимаешь, что значит беды с башкой
image.png888 Кб, 1857x1080
What are we fighting for, brah Windows 10: Firefox based 291 3364040
Ну вот
Ради чего, блять
test1 - cjxl - офф конвертер - качество то же, размер с мб ушел в 333 кб
test2 - libvips - мультиконвертер с поддержкой - качество сжалось чутка, размер ушел с 1 мб в 96 кб

вот и сиди теперь
Я буду конверитить оффициалом потому что качество нужно, но это какая-то шляпа
Linux: Chromium based 292 3364053
>>364040
А указать параметры сжатия в libvips нельзя?
Windows 10: Firefox based 293 3364062
>>364053
Да, можно, Я просто пока предпочитаю оффициал в любом случае пока
Linux: Chromium based 294 3369454
Компрессор для жпегов, примерно как jxl lossless transcode, но быстрее при той же или слегка лучшей степени сжатия:
https://github.com/microsoft/lepton_jpeg_rust
Windows 10: Firefox based 295 3381711
>>369454
Оно лучше mozjpeg?
Linux: Chromium based 296 3381750
>>381711
Сжимает лучше, но lepton это для архивации, ты не откроешь его ни в каком просмотрщике изображений, редакторе или браузере.
Windows 10: Firefox based 297 3381929
>>381750

>но lepton это для архивации, ты не откроешь его ни в каком просмотрщике изображений, редакторе или браузере


Получается хуита без задач.
Android: Mobile Safari 298 3382057
>>381929
Не согласен

На серверах картинкохранилищах вроде какого-нибудь imgur можно хранить архивированные (старые) фоточки и разархивировать их на лету по запросу пользователя

Конечно, в мире победившего jxl такой нужды не будет, так как у всех будут декодировщики в браузерах, но пока что имеем что имеем
Windows 10: Firefox based 299 3382081
>>382057

>На серверах картинкохранилищах вроде какого-нибудь imgur можно хранить архивированные (старые) фоточки и разархивировать их на лету по запросу пользователя


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

>imgur


Наверняка старые пикчи, которые ты предлагаешь архивировать, имеют нулевой трафик. Если цель - сэкономить место в датацентрах, то тот самый заблудший, случайно открывший страницу, наверняка сможет и подождать пару секунд пока его запрос сначала по всем кешам промахнется, а потом и картинка декодируется наилучшим кодеком. Ну тут впрочем без знания того как там все устроено можно только лишь прикидывать и гадать.
Android: Mobile Safari 300 3395505
Android: Mobile Safari 301 3414019
Samsung добавила в прилажку камеры на своих смарфонах поддержку JXL
https://r2.community.samsung.com/t5/CamCyclopedia/Introducing-the-Galaxy-S24-Camera-Gallery/ba-p/15350511
Linux: Firefox based 303 3415112
>>257646
Шакалит. Особенно градиенты. Шакалит цветопередачу. Вызывает бандинг вследствие урезания и так урезаного yuv до tv диапазона. Добавляет ложные границы на градиентах в виде горизонтальных или вертикальных прямых линий, в следствие работы механизма внутрикадрового предсказания.
image.png118 Кб, 671x517
Linux: Firefox based 304 3417198
В виндовсе возможно будет поддержка jxl из коробки:
https://nitter.cz/jonsneyers/status/1751453002299552202#m
Windows 7: Chromium based 305 3418289
>>213710 (OP)
Нахуя все это ебаное говно и дерьмо типа дерьма webp нужно, если есть православный жпег, нахуя утырки из пугла пытаются уже картинки под себя подмять? Основная нагрузка на каналы современных шизоронетов идет в виде видеотрафа, на картинки всем похуй сколько они там весят - на мобилах и десктопах уже терабайтные стораджи. Я не луддит, более того я наносек, но за этим говном нет ничего кроме скрытого стремления отдельных копрораций и купленных ими комитетов по стандартизации к технологической монополизации.
Только при существенном аппаратном прогрессе средств записи/генерации и отображения пикч потребуется новый формат, вместо эволюционно-зрелого устоявшегося жпега на котором запечатлена уже вся цифровая история человечества. Вот когда у каждого быдла в айфоне 55 ProHyperMaxKekus будет 1024-битный голографический проектор и 3D-голосканер, вот тогда и приходите.

>>415112
О Боги, неужели я встретил на сраче хоть одно адекватное мнение относительно этого уебищного энкодера.
Windows 10: Chromium based 306 3418292
>>418289

> если есть православный


heic, поправил тебя.
Linux: Firefox based 307 3418355
>>418289

> Только при существенном аппаратном прогрессе средств записи/генерации и отображения пикч потребуется новый формат


> альфа канал


> православный жпег


Ну как бы знаешь, картинки это не только фоточки. И если лично тебе не нужно, то это не значит что никому не нужно.

Да и хранить или передавать фотографические изображения на которых в фотошопе навесили альфа канал в том же PNG как то непрактично. А webp позволяет хоть криво косо, но пожать такое в lossy. И хотя в вебе это уже не так актуально, хотя-бы из-за наличия формата AVIF, но платформы такие как телега, дискорд и тот же двач поддержали только webp.

>>418292

> heic, поправил тебя.


Как то странно такое слышать от

> (Microsoft Windows 10: Chromium based)

Windows 10: Firefox based 308 3418421
>>418289
Датасеты, занимающие десятки терабайт памяти, с тобой не согласны.
изображение.png1006 Кб, 1000x778
Linux: Firefox based 309 3418491
>>418289

>православный жпег


Вся православность жипега в том что ты привык к его артефактам. Как привык к артефактам плёночного кино, винила, vhs и mp3. Настолько привык, что это стало частью эстетики. Что люди осознанно имитируют эти артефакты.
Привыкнешь со временим и к эстетике эпохи webp/heic с его мылом и дорисованными нейросетевыми тентаклями.
Linux: Firefox based 310 3418496
>>418491
Кстати, об артефактах, jxl намного лучше справляется с текстом.
С дефолтным -d 1 / -q 90 есть небольшие изменения цвета, но нет артефактов вокруг букв как у жпега.
Android: Firefox based 311 3418563
>>418355

> Как то странно такое слышать от


> (Microsoft Windows 10: Chromium based)


В 11-ой HEIC из коробки.
Windows 10: Chromium based 312 3419703
>>418491
ненавижу ебаную вебрепу ака швабп
сука его ни один нормальный хуессенджер вроде дуровсрама и другого говнища не жрет искаропки и прикрепят в виде файлика,
шиндус при печате портит цвета и делает их тусклыми, я буду рад когда его добьет хуефф ака эпплоговнище и авиф который недовидеоформат статичный
Linux: Firefox based 313 3419718
>>419703

> буду рад когда его добьет хуефф ака эпплоговнище и авиф который недовидеоформат статичный


Из этих двух я бы выбрал AVIF. Но тут как раз JPEG XL метит в

> эпплоговнище

Linux: Firefox based 314 3419740
>>419703
А хуефф, по-твоему, это не недовидеоформат?
Windows 10: Chromium based 315 3420892
>>419740
это какой-то ебаный раржипег, шиндусом нормально не просматривается, а внутри в одном файле может еще что-то лежать, но посмотрети вы можете только на дорогущем оверпрайснутом говнофоне, ну или установив хакинтош...
в общем какая-то ересь, благо хоть частично в шиндусе работает
Linux: Chromium based 316 3421011
>>420892
Речь о том, что webp, avif, heif все основаны на видеокодеках, vp8, av1 и h265 соответственно., то есть они все "недовидеоформаты".

> посмотрети вы можете только на дорогущем


В бесплатном линуксе тоже можно.
Windows 10: Firefox based 317 3421188
>>420892
>>421011

>В бесплатном линуксе тоже можно.


А в бесплатной шинде что, нельзя?
BSD: Firefox based 318 3425288
>>421011

>Речь о том, что webp, avif, heif все основаны на видеокодеках, vp8, av1 и h265 соответственно., то есть они все "недовидеоформаты".



Но это им не мешает более качественно показывать рисованные картинки, а не фотографии. В отличие от этого вашего Jpeg_Xl. Со стандартными параметрами конвертации. А то сторонники jpeg-xl любят рассказывать про особенности конвертации и ключи всякие для своего этого кодека чтобы правильно картинку конвертировать. У webp и avif это получается лучше для картинок при конвертации со стандартными параметрами.
Linux: Chromium based 319 3425313
>>425288

> А то сторонники jpeg-xl любят рассказывать про особенности конвертации и ключи всякие для своего этого кодека чтобы правильно картинку конвертировать.


Не нашел такого в этом треде например.

> У webp и avif это получается лучше для картинок при конвертации со стандартными параметрами.


Может быть, но где данные подтверждающие это?
Linux: Firefox based 320 3425439
>>425288

> А то сторонники jpeg-xl любят рассказывать про особенности конвертации и ключи всякие для своего этого кодека чтобы правильно картинку конвертировать.


Ты наверно живешь в какой-то параллельной реальности. Это для avifenc нужны параметры, для включения 10-ти битного режима, для включения адаптивного квантования, задать границы минимального, максимального и среднего квантования.

В то время как для jpeg-xl я мог бы обойтись именем входного и выходного файла. Я как то пробовал прогонять картинку через https://github.com/Blobfolio/refract, точнее несколько картинок, и -d 1 очень сложно отличить от оригинала, даже на тёмных участках. Бывало даже такое, что получалось сжать даже сильнее. А для avifenc и тем более webp приходилось завышать уровень качества. И webp в ряде случаев слишком сильно режет качество есть параметр качества там меньше 95.
Linux: Chromium based 321 3431675
В новой 0.10 версии добавили streaming сжатие, теперь энкодер стал быстрее и требует намного меньше ОЗУ.

https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
Android: Mobile Safari 322 3435806
Бамп.
Windows 10: Firefox based 323 3436118
>>213710 (OP)
Тут уже 300 постов насрали и думаю, что высказали такое мнение, но я всеравно досру сверху.

Эта хуйня НИНУЖНА!
Просто потому, что сейчас диски измеряются терабайтами, даже если ты хранишь кучу картинок, которые весят 10 МБ каждая, то на терабайт тебе придется 100 000 картинок.
Если ты в день будешь использовать 50 картинок, то у тебя уйдет больше 5 лет чтоб все их хоть раз открыть. Это дохуя.
У людей нет проблем с местом. Это только у всяких контор есть проблема с местом - вот щас много порногифок в виде webp представлено, чтоб экономить место на серверах, и это меня дохуя раздражает.
Эти новые форматы картинок - попытка решить проблему, которой нет. Разве что только каким-то супер узким специалистам, которые обрабатывают дохуища свадебных фотографий.

Вот видео - другое дело. Иметь возможность на двоще выкладывать 10 мб видео, которое в 4к и 60фпс длится десять минут - вот это заебись технология.

Второе:
Неудобно. Вот я чтоб найти анимированый пикрилейтед написал в гугле explanation meme gif
И я уже в результатах вижу где анимировано, а где нет. Я не тратя время уже знаю куда нажимать.
Потому что гиф уже ассоциируется с анимацией. Если все будет храниться в одном формате то придется дольше искать. То же самое с пнг. Если я пишу nasa logo png то с 90% вероятностью будет искать с альфаканалом уже вырезаное лого. Как мне блять искать это в jpgxxl ???

Перегонять из формата в формат и назад - вообще дебильная задача. Кому это нужно?

Короче, пока толку никакого, одни проблемы с совместимостью и срач среди вендоров.

Вердикт - пускай лучше для видео форматы придумывают, а тут нехуй ломать то. что не сломано.
Windows 10: New Opera 324 3436217
>>436118
ух как скрепно, двачую. да и интернет ентот ваш вообще нинужен, все можно в телевизоре посмотреть.
Windows 10: Firefox based 325 3436260
>>436217
Пукать ты знатно умеешь, а конкретно по какому-то пункту есть возражения с аргументами? Нет? Ну так иди дальше попукивай - можешь свисток в дупу себе вставить, чтоб веселее было.
Android: Mobile Safari 326 3436419
>>436118
Первый пункт разъёбывается тем, что сегодня с изображениями пользователь взаимодействует в основном через интернет. И если ты не заметил, сайты зачастую неплохо их так шакалят для того, чтобы у пользователей с медленным прдключением был удовлетворительный пользовательский опыт.
А JXL убивает одновременно улучшает пользовательский опыт двумя фичами: прогрессивным декодированием и лучшим соотношением размера к качеству.

Картинкохранитель, пора вылезти из морозилки, эпоха интернета наступила
Android: Mobile Safari 327 3436498
>>436419
JXL убивает двух зайцев и одновременно улучшает
медленнофикс
Windows 10: Firefox based 328 3436519
>>436419

>удовлетворительный пользовательский опыт.


Рекламой надо меньше засирать сайты, а не жать картинки.

Твой аргумент не валиден, потому что если картинка ненужная - типа шапка новости, то она может быть пожата - всем похуй. Если же человек идет именно скачать какую-то конкретную картинку, то он может и подождать чуток, но получить качественное изображение.
Windows 10: Firefox based 329 3436581
>>436118
Давно пора бы понять простую истину. Высеры корпорации гугла нужны только корпорации и её сотрудникам, остальным оно не только не нужно, но и активно вредит, потому что интересы корпораций всегда идут против интересов людей. Такой сегодня мир, пора бы уже выглянуть в окно на реальность.
Android: Mobile Safari 330 3436842
>>436581

>интересы корпораций всегда идут против интересов людей


Вы только посмотрите на этого марксиста!
Windows 10: Firefox based 331 3437615
>>436118

>https://huggingface.co/datasets/nyanko7/danbooru2023


>total size is now approximately 8 terabytes (8,000 GB)


Анон, ты долбоеб. Чтобы например хуйню по ссылке ворочать, нужно как минимум 20 ТБ памяти просто чтобы это всё нахуй работало.
image.png191 Кб, 877x835
Windows 10: Firefox based 332 3438244
>>437615
Это мне нужно ворочать или кому? Мне нах не всралось хранить 8 гб какой-то параши. И тебе нах не всралось. Для личного пользования это никому нах не всралось. Это нужно только тем, кто арендует сервера и трафик, то есть уже не для домашнего пользованя.

Даже еслилично тебе нужно хранить все это говно, то тебе все равно нужно бует отдельное хранилище, потмоу что если это 8 т пожать вдвое то все равно будет 4 т.

Смотрим цены - примерно 200 баксов за 8 т
Ок, 4 т ты купишь за 100. Итого этот всратый формат позволит тебе сэкономить сто баксов. Оно того стоит? Сто баксов это сейчас копейки, если ты не бомж или не школьник, который на обедах экономит. Тем более что эти 100 баксов ты растягиваешь на долгие годы использования. Ты можешь пользоваться этим винтом 10 лет тогда выходит по 10 баксов в год. Это 80 центов в месяц. По текущему курсу - 70 рублей.

То есть у тебя выбор - платить 70 рублей в месяц и вообще не заморачиваться. Просто без задней мысли юзать джипеги и пнг. Открывать пеинтом за секунду, вносить правки, и тут же сохранять. Отправлять в любом мессенджере и иметь предпросмотр адекватный.
Или пердолиться с конвертациями-хуйвертациями и с софтом, который поддерживает это. Иметь проблемы с открытием где-то не на твоем ПуКа и прочие красноглазые прелести.

Ответ очевиден.
Android: Mobile Safari 333 3438379
>>438244
Двачую адеквата. Все убийцы популярных форматов погорели именно на этом, даже обладая объективно лучшими характеристиками.
Windows 10: Firefox based 334 3439306
>>438244

>потмоу что если это 8 т пожать вдвое то все равно будет 4 т.


Нихуя себе, в 2 раза меньше затраты на хранилище это хуйня? А ведь может оказаться что сжимать ровно в два раза и не обязательно, потому что можно сжать сильнее и с потерями, ведь качество каждой отдельной пикчи не обязательно должно быть идеальным.

Какой же ты нахуй невыносимый дегенерат, чтобы эту хуйню ворочать нужна в первую очередь ПРОИЗВОДИТЕЛЬНОСТЬ, рандомного чтения и рандомной записи, ебанат с экономфака. Твои скрипящие-пердящие свистелки упали разве что тем самым школьникам-бомжам, которые на обедах экономят и которые готовы ждать пока у них 100к файлов скопируются пока их математичка с физруком ебут сначала в шкалке а потом в продленке. Но ты всё-таки ради эксперимента прикинь хуй к носу и разузнай, в какую копеечку обойдется хотя бы 20 ТБ с приемлимой производительностью, учитывая, что это самый минимум, и нужно ещё обеспечить избыточность чтобы не проебать драгоценные данные, и собственно нужно пространство, чтобы иметь возможность хранить например модифицированные копии или более маленькие, отфильтрованные подмножества этого датасета. А потом вспомни что такое альтернативные издержки и объясни мне почему так делать экономически невыгодно, если есть возможность купить в 2 раза меньше сидюков и докинуть две б/у 3090 сверху.

>Даже еслилично тебе


Конкретно ТЫ этим не занимаешься потому что ты ТУПОЙ и это ДОРОГО или ДОЛГО. Согласен, что стоимость хранилищ - не главная проблема при тренировки нейросеток на данный момент, но это тем не менее одна из самых важных проблем.
Windows 10: Firefox based 335 3439474
>>439306

>тренировки нейросеток


Да, каждый второй дома на 20 терабайтах тренгирует нейросетки. Без этого сегодня обычному юзеру никах. Ты просто пукнутое животное.
Windows 10: Firefox based 336 3439548
>>439474
Если бы ты мог, ты бы тоже попробовал, кек.
Apple Mac: Chromium based 337 3442723
>>213710 (OP)

> почти полнота по тьюрингу



ну все, пошел писать эксплойт на уровне ядра, который будет через баг с состоянием гонки писать в кернелспейс

мало вам было взлома айфона через ебучий pdf, да?
Linux: Chromium based 338 3442735
>>442723
Еще один клоун. Жду эксплоита от тебя.
Image1 (4).png66 Кб, 1475x701
Linux: Chromium based 339 3446661
Windows 10: Chromium based 340 3446743
>>217393
Летит "to the moon" или в канаву?
Windows 10: Chromium based 341 3446744
>>233657
А как же патчить kde под freebsd?
image.png1 Кб, 256x50
Linux: Firefox based 342 3447045
>>446744

> А как же патчить kde под freebsd?


> Microsoft Windows 10: Chromium based

Windows 10: Firefox based 343 3447653
Знатоки форматов, прошу вашей помощи. Вот тут есть порно-гифка.
Она работает в браузере. Если ее сохранить и открыть в браузере, то тоже работает. А на компьютере не проигрывается анимация. Попытки сохранить в анимированый вебп а потом обратно преобразовать в гиф не помогло - все равно не проигрывается. Пишет что неизвестный формат или битый фал. Но файл не битый и формат гиф.

Как сделать так чтоб проигрывалось?
https://porngipfy.com/nia-nacci-4-51725/
Windows 10: Chromium based 344 3447679
>>447045

>пук


>срёньк

Windows XP: Firefox based 345 3447990
>>447653
Совершенно обычный GIF-файл, 2322056 байт, не обрезан, не испорчен, нормально импортируется в редактор и показывается. Обратись к разработчику программы, которой пользуешься для просмотра картинок, либо поставь другую, нормальную.
BSD: Firefox based 346 3448022
>>447653

>Она работает в браузере. Если ее сохранить и открыть в браузере, то тоже работает. А на компьютере не проигрывается анимация.



УМВР. Открыл в XnView MP и в Xviewer. Всё нормально.

Скачай нормальную прогу для просмотра фоток себе и не парь мозги людям.
image.png281 Кб, 1925x1078
Windows 10: Firefox based 347 3448190
>>318045
Теперь рилейтед поддерживает сабж форматы. Единственный барьер не быть лучшим вьювером с собственным ФМ кажется уже преодолен, вместо прошлого громоздкого пика на кутэ. Вьюверы без своих собтвенных ФМ в счет не беру, кому-то и такого достаточно, их не сравниваю.
Windows 10: Chromium based 348 3476644
>>448022

>для просмотра фоток


>gif анимация


>>447653
Найди оригинал и вырежи себе видос в нормальном качестве (и меньше по весу)
image.png309 Кб, 1004x434
Linux: Chromium based 349 3477561
Собрал ванильный хромиум с блэкджеком и шлюхами патчем для jpeg xl.
Осталось только найти вебсайты, которые выдают jxl картинки.
Linux: Firefox based 350 3481769
>>442735

>Жду эксплоита от тебя.


А ждать надо от гугля. Прошлогодняя история с webp тебя ничему не научила?
Linux: Chromium based 351 3481829
>>481769
В webp очередное си говно с переполнением буфера, тут речь про полноту по тьюрингу была.
Впрочем, libjxl на крестах написан, можешь к этому прикопаться.
Windows 10: Chromium based 352 3482424
>>235053
Ты бы ещё в mpv текст набирал и капчевал
Linux: Firefox based 353 3482593
>>482424
Зачем mpv когда есть emacs?
Windows 10: Chromium based 354 3482693
>>482593
А emacs может показывать маняме?
Android: Mobile Safari 355 3484117
>>482693
Сам им не пользуюсь, но почти уверен, что да. Это же емакс
Windows 10: Chromium based 356 3484709
>>484117
Есть что-нибудь, во что емакс не может?
Windows 10: Chromium based 357 3487148
Linux: Chromium based 358 3487313
>>487148

> 404


> Ничего не найдено


Что там было?
image.png27 Кб, 663x345
Windows 10: New Opera 359 3489796
https://github.com/sylikc/jpegview
Неплохой просмотрщик изображений с поддержкой JPEG XL, HEIC, AVIF.
Оставлю тут, может кому пригодится, удобная штука.
Так же в PureREF недавно завезли поддержку JXL.
Android: Firefox based 360 3504022
>>299989
Этот GIF уже давно устарел и не актуален
Linux: Chromium based 361 3506210
>>226680

> ГЕНШИН ИМПАКТ


А что, в это кто-то, кроме девочек среднего школьного возраста играет? Это насколько альтернативно одарённым надо быть?
Linux: Chromium based 362 3506212
>>233661
А какие проблемы были с тушонкой? Юзаю её уже лет 10, особых траблов не наблюдаю. Даже флаки по кую норм нарезает в плейлисте (у фубара есть с этим проблемы местами). Тушонка охуенна, если тебе надо музычку играть при вменяемом интерфейсе.
Windows 10: Chromium based 363 3508330
>>225088
Видео отклеилос
Windows 7: Chromium based 364 3508358
Ну, охуенно - потерли мой пост с вопросом и ответы на него.
image.webp6 Кб, 316x104
Linux: Chromium based 365 3511082
Как же хочется поддержку jxl на дваче и в браузерах.
Windows 10: Chromium based 366 3513332
>>318229

>>По теме то, есть что сказать


Ну и складывает цифры ебаные

>>https://storage


MS Visusl Studio.
Windows 10: Firefox based 367 3514873

>PNG


Не заменит он его, пнг также берут чтобы фон прозрачный был, может твой жыпег так? а вот нихкя
Linux: Chromium based 368 3515172
>>514873
jxl может в прозрачность, обычный jpeg нет
Windows 10: Chromium based 369 3518993
>>303594
дрочерам, хули
Windows 10: Chromium based 370 3519270
>>233608
Я умею делать хорошие jpeg'и.
image.webp183 Кб, 1119x954
Linux: Chromium based 371 3523619
>>213710 (OP)
Новая версия вебсайта.
https://jpegxl.info/new/
image.webp366 Кб, 2048x1421
Linux: Chromium based 372 3527052
Готовятся переписывать на Rust.
Windows 10: Firefox based 373 3554158
Немного не в тему треда мейби

Есть оцифрованный видео-файл в формате .dv на 12Гб. Как его перекодировать в другой формат, чтобы можно было смотреть на телике?
На компе есть программа ffmpeg, но как задать правильно флаги, чтобы всё заработало, я не знаю. В интернете ничего не нашел про это.
Windows 7: Chromium based 374 3554237
>>554158
Ты не нашел мануал на ффмпег? В любом случае, тебе сюда:
>>3441805 (OP)
Android: Mobile Safari 375 3555162
>>213710 (OP)

> вебп не очень


Лол
Иди джипег2к наебни
Android: Mobile Safari 376 3555169
>>213710 (OP)

> 20 процентов от оригинала


> никто не может


Тем временем mozjpg делает тоже самое. Вот только не забываем, что помимо таблицы хофмана они удаляют на кой то хер метаданные.
А ещё архиваторы на такие же проценты сжимают картинки уже давно, что как-бы намекает, что больше похоже на контейнер, где изображение тупо сжато.
Android: Mobile Safari 377 3555170
>>213710 (OP)
Так чем. Вебп плох?
Apple Mac: Safari 378 3555498
>>555170
lossy: сжимает хуже чем jpegli
lossless: лучше чем png, хуже чем jxl - сойдет если не нужно больше 8 бит
Android: Mobile Safari 379 3555519
>>555498

> хуже jpg


Очень жирно. Он как раз потому что жмёт в разы лучше и стал использоваться
Apple Mac: Safari 380 3555537
>>555519
Смотри тесты выше или проверь сам, некомпетентный дурачок.
Android: Mobile Safari 381 3555825
>>555537
Я проверил, вебп везде лучше, даже на онлайн давильщиках. Ты долбаеб, видимо
Android: Mobile Safari 382 3555828
>>555537

> тесты найди сам я ничего не пруфану


Норм ты слился
https://web.archive.org/web/20101004134848/http://code.google.com/intl/no/speed/webp/docs/c_study.html

> new open format for lossy compressed true-color graphics on the web, producing files that were smaller than JPEG files for comparable image quality


> a conversion from PNG to WebP resulted in a 45% reduction in file size when starting with PNGs found on the web, and a 28% reduction compared to PNGs that are recompressed with pngcrush and PNGOUT

Linux: Chromium based 383 3555831
>>555828
Аж в архив полез за устаревшей инфой. Какой же ты забавный клоун.

> тесты найди сам я ничего не пруфану


Читай тред, тут всё есть.

>>555825
Ну ты хотя бы покажи что ты и как проверял. Где результаты?
Android: Mobile Safari 384 3555854
>>555831

> в архив полез


Так долбаеб, мы увидим от тебя пруфы? Обычный jpeg хуже webp и он даже не обновляется. Все что я могу поверить это мозиловский. Но ты же утверждает другое
Windows 10: Chromium based 385 3559337
JXL это говно по сравнению с avif
Хватит пиарить этот красноглазый кал, хоть усритесь но качество в нем будет хуже на тот же размер
Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную позавчера в 20:21.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /s/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски