Референсный энкодер, декодер и транскодер для тех, кто хочет поиграться с форматом.
https://github.com/libjxl/libjxl
ImageMagick тоже поддерживает JXL, но когда я в последний раз его тыкал, он это делал хреново. Возможно сейчас уже лучше.
https://github.com/libjxl/libjxl
ImageMagick тоже поддерживает JXL, но когда я в последний раз его тыкал, он это делал хреново. Возможно сейчас уже лучше.
> - Почти полнота по Тьюрингу (если бы не ограничения на максимальный размер обрабатываемых пикселей). Это позволит почти бесконечно оптимизировать формат. Пикрил в формате JPEG XL весит всего 117 байтов! И по факту является программой по его генерации, написанной вручную.
Время вирусни в картинках.
Да, это теоретически может быть проблемой при использовании кривых декодеров.
Но в целом предпосылок не должно быть. Коммент с 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).
У меня пока нет потребности в свободном месте, да и галерея не такая большая. Торопиться не надо. Но когда появится повсеместная поддержка, то почему нет?
> - Свободный формат, а это значит, что его может использовать кто и как угодно. Его уже можно активировать в Chrome, если включить флаг enable-jxl, и в ночных сборках Firefox. Также его поддержка уже добавлена в Gnome. Для винды тоже есть вьюеры. Про Plasma вообще без понятия (скорее всего тоже есть).
mpv, который работает везде, тоже открывает jpeg xl.
>mpv
хуета, разработчики-инвалиды даже настроек в нормальном виде не завезли.
Generation loss у разных форматов:
https://youtu.be/w7UDJUCMTng
Сравнение прогрессивного декодирования:
https://youtu.be/inQxEBn831w
На канале ещё много подобных видосов.
Но они относительно старые, по идее, сейчас кодировщик и декодировщик могли стать ещё лучше.
https://youtu.be/w7UDJUCMTng
Сравнение прогрессивного декодирования:
https://youtu.be/inQxEBn831w
На канале ещё много подобных видосов.
Но они относительно старые, по идее, сейчас кодировщик и декодировщик могли стать ещё лучше.
Только его бетатестерские сборки. Stable старый, 0.34.1, не поддерживает.
Если собрать стабильную версию со свежим ffmpeg'ом, то должно открывать, но я не пробовал.
Это называется контейнер. И пошли они в пень. Знать о формате изображения только на этапе декодирования - удобно только для "листальщиков картинок".
Кто контейнер?
Когда будет поддержка в HoneyView, XnView Cassic или хотя бы в FastStone, то можно пользоваться.
>Он одновременно может заменить JPEG, в случаях сжатия с потерями (например фотки), PNG, в случаях сжатия без потерь (скриншоты)
И как тогда различать пережатые картинки от непережатых? Никак? Нахуй следуйте.
>Почти полнота по Тьюрингу
>картинка по факту является программой
Круто, теперь вирусы/майнеры в картинках. Нахуй следуйте.
> Сжимает на 60% лучше, чем JPEG
А по сравнению с вебп?
А по сравнению с вебп?
Помнится, когда появился jfif, тоже было визгу. И где оно теперь?
А инфу в нем можно хранить, как в раржпег например?
Оно и нинужно было никогда. Опус взлетел, джхл тоже летит.
Можно.
Короче, нинужно.
Ну, удачного полёта. Может, и до меня долетит. А я капризный.
>Пикрил в формате JPEG XL весит всего 117 байтов! И по факту является программой по его генерации
Ждем когда вместо любого хайрез изображения будет промпт для генерации на аппаратно реализованном Stable Diffusion.
Ждем когда вместо любого хайрез изображения будет промпт для генерации на аппаратно реализованном Stable Diffusion.
НИНУЖНО, ибо в png анимацию завезут
https://www.opennet.ru/opennews/art.shtml?num=57977
https://www.opennet.ru/opennews/art.shtml?num=57977
Это, кстати, хорошее ожидание. Появление аппаратной реализации dpi-независмой модели Continuous Image Representation существенно перезапустит взгляды и на сжатие, и на рендер.
https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL
Они убили jxl, сволочи!
Они убили jxl, сволочи!
Вот так оно иметь монополиста. А кто-то за него ещё и бесплатно топит прямо на этой доске.
Гуглохрому и мобилкам нужно просто перестать поддерживать жипег для того, чтобы сдвинуть дело с мёртвой точки
Google и Apple похоже решили сделать AVIF дефолтным next-gen форматом для изображений.
IOS 16 например уже поддерживает AVIF, в то время как у них ушло 10 лет, чтобы добавить поддержку WEBP.
С чего? Двач до сих пор в webp не может, чего уж говорить о jxl, разумеется картинку нужно было конвертировать в пнг или в жпег.
>- Он может транскодировать jpeg изображение без потерь туда и обратно.
a PNG?
Поддержка есть в windows - следовательно везде, гугли WIC decoding
Вам смешно, а я б был рад еслиб waifu2x встроили б в мозиллу для апскейла картинок
мимо читаю комиксы от ебучих шакалов постоянно
C jpeg -> jxl -> jpeg ты получишь в точности тот же самый файл.
С пнг ты получишь другой файл другого размера в байтах, но с теми же пикселями.
>С пнг ты получишь другой файл другого размера в байтах, но с теми же пикселями.
А почему тогда файл будет другой если пиксели те же?
Я про перегонку loseless JXL - > PNG и обратно конечно же
jxl -> png -> jxl даст одинаковые файлы.
png -> jxl -> png необязательно, так как оригинальный пнг неизвестно чем создан и с какими опциями.
>так как оригинальный пнг неизвестно чем создан и с какими опциями.
Если ты про всякие хуептимизации - так и хуй с ним, ведь на картинку не влияет же, разве нет?
> на картинку не влияет
Всё так
Стоит конвертировать форточки из jpeg в jxl? Существенная экономия будет?
>мимо
>мимо
Каким боком тут монополия? Они этот формат разрабатывают, они и могут его убить.
Ты новость-то читал?
Монополия — на браузерный движок. Разрабатывают, именно что за пределами гугла, и конкурироет с домашним гугловским webp.
Создайте своего монополиста, чо.
>Создайте своего монополиста, чо.
Это не решит проблему монополистов, очевидно же?
Исходный код пердоформата есть, в чём похороны заключаются?
Некоторые кодеки вроде TAK вообще одним васяном пилятся и вполне себе живут, бгг
Некоторые кодеки вроде TAK вообще одним васяном пилятся и вполне себе живут, бгг
Мы живëм в мире вытесняющей товарности. Но я в этом не уверен.
Тогда непонятно почему гугл указан как один из разработчиков на педивикии.
>вроде TAK
>вполне себе живут
Этот ТАК один шизик на весь /с/ форсит. Не удивлюсь что это и есть тот самый один васян.
Потому что кто-то из гугла пилил PIK, который впоследствии слился с FUIF в jxl.
https://github.com/google/pik
https://github.com/cloudinary/fuif
https://github.com/FLIF-hub/FLIF/issues/549#issuecomment-912335312
Ну и теперь эти люди из гугла пилят jxl, например:
https://github.com/jan-wassenberg
https://github.com/mo271
Что за ТАК то вообще?? Есть годные аудиоформаты типа wavpack и musepack, которым уже сто лет, но их мало кто поддерживает, что впрочем не мешает их использовать. Именно поэтому я все фоточки давно корветнул в jxl, а что там хипстеры ебаные о себе возомнили мне похуй. Ещё бы на мнение FAGMAN равняться.
> Что за ТАК то вообще??
Формат кодирования аудио без потерь, обеспечивающий максимальную степень компрессии по сравнению с другими lossless-кодеками.
Причаститься: http://thbeck.de/Tak/Tak.html
Автор всё хочет в Open Source своё детище перевести, но пока не получается особо.
> Linux
Тебе просто обидно, что тебя ниопустили совсем, обойдя стороной прошивку для роутера, бгг. А TAK пилит немец, он не может здесь его форсить.
Как у нас на ЛОРе говорят, НИНУЖНО!!111
>максимальную степень компрессии
Мало того, что не максимальную. Так ещё и компрессию примерно на 2..3% отличающуюся от любого распространённого опенсорсного формата.
Два самых нинужных кодека, согласно этой таблице, т.к. даже software support хромает. Про hardware молчу.
> Более уплотнённо сжимает только OptimFROG, Monkey's Audio и Lossless Audio
> все находятся в вилке 49..52%
Ты только что тупо повторил моё утверждение.
Все, устал тебя кормить, иди своё нинужно свидетелям фубара форси. Неудивительно, что проприетарное говно, которое даже рокбокс не умеет, никто не хочет использовать. Да и вообще все проприетарные форматы через лет 50 превратятся в тыкву.
Похоже из стандартного жпега можно выжать еще больше сжатия при том же качестве картинки.
>28%
Звучит слишком хорошо, я фотки перевёл в jxl получил где то так же. Зачем тогда изобрели jxl?
Я так это понимаю:
100 png->jpg (baseline)
80% png->jpg->jxl (lossless transcoding)
72% png->jpg+ (кодек из скриншота)
40% png->jxl (lossy jxl)
jxl жмёт аж на 60% лучше jpg (обычного)?
Это то, что указано в оп посте.
>Основные фичи формата:
>- Сжимает на 60% лучше, чем JPEG.
Только проблема сайтов не в дохуя тяжелых картиночках, а в ебучих скриптах по несколько мегабайт.
Это понятно, но если на сайтах и в браузерах не будет jxl, его нигде не будет, где он нужен.
то-то они глубоко прожаривают пользовательские картинки
Во-первых, 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
>Какой-то из компрессоров на соревнованиях по сжатию картинок без потерь, помню, оказался с потерями, но оптимизированным так, чтобы на большинстве типичных данных генерировать не отличающуюся копию.
а вот это очень интересно. зачем? нахуя? не можешь вспомнить что это было?
Это могла быть просто не отлаженная программа. Если ты посмотришь, в тестах кучу строчек занимают программы, которые поддерживают только часть форматов изображений или специально написаны для сжатия конкретного набора данных, даже не пытаясь работать с остальными. Смысл в том, что это опорные точки для оптимизации, на которые можно ориентироваться при оценке общих алгоритмов.
> зачем? нахуя?
Ну так если у тебя программа на миллионе прочих данных работает некорректно, а с тестовыми всё хорошо, и это позволяет улучшить результат, то ты просто получил некий алгоритм генерации именно этих данных. См. пример сжатия цифр числа пи.
Ну хром (90% юзеров на нём) сказал "НЕТ, будем делать СВОЁ", - так что хороним.
понятно, ну это уже совсем другое соревнование получается, к сжатию изображений отношения не имеющее,
Ага, люди годами что-то обсуждают, статьи в научные журналы пишут, а потому приходишь ты и говоришь, что это всё чепуха какая-то. Ты понимаешь, что вон те результаты нейросеточек, на вычислительных кластерах подбирающих алгоритм, возникли по следам ковыряния вот этих маленьких программ и их обобщения?
Наконец, можно оценить общую картину. Вон строчка с результатами обычного PNG, что мы понимаем, глядя на неё? Во-первых, что стандартный zlib что-то как-то медленно работает (а это не новость, всем известные проекты предлагают сравнимый результат с теми же принципами сжатия за меньшее время). Во-вторых, что от современного формата сжатия без потерь общего назначения мы можем ожидать улучшения в 20-25% относительно PNG. А кому это надо? Если ты строишь три датацентра вместо четырёх и заказываешь на столько же меньше грузовиков с дисками, сумма экономии выходит внушительная. Если же у тебя картинки занимают четыре гигабайта вместо пяти, ты этого просто не заметишь на фоне всей прочей скачанной порнухи с пенсионерками.
Пока просмотрощики и редакторы его поддерживают, можно продолжать фотки в него пережимать. Ну а инстабляди пусть сосут.
>просмотрощики
Сам создал изображение, - сам посмотрел, - ЗАЕБИСЬ какой нужный формат.
Нужный. Почему меня должно волновать место на серверах гугля или яндекса? Мне jxl моё место экономит.
>Вон строчка с результатами обычного PNG, что мы понимаем, глядя на неё? Во-первых, что стандартный zlib что-то как-то медленно работает
Кстати, натыкался на прототип пнг, в котором заменили zlib на zstandard.
https://github.com/catid/Zpng
Судя по ридми работает гораздо быстрее и дает файлы меньшего размера.
извиняюсь перед учеными.
и все же, на реальных данных, а не на заранее известном бенчмарке, программы-рекордсмены все еще показывают лучший результат? может бы я описал не текущую ситуацию, а будущую, но она явно случится - когда переоптимизация под кокретные картинки перестанет нести поелзные на практике идеи. что-то типа оп-пика.
вот кстати перевод из жпега и обратно в жпг без потерь реально киллер фича. только удобный пользовательский интерфейс чтобы картинки из своего хранилища постить в интернет современные оси и браузеры даже не позволят сделать нормально.
>Сам создал изображение
>сам посмотрел
в том-то и дело что нет и нет. ты описал любой рандомный кодек, а jpeg xl может пережать без потерь существующий жпег, причем не только без потери пикселей но и без потери самого жпега!
вот бы для h264 сделали оптимизатор, там как и в любом кодеке есть беспотерьная часть, и реалтаймовые кодеры использующиеся при съемке явно не оптимальны.
а ведь сделали, только за каким-то хером оно заброшено...
https://encode.su/threads/3213-Is-there-an-MP4-optimizer
https://encode.su/threads/3213-Is-there-an-MP4-optimizer
> вот кстати перевод из жпега и обратно в жпг без потерь реально киллер фича.
Как правило, если не инстаблядь, то фотки и нет необходимости постить.
>без потери самого жпега
И зачем это нужно, jpeg же говно.
а как же мемы и реакшнфейсы?
Если ты коллекционируешь это говно, значит ты слишком много времени проводишь онлайн и вообще лазер...
>И зачем это нужно
Сегодня придумали JPEX XL - ты перегнал в него всё, завтра JPEG XXL - опять перегнал, JPEX XXXL - опять - и вот у тебя бы уже были одни шакалы видны если после каждого шага был было бы перекодирование перекодированного
А гугель против что ли?
Да, против.
Вся надежда на лису, сафари и эдж.
А что, Edge уже не на хромиуме?
Ну добавить поддержку они могут, наверное.
Если добавят, то сразу в хромикм закинут. От совсем халявы там не откажутся.
Если согласятся поддерживать, то да. Именно из-за недостатка интереса её и убрали оттуда недавно.
все так просто? а я думал политические интересы
Да, скорее ты прав. Вот поэтому я надеюсь, что в edge быстрей добавят. Не хочется уж больно юзать webp2 или как его там.
avif, webp2 тоже отменили
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.
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.
и чем сабж лучше чем AVIF?
я столько крутил вертел и всё равно результат хуже чем у avif
>Эпоха ссд накопителей
>Средний сайт занипер в памяти 5 мегабайт
>Средняя программа минимум 200 мегабайт
>Уии, новый формат позволяет сократить размер картинки на 50 килобайт, уряяя, перемога, срочна начинаем его форсить вместо старых добрых jpg, gif и bmp
>Средний сайт занипер в памяти 5 мегабайт
>Средняя программа минимум 200 мегабайт
>Уии, новый формат позволяет сократить размер картинки на 50 килобайт, уряяя, перемога, срочна начинаем его форсить вместо старых добрых jpg, gif и bmp
>занипер
Занимает
Зачем жрать говно если можно не жрать? Перегнал все свои jpeg и png в jxl без потерь в качестве. Единый формат, который меньше их обоих.
Зачем мне пердолиться ради 0.001% экономии места на диске?
Отправить фотку кому-нибудь показать? - Нет, я ведь пердольщик
Выложить в интернет показать? - Нет, я ведь пердольщик
Сохранил картиночку из инета, что дальше? - Да, пердолиться!
Всего то скриптик запустить.
> Отправить фотку кому-нибудь показать? - Нет, я ведь пердольщик
На переходном этапе, а если поддержка будет везде, то эта проблема отпадает сама собой.
Напомнить сколько переходной этап у webp был? 12 лет прошло, а двач до сих пор не осилил.
Или напомнить сколько этот переходный период был у jpg2000?
УРРЯЯЯ, АЖ НА ПИТЬСОТ КИЛАБАЙТ МЕНЬШЕ МЕСТА, ПЕРЕМОГА
@
IШТО ЗНАЧИТ , ГЕНШИН ИМПАКТ ЗАНИМАЕТ 228 ГИГАБАЙТ (ПРИ ГРАФИКЕ ХУЖЕ ЧЕМ В КРУЗИС 1), ТЫ ЧО РЕТРАГРАД ИЗ ПРОШЛОГО ВЕКА ШТО ЛИ, ПРОСТА КУПИ НОВЫЙ СОСОДИ НА 100500 ТБ
>Геншин
Он идет даже на пука времен Windows XP с соответствующей видеокартой
Автор темы писал, что загрузка застревает на 13%. Возможно из-за отсутствия SSE4.
Суть не в этом. Главное что сама игра не особо требовательная, но при этом занимает даже больше места чем гта 5.
Ну так в обоих этих играх половину объёма занимает озвучка.
>Уии, новый формат позволяет сократить размер картинки на 50 килобайт
А вот и нихуя, больше. Если lossless в png весит 19,7 мегабайт, то математический lossless (-d 0) jxl весит 9,64 мегабайта. Если брать почти lossless (-d 0.3 -e 9 --brotli_effort 11), то он весит 3,88 мегабайта, и отличий от png вообще нет, даже если в прильнуть лицом к экрану и заняться охотой на пиксели.
> "почти lossless"
> Продолжает сравнивать с .png
А ты хорош. У тебя еще и .png поди не оптимизированный?
А с чем сравнивать, с jpg или gif что ли?
А почему нет то? Потерьное с потерьным. Сравнивай с оптимизированным jpeg'ом на максималке.
Потому что любой жпег визуально гораздо хуже nearly-lossless jxl.
Ты просто не умеешь делать хорошие jpeg'и.
Для тех, кто не хочет переходить по ссылке. Там пишут, что jxl в среднем примерно на 48% и 37% меньше, чем png и оптимизированный png соответственно.
И кодируется в 35 раз дольше, ога.
> И кодируется в 35 раз дольше, ога.
> These tests have also been done at the lowest possible speeds
И? На быстрых прирост сжатия будет - копейки.
25% будет по сравнению с оптимизированным пнг.
Во первых, эти тесты не учитывают скорость кодирования PNG, а только скорость оптимизации. Так что некорректно делить 25 на 0.7, как ты сделал.
Во вторых, от oxipng толку мало, какой смысл с ним сравнивать? Этак можно вообще без оптимизацией сравнить будет 0 сек, лол.
Вот еще любопытные графики, fjxl и fpng были написаны в ответ на qoi, автор которого заявлял, что пнг слишком медленно кодируется, из-за чего он решил запилить свой простой 300 строк кода на си и быстрый формат без бэкджека и шлюх.
fjxl годнота походуа fpng все равно сосет
Ёбаный рот луддитов на разработчике. Нет адекватных вьюверов, которые бы поддерживали jxl. HoneyView - годнота как вьювер, но не поддерживает, XnView - открывает jxl файлы очень медленно, IrfanView - говнище без возможности поменять хоткеи, отчего скроллить масштабированные изображения можно только клавиатурой но не мышью. Есть ещё mpv, но он предназначен для видео, и во вьювер картинок его превращает набор скриптов.
Ставь линукс с кде
Хотя, с другой стороны, fjxl и жмёт хреново, чуда не произошло
Не буду я ради одного кодека отказываться от большей части софта. Вон, аудиоплеера нормального под прыщами до сих пор нет - foobar2000 вин-онли, фотошопа нет, игры (по крайней мере пиратские, без зависимости от барского стима) запускаются через костыли и с меньшей производительностью. У файрфокса нет отдельного хранилища сертификатов, а линукс позиционирует себя как ОС для продвинутых пользователей. Вся эта возня с пакетными менеджерами, репозиториями, зависимостями, ну его на хуй короче.
>foobar2000 вин-онли
На него похож Deadbeef, но он и без протествари не славится адекватной работой.
Я на винде chocolatey лет пять использовал, а ты говоришь с репозиьориями ебаться ;-)
Ну на уровне пнг, согласно тем графикам, при этом намного быстрее.
Ну кому надо побыстрее те и на fpng перейдут, а кому больше размер важен, не думаю, что станут на fjxl смотреть.
>На него похож Deadbeef
Именно что похож, а нужных плагинов нет. Я их много использую.
Ради смеха спрошу, какой дистрибутив линукса ставить? Они все или почти все - крайности определённых недостатков, и если спросишь на форуме (не на форуме дистрибутива, где мынивиноваты, софт ненужон и используй аналоговнет, а на форуме разработчика какого-нибудь софта) "как решить эту проблему с вашим софтом?", то в ответ получишь "пок-пок-пок, скачай другой дистрибутив", с которым тебя пошлют нахуй уже на другом форуме. Лебедь, рак и щука в жму/пениксе.
>Сжимает на 60% лучше, чем JPEG.
>Сжимает без потерь на 35% лучше, чем PNG.
В итоге такой же обсер как и у WebP - А КАК ИХ РАЗЛИЧАТЬ-ТО В ИТОГЕ?
На самом деле различать лосслесс и лосси не тривиальная задача. Вот у тебя похоже убеждение, что раз пнг значит очевидно лосслесс, но ведь есть пнг сконвертированные из жпегов, а еще есть утилиты, которые делают сразу лосси пнг, например pngquant, как ты различаешь такие пнг от Ъ-лосслесс?
В libjxl гитхабе есть утилита jxlinfo, которая пытается детектить лосси:
> info.uses_original_profile ? "(possibly) lossless" : "lossy");
Помимо этого можешь ориентироваться на размер файла, лосси файлы обычно на порядок меньше занимают места.
Люди продолжают сравнивать 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".
Если даже в таком варианте, jxl все равно лучше на 3%, нахуя выпилили то ебланы
Honeyview jxl картинки так и не открывает, несмотря на установленный в системе wic кодек для jxl.
>Honeyview, pictus, qview
Столь мелкие поделки может вполне заменить всеядный mpv и даже лучше их быть. Смысла нет в них.
Проблемы негров-виндузятников. Жрите баренский jpeg и png
Появилось расширение для браузеров, которое через wasm декодирует jxl:
https://github.com/zamfofex/jxl-crx
Пока что находится в ранней стадии разработки.
https://github.com/zamfofex/jxl-crx
Пока что находится в ранней стадии разработки.
> Он одновременно может заменить JPEG, в случаях сжатия с потерями (например фотки), PNG, в случаях сжатия без потерь (скриншоты
И как отличать изображение со сжатием от изображения без сжатия? Когда я вижу пнг я сразу понимаю, что картинка не сжималась, а тут что?
Можно и jpeg переконвертировать в png и не всегда легко будет заметить разницу. Но в общем случае, согласен, это неудобно и у webp та же проблема.
>JPEG XL
>собрались компании Google и JPEG и решили
>WebP
>is an image file format developed by Google
>та же проблема
И имя ей Google
Отдельно кринжую к кукареков про "швабодный" формат, в одном предложении с Google. Жидорабы пердососки не палятся.
Таблетки прими, шизло, может речь связной хоть будет.
Если я jpeg преобразуются в png, а затем png в jxl (lossless), то размер будет равен прямому преобразованию того же самого jpeg в jxl (lossless)? Если нет, то почему.
Не будет равным.
Потому что транскодирование jpeg без потерь выполняется особым образом.
Как я это понимаю: при обычном транскодировании сначала декодируется изображение, из которого мы получаем набор пикселей. Этот набор кодируется в другой формат.
А при транскодировании jpeg, дополнительно используется информация из оригинального jpeg вроде того, как на какие блоки было поделено изображение и как они были закодированы. Кодировщик jxl использует эту информацию для создания новой пикчи, где используются точно такие же блоки, но хранятся они более эффективно.
Я далёк от процесса транскодирования, это лишь предположение.
Тогда в чем смысл конвертации из jpeg напрямую, кроме возможности восстановить исходный jpeg, если можно потенциально достичь меньшего размера при том же качестве, закодировав сперва в png.
При конвертации из jpeg в png крайне сильно раздуется формат файла. Потому что png будет вынужден хранить все эти артефакты компрессии jpeg как отдельные странные последовательности пикселей, которые сложно эффективно закодировать.
При перекодировании из png в jxl, последний тоже будет вынужден хранить все эти артефакты как последовательности пикселей, которые сложно эффективно закодировать. У jxl кодировщика не будет информации о том, что эти артефакты компрессии на самом деле являются наложением разных градиентов, соответственно он не сможет использовать такие же градиенты для создания jxl изображения.
>если можно потенциально достичь меньшего размера при том же качестве
В твоей схеме он будет потенциально большего размера. В этом проблема.
Проверю, доложу. Я почему этой темой заинтересовался, многие png - по сути пересжатые jpg, а не с нуля созданные изображения. Вот и пытаюсь понять, что делать в таких случаях, конвертировать из png или брать jpg источник.
В общем расклад такой, да действительно, если jpeg файл сконвертировать в png, а затем в jxl, то размер получится больше (716K против исходных 387K в моем примере), но это при использовании -d 0 (математический лосслесс), если же получившийся png закодировать с -d 1 (визуальный лосслесс), а jpeg напрямую с -d 1 и --lossless_jpeg=0, то размер уменьшится одинаково (до 135K) без видимой потери качества в теории. Значит преобразовывать предварительно в png смысла нет, если можно закодировать напрямую.
> без видимой потери качества в теории
Попробуй поперекодировать скрины png'шные с текстом, охуеешь от этих теорий
Так самое смешное, что когда я кодировал с -d 0 (для jpeg по умолчанию), то выигрыш был всего несколько десятков килобайт. То есть смысла нет на моём примере.
> есть пнг сконвертированные из жпегов
Двачую, заебали пидорасы, которым лень сохранить файл или поставить куклу, и они постят из буфера своё мыло в пнг, и оно со всеми шакалами весит 8 метров блять.
Ты свечку держал что ли, мразь? Я блять копирую из гугла жипег и вставляю тебе из буфера в пнг, отчего он раздувается в 7.6 раз нахуй. Твои действия, чмо?
Что не так с webp?
Тем, что разширкние не отличается, был бы webp (lossless) и webj какой-нить, тут бы всем было ясно.
В метаданных всё написано.
Я тут обнаружил, что двач теперь может в webp.
Ебать разродились, когда уже в .avif уметь надо.
Не нужен. В jxl.
Lossless webp сжимает значительно лучше png, особенно скриншоты с текстом, lossless avif совершенно бесполезен.
Как замена jpeg'у avif действительно был бы лучше.
JXL мог бы заменить все упомянутое, конечно.
подскажите аноны, тот факт что гуголь бросил играться с jpegxl что-то значит для его будующего и поддержки? я не планирую никуда постить свои фоточки, но вот потерять возможность перекодировать всё обратно в png/jpeg лет через 5-10 не хотелось-бы
Ты не потеряешь возможность перекодировать обратно без потерь даже через 100 лет. Даже если jxl вообще перестанут развивать при условии, что человечество каким-то образом не проебёт исходные коды/бинарники.
Скорее ты проебёшь свои фотки, так что не переживай.
Причем уже есть 3 альтернативных декодера разной степени готовности:
https://github.com/tirr-c/jxl-oxide
https://github.com/thebombzen/jxlatte
https://github.com/lifthrasiir/j40
> - Почти полнота по Тьюрингу
Открыл картинку - а она начала майнить. Круто!
Опять эта чушь про майнеры.
Ты бы хоть посмотрел на этот их тьюринг полный язык и его ограничения.
SVG тоже почти тьюринг комплит, но ты почему-то не выёбываешься на это.
Ах, да, всё от невежества.
Сравни лучше с PDF, который из-за сложности исторически являлся источником кучи дырок, как в логике обработки так и самих либах.
В jxl можно встроить wishmaster?
Пидарасы какие то продвигают ебучий avif.
Даже если не проебет (фоточки и исходники), то все равно скорее всего все уже перестанут пользоваться лосси форматами, и даже jpeg будет нечем открыть. Но это явно не перспектива ближайших 5-10 лет.
Для форк-бомбы достаточно
Лучше сразу встроить в сракло софтошиза для лучшего расширения™
Я слишком тупой, покажи мне, как у тебя получилось сделать форк-бомбу на пикриле.
User: хэй, не могли бы вы вернуть поддержку jxl?
Devs: слишком сложно, мы не осилим
User: вот есть уже готовый патч от Васяна
Devs: мм, там лицензия не та
Васян: я сменил лицензию на совместимую с вашим проектом
Интересно, какие отговорки сейчас пойдут.
Devs: слишком сложно, мы не осилим
User: вот есть уже готовый патч от Васяна
Devs: мм, там лицензия не та
Васян: я сменил лицензию на совместимую с вашим проектом
Интересно, какие отговорки сейчас пойдут.
Хоть какая то польза от васянов.
аноны, поскольку в jxl нельзя транскодировать jpeg изображения с CMYK, то возникает вопрос: а как нахуй узнать, какие изображения у меня имеют cmyk? в ручную проверять вообще не вариант, слишком много их
Посмотри в сторону imagemagick, а именно identify. Почти на 100% уверен, что там должна быть эта инфа.
Какой красивый терминал. Что за шрифты и реленватнтые настройки?
А зачем нужен авиф, если есть webp?
Я вообще-то даже в нужности jxl сомневаюсь, на фоне вебп
А какая годная альтернатива кроме djvu? Планирую OCRить отсканенные книги.
Liberation Mono
fish + https://github.com/pure-fish/pure до этого был zsh+pure, можешь еще посмотреть в сторону https://starship.rs
JXL лучше webp и для lossy и для lossless, и позволяет jpeg изображения в него конвертировать без потерь. Таким образом потенциально можно будет от jpeg вообще отказаться в будущем.
> и позволяет jpeg изображения в него конвертировать без потерь
С аж 25% сжатием. Ну охуеть теперь.
> JXL лучше webp и для lossy и для lossless
Ну лучше и лучше, стандарт лучше тот, который широко применяется и имеет максимальную поддержку, это очевидно. С нишевым же адопшеном - это сугубо локаьлное баловство, личную коллекцию пикч с двачей пережать, если сохранюх
Зачем jpeg xl, когда есть avif?
> С аж 25% сжатием. Ну охуеть теперь.
Дело не в процентах, а в том, что это позволяет отказаться от устаревшего формата (jpeg). Если в качестве альтернативы продвигать webp, то jpeg никуда не исчезнет.
>стандарт лучше тот, который широко применяется и имеет максимальную поддержку
Тогда это jpeg и png и не надо никуда переходить? Или все таки надо? И если переходить, то может не стоить менять шило на мыло?
Он только для сжатия с потерями хорош, для lossless он ужасен.
Почему ужасен?
Сравнил дефолтные настройки avif в ffmpeg с -q 6 jpg. Разница 439 против 691 кб в пользу avif, но у него шум, который является частью картинки, замылен. А у джипега деталей больше, хоть и шум сыпится большими квадратами. Но на кодирование avif ушло несоизмеримо больше времени чем на jpg, а ещё я не нашёл ни одну программу кроме ffplay, которой я мог бы его открыть.
mpv, jpegview, xnview
🤗
https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html#08-2011-panthera-tigris-tigris-texas-park-lanzarote-tp041:1&WEBP=s&WEBP2=s&subset1
https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html#08-2011-panthera-tigris-tigris-texas-park-lanzarote-tp041:1&WEBP2=s&JXL=s&subset1
https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html#08-2011-panthera-tigris-tigris-texas-park-lanzarote-tp041:1&WEBP=s&WEBP2=s&subset1
https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html#08-2011-panthera-tigris-tigris-texas-park-lanzarote-tp041:1&WEBP2=s&JXL=s&subset1
>avif
Говно, еще и медленное
https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html#08-2011-panthera-tigris-tigris-texas-park-lanzarote-tp04*1:1&AVIF-AOM=s&JXL=s&subset1
Кто-то выкладывал тут в прошлом году батник https://paste.debian.net/plain/1277842 . Создайте его там же, куда распаковали это https://github.com/libjxl/libjxl/releases и сделайте батнику ярлык, положите ярлык в Windows SendTo и сжимайте в один клик jpg в jxl его киллер фичей без потерь. Смотрим этим:
В шапку не хватает: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html
В шапку не хватает: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html
Да после установки расширения https://apps.microsoft.com/store/detail/av1-video-extension/9MVZQVXJBQ9V?hl=be-by&gl=by все просмотрщики вроде как открывают только полосы какие-то зеленые иногда по краям вылезают.
>Windows SendTo
О, удобно
Зачем вы тащите этот плесневелый кал, когда есть официальная страница тестов у гугла. 🤔
Судя по скорости декодирования - это вообще дефолтные префы, а не максы. Так в максах снижает ~ до 20% +- в сравнении с -8 у флак. Сам проверяй, лучше всего эмбиент. Даже free-dl wav подкину, чтоб потестить https://asurarevolver.bandcamp.com/album/rainforest-hill-i-ii
Пруфы?
Одного zones lua достаточно, лол.
>IrfanView - говнище без возможности поменять хоткеи, отчего скроллить масштабированные изображения можно только клавиатурой но не мышью.
Почему каждый ебаный раз, когда читаешь инфантильное нытьё софтошизов, за ним скрывается тупой мудак, неспособный зайти в настройки?
Сложности с сайтами, как единственный аргумент невозможностью пикчу залить/поделиться - хуйня и не всех задевает неудобствами. Если JXL у анона в первую очередь с целью личной коллекции и лично приобщиться к использованию со всеми фичами экономии/скоростью/етк, а не холиварной массовой поддержкой веба/пиписитарных гуглоподелок-браузеров , то смотреть формат можно в своём уютненьком просмотрщике/редакторе. А если нужно вкинуть онлайн, то копировать пикчу в clipboard и вставить на сайте - всё подтянется в простом формате. Лол, неудобств вы с этим получается избежали. Тогда какие аргументы не перекатиться с вашим архивом фото, если нёрф так легко обойти (за исключением древних веб помоек со старым методом ручной вставки пикчей, возможно мессенджеров, что без веб версий и всяких веб макак). Остальных как это задевает вообще? В том и забава , что один только гугл не видит "потенциал", но на самом деле видит скорее нелепый обсер, что не успев вложиться в потуги авифа, не успев толком вкусить фидбэека в статусе топ1 формат - уже вынуждены признать пук, среньк, уже есть что-то получше, лол.
Лол, даже не знал что список шизов пополнил. Быть может пару лет назад спалил плюсы, дак до сих пор рвутся 🤣
соглы, на винде jxl даже как обои не поставить
Побаловался в Krita. Там давно реализован.
Жмёт хреново. Мало где поддерживается.
Жмёт хреново. Мало где поддерживается.
Жмёт хорошо. Много где поддерживается.
>GIF, который давно пора отправить на свалку истории.
пора
Бамп
Vimeo оказывается все картинки в avif держит 😳
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.
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.
feh откроет?
Какой наиболее качественный на текущий момент инструмент для конвертации и сжатия в jxl?
Пока как просмоторщик использую XnView и у них есть встроенные конвертер насчет которого не уверен.
В треде пчелы активно работают с ffmpeg и imagemagick
Так что прошу рекомендации, какие стоит попробовать и где читать, как с ними работать
Пока как просмоторщик использую XnView и у них есть встроенные конвертер насчет которого не уверен.
В треде пчелы активно работают с ffmpeg и imagemagick
Так что прошу рекомендации, какие стоит попробовать и где читать, как с ними работать
Не поверишь, официальный. Сделай батники по типу этого и всё станет максимально просто. Ни один конвертер не может в перепаковку jpg в jxl без потерь, а это важная фича у сабжа, так-то. Вьюверы да, xnview, jpegview и mpv - лучшие для jxl, во всяком случае пока.
>Сделай батники по типу этого
Мне кажется ты промахнулся.
Ну так новый стандарт - это webp, если так дело пойдёт и дальше. Для любителей огромных паков, это вообще идеальный формат. И размер как у jpg и даже меньше иногда и поддержка прозрачности.
Можно вообще в хуй не дуть и всё в него перегонять не боясь.
>Ну так новый стандарт - это webp
В твоём мирке? Или гугла? Или ты из началов десятых капчуешь. Вебп уже давно доживает и проигрывает всем актуальным, если дескать вообще был в чьих-то глазах живым, лол.
>Для любителей огромных паков, это вообще идеальный формат.
В твоём мирке? Мыло сраное, а не идеальный формат, лол. Этот тред обсуждения сабжа, а не мыльных форматов конца нулевых.
Обязательно в шапку треда ссылку, чтоб больше такой чуши не писали (для приватопердолей: для просмотра сравнений нужен включенный WEBGL и разрешенные workers api): https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html
>в твоём мирке!
>мыло!
>доживает!
По теме то, есть что сказать? 10 лет назад те же вскукареки слышал, какой webp не нужный и плохой, а по итогу и поддержку везде добавили и массово он начал пнг заменять, ибо легче. Да и с жпг нормально справляется.
Сегодня это самый лучший формат, если у тебя тонны пикч которые нужно быстро подогнать под один формат без проёбов. Сожрёт и пнг и жпг и везде залезет без танцев с бубном.
>GIF, который давно пора отправить на свалку истории.
Иди нахуй
Гифки с котиками форевер
>По теме то, есть что сказать?
>https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html
Глаза протри.
Отправляют на свалку формат, а не сами анимации, тугосеря.
Мне похуй
> для просмотра сравнений нужен включенный WEBGL и разрешенные workers api
Угу, спасибо, что предупредил о ботнете.
Так тема треда и есть троян. Встраивать программный код в картинки, ты буквально вирусню качаешь под видом картинок, классический троянский конь, еще и название маскируется под JPEG, всем известный и безопастный. Прям комбо малвари, наебать и пропихнуть вирус.
Знал бы ты как SVG работает, вообще бы комп включать побоялся.
То есть, про ЖПЕГ ТРОЯН прокомментировать нечего, так и знал что во всём прав.
Таблетки прими, а то шутки про уязвимые картинки уже доебали.
Там троян на уровне шрифтов true type. То есть запускается в своей винтуалке по стандарту. Если кто-то и додумается запихнуть туда код, он сработает только внутри картинки и хуй вылезет дальше.
Максимум скример сделает из картинки, что конечно смешно но троянить что-то из файлов пикча не сможет.
Этому треду требуется бамп.
А что, идея здравая. Компрессия на уровне операционной системы это тема.
>операционной
Файловой, имеется в виду.
Что это значит?
Ну это не трудно, можно самому модуль сделать и перехватывать запись/чтение всех жпегов. Только может что-нибудь отвалится
Это значит, что ты пидор файлы занимают на диске меньше физического пространства, чем их фактический размер
Как это относится к jxl?
>Кто-то выкладывал тут в прошлом году батник
Что-то он у меня перестает работать при превышении какого-то определенного количества выделенных файлов - окно cmd моргнет просто на 10 мс и все. Пока не смог понять закономерность, т.к. в одном случае работает со 129-ю файлами, а со 130-ю уже не хочет, а в другом - со 150-ю все ок, а со 151-м уже нет.
Может, есть какие-то лимиты на кол-во аргументов для батников или что-то около того?
Исполни его из cmd, а не мышкой и покажи что он выдаст. Может какой анон исправит.
Короче, погуглил и думаю, причина в этом
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 символ, то все работает. Хз так же на десятке или нет.
тред мельком посмотрел, вроде не поднималось такого вопроса
дано: папка с jpg, png, gif огромного размера (15к+ файлов). надо: одной комадной затранскодить в jpg, на ляликсе
дано: папка с jpg, png, gif огромного размера (15к+ файлов). надо: одной комадной затранскодить в jpg, на ляликсе
>затранскодить в jpg
jpegxl, конечно же
быстрофикс
https://github.com/sharkdp/fd
fd -e png -e jpg -e jpeg -e gif -x cjxl <opts> {} {.}.jxl
По умолчанию запускает параллельно по количеству ядер, можно ограничить с помощью -j <N>.
Тебе тоже пригодится, с fd нет ограничения по количеству аргументов.
>Тебе тоже пригодится, с fd нет ограничения по количеству аргументов.
Спасибо, конечно, но я не совсем понимаю, как fd можно применить, если в условной папке нужно переконвертить некоторое большое кол-во пикч, кот. я могу выделить вручную, но не все из них. В варианте с понятно: выделил нужные - отправил в батник (и только 8191-лимит тут поднасрал). А с fd как быть?
Понятно, тебе не подойдет fd.
Подозреваю, что с выделением в проводнике любой скрипт или консольная программа будет натыкаться на ограничение длины аргументов.
В терминале можно было бы что-нибудь соорудить с выделением файлов с помощью какого-нибудь fzf и записи их во временный файл, потом для каждой строки в нем запускать cjxl.
У меня есть каталог с 10к файлов cjxl
Как я могу их пролистать?
Ирфан открывает их исключительно пофайлово, а при попытке листать предлагает перейти в следующую папку.
ОС - винда.
Как я могу их пролистать?
Ирфан открывает их исключительно пофайлово, а при попытке листать предлагает перейти в следующую папку.
ОС - винда.
>Как я могу их пролистать?
Ты имеешь ввиду листание "колесиком" или "через пробел"?
Накидал 12к мелких jxl в папку и у меня все нормально листает и миниатюры через T работают. Хз, обнови ирфан.
Нашёл причину своих страданий. Я при конвертации присваивал расширение cjxl
Большое спасибо тебе, добра. А то я уже начал ебаться с AHK, чтобы рекурсивно по PageDown каждый раз новое окно ирфана вызывать.
Нужен совет по конвертации
Есть несколько папок в пнг
Перегон в jxl loseless съэкономит место или наоборот?
Есть несколько папок в пнг
Перегон в jxl loseless съэкономит место или наоборот?
Сэкономит.
Неоптимизированные пнг сжимаются на 40-50%.
Для изображений преимущественно с текстом, то есть для скриншотов приложений без картинок, lossless webp cwebp -z 9 нередко сжимает лучше, чем jxl, и при этом быстрее. На всякий случай, webp не поддерживает больше 8-бит и молча конвертирует в 8 бит с потерями.
Если ты пользуешься cjxl и тебе важна дата модификации файлов, на никсах можно восстановить ее с помощью touch -cr file.png file.jxl.
> lossless webp cwebp -z 9 нередко сжимает лучше, чем jxl, и при этом быстрее
Крутяк, как раз хотел свою коллекцию скриншотов перекодировать в лузлесс webp, благо макака завезла наконец поддержку.
Мимо
Хм, почему при попытке конверта пик1 с дефолтными настройками получается пик2 с поехавшей гаммой?
>lossless webp
>молча конвертирует в 8 бит с потерями
Ебало lossless представили?
Так даже лучше
Похуй, тебе все равно не светит
Хочу тяночку
Н
Е
В
З
Л
Е
Т
И
Т
Запомните этот твит.
Нормально без возьни смотреть такие картинки на Линухе можно только в браузере PaleMoon? Со стандартными настройками без всяких экспериментальных флагов и прочей фигни.
Из браузеров еще Thorium.
Из остального софта много что поддерживает. Весь кутешный и гткшный софт должен поддерживать, если поставить нужные плагины.
Уже взлетело, эпл впилили в последний сафари, а остальные как все мы знаем, повторяют за эпл
Хуело.
Абу поддержку .webp впилил буквально лет через 10 после того, как оно «взлетело».
>Абу
Кто-то важный наверное)
Кто-то важный наверное)
Да не, так, хуёк. Буду пересылать всем неподдерживаемый формат, убеждая «ну чё вы, пацаны, эпол же уже одобрил, пользуйтесь! Нужно всего лишь скачать специальное приложение с его поддержкой, скачивать файлы и открывать в нём, ну. Удобно же!».
Ты даже не заметишь переход, ебанашка, если не будешь одним из этих фриков треда, которые сами все конвертируют. Просто сиди дрочи дальше на картинки в интернете и не забивай голову
> Ты даже не заметишь переход
>В самом конце есть список софта:
GIMP и Krita это всё-таки не программы для просмотра фоток. Признаем очевидное, что в большинстве дистрибутивов Linux нет самого новейшего Ffmpeg, в котором добавлена поддержка этого формата для кодирования и декодирования. XnView поддерживает просмотр этого формата только на винде. Не зачет.
>Весь кутешный и гткшный софт должен поддерживать, если поставить нужные плагины.
Интересно... вот у меня в среде рабочего стола родной просмотрщик фоток это Xviewer. Где плагин найти?
https://github.com/linuxmint/xviewer/issues/162
Для дебиана libjxl-gdk-pixbuf я беру отсюда:
https://artifacts.lucaversari.it/info.txt
Для freebsd я вижу нужную so'шку в списке тут:
https://www.freshports.org/graphics/libjxl
> GIMP и Krita это всё-таки не программы для просмотра фоток.
Ты видимо пропустил строчку со списком просмотрщиков изображений и прочим после иконок.
> Также есть несколько относительно свежих форматов изображений, которые являются побочным продуктом, полученным при разработки видеокодеков. К примеру HEIС (HEIF) который так любит Apple происходит из видеокодека HEVC. Та же история с форматами WebP и AVIF, которые произошли из VP9 (VP8) и AV1 соответственно.
> Но так как эти кодировщики делались изначально для видео, они концептуально не настолько эффективны для хранения изображений.
Зато есть аппаратное декодирование.
А оно вообще используется для декодирования изображений?
> мазня с энтропией уровня хлебушка
> 4000х4000
> 15Мб
Формат будущего прост, моё почтение.
Судя по тому как ты пишешь, ты явно умный парниша и разбираешься в теме, до тебя должно быть сразу дошло, что картинка сжата в лосслесс режиме.
Можешь порекомендовать лосслесс формат, который сожмет значительно лучше?
>лосслесс формат, который сожмет значительно лучше?
bmp в архиве, и это не шутка: http://qlic.altervista.org/
Серьёзно, лослесс сжатие - это идея из 80х. Со времён арифметического кодирования там ничего принципиально не меняется. Что звук, что изображение устаканились в нулевых и сейчас ты можешь только сжигать терафлопсы ради призрачной прибавки в 5-10%.
А вот лосси - это действительно вызов. Поиск избыточности, модель восприятия, психоакустика, разные способы оценки, генеративные модели. Вот где жизнь бьёт ключом и останавливаться не собирается. Лосси в эти твои 15Мб целый артбук упаковать может, а ты разницы и не увидишь.
> bmp в архиве, и это не шутка: http://qlic.altervista.org/
zpaq действительно сжал лучше, но всего лишь на 5% по сравнению с jxl.
Для gralic и bmf я не нашел исходный код, paq8px и cmix слишком медленные, судя по твоей ссылке.
И ничего из этого не поддерживается обычным софтом.
> ради призрачной прибавки в 5-10%.
На подобных картинках скорее 20-30% по сравнению с оптимизированным png.
> А вот лосси - это действительно вызов.
И какие у тебя претензии к lossy jxl?
Если там сжатие такое же как в видеокодеках то по идее может, как на самом деле - не знаю. Но жпег устарел и сильно.
Критическая уязвимость сразу во всех браузерах Аноним (Linux: Firefox based) 15/09/23 Птн 00:06:02 #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
Что с ебалом, шлюхи гугловские? Не зря поддержку вашего кала отовсюду выпиливал!
Суть уязвимости в переполнении буфера, которая позволяет злоумышленнику подготовить специальное WebP изображение, при открытии которого на машине пользователя выполнится код. Google не раскрывает подробности механизма эксплуатации уязвимости, но утверждает, что в сети уже доступны рабочие эксплоиты, основанные на ней.
https://www.linux.org.ru/news/security/17351631
Что с ебалом, шлюхи гугловские? Не зря поддержку вашего кала отовсюду выпиливал!
Скажу тебе по секрету, такие CVE есть для PNG\JPEG-JPG-JPEG2000\TIFF\BMP\GIF\PSD. Все графические файлы имеют проблемы с библиотеками или исполнителями. И что теперь, всю графику резать? Нет, просто используй вылеченное.
Скажу тебе по секрету, такого пиздеца нет нигде, когда никому больше не нужное проприетарное картинкоговно от гугла оказывается дырявое, и в результате всё на свете оказывается дырявым, начиная с браузеров и заканчивая всевозможным софтом, и даже не софтом, а библиотеками вшитыми в систему как webview. Всё потому, что все сидят на игле монополиста с гуглозондом в жопе. Итоги блять.
У mp3 тоже есть проблема с интеграцией тега и возможностью поднять права программного плеера. Четверть века прошло, никто не орет особо, mp3 везде.
Вы крикуны обычные, разделяйте данные, которыми можно делиться и данные, которые private\own, и не давайте данным вылазить в СЕТЬ. Подцепил сеть к гаджету - твои данные не твои, а СЕТИ, иного не дано.
У mp3 нет проблем, потому что это не гуглозонд от одного производителя впердоленный везде где надо и не надо, просто патамушта, чтобы бэкдоры гугла были во всём.
mp3 реализуется разными библиотеками от разных разработчиков, и в большинстве софта вообще не встроено. Если даже в одной какой-то библиотеке есть уязвимость, это капля в море, вообще не проблема.
А гуглопараша одна на весь мир, и встроена во всё на свете, все под гуглодырами. И как только дыру опубликовали, любой васян уже может ломать всё на свете. Какая красота. Спасибо монополии, гулагу барина гугла, хозяина интернета и всего софта во всём мире.
> это не гуглозонд
Чел, пойми. У тебя проблема с расставлением границы между нашим, твоим и общим. Если ты не желаешь полного деанона и взлома всего и вся - сиди оффлайн или в тайгу беги.
Или учись и повышай шкиллы защиты, сиди за аппаратным файером на фряхе, и изучай каждый пук нотиков и алерты этого файрлола. Просто сейчас ты смешон очень, ты предельно параноидален, ты даже не понимаешь, что компы придумывали как сетевые клиенты для сервака, и ко всему, что в них есть, можно механистически получить доступ, и это ВПОЛНЕ НОРМАЛЬНАЯ СИТУАЦИЯ, это же парадигма компа такая. И в мобильных осях также, ты доверяешь гуглу все свои данные, или эплл свои данные, и так далее. И когда ты начинаешь параноить и ныть, это вызывает непонимание. Ты похож на ребенка, который ест говно из подгузника, мажет его везде в хате и орет, что невкусно. Ты или вырастай и умней, или прекращай пользоваться ВСЕМ софтом, потому что он ВЕСЬ имеет ошибки, и 1% из этих ошибок позволяет получать права на доступ к твоим данным.
Всё, можешь не ррякать мне в ответ, просто прочитай и осмысли.
Не сри дебил.
- Гуглодыры везде, потому что гугл охуел и везде.
- И это не теоретические дыры на словах, а реальные дыры исполнения кода от любой картинки в интернете.
- Картинки это не шутки, картинки везде. Дыра в картинках, это значит ты подключился в интернету и всё, пизда тебе, это даже хуже чем WannaCry.
- Толще дыры нельзя придумать, и она везде, в любом софте использующем интернет, на любой платформе, потому что мистер гугл везде, вместе со своими дырами.
>ВПОЛНЕ НОРМАЛЬНАЯ СИТУАЦИЯ
Не сри тупостью, дебил.
Ты качал, тебя ломали...
ГУГЛАГ ВПЕРДЕ, ВСЕМ КРЫШ!
Кодь сам, или слабачок-дурачок?
>Для дебиана libjxl-gdk-pixbuf я беру отсюда:
https://artifacts.lucaversari.it/info.txt
Так это сами библиотеки и кодировщик.
Это я просто установил всё одной командой?
apt install libjxl-tools
Но это не заставит GTK-программы просмотра фото поддерживать формат JPEG-XL. Вот установка jxl-pixbuf-loader должны это сделать в теории. Только под всякие Ubuntu его пока нет готового собранного. Для Федорки есть. Может там более модная версия GTK нужна х.з.
>Тут тоже есть внутри тар архивов:
Скачал архив jxl-debs-amd64-ubuntu-22.04-v0.8.1.tar.gz и там нет
>jxl-pixbuf-loader
Там есть libjxl-gdk-pixbuf, он и нужен.
Там же в этих браузерах песочница в песочнице песком песочит. Да так, что элементарные действия лагают как по времен пенька. Неужели всё это не помогает?
Ты не понимаешь, что значит беды с башкой
What are we fighting for, brah Аноним (Microsoft Windows 10: Firefox based) 30/09/23 Суб 05:52:08 #291 №3364040
Ну вот
Ради чего, блять
test1 - cjxl - офф конвертер - качество то же, размер с мб ушел в 333 кб
test2 - libvips - мультиконвертер с поддержкой - качество сжалось чутка, размер ушел с 1 мб в 96 кб
вот и сиди теперь
Я буду конверитить оффициалом потому что качество нужно, но это какая-то шляпа
Ради чего, блять
test1 - cjxl - офф конвертер - качество то же, размер с мб ушел в 333 кб
test2 - libvips - мультиконвертер с поддержкой - качество сжалось чутка, размер ушел с 1 мб в 96 кб
вот и сиди теперь
Я буду конверитить оффициалом потому что качество нужно, но это какая-то шляпа
А указать параметры сжатия в libvips нельзя?
Да, можно, Я просто пока предпочитаю оффициал в любом случае пока
Компрессор для жпегов, примерно как jxl lossless transcode, но быстрее при той же или слегка лучшей степени сжатия:
https://github.com/microsoft/lepton_jpeg_rust
https://github.com/microsoft/lepton_jpeg_rust
Оно лучше mozjpeg?
Сжимает лучше, но lepton это для архивации, ты не откроешь его ни в каком просмотрщике изображений, редакторе или браузере.
>но lepton это для архивации, ты не откроешь его ни в каком просмотрщике изображений, редакторе или браузере
Получается хуита без задач.
Не согласен
На серверах картинкохранилищах вроде какого-нибудь imgur можно хранить архивированные (старые) фоточки и разархивировать их на лету по запросу пользователя
Конечно, в мире победившего jxl такой нужды не будет, так как у всех будут декодировщики в браузерах, но пока что имеем что имеем
>На серверах картинкохранилищах вроде какого-нибудь imgur можно хранить архивированные (старые) фоточки и разархивировать их на лету по запросу пользователя
Это и есть та единственная задача, которая им решается. Спектр применения слушком узок, и даже для решения той задачи для которой он создан существуют альтернативы, пусть возможно для конкретной ситуации подходящие немного хуже, но более гибкие по своей сути.
>imgur
Наверняка старые пикчи, которые ты предлагаешь архивировать, имеют нулевой трафик. Если цель - сэкономить место в датацентрах, то тот самый заблудший, случайно открывший страницу, наверняка сможет и подождать пару секунд пока его запрос сначала по всем кешам промахнется, а потом и картинка декодируется наилучшим кодеком. Ну тут впрочем без знания того как там все устроено можно только лишь прикидывать и гадать.
Samsung добавила в прилажку камеры на своих смарфонах поддержку JXL
https://r2.community.samsung.com/t5/CamCyclopedia/Introducing-the-Galaxy-S24-Camera-Gallery/ba-p/15350511
https://r2.community.samsung.com/t5/CamCyclopedia/Introducing-the-Galaxy-S24-Camera-Gallery/ba-p/15350511
Шакалит. Особенно градиенты. Шакалит цветопередачу. Вызывает бандинг вследствие урезания и так урезаного yuv до tv диапазона. Добавляет ложные границы на градиентах в виде горизонтальных или вертикальных прямых линий, в следствие работы механизма внутрикадрового предсказания.
В виндовсе возможно будет поддержка jxl из коробки:
https://nitter.cz/jonsneyers/status/1751453002299552202#m
https://nitter.cz/jonsneyers/status/1751453002299552202#m
Нахуя все это ебаное говно и дерьмо типа дерьма webp нужно, если есть православный жпег, нахуя утырки из пугла пытаются уже картинки под себя подмять? Основная нагрузка на каналы современных шизоронетов идет в виде видеотрафа, на картинки всем похуй сколько они там весят - на мобилах и десктопах уже терабайтные стораджи. Я не луддит, более того я наносек, но за этим говном нет ничего кроме скрытого стремления отдельных копрораций и купленных ими комитетов по стандартизации к технологической монополизации.
Только при существенном аппаратном прогрессе средств записи/генерации и отображения пикч потребуется новый формат, вместо эволюционно-зрелого устоявшегося жпега на котором запечатлена уже вся цифровая история человечества. Вот когда у каждого быдла в айфоне 55 ProHyperMaxKekus будет 1024-битный голографический проектор и 3D-голосканер, вот тогда и приходите.
О Боги, неужели я встретил на сраче хоть одно адекватное мнение относительно этого уебищного энкодера.
> если есть православный
heic, поправил тебя.
> Только при существенном аппаратном прогрессе средств записи/генерации и отображения пикч потребуется новый формат
> альфа канал
> православный жпег
Ну как бы знаешь, картинки это не только фоточки. И если лично тебе не нужно, то это не значит что никому не нужно.
Да и хранить или передавать фотографические изображения на которых в фотошопе навесили альфа канал в том же PNG как то непрактично. А webp позволяет хоть криво косо, но пожать такое в lossy. И хотя в вебе это уже не так актуально, хотя-бы из-за наличия формата AVIF, но платформы такие как телега, дискорд и тот же двач поддержали только webp.
> heic, поправил тебя.
Как то странно такое слышать от
> (Microsoft Windows 10: Chromium based)
Датасеты, занимающие десятки терабайт памяти, с тобой не согласны.
>православный жпег
Вся православность жипега в том что ты привык к его артефактам. Как привык к артефактам плёночного кино, винила, vhs и mp3. Настолько привык, что это стало частью эстетики. Что люди осознанно имитируют эти артефакты.
Привыкнешь со временим и к эстетике эпохи webp/heic с его мылом и дорисованными нейросетевыми тентаклями.
Кстати, об артефактах, jxl намного лучше справляется с текстом.
С дефолтным -d 1 / -q 90 есть небольшие изменения цвета, но нет артефактов вокруг букв как у жпега.
> Как то странно такое слышать от
> (Microsoft Windows 10: Chromium based)
В 11-ой HEIC из коробки.
ненавижу ебаную вебрепу ака швабп
сука его ни один нормальный хуессенджер вроде дуровсрама и другого говнища не жрет искаропки и прикрепят в виде файлика,
шиндус при печате портит цвета и делает их тусклыми, я буду рад когда его добьет хуефф ака эпплоговнище и авиф который недовидеоформат статичный
> буду рад когда его добьет хуефф ака эпплоговнище и авиф который недовидеоформат статичный
Из этих двух я бы выбрал AVIF. Но тут как раз JPEG XL метит в
> эпплоговнище
А хуефф, по-твоему, это не недовидеоформат?
это какой-то ебаный раржипег, шиндусом нормально не просматривается, а внутри в одном файле может еще что-то лежать, но посмотрети вы можете только на дорогущем оверпрайснутом говнофоне, ну или установив хакинтош...
в общем какая-то ересь, благо хоть частично в шиндусе работает
Речь о том, что webp, avif, heif все основаны на видеокодеках, vp8, av1 и h265 соответственно., то есть они все "недовидеоформаты".
> посмотрети вы можете только на дорогущем
В бесплатном линуксе тоже можно.
>В бесплатном линуксе тоже можно.
А в бесплатной шинде что, нельзя?
>Речь о том, что webp, avif, heif все основаны на видеокодеках, vp8, av1 и h265 соответственно., то есть они все "недовидеоформаты".
Но это им не мешает более качественно показывать рисованные картинки, а не фотографии. В отличие от этого вашего Jpeg_Xl. Со стандартными параметрами конвертации. А то сторонники jpeg-xl любят рассказывать про особенности конвертации и ключи всякие для своего этого кодека чтобы правильно картинку конвертировать. У webp и avif это получается лучше для картинок при конвертации со стандартными параметрами.
> А то сторонники jpeg-xl любят рассказывать про особенности конвертации и ключи всякие для своего этого кодека чтобы правильно картинку конвертировать.
Не нашел такого в этом треде например.
> У webp и avif это получается лучше для картинок при конвертации со стандартными параметрами.
Может быть, но где данные подтверждающие это?
> А то сторонники jpeg-xl любят рассказывать про особенности конвертации и ключи всякие для своего этого кодека чтобы правильно картинку конвертировать.
Ты наверно живешь в какой-то параллельной реальности. Это для avifenc нужны параметры, для включения 10-ти битного режима, для включения адаптивного квантования, задать границы минимального, максимального и среднего квантования.
В то время как для jpeg-xl я мог бы обойтись именем входного и выходного файла. Я как то пробовал прогонять картинку через https://github.com/Blobfolio/refract, точнее несколько картинок, и -d 1 очень сложно отличить от оригинала, даже на тёмных участках. Бывало даже такое, что получалось сжать даже сильнее. А для avifenc и тем более webp приходилось завышать уровень качества. И webp в ряде случаев слишком сильно режет качество есть параметр качества там меньше 95.
В новой 0.10 версии добавили streaming сжатие, теперь энкодер стал быстрее и требует намного меньше ОЗУ.
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
Бамп.
Тут уже 300 постов насрали и думаю, что высказали такое мнение, но я всеравно досру сверху.
Эта хуйня НИНУЖНА!
Просто потому, что сейчас диски измеряются терабайтами, даже если ты хранишь кучу картинок, которые весят 10 МБ каждая, то на терабайт тебе придется 100 000 картинок.
Если ты в день будешь использовать 50 картинок, то у тебя уйдет больше 5 лет чтоб все их хоть раз открыть. Это дохуя.
У людей нет проблем с местом. Это только у всяких контор есть проблема с местом - вот щас много порногифок в виде webp представлено, чтоб экономить место на серверах, и это меня дохуя раздражает.
Эти новые форматы картинок - попытка решить проблему, которой нет. Разве что только каким-то супер узким специалистам, которые обрабатывают дохуища свадебных фотографий.
Вот видео - другое дело. Иметь возможность на двоще выкладывать 10 мб видео, которое в 4к и 60фпс длится десять минут - вот это заебись технология.
Второе:
Неудобно. Вот я чтоб найти анимированый пикрилейтед написал в гугле explanation meme gif
И я уже в результатах вижу где анимировано, а где нет. Я не тратя время уже знаю куда нажимать.
Потому что гиф уже ассоциируется с анимацией. Если все будет храниться в одном формате то придется дольше искать. То же самое с пнг. Если я пишу nasa logo png то с 90% вероятностью будет искать с альфаканалом уже вырезаное лого. Как мне блять искать это в jpgxxl ???
Перегонять из формата в формат и назад - вообще дебильная задача. Кому это нужно?
Короче, пока толку никакого, одни проблемы с совместимостью и срач среди вендоров.
Вердикт - пускай лучше для видео форматы придумывают, а тут нехуй ломать то. что не сломано.
ух как скрепно, двачую. да и интернет ентот ваш вообще нинужен, все можно в телевизоре посмотреть.
Пукать ты знатно умеешь, а конкретно по какому-то пункту есть возражения с аргументами? Нет? Ну так иди дальше попукивай - можешь свисток в дупу себе вставить, чтоб веселее было.
Первый пункт разъёбывается тем, что сегодня с изображениями пользователь взаимодействует в основном через интернет. И если ты не заметил, сайты зачастую неплохо их так шакалят для того, чтобы у пользователей с медленным прдключением был удовлетворительный пользовательский опыт.
А JXL убивает одновременно улучшает пользовательский опыт двумя фичами: прогрессивным декодированием и лучшим соотношением размера к качеству.
Картинкохранитель, пора вылезти из морозилки, эпоха интернета наступила
JXL убивает двух зайцев и одновременно улучшает
медленнофикс
>удовлетворительный пользовательский опыт.
Рекламой надо меньше засирать сайты, а не жать картинки.
Твой аргумент не валиден, потому что если картинка ненужная - типа шапка новости, то она может быть пожата - всем похуй. Если же человек идет именно скачать какую-то конкретную картинку, то он может и подождать чуток, но получить качественное изображение.
Давно пора бы понять простую истину. Высеры корпорации гугла нужны только корпорации и её сотрудникам, остальным оно не только не нужно, но и активно вредит, потому что интересы корпораций всегда идут против интересов людей. Такой сегодня мир, пора бы уже выглянуть в окно на реальность.
>интересы корпораций всегда идут против интересов людей
Вы только посмотрите на этого марксиста!
>https://huggingface.co/datasets/nyanko7/danbooru2023
>total size is now approximately 8 terabytes (8,000 GB)
Анон, ты долбоеб. Чтобы например хуйню по ссылке ворочать, нужно как минимум 20 ТБ памяти просто чтобы это всё нахуй работало.
Это мне нужно ворочать или кому? Мне нах не всралось хранить 8 гб какой-то параши. И тебе нах не всралось. Для личного пользования это никому нах не всралось. Это нужно только тем, кто арендует сервера и трафик, то есть уже не для домашнего пользованя.
Даже еслилично тебе нужно хранить все это говно, то тебе все равно нужно бует отдельное хранилище, потмоу что если это 8 т пожать вдвое то все равно будет 4 т.
Смотрим цены - примерно 200 баксов за 8 т
Ок, 4 т ты купишь за 100. Итого этот всратый формат позволит тебе сэкономить сто баксов. Оно того стоит? Сто баксов это сейчас копейки, если ты не бомж или не школьник, который на обедах экономит. Тем более что эти 100 баксов ты растягиваешь на долгие годы использования. Ты можешь пользоваться этим винтом 10 лет тогда выходит по 10 баксов в год. Это 80 центов в месяц. По текущему курсу - 70 рублей.
То есть у тебя выбор - платить 70 рублей в месяц и вообще не заморачиваться. Просто без задней мысли юзать джипеги и пнг. Открывать пеинтом за секунду, вносить правки, и тут же сохранять. Отправлять в любом мессенджере и иметь предпросмотр адекватный.
Или пердолиться с конвертациями-хуйвертациями и с софтом, который поддерживает это. Иметь проблемы с открытием где-то не на твоем ПуКа и прочие красноглазые прелести.
Ответ очевиден.
Двачую адеквата. Все убийцы популярных форматов погорели именно на этом, даже обладая объективно лучшими характеристиками.
>потмоу что если это 8 т пожать вдвое то все равно будет 4 т.
Нихуя себе, в 2 раза меньше затраты на хранилище это хуйня? А ведь может оказаться что сжимать ровно в два раза и не обязательно, потому что можно сжать сильнее и с потерями, ведь качество каждой отдельной пикчи не обязательно должно быть идеальным.
Какой же ты нахуй невыносимый дегенерат, чтобы эту хуйню ворочать нужна в первую очередь ПРОИЗВОДИТЕЛЬНОСТЬ, рандомного чтения и рандомной записи, ебанат с экономфака. Твои скрипящие-пердящие свистелки упали разве что тем самым школьникам-бомжам, которые на обедах экономят и которые готовы ждать пока у них 100к файлов скопируются пока их математичка с физруком ебут сначала в шкалке а потом в продленке. Но ты всё-таки ради эксперимента прикинь хуй к носу и разузнай, в какую копеечку обойдется хотя бы 20 ТБ с приемлимой производительностью, учитывая, что это самый минимум, и нужно ещё обеспечить избыточность чтобы не проебать драгоценные данные, и собственно нужно пространство, чтобы иметь возможность хранить например модифицированные копии или более маленькие, отфильтрованные подмножества этого датасета. А потом вспомни что такое альтернативные издержки и объясни мне почему так делать экономически невыгодно, если есть возможность купить в 2 раза меньше сидюков и докинуть две б/у 3090 сверху.
>Даже еслилично тебе
Конкретно ТЫ этим не занимаешься потому что ты ТУПОЙ и это ДОРОГО или ДОЛГО. Согласен, что стоимость хранилищ - не главная проблема при тренировки нейросеток на данный момент, но это тем не менее одна из самых важных проблем.
>тренировки нейросеток
Да, каждый второй дома на 20 терабайтах тренгирует нейросетки. Без этого сегодня обычному юзеру никах. Ты просто пукнутое животное.
Если бы ты мог, ты бы тоже попробовал, кек.
> почти полнота по тьюрингу
ну все, пошел писать эксплойт на уровне ядра, который будет через баг с состоянием гонки писать в кернелспейс
мало вам было взлома айфона через ебучий pdf, да?
Еще один клоун. Жду эксплоита от тебя.
Летит "to the moon" или в канаву?
А как же патчить kde под freebsd?
> А как же патчить kde под freebsd?
> Microsoft Windows 10: Chromium based
Знатоки форматов, прошу вашей помощи. Вот тут есть порно-гифка.
Она работает в браузере. Если ее сохранить и открыть в браузере, то тоже работает. А на компьютере не проигрывается анимация. Попытки сохранить в анимированый вебп а потом обратно преобразовать в гиф не помогло - все равно не проигрывается. Пишет что неизвестный формат или битый фал. Но файл не битый и формат гиф.
Как сделать так чтоб проигрывалось?
https://porngipfy.com/nia-nacci-4-51725/
Она работает в браузере. Если ее сохранить и открыть в браузере, то тоже работает. А на компьютере не проигрывается анимация. Попытки сохранить в анимированый вебп а потом обратно преобразовать в гиф не помогло - все равно не проигрывается. Пишет что неизвестный формат или битый фал. Но файл не битый и формат гиф.
Как сделать так чтоб проигрывалось?
https://porngipfy.com/nia-nacci-4-51725/
>пук
>срёньк
Совершенно обычный GIF-файл, 2322056 байт, не обрезан, не испорчен, нормально импортируется в редактор и показывается. Обратись к разработчику программы, которой пользуешься для просмотра картинок, либо поставь другую, нормальную.
>Она работает в браузере. Если ее сохранить и открыть в браузере, то тоже работает. А на компьютере не проигрывается анимация.
УМВР. Открыл в XnView MP и в Xviewer. Всё нормально.
Скачай нормальную прогу для просмотра фоток себе и не парь мозги людям.
Теперь рилейтед поддерживает сабж форматы. Единственный барьер не быть лучшим вьювером с собственным ФМ кажется уже преодолен, вместо прошлого громоздкого пика на кутэ. Вьюверы без своих собтвенных ФМ в счет не беру, кому-то и такого достаточно, их не сравниваю.
Из распространённых форматов на сегодняшний день мы имеем старый добрый 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/
Там все нужные ссылки, картинки и более подробное объяснение всего.