528 Кб, 1000x1000JPEG 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/
Там все нужные ссылки, картинки и более подробное объяснение всего.
Из распространённых форматов на сегодняшний день мы имеем старый добрый 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/
Там все нужные ссылки, картинки и более подробное объяснение всего.
Референсный энкодер, декодер и транскодер для тех, кто хочет поиграться с форматом.
https://github.com/libjxl/libjxl
ImageMagick тоже поддерживает JXL, но когда я в последний раз его тыкал, он это делал хреново. Возможно сейчас уже лучше.
https://github.com/libjxl/libjxl
ImageMagick тоже поддерживает JXL, но когда я в последний раз его тыкал, он это делал хреново. Возможно сейчас уже лучше.
>>213710 (OP)
Время вирусни в картинках.
> - Почти полнота по Тьюрингу (если бы не ограничения на максимальный размер обрабатываемых пикселей). Это позволит почти бесконечно оптимизировать формат. Пикрил в формате JPEG XL весит всего 117 байтов! И по факту является программой по его генерации, написанной вручную.
Время вирусни в картинках.
>>213719
Да, это теоретически может быть проблемой при использовании кривых декодеров.
Но в целом предпосылок не должно быть. Коммент с HackerNews:
https://news.ycombinator.com/item?id=27577447
Да, это теоретически может быть проблемой при использовании кривых декодеров.
Но в целом предпосылок не должно быть. Коммент с 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).
>>213723 (Del)
У меня пока нет потребности в свободном месте, да и галерея не такая большая. Торопиться не надо. Но когда появится повсеместная поддержка, то почему нет?
У меня пока нет потребности в свободном месте, да и галерея не такая большая. Торопиться не надо. Но когда появится повсеместная поддержка, то почему нет?
>>213710 (OP)
mpv, который работает везде, тоже открывает jpeg xl.
> - Свободный формат, а это значит, что его может использовать кто и как угодно. Его уже можно активировать в Chrome, если включить флаг enable-jxl, и в ночных сборках Firefox. Также его поддержка уже добавлена в Gnome. Для винды тоже есть вьюеры. Про Plasma вообще без понятия (скорее всего тоже есть).
mpv, который работает везде, тоже открывает jpeg xl.
Generation loss у разных форматов:
https://youtu.be/w7UDJUCMTng
Сравнение прогрессивного декодирования:
https://youtu.be/inQxEBn831w
На канале ещё много подобных видосов.
Но они относительно старые, по идее, сейчас кодировщик и декодировщик могли стать ещё лучше.
https://youtu.be/w7UDJUCMTng
Сравнение прогрессивного декодирования:
https://youtu.be/inQxEBn831w
На канале ещё много подобных видосов.
Но они относительно старые, по идее, сейчас кодировщик и декодировщик могли стать ещё лучше.
>>213738
Если собрать стабильную версию со свежим ffmpeg'ом, то должно открывать, но я не пробовал.
Если собрать стабильную версию со свежим ffmpeg'ом, то должно открывать, но я не пробовал.
14 Кб, 225x225>>213710 (OP)
Это называется контейнер. И пошли они в пень. Знать о формате изображения только на этапе декодирования - удобно только для "листальщиков картинок".
Это называется контейнер. И пошли они в пень. Знать о формате изображения только на этапе декодирования - удобно только для "листальщиков картинок".
>>213745
Кто контейнер?
Кто контейнер?
>>213710 (OP)
Когда будет поддержка в HoneyView, XnView Cassic или хотя бы в FastStone, то можно пользоваться.
Когда будет поддержка в HoneyView, XnView Cassic или хотя бы в FastStone, то можно пользоваться.
>>213710 (OP)
И как тогда различать пережатые картинки от непережатых? Никак? Нахуй следуйте.
Круто, теперь вирусы/майнеры в картинках. Нахуй следуйте.
>Он одновременно может заменить JPEG, в случаях сжатия с потерями (например фотки), PNG, в случаях сжатия без потерь (скриншоты)
И как тогда различать пережатые картинки от непережатых? Никак? Нахуй следуйте.
>Почти полнота по Тьюрингу
>картинка по факту является программой
Круто, теперь вирусы/майнеры в картинках. Нахуй следуйте.
> Сжимает на 60% лучше, чем JPEG
А по сравнению с вебп?
>>213710 (OP)
Помнится, когда появился jfif, тоже было визгу. И где оно теперь?
Помнится, когда появился jfif, тоже было визгу. И где оно теперь?
Короче, нинужно.
>>217393
Ну, удачного полёта. Может, и до меня долетит. А я капризный.
Ну, удачного полёта. Может, и до меня долетит. А я капризный.
>Пикрил в формате JPEG XL весит всего 117 байтов! И по факту является программой по его генерации
Ждем когда вместо любого хайрез изображения будет промпт для генерации на аппаратно реализованном Stable Diffusion.
НИНУЖНО, ибо в png анимацию завезут
https://www.opennet.ru/opennews/art.shtml?num=57977
https://www.opennet.ru/opennews/art.shtml?num=57977
>>218687
Это, кстати, хорошее ожидание. Появление аппаратной реализации dpi-независмой модели Continuous Image Representation существенно перезапустит взгляды и на сжатие, и на рендер.
Это, кстати, хорошее ожидание. Появление аппаратной реализации dpi-независмой модели Continuous Image Representation существенно перезапустит взгляды и на сжатие, и на рендер.
https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL
Они убили jxl, сволочи!
Они убили jxl, сволочи!
>>220573
Вот так оно иметь монополиста. А кто-то за него ещё и бесплатно топит прямо на этой доске.
Вот так оно иметь монополиста. А кто-то за него ещё и бесплатно топит прямо на этой доске.
Гуглохрому и мобилкам нужно просто перестать поддерживать жипег для того, чтобы сдвинуть дело с мёртвой точки
>>220573
Google и Apple похоже решили сделать AVIF дефолтным next-gen форматом для изображений.
IOS 16 например уже поддерживает AVIF, в то время как у них ушло 10 лет, чтобы добавить поддержку WEBP.
Google и Apple похоже решили сделать AVIF дефолтным next-gen форматом для изображений.
IOS 16 например уже поддерживает AVIF, в то время как у них ушло 10 лет, чтобы добавить поддержку WEBP.
>>221071
С чего? Двач до сих пор в webp не может, чего уж говорить о jxl, разумеется картинку нужно было конвертировать в пнг или в жпег.
С чего? Двач до сих пор в webp не может, чего уж говорить о jxl, разумеется картинку нужно было конвертировать в пнг или в жпег.
>>218687
Вам смешно, а я б был рад еслиб waifu2x встроили б в мозиллу для апскейла картинок
мимо читаю комиксы от ебучих шакалов постоянно
Вам смешно, а я б был рад еслиб waifu2x встроили б в мозиллу для апскейла картинок
мимо читаю комиксы от ебучих шакалов постоянно
>>221252
C jpeg -> jxl -> jpeg ты получишь в точности тот же самый файл.
С пнг ты получишь другой файл другого размера в байтах, но с теми же пикселями.
C jpeg -> jxl -> jpeg ты получишь в точности тот же самый файл.
С пнг ты получишь другой файл другого размера в байтах, но с теми же пикселями.
>>221280
А почему тогда файл будет другой если пиксели те же?
Я про перегонку loseless JXL - > PNG и обратно конечно же
>С пнг ты получишь другой файл другого размера в байтах, но с теми же пикселями.
А почему тогда файл будет другой если пиксели те же?
Я про перегонку loseless JXL - > PNG и обратно конечно же
>>221283
jxl -> png -> jxl даст одинаковые файлы.
png -> jxl -> png необязательно, так как оригинальный пнг неизвестно чем создан и с какими опциями.
jxl -> png -> jxl даст одинаковые файлы.
png -> jxl -> png необязательно, так как оригинальный пнг неизвестно чем создан и с какими опциями.
>>221285
Если ты про всякие хуептимизации - так и хуй с ним, ведь на картинку не влияет же, разве нет?
>так как оригинальный пнг неизвестно чем создан и с какими опциями.
Если ты про всякие хуептимизации - так и хуй с ним, ведь на картинку не влияет же, разве нет?
Стоит конвертировать форточки из jpeg в jxl? Существенная экономия будет?
>мимо
>>220694
Каким боком тут монополия? Они этот формат разрабатывают, они и могут его убить.
Каким боком тут монополия? Они этот формат разрабатывают, они и могут его убить.
>>221586
Ты новость-то читал?
Монополия — на браузерный движок. Разрабатывают, именно что за пределами гугла, и конкурироет с домашним гугловским webp.
Ты новость-то читал?
Монополия — на браузерный движок. Разрабатывают, именно что за пределами гугла, и конкурироет с домашним гугловским webp.
Исходный код пердоформата есть, в чём похороны заключаются?
Некоторые кодеки вроде TAK вообще одним васяном пилятся и вполне себе живут, бгг
Некоторые кодеки вроде TAK вообще одним васяном пилятся и вполне себе живут, бгг
>>221602
Мы живëм в мире вытесняющей товарности. Но я в этом не уверен.
Мы живëм в мире вытесняющей товарности. Но я в этом не уверен.
>>221593
Тогда непонятно почему гугл указан как один из разработчиков на педивикии.
Тогда непонятно почему гугл указан как один из разработчиков на педивикии.
>>221602
Этот ТАК один шизик на весь /с/ форсит. Не удивлюсь что это и есть тот самый один васян.
>вроде TAK
>вполне себе живут
Этот ТАК один шизик на весь /с/ форсит. Не удивлюсь что это и есть тот самый один васян.
302 Кб, 1837x561>>221671
Потому что кто-то из гугла пилил PIK, который впоследствии слился с FUIF в jxl.
https://github.com/google/pik
https://github.com/cloudinary/fuif
https://github.com/FLIF-hub/FLIF/issues/549#issuecomment-912335312
Потому что кто-то из гугла пилил PIK, который впоследствии слился с FUIF в jxl.
https://github.com/google/pik
https://github.com/cloudinary/fuif
https://github.com/FLIF-hub/FLIF/issues/549#issuecomment-912335312
>>221671>>221886
Ну и теперь эти люди из гугла пилят jxl, например:
https://github.com/jan-wassenberg
https://github.com/mo271
Ну и теперь эти люди из гугла пилят jxl, например:
https://github.com/jan-wassenberg
https://github.com/mo271
>>221881
Что за ТАК то вообще?? Есть годные аудиоформаты типа wavpack и musepack, которым уже сто лет, но их мало кто поддерживает, что впрочем не мешает их использовать. Именно поэтому я все фоточки давно корветнул в jxl, а что там хипстеры ебаные о себе возомнили мне похуй. Ещё бы на мнение FAGMAN равняться.
Что за ТАК то вообще?? Есть годные аудиоформаты типа wavpack и musepack, которым уже сто лет, но их мало кто поддерживает, что впрочем не мешает их использовать. Именно поэтому я все фоточки давно корветнул в jxl, а что там хипстеры ебаные о себе возомнили мне похуй. Ещё бы на мнение FAGMAN равняться.
>>221937
Формат кодирования аудио без потерь, обеспечивающий максимальную степень компрессии по сравнению с другими lossless-кодеками.
Причаститься: http://thbeck.de/Tak/Tak.html
Автор всё хочет в Open Source своё детище перевести, но пока не получается особо.
> Что за ТАК то вообще??
Формат кодирования аудио без потерь, обеспечивающий максимальную степень компрессии по сравнению с другими lossless-кодеками.
Причаститься: http://thbeck.de/Tak/Tak.html
Автор всё хочет в Open Source своё детище перевести, но пока не получается особо.
>>221881
Тебе просто обидно, что тебя ниопустили совсем, обойдя стороной прошивку для роутера, бгг. А TAK пилит немец, он не может здесь его форсить.
> Linux
Тебе просто обидно, что тебя ниопустили совсем, обойдя стороной прошивку для роутера, бгг. А TAK пилит немец, он не может здесь его форсить.
185 Кб, 1800x698>>221958
Мало того, что не максимальную. Так ещё и компрессию примерно на 2..3% отличающуюся от любого распространённого опенсорсного формата.
>максимальную степень компрессии
Мало того, что не максимальную. Так ещё и компрессию примерно на 2..3% отличающуюся от любого распространённого опенсорсного формата.
>>221977 (Del)
Два самых нинужных кодека, согласно этой таблице, т.к. даже software support хромает. Про hardware молчу.
Два самых нинужных кодека, согласно этой таблице, т.к. даже software support хромает. Про hardware молчу.
>>221977 (Del)
Ты только что тупо повторил моё утверждение.
> Более уплотнённо сжимает только OptimFROG, Monkey's Audio и Lossless Audio
> все находятся в вилке 49..52%
Ты только что тупо повторил моё утверждение.
>>221983 (Del)
Все, устал тебя кормить, иди своё нинужно свидетелям фубара форси. Неудивительно, что проприетарное говно, которое даже рокбокс не умеет, никто не хочет использовать. Да и вообще все проприетарные форматы через лет 50 превратятся в тыкву.
Все, устал тебя кормить, иди своё нинужно свидетелям фубара форси. Неудивительно, что проприетарное говно, которое даже рокбокс не умеет, никто не хочет использовать. Да и вообще все проприетарные форматы через лет 50 превратятся в тыкву.
642 Кб, 1212x1741Похоже из стандартного жпега можно выжать еще больше сжатия при том же качестве картинки.
>>224550
Звучит слишком хорошо, я фотки перевёл в jxl получил где то так же. Зачем тогда изобрели jxl?
>28%
Звучит слишком хорошо, я фотки перевёл в jxl получил где то так же. Зачем тогда изобрели jxl?
>>224684
Я так это понимаю:
100 png->jpg (baseline)
80% png->jpg->jxl (lossless transcoding)
72% png->jpg+ (кодек из скриншота)
40% png->jxl (lossy jxl)
Я так это понимаю:
100 png->jpg (baseline)
80% png->jpg->jxl (lossless transcoding)
72% png->jpg+ (кодек из скриншота)
40% png->jxl (lossy jxl)
>>213710 (OP)
Только проблема сайтов не в дохуя тяжелых картиночках, а в ебучих скриптах по несколько мегабайт.
Только проблема сайтов не в дохуя тяжелых картиночках, а в ебучих скриптах по несколько мегабайт.
>>224743
Это понятно, но если на сайтах и в браузерах не будет jxl, его нигде не будет, где он нужен.
Это понятно, но если на сайтах и в браузерах не будет jxl, его нигде не будет, где он нужен.
>>224743
то-то они глубоко прожаривают пользовательские картинки
то-то они глубоко прожаривают пользовательские картинки
63 Кб, 561x1260>>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
Во-первых, 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
>>224823
а вот это очень интересно. зачем? нахуя? не можешь вспомнить что это было?
>Какой-то из компрессоров на соревнованиях по сжатию картинок без потерь, помню, оказался с потерями, но оптимизированным так, чтобы на большинстве типичных данных генерировать не отличающуюся копию.
а вот это очень интересно. зачем? нахуя? не можешь вспомнить что это было?
>>224832
Это могла быть просто не отлаженная программа. Если ты посмотришь, в тестах кучу строчек занимают программы, которые поддерживают только часть форматов изображений или специально написаны для сжатия конкретного набора данных, даже не пытаясь работать с остальными. Смысл в том, что это опорные точки для оптимизации, на которые можно ориентироваться при оценке общих алгоритмов.
Ну так если у тебя программа на миллионе прочих данных работает некорректно, а с тестовыми всё хорошо, и это позволяет улучшить результат, то ты просто получил некий алгоритм генерации именно этих данных. См. пример сжатия цифр числа пи.
Это могла быть просто не отлаженная программа. Если ты посмотришь, в тестах кучу строчек занимают программы, которые поддерживают только часть форматов изображений или специально написаны для сжатия конкретного набора данных, даже не пытаясь работать с остальными. Смысл в том, что это опорные точки для оптимизации, на которые можно ориентироваться при оценке общих алгоритмов.
> зачем? нахуя?
Ну так если у тебя программа на миллионе прочих данных работает некорректно, а с тестовыми всё хорошо, и это позволяет улучшить результат, то ты просто получил некий алгоритм генерации именно этих данных. См. пример сжатия цифр числа пи.
>>224850
понятно, ну это уже совсем другое соревнование получается, к сжатию изображений отношения не имеющее,
понятно, ну это уже совсем другое соревнование получается, к сжатию изображений отношения не имеющее,
>>224853
Ага, люди годами что-то обсуждают, статьи в научные журналы пишут, а потому приходишь ты и говоришь, что это всё чепуха какая-то. Ты понимаешь, что вон те результаты нейросеточек, на вычислительных кластерах подбирающих алгоритм, возникли по следам ковыряния вот этих маленьких программ и их обобщения?
Наконец, можно оценить общую картину. Вон строчка с результатами обычного PNG, что мы понимаем, глядя на неё? Во-первых, что стандартный zlib что-то как-то медленно работает (а это не новость, всем известные проекты предлагают сравнимый результат с теми же принципами сжатия за меньшее время). Во-вторых, что от современного формата сжатия без потерь общего назначения мы можем ожидать улучшения в 20-25% относительно PNG. А кому это надо? Если ты строишь три датацентра вместо четырёх и заказываешь на столько же меньше грузовиков с дисками, сумма экономии выходит внушительная. Если же у тебя картинки занимают четыре гигабайта вместо пяти, ты этого просто не заметишь на фоне всей прочей скачанной порнухи с пенсионерками.
Ага, люди годами что-то обсуждают, статьи в научные журналы пишут, а потому приходишь ты и говоришь, что это всё чепуха какая-то. Ты понимаешь, что вон те результаты нейросеточек, на вычислительных кластерах подбирающих алгоритм, возникли по следам ковыряния вот этих маленьких программ и их обобщения?
Наконец, можно оценить общую картину. Вон строчка с результатами обычного PNG, что мы понимаем, глядя на неё? Во-первых, что стандартный zlib что-то как-то медленно работает (а это не новость, всем известные проекты предлагают сравнимый результат с теми же принципами сжатия за меньшее время). Во-вторых, что от современного формата сжатия без потерь общего назначения мы можем ожидать улучшения в 20-25% относительно PNG. А кому это надо? Если ты строишь три датацентра вместо четырёх и заказываешь на столько же меньше грузовиков с дисками, сумма экономии выходит внушительная. Если же у тебя картинки занимают четыре гигабайта вместо пяти, ты этого просто не заметишь на фоне всей прочей скачанной порнухи с пенсионерками.
>>224851
Пока просмотрощики и редакторы его поддерживают, можно продолжать фотки в него пережимать. Ну а инстабляди пусть сосут.
Пока просмотрощики и редакторы его поддерживают, можно продолжать фотки в него пережимать. Ну а инстабляди пусть сосут.
>>224893
Нужный. Почему меня должно волновать место на серверах гугля или яндекса? Мне jxl моё место экономит.
Нужный. Почему меня должно волновать место на серверах гугля или яндекса? Мне jxl моё место экономит.
>>224865
Кстати, натыкался на прототип пнг, в котором заменили zlib на zstandard.
https://github.com/catid/Zpng
Судя по ридми работает гораздо быстрее и дает файлы меньшего размера.
>Вон строчка с результатами обычного PNG, что мы понимаем, глядя на неё? Во-первых, что стандартный zlib что-то как-то медленно работает
Кстати, натыкался на прототип пнг, в котором заменили zlib на zstandard.
https://github.com/catid/Zpng
Судя по ридми работает гораздо быстрее и дает файлы меньшего размера.
>>224865
извиняюсь перед учеными.
и все же, на реальных данных, а не на заранее известном бенчмарке, программы-рекордсмены все еще показывают лучший результат? может бы я описал не текущую ситуацию, а будущую, но она явно случится - когда переоптимизация под кокретные картинки перестанет нести поелзные на практике идеи. что-то типа оп-пика.
>>224895
вот кстати перевод из жпега и обратно в жпг без потерь реально киллер фича. только удобный пользовательский интерфейс чтобы картинки из своего хранилища постить в интернет современные оси и браузеры даже не позволят сделать нормально.
извиняюсь перед учеными.
и все же, на реальных данных, а не на заранее известном бенчмарке, программы-рекордсмены все еще показывают лучший результат? может бы я описал не текущую ситуацию, а будущую, но она явно случится - когда переоптимизация под кокретные картинки перестанет нести поелзные на практике идеи. что-то типа оп-пика.
>>224895
вот кстати перевод из жпега и обратно в жпг без потерь реально киллер фича. только удобный пользовательский интерфейс чтобы картинки из своего хранилища постить в интернет современные оси и браузеры даже не позволят сделать нормально.
>>224893
в том-то и дело что нет и нет. ты описал любой рандомный кодек, а jpeg xl может пережать без потерь существующий жпег, причем не только без потери пикселей но и без потери самого жпега!
вот бы для h264 сделали оптимизатор, там как и в любом кодеке есть беспотерьная часть, и реалтаймовые кодеры использующиеся при съемке явно не оптимальны.
>Сам создал изображение
>сам посмотрел
в том-то и дело что нет и нет. ты описал любой рандомный кодек, а jpeg xl может пережать без потерь существующий жпег, причем не только без потери пикселей но и без потери самого жпега!
вот бы для h264 сделали оптимизатор, там как и в любом кодеке есть беспотерьная часть, и реалтаймовые кодеры использующиеся при съемке явно не оптимальны.
а ведь сделали, только за каким-то хером оно заброшено...
https://encode.su/threads/3213-Is-there-an-MP4-optimizer
https://encode.su/threads/3213-Is-there-an-MP4-optimizer
>>225088
Если ты коллекционируешь это говно, значит ты слишком много времени проводишь онлайн и вообще лазер...
Если ты коллекционируешь это говно, значит ты слишком много времени проводишь онлайн и вообще лазер...
>>225085
Сегодня придумали JPEX XL - ты перегнал в него всё, завтра JPEG XXL - опять перегнал, JPEX XXXL - опять - и вот у тебя бы уже были одни шакалы видны если после каждого шага был было бы перекодирование перекодированного
>И зачем это нужно
Сегодня придумали JPEX XL - ты перегнал в него всё, завтра JPEG XXL - опять перегнал, JPEX XXXL - опять - и вот у тебя бы уже были одни шакалы видны если после каждого шага был было бы перекодирование перекодированного
>>217316 (Del)
А гугель против что ли?
А гугель против что ли?
>>225468
Если согласятся поддерживать, то да. Именно из-за недостатка интереса её и убрали оттуда недавно.
Если согласятся поддерживать, то да. Именно из-за недостатка интереса её и убрали оттуда недавно.
>>225480
Да, скорее ты прав. Вот поэтому я надеюсь, что в edge быстрей добавят. Не хочется уж больно юзать webp2 или как его там.
Да, скорее ты прав. Вот поэтому я надеюсь, что в edge быстрей добавят. Не хочется уж больно юзать webp2 или как его там.
>>225481
avif, webp2 тоже отменили
avif, webp2 тоже отменили
899 Кб, 1231x2055Google продолжает настаивать на их решении:
https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/0XA-0G6hBgAJ
Тем, кто хочет пользоваться форматом в хроме, предлагают wasm версию.
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.
>>213710 (OP)
и чем сабж лучше чем AVIF?
я столько крутил вертел и всё равно результат хуже чем у avif
и чем сабж лучше чем AVIF?
я столько крутил вертел и всё равно результат хуже чем у avif
>Эпоха ссд накопителей
>Средний сайт занипер в памяти 5 мегабайт
>Средняя программа минимум 200 мегабайт
>Уии, новый формат позволяет сократить размер картинки на 50 килобайт, уряяя, перемога, срочна начинаем его форсить вместо старых добрых jpg, gif и bmp
>>226196
Зачем жрать говно если можно не жрать? Перегнал все свои jpeg и png в jxl без потерь в качестве. Единый формат, который меньше их обоих.
Зачем жрать говно если можно не жрать? Перегнал все свои jpeg и png в jxl без потерь в качестве. Единый формат, который меньше их обоих.
>>226207
Зачем мне пердолиться ради 0.001% экономии места на диске?
Отправить фотку кому-нибудь показать? - Нет, я ведь пердольщик
Выложить в интернет показать? - Нет, я ведь пердольщик
Сохранил картиночку из инета, что дальше? - Да, пердолиться!
Зачем мне пердолиться ради 0.001% экономии места на диске?
Отправить фотку кому-нибудь показать? - Нет, я ведь пердольщик
Выложить в интернет показать? - Нет, я ведь пердольщик
Сохранил картиночку из инета, что дальше? - Да, пердолиться!
>>226211
Всего то скриптик запустить.
На переходном этапе, а если поддержка будет везде, то эта проблема отпадает сама собой.
Всего то скриптик запустить.
> Отправить фотку кому-нибудь показать? - Нет, я ведь пердольщик
На переходном этапе, а если поддержка будет везде, то эта проблема отпадает сама собой.
>>226219
Напомнить сколько переходной этап у webp был? 12 лет прошло, а двач до сих пор не осилил.
Или напомнить сколько этот переходный период был у jpg2000?
Напомнить сколько переходной этап у webp был? 12 лет прошло, а двач до сих пор не осилил.
Или напомнить сколько этот переходный период был у jpg2000?
>>226656 (Del)
УРРЯЯЯ, АЖ НА ПИТЬСОТ КИЛАБАЙТ МЕНЬШЕ МЕСТА, ПЕРЕМОГА
@
IШТО ЗНАЧИТ , ГЕНШИН ИМПАКТ ЗАНИМАЕТ 228 ГИГАБАЙТ (ПРИ ГРАФИКЕ ХУЖЕ ЧЕМ В КРУЗИС 1), ТЫ ЧО РЕТРАГРАД ИЗ ПРОШЛОГО ВЕКА ШТО ЛИ, ПРОСТА КУПИ НОВЫЙ СОСОДИ НА 100500 ТБ
УРРЯЯЯ, АЖ НА ПИТЬСОТ КИЛАБАЙТ МЕНЬШЕ МЕСТА, ПЕРЕМОГА
@
IШТО ЗНАЧИТ , ГЕНШИН ИМПАКТ ЗАНИМАЕТ 228 ГИГАБАЙТ (ПРИ ГРАФИКЕ ХУЖЕ ЧЕМ В КРУЗИС 1), ТЫ ЧО РЕТРАГРАД ИЗ ПРОШЛОГО ВЕКА ШТО ЛИ, ПРОСТА КУПИ НОВЫЙ СОСОДИ НА 100500 ТБ
464 Кб, 1332x850>>226680
Отклеилось
Отклеилось
>>226902
Суть не в этом. Главное что сама игра не особо требовательная, но при этом занимает даже больше места чем гта 5.
Суть не в этом. Главное что сама игра не особо требовательная, но при этом занимает даже больше места чем гта 5.
>>226955
Ну так в обоих этих играх половину объёма занимает озвучка.
Ну так в обоих этих играх половину объёма занимает озвучка.
>>226196
А вот и нихуя, больше. Если lossless в png весит 19,7 мегабайт, то математический lossless (-d 0) jxl весит 9,64 мегабайта. Если брать почти lossless (-d 0.3 -e 9 --brotli_effort 11), то он весит 3,88 мегабайта, и отличий от png вообще нет, даже если в прильнуть лицом к экрану и заняться охотой на пиксели.
>Уии, новый формат позволяет сократить размер картинки на 50 килобайт
А вот и нихуя, больше. Если lossless в png весит 19,7 мегабайт, то математический lossless (-d 0) jxl весит 9,64 мегабайта. Если брать почти lossless (-d 0.3 -e 9 --brotli_effort 11), то он весит 3,88 мегабайта, и отличий от png вообще нет, даже если в прильнуть лицом к экрану и заняться охотой на пиксели.
>>233574
А ты хорош. У тебя еще и .png поди не оптимизированный?
> "почти lossless"
> Продолжает сравнивать с .png
А ты хорош. У тебя еще и .png поди не оптимизированный?
>>233599
А почему нет то? Потерьное с потерьным. Сравнивай с оптимизированным jpeg'ом на максималке.
А почему нет то? Потерьное с потерьным. Сравнивай с оптимизированным jpeg'ом на максималке.
>>233611
Для тех, кто не хочет переходить по ссылке. Там пишут, что jxl в среднем примерно на 48% и 37% меньше, чем png и оптимизированный png соответственно.
Для тех, кто не хочет переходить по ссылке. Там пишут, что jxl в среднем примерно на 48% и 37% меньше, чем png и оптимизированный png соответственно.
>>233627
> И кодируется в 35 раз дольше, ога.
> These tests have also been done at the lowest possible speeds
>>233629
25% будет по сравнению с оптимизированным пнг.
25% будет по сравнению с оптимизированным пнг.
>>233627
Во первых, эти тесты не учитывают скорость кодирования PNG, а только скорость оптимизации. Так что некорректно делить 25 на 0.7, как ты сделал.
Во вторых, от oxipng толку мало, какой смысл с ним сравнивать? Этак можно вообще без оптимизацией сравнить будет 0 сек, лол.
Во первых, эти тесты не учитывают скорость кодирования PNG, а только скорость оптимизации. Так что некорректно делить 25 на 0.7, как ты сделал.
Во вторых, от oxipng толку мало, какой смысл с ним сравнивать? Этак можно вообще без оптимизацией сравнить будет 0 сек, лол.
260 Кб, 3016x1394Вот еще любопытные графики, fjxl и fpng были написаны в ответ на qoi, автор которого заявлял, что пнг слишком медленно кодируется, из-за чего он решил запилить свой простой 300 строк кода на си и быстрый формат без бэкджека и шлюх.
>>213710 (OP)
Ёбаный рот луддитов на разработчике. Нет адекватных вьюверов, которые бы поддерживали jxl. HoneyView - годнота как вьювер, но не поддерживает, XnView - открывает jxl файлы очень медленно, IrfanView - говнище без возможности поменять хоткеи, отчего скроллить масштабированные изображения можно только клавиатурой но не мышью. Есть ещё mpv, но он предназначен для видео, и во вьювер картинок его превращает набор скриптов.
Ёбаный рот луддитов на разработчике. Нет адекватных вьюверов, которые бы поддерживали jxl. HoneyView - годнота как вьювер, но не поддерживает, XnView - открывает jxl файлы очень медленно, IrfanView - говнище без возможности поменять хоткеи, отчего скроллить масштабированные изображения можно только клавиатурой но не мышью. Есть ещё mpv, но он предназначен для видео, и во вьювер картинок его превращает набор скриптов.
>>233657
Не буду я ради одного кодека отказываться от большей части софта. Вон, аудиоплеера нормального под прыщами до сих пор нет - foobar2000 вин-онли, фотошопа нет, игры (по крайней мере пиратские, без зависимости от барского стима) запускаются через костыли и с меньшей производительностью. У файрфокса нет отдельного хранилища сертификатов, а линукс позиционирует себя как ОС для продвинутых пользователей. Вся эта возня с пакетными менеджерами, репозиториями, зависимостями, ну его на хуй короче.
Не буду я ради одного кодека отказываться от большей части софта. Вон, аудиоплеера нормального под прыщами до сих пор нет - foobar2000 вин-онли, фотошопа нет, игры (по крайней мере пиратские, без зависимости от барского стима) запускаются через костыли и с меньшей производительностью. У файрфокса нет отдельного хранилища сертификатов, а линукс позиционирует себя как ОС для продвинутых пользователей. Вся эта возня с пакетными менеджерами, репозиториями, зависимостями, ну его на хуй короче.
>>233659
На него похож Deadbeef, но он и без протествари не славится адекватной работой.
>foobar2000 вин-онли
На него похож Deadbeef, но он и без протествари не славится адекватной работой.
>>233659
Я на винде chocolatey лет пять использовал, а ты говоришь с репозиьориями ебаться ;-)
Я на винде chocolatey лет пять использовал, а ты говоришь с репозиьориями ебаться ;-)
>>233664
Ну кому надо побыстрее те и на fpng перейдут, а кому больше размер важен, не думаю, что станут на fjxl смотреть.
Ну кому надо побыстрее те и на fpng перейдут, а кому больше размер важен, не думаю, что станут на fjxl смотреть.
>>233661
Именно что похож, а нужных плагинов нет. Я их много использую.
>>233657
Ради смеха спрошу, какой дистрибутив линукса ставить? Они все или почти все - крайности определённых недостатков, и если спросишь на форуме (не на форуме дистрибутива, где мынивиноваты, софт ненужон и используй аналоговнет, а на форуме разработчика какого-нибудь софта) "как решить эту проблему с вашим софтом?", то в ответ получишь "пок-пок-пок, скачай другой дистрибутив", с которым тебя пошлют нахуй уже на другом форуме. Лебедь, рак и щука в жму/пениксе.
>На него похож Deadbeef
Именно что похож, а нужных плагинов нет. Я их много использую.
>>233657
Ради смеха спрошу, какой дистрибутив линукса ставить? Они все или почти все - крайности определённых недостатков, и если спросишь на форуме (не на форуме дистрибутива, где мынивиноваты, софт ненужон и используй аналоговнет, а на форуме разработчика какого-нибудь софта) "как решить эту проблему с вашим софтом?", то в ответ получишь "пок-пок-пок, скачай другой дистрибутив", с которым тебя пошлют нахуй уже на другом форуме. Лебедь, рак и щука в жму/пениксе.
>>213710 (OP)
В итоге такой же обсер как и у WebP - А КАК ИХ РАЗЛИЧАТЬ-ТО В ИТОГЕ?
>Сжимает на 60% лучше, чем JPEG.
>Сжимает без потерь на 35% лучше, чем PNG.
В итоге такой же обсер как и у WebP - А КАК ИХ РАЗЛИЧАТЬ-ТО В ИТОГЕ?
>>233676
На самом деле различать лосслесс и лосси не тривиальная задача. Вот у тебя похоже убеждение, что раз пнг значит очевидно лосслесс, но ведь есть пнг сконвертированные из жпегов, а еще есть утилиты, которые делают сразу лосси пнг, например pngquant, как ты различаешь такие пнг от Ъ-лосслесс?
В libjxl гитхабе есть утилита jxlinfo, которая пытается детектить лосси:
Помимо этого можешь ориентироваться на размер файла, лосси файлы обычно на порядок меньше занимают места.
На самом деле различать лосслесс и лосси не тривиальная задача. Вот у тебя похоже убеждение, что раз пнг значит очевидно лосслесс, но ведь есть пнг сконвертированные из жпегов, а еще есть утилиты, которые делают сразу лосси пнг, например pngquant, как ты различаешь такие пнг от Ъ-лосслесс?
В libjxl гитхабе есть утилита jxlinfo, которая пытается детектить лосси:
> info.uses_original_profile ? "(possibly) lossless" : "lossy");
Помимо этого можешь ориентироваться на размер файла, лосси файлы обычно на порядок меньше занимают места.
>>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".
Люди продолжают сравнивать 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".
>>234700
Если даже в таком варианте, jxl все равно лучше на 3%, нахуя выпилили то ебланы
Если даже в таком варианте, jxl все равно лучше на 3%, нахуя выпилили то ебланы
>>221257
Honeyview jxl картинки так и не открывает, несмотря на установленный в системе wic кодек для jxl.
Honeyview jxl картинки так и не открывает, несмотря на установленный в системе wic кодек для jxl.
>>234957
Столь мелкие поделки может вполне заменить всеядный mpv и даже лучше их быть. Смысла нет в них.
>Honeyview, pictus, qview
Столь мелкие поделки может вполне заменить всеядный mpv и даже лучше их быть. Смысла нет в них.
Проблемы негров-виндузятников. Жрите баренский jpeg и png
Появилось расширение для браузеров, которое через wasm декодирует jxl:
https://github.com/zamfofex/jxl-crx
Пока что находится в ранней стадии разработки.
https://github.com/zamfofex/jxl-crx
Пока что находится в ранней стадии разработки.
>>213710 (OP)
И как отличать изображение со сжатием от изображения без сжатия? Когда я вижу пнг я сразу понимаю, что картинка не сжималась, а тут что?
> Он одновременно может заменить JPEG, в случаях сжатия с потерями (например фотки), PNG, в случаях сжатия без потерь (скриншоты
И как отличать изображение со сжатием от изображения без сжатия? Когда я вижу пнг я сразу понимаю, что картинка не сжималась, а тут что?
>>254770
Можно и jpeg переконвертировать в png и не всегда легко будет заметить разницу. Но в общем случае, согласен, это неудобно и у webp та же проблема.
Можно и jpeg переконвертировать в png и не всегда легко будет заметить разницу. Но в общем случае, согласен, это неудобно и у webp та же проблема.
>>254899
И имя ей Google
Отдельно кринжую к кукареков про "швабодный" формат, в одном предложении с Google. Жидорабы пердососки не палятся.
>JPEG XL
>собрались компании Google и JPEG и решили
>WebP
>is an image file format developed by Google
>та же проблема
И имя ей Google
Отдельно кринжую к кукареков про "швабодный" формат, в одном предложении с Google. Жидорабы пердососки не палятся.
>>254950
Таблетки прими, шизло, может речь связной хоть будет.
Таблетки прими, шизло, может речь связной хоть будет.
Если я jpeg преобразуются в png, а затем png в jxl (lossless), то размер будет равен прямому преобразованию того же самого jpeg в jxl (lossless)? Если нет, то почему.
>>256031
Не будет равным.
Потому что транскодирование jpeg без потерь выполняется особым образом.
Как я это понимаю: при обычном транскодировании сначала декодируется изображение, из которого мы получаем набор пикселей. Этот набор кодируется в другой формат.
А при транскодировании jpeg, дополнительно используется информация из оригинального jpeg вроде того, как на какие блоки было поделено изображение и как они были закодированы. Кодировщик jxl использует эту информацию для создания новой пикчи, где используются точно такие же блоки, но хранятся они более эффективно.
Я далёк от процесса транскодирования, это лишь предположение.
Не будет равным.
Потому что транскодирование jpeg без потерь выполняется особым образом.
Как я это понимаю: при обычном транскодировании сначала декодируется изображение, из которого мы получаем набор пикселей. Этот набор кодируется в другой формат.
А при транскодировании jpeg, дополнительно используется информация из оригинального jpeg вроде того, как на какие блоки было поделено изображение и как они были закодированы. Кодировщик jxl использует эту информацию для создания новой пикчи, где используются точно такие же блоки, но хранятся они более эффективно.
Я далёк от процесса транскодирования, это лишь предположение.
>>256147
Тогда в чем смысл конвертации из jpeg напрямую, кроме возможности восстановить исходный jpeg, если можно потенциально достичь меньшего размера при том же качестве, закодировав сперва в png.
Тогда в чем смысл конвертации из jpeg напрямую, кроме возможности восстановить исходный jpeg, если можно потенциально достичь меньшего размера при том же качестве, закодировав сперва в png.
>>256157
При конвертации из jpeg в png крайне сильно раздуется формат файла. Потому что png будет вынужден хранить все эти артефакты компрессии jpeg как отдельные странные последовательности пикселей, которые сложно эффективно закодировать.
При перекодировании из png в jxl, последний тоже будет вынужден хранить все эти артефакты как последовательности пикселей, которые сложно эффективно закодировать. У jxl кодировщика не будет информации о том, что эти артефакты компрессии на самом деле являются наложением разных градиентов, соответственно он не сможет использовать такие же градиенты для создания jxl изображения.
При конвертации из jpeg в png крайне сильно раздуется формат файла. Потому что png будет вынужден хранить все эти артефакты компрессии jpeg как отдельные странные последовательности пикселей, которые сложно эффективно закодировать.
При перекодировании из png в jxl, последний тоже будет вынужден хранить все эти артефакты как последовательности пикселей, которые сложно эффективно закодировать. У jxl кодировщика не будет информации о том, что эти артефакты компрессии на самом деле являются наложением разных градиентов, соответственно он не сможет использовать такие же градиенты для создания jxl изображения.
>>256157
В твоей схеме он будет потенциально большего размера. В этом проблема.
>если можно потенциально достичь меньшего размера при том же качестве
В твоей схеме он будет потенциально большего размера. В этом проблема.
>>256351
Проверю, доложу. Я почему этой темой заинтересовался, многие png - по сути пересжатые jpg, а не с нуля созданные изображения. Вот и пытаюсь понять, что делать в таких случаях, конвертировать из png или брать jpg источник.
Проверю, доложу. Я почему этой темой заинтересовался, многие png - по сути пересжатые jpg, а не с нуля созданные изображения. Вот и пытаюсь понять, что делать в таких случаях, конвертировать из png или брать jpg источник.
В общем расклад такой, да действительно, если jpeg файл сконвертировать в png, а затем в jxl, то размер получится больше (716K против исходных 387K в моем примере), но это при использовании -d 0 (математический лосслесс), если же получившийся png закодировать с -d 1 (визуальный лосслесс), а jpeg напрямую с -d 1 и --lossless_jpeg=0, то размер уменьшится одинаково (до 135K) без видимой потери качества в теории. Значит преобразовывать предварительно в png смысла нет, если можно закодировать напрямую.
>>256504
Попробуй поперекодировать скрины png'шные с текстом, охуеешь от этих теорий
> без видимой потери качества в теории
Попробуй поперекодировать скрины png'шные с текстом, охуеешь от этих теорий
>>256679
Так самое смешное, что когда я кодировал с -d 0 (для jpeg по умолчанию), то выигрыш был всего несколько десятков килобайт. То есть смысла нет на моём примере.
Так самое смешное, что когда я кодировал с -d 0 (для jpeg по умолчанию), то выигрыш был всего несколько десятков килобайт. То есть смысла нет на моём примере.
4,1 Мб, 1920x1200>>254770
Ты свечку держал что ли, мразь? Я блять копирую из гугла жипег и вставляю тебе из буфера в пнг, отчего он раздувается в 7.6 раз нахуй. Твои действия, чмо?
Ты свечку держал что ли, мразь? Я блять копирую из гугла жипег и вставляю тебе из буфера в пнг, отчего он раздувается в 7.6 раз нахуй. Твои действия, чмо?
>>257782 (Del)
Тем, что разширкние не отличается, был бы webp (lossless) и webj какой-нить, тут бы всем было ясно.
Тем, что разширкние не отличается, был бы webp (lossless) и webj какой-нить, тут бы всем было ясно.
>>262225
Не нужен. В jxl.
Не нужен. В jxl.
>>262225
Lossless webp сжимает значительно лучше png, особенно скриншоты с текстом, lossless avif совершенно бесполезен.
Как замена jpeg'у avif действительно был бы лучше.
JXL мог бы заменить все упомянутое, конечно.
Lossless webp сжимает значительно лучше png, особенно скриншоты с текстом, lossless avif совершенно бесполезен.
Как замена jpeg'у avif действительно был бы лучше.
JXL мог бы заменить все упомянутое, конечно.
подскажите аноны, тот факт что гуголь бросил играться с jpegxl что-то значит для его будующего и поддержки? я не планирую никуда постить свои фоточки, но вот потерять возможность перекодировать всё обратно в png/jpeg лет через 5-10 не хотелось-бы
>>283442
Ты не потеряешь возможность перекодировать обратно без потерь даже через 100 лет. Даже если jxl вообще перестанут развивать при условии, что человечество каким-то образом не проебёт исходные коды/бинарники.
Скорее ты проебёшь свои фотки, так что не переживай.
Ты не потеряешь возможность перекодировать обратно без потерь даже через 100 лет. Даже если jxl вообще перестанут развивать при условии, что человечество каким-то образом не проебёт исходные коды/бинарники.
Скорее ты проебёшь свои фотки, так что не переживай.
>>283488
Причем уже есть 3 альтернативных декодера разной степени готовности:
https://github.com/tirr-c/jxl-oxide
https://github.com/thebombzen/jxlatte
https://github.com/lifthrasiir/j40
Причем уже есть 3 альтернативных декодера разной степени готовности:
https://github.com/tirr-c/jxl-oxide
https://github.com/thebombzen/jxlatte
https://github.com/lifthrasiir/j40
>>283561
Опять эта чушь про майнеры.
Ты бы хоть посмотрел на этот их тьюринг полный язык и его ограничения.
Опять эта чушь про майнеры.
Ты бы хоть посмотрел на этот их тьюринг полный язык и его ограничения.
>>283561
SVG тоже почти тьюринг комплит, но ты почему-то не выёбываешься на это.
Ах, да, всё от невежества.
SVG тоже почти тьюринг комплит, но ты почему-то не выёбываешься на это.
Ах, да, всё от невежества.
>>283646
Сравни лучше с PDF, который из-за сложности исторически являлся источником кучи дырок, как в логике обработки так и самих либах.
Сравни лучше с PDF, который из-за сложности исторически являлся источником кучи дырок, как в логике обработки так и самих либах.
>>283763
Лучше сразу встроить в сракло софтошиза для лучшего расширения™
Лучше сразу встроить в сракло софтошиза для лучшего расширения™
47 Кб, 770x775>>283808
Я слишком тупой, покажи мне, как у тебя получилось сделать форк-бомбу на пикриле.
Я слишком тупой, покажи мне, как у тебя получилось сделать форк-бомбу на пикриле.
489 Кб, 1474x1559User: хэй, не могли бы вы вернуть поддержку jxl?
Devs: слишком сложно, мы не осилим
User: вот есть уже готовый патч от Васяна
Devs: мм, там лицензия не та
Васян: я сменил лицензию на совместимую с вашим проектом
Интересно, какие отговорки сейчас пойдут.
Devs: слишком сложно, мы не осилим
User: вот есть уже готовый патч от Васяна
Devs: мм, там лицензия не та
Васян: я сменил лицензию на совместимую с вашим проектом
Интересно, какие отговорки сейчас пойдут.
>>290227
Хоть какая то польза от васянов.
Хоть какая то польза от васянов.
аноны, поскольку в jxl нельзя транскодировать jpeg изображения с CMYK, то возникает вопрос: а как нахуй узнать, какие изображения у меня имеют cmyk? в ручную проверять вообще не вариант, слишком много их
>>291572
Посмотри в сторону imagemagick, а именно identify. Почти на 100% уверен, что там должна быть эта инфа.
Посмотри в сторону imagemagick, а именно identify. Почти на 100% уверен, что там должна быть эта инфа.
>>283684
А какая годная альтернатива кроме djvu? Планирую OCRить отсканенные книги.
А какая годная альтернатива кроме djvu? Планирую OCRить отсканенные книги.
>>291610
Liberation Mono
fish + https://github.com/pure-fish/pure до этого был zsh+pure, можешь еще посмотреть в сторону https://starship.rs
Liberation Mono
fish + https://github.com/pure-fish/pure до этого был zsh+pure, можешь еще посмотреть в сторону https://starship.rs
>>291624
JXL лучше webp и для lossy и для lossless, и позволяет jpeg изображения в него конвертировать без потерь. Таким образом потенциально можно будет от jpeg вообще отказаться в будущем.
JXL лучше webp и для lossy и для lossless, и позволяет jpeg изображения в него конвертировать без потерь. Таким образом потенциально можно будет от jpeg вообще отказаться в будущем.
>>291691
С аж 25% сжатием. Ну охуеть теперь.
Ну лучше и лучше, стандарт лучше тот, который широко применяется и имеет максимальную поддержку, это очевидно. С нишевым же адопшеном - это сугубо локаьлное баловство, личную коллекцию пикч с двачей пережать, если сохранюх
> и позволяет jpeg изображения в него конвертировать без потерь
С аж 25% сжатием. Ну охуеть теперь.
> JXL лучше webp и для lossy и для lossless
Ну лучше и лучше, стандарт лучше тот, который широко применяется и имеет максимальную поддержку, это очевидно. С нишевым же адопшеном - это сугубо локаьлное баловство, личную коллекцию пикч с двачей пережать, если сохранюх
>>291703
Дело не в процентах, а в том, что это позволяет отказаться от устаревшего формата (jpeg). Если в качестве альтернативы продвигать webp, то jpeg никуда не исчезнет.
Тогда это jpeg и png и не надо никуда переходить? Или все таки надо? И если переходить, то может не стоить менять шило на мыло?
> С аж 25% сжатием. Ну охуеть теперь.
Дело не в процентах, а в том, что это позволяет отказаться от устаревшего формата (jpeg). Если в качестве альтернативы продвигать webp, то jpeg никуда не исчезнет.
>стандарт лучше тот, который широко применяется и имеет максимальную поддержку
Тогда это jpeg и png и не надо никуда переходить? Или все таки надо? И если переходить, то может не стоить менять шило на мыло?
>>291765
Почему ужасен?
Почему ужасен?
>>291726
Сравнил дефолтные настройки avif в ffmpeg с -q 6 jpg. Разница 439 против 691 кб в пользу avif, но у него шум, который является частью картинки, замылен. А у джипега деталей больше, хоть и шум сыпится большими квадратами. Но на кодирование avif ушло несоизмеримо больше времени чем на jpg, а ещё я не нашёл ни одну программу кроме ffplay, которой я мог бы его открыть.
Сравнил дефолтные настройки avif в ffmpeg с -q 6 jpg. Разница 439 против 691 кб в пользу avif, но у него шум, который является частью картинки, замылен. А у джипега деталей больше, хоть и шум сыпится большими квадратами. Но на кодирование avif ушло несоизмеримо больше времени чем на jpg, а ещё я не нашёл ни одну программу кроме ffplay, которой я мог бы его открыть.
🤗
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
>>291726
Говно, еще и медленное
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
>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
1,2 Мб, 980x500Кто-то выкладывал тут в прошлом году батник 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
>>213710 (OP)
В шапку не хватает: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html
66 Кб, 1325x730>>297671
Да после установки расширения https://apps.microsoft.com/store/detail/av1-video-extension/9MVZQVXJBQ9V?hl=be-by&gl=by все просмотрщики вроде как открывают только полосы какие-то зеленые иногда по краям вылезают.
Да после установки расширения https://apps.microsoft.com/store/detail/av1-video-extension/9MVZQVXJBQ9V?hl=be-by&gl=by все просмотрщики вроде как открывают только полосы какие-то зеленые иногда по краям вылезают.
>>213736
Зачем вы тащите этот плесневелый кал, когда есть официальная страница тестов у гугла. 🤔
>>221974
Судя по скорости декодирования - это вообще дефолтные префы, а не максы. Так в максах снижает ~ до 20% +- в сравнении с -8 у флак. Сам проверяй, лучше всего эмбиент. Даже free-dl wav подкину, чтоб потестить https://asurarevolver.bandcamp.com/album/rainforest-hill-i-ii
>>226179
Пруфы?
>>233656
Одного zones lua достаточно, лол.
Зачем вы тащите этот плесневелый кал, когда есть официальная страница тестов у гугла. 🤔
>>221974
Судя по скорости декодирования - это вообще дефолтные префы, а не максы. Так в максах снижает ~ до 20% +- в сравнении с -8 у флак. Сам проверяй, лучше всего эмбиент. Даже free-dl wav подкину, чтоб потестить https://asurarevolver.bandcamp.com/album/rainforest-hill-i-ii
>>226179
Пруфы?
>>233656
Одного zones lua достаточно, лол.
8 Кб, 590x343>>233656
Почему каждый ебаный раз, когда читаешь инфантильное нытьё софтошизов, за ним скрывается тупой мудак, неспособный зайти в настройки?
>IrfanView - говнище без возможности поменять хоткеи, отчего скроллить масштабированные изображения можно только клавиатурой но не мышью.
Почему каждый ебаный раз, когда читаешь инфантильное нытьё софтошизов, за ним скрывается тупой мудак, неспособный зайти в настройки?
663 Кб, 1254x795Сложности с сайтами, как единственный аргумент невозможностью пикчу залить/поделиться - хуйня и не всех задевает неудобствами. Если JXL у анона в первую очередь с целью личной коллекции и лично приобщиться к использованию со всеми фичами экономии/скоростью/етк, а не холиварной массовой поддержкой веба/пиписитарных гуглоподелок-браузеров , то смотреть формат можно в своём уютненьком просмотрщике/редакторе. А если нужно вкинуть онлайн, то копировать пикчу в clipboard и вставить на сайте - всё подтянется в простом формате. Лол, неудобств вы с этим получается избежали. Тогда какие аргументы не перекатиться с вашим архивом фото, если нёрф так легко обойти (за исключением древних веб помоек со старым методом ручной вставки пикчей, возможно мессенджеров, что без веб версий и всяких веб макак). Остальных как это задевает вообще? В том и забава >>225437 , что один только гугл не видит "потенциал", но на самом деле видит скорее нелепый обсер, что не успев вложиться в потуги авифа, не успев толком вкусить фидбэека в статусе топ1 формат - уже вынуждены признать пук, среньк, уже есть что-то получше, лол.
>>221881
Лол, даже не знал что список шизов пополнил. Быть может пару лет назад спалил плюсы, дак до сих пор рвутся 🤣
Лол, даже не знал что список шизов пополнил. Быть может пару лет назад спалил плюсы, дак до сих пор рвутся 🤣
>>298018
соглы, на винде jxl даже как обои не поставить
соглы, на винде jxl даже как обои не поставить
>>298166
Жмёт хорошо. Много где поддерживается.
Жмёт хорошо. Много где поддерживается.
Бамп
107 Кб, 1280x720JPEG 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.
>>213710 (OP)
feh откроет?
feh откроет?
Какой наиболее качественный на текущий момент инструмент для конвертации и сжатия в jxl?
Пока как просмоторщик использую XnView и у них есть встроенные конвертер насчет которого не уверен.
В треде пчелы активно работают с ffmpeg и imagemagick
Так что прошу рекомендации, какие стоит попробовать и где читать, как с ними работать
Пока как просмоторщик использую XnView и у них есть встроенные конвертер насчет которого не уверен.
В треде пчелы активно работают с ffmpeg и imagemagick
Так что прошу рекомендации, какие стоит попробовать и где читать, как с ними работать
>>291764
Ну так новый стандарт - это webp, если так дело пойдёт и дальше. Для любителей огромных паков, это вообще идеальный формат. И размер как у jpg и даже меньше иногда и поддержка прозрачности.
Можно вообще в хуй не дуть и всё в него перегонять не боясь.
Ну так новый стандарт - это webp, если так дело пойдёт и дальше. Для любителей огромных паков, это вообще идеальный формат. И размер как у jpg и даже меньше иногда и поддержка прозрачности.
Можно вообще в хуй не дуть и всё в него перегонять не боясь.
663 Кб, 1254x795>>317994
В твоём мирке? Или гугла? Или ты из началов десятых капчуешь. Вебп уже давно доживает и проигрывает всем актуальным, если дескать вообще был в чьих-то глазах живым, лол.
В твоём мирке? Мыло сраное, а не идеальный формат, лол. Этот тред обсуждения сабжа, а не мыльных форматов конца нулевых.
Обязательно в шапку треда ссылку, чтоб больше такой чуши не писали (для приватопердолей: для просмотра сравнений нужен включенный WEBGL и разрешенные workers api): https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html
>Ну так новый стандарт - это webp
В твоём мирке? Или гугла? Или ты из началов десятых капчуешь. Вебп уже давно доживает и проигрывает всем актуальным, если дескать вообще был в чьих-то глазах живым, лол.
>Для любителей огромных паков, это вообще идеальный формат.
В твоём мирке? Мыло сраное, а не идеальный формат, лол. Этот тред обсуждения сабжа, а не мыльных форматов конца нулевых.
Обязательно в шапку треда ссылку, чтоб больше такой чуши не писали (для приватопердолей: для просмотра сравнений нужен включенный WEBGL и разрешенные workers api): https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html
>>318045
По теме то, есть что сказать? 10 лет назад те же вскукареки слышал, какой webp не нужный и плохой, а по итогу и поддержку везде добавили и массово он начал пнг заменять, ибо легче. Да и с жпг нормально справляется.
Сегодня это самый лучший формат, если у тебя тонны пикч которые нужно быстро подогнать под один формат без проёбов. Сожрёт и пнг и жпг и везде залезет без танцев с бубном.
>в твоём мирке!
>мыло!
>доживает!
По теме то, есть что сказать? 10 лет назад те же вскукареки слышал, какой webp не нужный и плохой, а по итогу и поддержку везде добавили и массово он начал пнг заменять, ибо легче. Да и с жпг нормально справляется.
Сегодня это самый лучший формат, если у тебя тонны пикч которые нужно быстро подогнать под один формат без проёбов. Сожрёт и пнг и жпг и везде залезет без танцев с бубном.
>>318108
Глаза протри.
>По теме то, есть что сказать?
>https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html
Глаза протри.
>>318232
Мне похуй
Мне похуй
>>318045
Угу, спасибо, что предупредил о ботнете.
> для просмотра сравнений нужен включенный WEBGL и разрешенные workers api
Угу, спасибо, что предупредил о ботнете.
>>318249
Так тема треда и есть троян. Встраивать программный код в картинки, ты буквально вирусню качаешь под видом картинок, классический троянский конь, еще и название маскируется под JPEG, всем известный и безопастный. Прям комбо малвари, наебать и пропихнуть вирус.
Так тема треда и есть троян. Встраивать программный код в картинки, ты буквально вирусню качаешь под видом картинок, классический троянский конь, еще и название маскируется под JPEG, всем известный и безопастный. Прям комбо малвари, наебать и пропихнуть вирус.
>>318962
То есть, про ЖПЕГ ТРОЯН прокомментировать нечего, так и знал что во всём прав.
То есть, про ЖПЕГ ТРОЯН прокомментировать нечего, так и знал что во всём прав.
>>318921
Таблетки прими, а то шутки про уязвимые картинки уже доебали.
Там троян на уровне шрифтов true type. То есть запускается в своей винтуалке по стандарту. Если кто-то и додумается запихнуть туда код, он сработает только внутри картинки и хуй вылезет дальше.
Максимум скример сделает из картинки, что конечно смешно но троянить что-то из файлов пикча не сможет.
Таблетки прими, а то шутки про уязвимые картинки уже доебали.
Там троян на уровне шрифтов true type. То есть запускается в своей винтуалке по стандарту. Если кто-то и додумается запихнуть туда код, он сработает только внутри картинки и хуй вылезет дальше.
Максимум скример сделает из картинки, что конечно смешно но троянить что-то из файлов пикча не сможет.
29 Кб, 480x620>>325204
А что, идея здравая. Компрессия на уровне операционной системы это тема.
А что, идея здравая. Компрессия на уровне операционной системы это тема.
>>325204
Ну это не трудно, можно самому модуль сделать и перехватывать запись/чтение всех жпегов. Только может что-нибудь отвалится
Ну это не трудно, можно самому модуль сделать и перехватывать запись/чтение всех жпегов. Только может что-нибудь отвалится
68 Кб, 750x750>>325960
Как это относится к jxl?
Как это относится к jxl?
>>297880
Что-то он у меня перестает работать при превышении какого-то определенного количества выделенных файлов - окно cmd моргнет просто на 10 мс и все. Пока не смог понять закономерность, т.к. в одном случае работает со 129-ю файлами, а со 130-ю уже не хочет, а в другом - со 150-ю все ок, а со 151-м уже нет.
Может, есть какие-то лимиты на кол-во аргументов для батников или что-то около того?
>Кто-то выкладывал тут в прошлом году батник
Что-то он у меня перестает работать при превышении какого-то определенного количества выделенных файлов - окно cmd моргнет просто на 10 мс и все. Пока не смог понять закономерность, т.к. в одном случае работает со 129-ю файлами, а со 130-ю уже не хочет, а в другом - со 150-ю все ок, а со 151-м уже нет.
Может, есть какие-то лимиты на кол-во аргументов для батников или что-то около того?
>>327293
Исполни его из cmd, а не мышкой и покажи что он выдаст. Может какой анон исправит.
Исполни его из cmd, а не мышкой и покажи что он выдаст. Может какой анон исправит.
>>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 символ, то все работает. Хз так же на десятке или нет.
Короче, погуглил и думаю, причина в этом
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, на ляликсе
>>327312
https://github.com/sharkdp/fd
fd -e png -e jpg -e jpeg -e gif -x cjxl <opts> {} {.}.jxl
По умолчанию запускает параллельно по количеству ядер, можно ограничить с помощью -j <N>.
>>327306
Тебе тоже пригодится, с fd нет ограничения по количеству аргументов.
https://github.com/sharkdp/fd
fd -e png -e jpg -e jpeg -e gif -x cjxl <opts> {} {.}.jxl
По умолчанию запускает параллельно по количеству ядер, можно ограничить с помощью -j <N>.
>>327306
Тебе тоже пригодится, с fd нет ограничения по количеству аргументов.
>>327317
Спасибо, конечно, но я не совсем понимаю, как fd можно применить, если в условной папке нужно переконвертить некоторое большое кол-во пикч, кот. я могу выделить вручную, но не все из них. В варианте с >>297880 понятно: выделил нужные - отправил в батник (и только 8191-лимит тут поднасрал). А с fd как быть?
>Тебе тоже пригодится, с fd нет ограничения по количеству аргументов.
Спасибо, конечно, но я не совсем понимаю, как fd можно применить, если в условной папке нужно переконвертить некоторое большое кол-во пикч, кот. я могу выделить вручную, но не все из них. В варианте с >>297880 понятно: выделил нужные - отправил в батник (и только 8191-лимит тут поднасрал). А с fd как быть?
>>327475
Понятно, тебе не подойдет fd.
Подозреваю, что с выделением в проводнике любой скрипт или консольная программа будет натыкаться на ограничение длины аргументов.
В терминале можно было бы что-нибудь соорудить с выделением файлов с помощью какого-нибудь fzf и записи их во временный файл, потом для каждой строки в нем запускать cjxl.
Понятно, тебе не подойдет fd.
Подозреваю, что с выделением в проводнике любой скрипт или консольная программа будет натыкаться на ограничение длины аргументов.
В терминале можно было бы что-нибудь соорудить с выделением файлов с помощью какого-нибудь fzf и записи их во временный файл, потом для каждой строки в нем запускать cjxl.
У меня есть каталог с 10к файлов cjxl
Как я могу их пролистать?
Ирфан открывает их исключительно пофайлово, а при попытке листать предлагает перейти в следующую папку.
ОС - винда.
Как я могу их пролистать?
Ирфан открывает их исключительно пофайлово, а при попытке листать предлагает перейти в следующую папку.
ОС - винда.
>>327763
Ты имеешь ввиду листание "колесиком" или "через пробел"?
Накидал 12к мелких jxl в папку и у меня все нормально листает и миниатюры через T работают. Хз, обнови ирфан.
>Как я могу их пролистать?
Ты имеешь ввиду листание "колесиком" или "через пробел"?
Накидал 12к мелких jxl в папку и у меня все нормально листает и миниатюры через T работают. Хз, обнови ирфан.
13 Кб, 598x141>>327875
Нашёл причину своих страданий. Я при конвертации присваивал расширение cjxl
Большое спасибо тебе, добра. А то я уже начал ебаться с AHK, чтобы рекурсивно по PageDown каждый раз новое окно ирфана вызывать.
Нашёл причину своих страданий. Я при конвертации присваивал расширение cjxl
Большое спасибо тебе, добра. А то я уже начал ебаться с AHK, чтобы рекурсивно по PageDown каждый раз новое окно ирфана вызывать.
Нужен совет по конвертации
Есть несколько папок в пнг
Перегон в jxl loseless съэкономит место или наоборот?
Есть несколько папок в пнг
Перегон в jxl loseless съэкономит место или наоборот?
>>335256
Сэкономит.
Сэкономит.
21 Кб, 354x140>>335256
Неоптимизированные пнг сжимаются на 40-50%.
Для изображений преимущественно с текстом, то есть для скриншотов приложений без картинок, lossless webp cwebp -z 9 нередко сжимает лучше, чем jxl, и при этом быстрее. На всякий случай, webp не поддерживает больше 8-бит и молча конвертирует в 8 бит с потерями.
Если ты пользуешься cjxl и тебе важна дата модификации файлов, на никсах можно восстановить ее с помощью touch -cr file.png file.jxl.
Неоптимизированные пнг сжимаются на 40-50%.
Для изображений преимущественно с текстом, то есть для скриншотов приложений без картинок, lossless webp cwebp -z 9 нередко сжимает лучше, чем jxl, и при этом быстрее. На всякий случай, webp не поддерживает больше 8-бит и молча конвертирует в 8 бит с потерями.
Если ты пользуешься cjxl и тебе важна дата модификации файлов, на никсах можно восстановить ее с помощью touch -cr file.png file.jxl.
>>335397
Крутяк, как раз хотел свою коллекцию скриншотов перекодировать в лузлесс webp, благо макака завезла наконец поддержку.
Мимо
> lossless webp cwebp -z 9 нередко сжимает лучше, чем jxl, и при этом быстрее
Крутяк, как раз хотел свою коллекцию скриншотов перекодировать в лузлесс webp, благо макака завезла наконец поддержку.
Мимо
Хм, почему при попытке конверта пик1 с дефолтными настройками получается пик2 с поехавшей гаммой?
>>336335
Так даже лучше
Так даже лучше
>>336335
Похуй, тебе все равно не светит
Похуй, тебе все равно не светит
2 Кб, 220x229>>336335
Хочу тяночку
Хочу тяночку
Нормально без возьни смотреть такие картинки на Линухе можно только в браузере PaleMoon? Со стандартными настройками без всяких экспериментальных флагов и прочей фигни.
>>349251
Из браузеров еще Thorium.
Из остального софта много что поддерживает. Весь кутешный и гткшный софт должен поддерживать, если поставить нужные плагины.
Из браузеров еще Thorium.
Из остального софта много что поддерживает. Весь кутешный и гткшный софт должен поддерживать, если поставить нужные плагины.
>>349109
Уже взлетело, эпл впилили в последний сафари, а остальные как все мы знаем, повторяют за эпл
Уже взлетело, эпл впилили в последний сафари, а остальные как все мы знаем, повторяют за эпл
>>349380
Да не, так, хуёк. Буду пересылать всем неподдерживаемый формат, убеждая «ну чё вы, пацаны, эпол же уже одобрил, пользуйтесь! Нужно всего лишь скачать специальное приложение с его поддержкой, скачивать файлы и открывать в нём, ну. Удобно же!».
Да не, так, хуёк. Буду пересылать всем неподдерживаемый формат, убеждая «ну чё вы, пацаны, эпол же уже одобрил, пользуйтесь! Нужно всего лишь скачать специальное приложение с его поддержкой, скачивать файлы и открывать в нём, ну. Удобно же!».
>>349386
Ты даже не заметишь переход, ебанашка, если не будешь одним из этих фриков треда, которые сами все конвертируют. Просто сиди дрочи дальше на картинки в интернете и не забивай голову
Ты даже не заметишь переход, ебанашка, если не будешь одним из этих фриков треда, которые сами все конвертируют. Просто сиди дрочи дальше на картинки в интернете и не забивай голову
>>349362
GIMP и Krita это всё-таки не программы для просмотра фоток. Признаем очевидное, что в большинстве дистрибутивов Linux нет самого новейшего Ffmpeg, в котором добавлена поддержка этого формата для кодирования и декодирования. XnView поддерживает просмотр этого формата только на винде. Не зачет.
>В самом конце есть список софта:
GIMP и Krita это всё-таки не программы для просмотра фоток. Признаем очевидное, что в большинстве дистрибутивов Linux нет самого новейшего Ffmpeg, в котором добавлена поддержка этого формата для кодирования и декодирования. XnView поддерживает просмотр этого формата только на винде. Не зачет.
>>349346
Интересно... вот у меня в среде рабочего стола родной просмотрщик фоток это Xviewer. Где плагин найти?
>Весь кутешный и гткшный софт должен поддерживать, если поставить нужные плагины.
Интересно... вот у меня в среде рабочего стола родной просмотрщик фоток это Xviewer. Где плагин найти?
331 Кб, 537x640>>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
Ты видимо пропустил строчку со списком просмотрщиков изображений и прочим после иконок.
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 это всё-таки не программы для просмотра фоток.
Ты видимо пропустил строчку со списком просмотрщиков изображений и прочим после иконок.
>>213710 (OP)
>>213710 (OP)
Зато есть аппаратное декодирование.
>>213710 (OP)
> Также есть несколько относительно свежих форматов изображений, которые являются побочным продуктом, полученным при разработки видеокодеков. К примеру HEIС (HEIF) который так любит Apple происходит из видеокодека HEVC. Та же история с форматами WebP и AVIF, которые произошли из VP9 (VP8) и AV1 соответственно.
> Но так как эти кодировщики делались изначально для видео, они концептуально не настолько эффективны для хранения изображений.
Зато есть аппаратное декодирование.
>>349662
Судя по тому как ты пишешь, ты явно умный парниша и разбираешься в теме, до тебя должно быть сразу дошло, что картинка сжата в лосслесс режиме.
Можешь порекомендовать лосслесс формат, который сожмет значительно лучше?
Судя по тому как ты пишешь, ты явно умный парниша и разбираешься в теме, до тебя должно быть сразу дошло, что картинка сжата в лосслесс режиме.
Можешь порекомендовать лосслесс формат, который сожмет значительно лучше?
>>349689
bmp в архиве, и это не шутка: http://qlic.altervista.org/
Серьёзно, лослесс сжатие - это идея из 80х. Со времён арифметического кодирования там ничего принципиально не меняется. Что звук, что изображение устаканились в нулевых и сейчас ты можешь только сжигать терафлопсы ради призрачной прибавки в 5-10%.
А вот лосси - это действительно вызов. Поиск избыточности, модель восприятия, психоакустика, разные способы оценки, генеративные модели. Вот где жизнь бьёт ключом и останавливаться не собирается. Лосси в эти твои 15Мб целый артбук упаковать может, а ты разницы и не увидишь.
>лосслесс формат, который сожмет значительно лучше?
bmp в архиве, и это не шутка: http://qlic.altervista.org/
Серьёзно, лослесс сжатие - это идея из 80х. Со времён арифметического кодирования там ничего принципиально не меняется. Что звук, что изображение устаканились в нулевых и сейчас ты можешь только сжигать терафлопсы ради призрачной прибавки в 5-10%.
А вот лосси - это действительно вызов. Поиск избыточности, модель восприятия, психоакустика, разные способы оценки, генеративные модели. Вот где жизнь бьёт ключом и останавливаться не собирается. Лосси в эти твои 15Мб целый артбук упаковать может, а ты разницы и не увидишь.
17 Кб, 336x118>>349715
zpaq действительно сжал лучше, но всего лишь на 5% по сравнению с jxl.
Для gralic и bmf я не нашел исходный код, paq8px и cmix слишком медленные, судя по твоей ссылке.
И ничего из этого не поддерживается обычным софтом.
На подобных картинках скорее 20-30% по сравнению с оптимизированным png.
И какие у тебя претензии к lossy jxl?
> bmp в архиве, и это не шутка: http://qlic.altervista.org/
zpaq действительно сжал лучше, но всего лишь на 5% по сравнению с jxl.
Для gralic и bmf я не нашел исходный код, paq8px и cmix слишком медленные, судя по твоей ссылке.
И ничего из этого не поддерживается обычным софтом.
> ради призрачной прибавки в 5-10%.
На подобных картинках скорее 20-30% по сравнению с оптимизированным png.
> А вот лосси - это действительно вызов.
И какие у тебя претензии к lossy jxl?
>>349632
Если там сжатие такое же как в видеокодеках то по идее может, как на самом деле - не знаю. Но жпег устарел и сильно.
Если там сжатие такое же как в видеокодеках то по идее может, как на самом деле - не знаю. Но жпег устарел и сильно.
Компания 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
Что с ебалом, шлюхи гугловские? Не зря поддержку вашего кала отовсюду выпиливал!
>>357512
Скажу тебе по секрету, такие CVE есть для PNG\JPEG-JPG-JPEG2000\TIFF\BMP\GIF\PSD. Все графические файлы имеют проблемы с библиотеками или исполнителями. И что теперь, всю графику резать? Нет, просто используй вылеченное.
Скажу тебе по секрету, такие CVE есть для PNG\JPEG-JPG-JPEG2000\TIFF\BMP\GIF\PSD. Все графические файлы имеют проблемы с библиотеками или исполнителями. И что теперь, всю графику резать? Нет, просто используй вылеченное.
>>357524
Скажу тебе по секрету, такого пиздеца нет нигде, когда никому больше не нужное проприетарное картинкоговно от гугла оказывается дырявое, и в результате всё на свете оказывается дырявым, начиная с браузеров и заканчивая всевозможным софтом, и даже не софтом, а библиотеками вшитыми в систему как webview. Всё потому, что все сидят на игле монополиста с гуглозондом в жопе. Итоги блять.
Скажу тебе по секрету, такого пиздеца нет нигде, когда никому больше не нужное проприетарное картинкоговно от гугла оказывается дырявое, и в результате всё на свете оказывается дырявым, начиная с браузеров и заканчивая всевозможным софтом, и даже не софтом, а библиотеками вшитыми в систему как webview. Всё потому, что все сидят на игле монополиста с гуглозондом в жопе. Итоги блять.
>>357544
У mp3 тоже есть проблема с интеграцией тега и возможностью поднять права программного плеера. Четверть века прошло, никто не орет особо, mp3 везде.
Вы крикуны обычные, разделяйте данные, которыми можно делиться и данные, которые private\own, и не давайте данным вылазить в СЕТЬ. Подцепил сеть к гаджету - твои данные не твои, а СЕТИ, иного не дано.
У mp3 тоже есть проблема с интеграцией тега и возможностью поднять права программного плеера. Четверть века прошло, никто не орет особо, mp3 везде.
Вы крикуны обычные, разделяйте данные, которыми можно делиться и данные, которые private\own, и не давайте данным вылазить в СЕТЬ. Подцепил сеть к гаджету - твои данные не твои, а СЕТИ, иного не дано.
>>357551
У mp3 нет проблем, потому что это не гуглозонд от одного производителя впердоленный везде где надо и не надо, просто патамушта, чтобы бэкдоры гугла были во всём.
mp3 реализуется разными библиотеками от разных разработчиков, и в большинстве софта вообще не встроено. Если даже в одной какой-то библиотеке есть уязвимость, это капля в море, вообще не проблема.
А гуглопараша одна на весь мир, и встроена во всё на свете, все под гуглодырами. И как только дыру опубликовали, любой васян уже может ломать всё на свете. Какая красота. Спасибо монополии, гулагу барина гугла, хозяина интернета и всего софта во всём мире.
У mp3 нет проблем, потому что это не гуглозонд от одного производителя впердоленный везде где надо и не надо, просто патамушта, чтобы бэкдоры гугла были во всём.
mp3 реализуется разными библиотеками от разных разработчиков, и в большинстве софта вообще не встроено. Если даже в одной какой-то библиотеке есть уязвимость, это капля в море, вообще не проблема.
А гуглопараша одна на весь мир, и встроена во всё на свете, все под гуглодырами. И как только дыру опубликовали, любой васян уже может ломать всё на свете. Какая красота. Спасибо монополии, гулагу барина гугла, хозяина интернета и всего софта во всём мире.
>>357552
Чел, пойми. У тебя проблема с расставлением границы между нашим, твоим и общим. Если ты не желаешь полного деанона и взлома всего и вся - сиди оффлайн или в тайгу беги.
Или учись и повышай шкиллы защиты, сиди за аппаратным файером на фряхе, и изучай каждый пук нотиков и алерты этого файрлола. Просто сейчас ты смешон очень, ты предельно параноидален, ты даже не понимаешь, что компы придумывали как сетевые клиенты для сервака, и ко всему, что в них есть, можно механистически получить доступ, и это ВПОЛНЕ НОРМАЛЬНАЯ СИТУАЦИЯ, это же парадигма компа такая. И в мобильных осях также, ты доверяешь гуглу все свои данные, или эплл свои данные, и так далее. И когда ты начинаешь параноить и ныть, это вызывает непонимание. Ты похож на ребенка, который ест говно из подгузника, мажет его везде в хате и орет, что невкусно. Ты или вырастай и умней, или прекращай пользоваться ВСЕМ софтом, потому что он ВЕСЬ имеет ошибки, и 1% из этих ошибок позволяет получать права на доступ к твоим данным.
Всё, можешь не ррякать мне в ответ, просто прочитай и осмысли.
> это не гуглозонд
Чел, пойми. У тебя проблема с расставлением границы между нашим, твоим и общим. Если ты не желаешь полного деанона и взлома всего и вся - сиди оффлайн или в тайгу беги.
Или учись и повышай шкиллы защиты, сиди за аппаратным файером на фряхе, и изучай каждый пук нотиков и алерты этого файрлола. Просто сейчас ты смешон очень, ты предельно параноидален, ты даже не понимаешь, что компы придумывали как сетевые клиенты для сервака, и ко всему, что в них есть, можно механистически получить доступ, и это ВПОЛНЕ НОРМАЛЬНАЯ СИТУАЦИЯ, это же парадигма компа такая. И в мобильных осях также, ты доверяешь гуглу все свои данные, или эплл свои данные, и так далее. И когда ты начинаешь параноить и ныть, это вызывает непонимание. Ты похож на ребенка, который ест говно из подгузника, мажет его везде в хате и орет, что невкусно. Ты или вырастай и умней, или прекращай пользоваться ВСЕМ софтом, потому что он ВЕСЬ имеет ошибки, и 1% из этих ошибок позволяет получать права на доступ к твоим данным.
Всё, можешь не ррякать мне в ответ, просто прочитай и осмысли.
>>357554
Не сри дебил.
- Гуглодыры везде, потому что гугл охуел и везде.
- И это не теоретические дыры на словах, а реальные дыры исполнения кода от любой картинки в интернете.
- Картинки это не шутки, картинки везде. Дыра в картинках, это значит ты подключился в интернету и всё, пизда тебе, это даже хуже чем WannaCry.
- Толще дыры нельзя придумать, и она везде, в любом софте использующем интернет, на любой платформе, потому что мистер гугл везде, вместе со своими дырами.
Не сри тупостью, дебил.
Не сри дебил.
- Гуглодыры везде, потому что гугл охуел и везде.
- И это не теоретические дыры на словах, а реальные дыры исполнения кода от любой картинки в интернете.
- Картинки это не шутки, картинки везде. Дыра в картинках, это значит ты подключился в интернету и всё, пизда тебе, это даже хуже чем WannaCry.
- Толще дыры нельзя придумать, и она везде, в любом софте использующем интернет, на любой платформе, потому что мистер гугл везде, вместе со своими дырами.
>ВПОЛНЕ НОРМАЛЬНАЯ СИТУАЦИЯ
Не сри тупостью, дебил.
>>349436
https://artifacts.lucaversari.it/info.txt
Так это сами библиотеки и кодировщик.
Это я просто установил всё одной командой?
apt install libjxl-tools
Но это не заставит GTK-программы просмотра фото поддерживать формат JPEG-XL. Вот установка jxl-pixbuf-loader должны это сделать в теории. Только под всякие Ubuntu его пока нет готового собранного. Для Федорки есть. Может там более модная версия GTK нужна х.з.
>Для дебиана libjxl-gdk-pixbuf я беру отсюда:
https://artifacts.lucaversari.it/info.txt
Так это сами библиотеки и кодировщик.
Это я просто установил всё одной командой?
apt install libjxl-tools
Но это не заставит GTK-программы просмотра фото поддерживать формат JPEG-XL. Вот установка jxl-pixbuf-loader должны это сделать в теории. Только под всякие Ubuntu его пока нет готового собранного. Для Федорки есть. Может там более модная версия GTK нужна х.з.
>>357671
Скачал архив jxl-debs-amd64-ubuntu-22.04-v0.8.1.tar.gz и там нет
>Тут тоже есть внутри тар архивов:
Скачал архив jxl-debs-amd64-ubuntu-22.04-v0.8.1.tar.gz и там нет
>jxl-pixbuf-loader
177 Кб, 693x404>>358271
Там есть libjxl-gdk-pixbuf, он и нужен.
Там есть libjxl-gdk-pixbuf, он и нужен.
>>357512
Там же в этих браузерах песочница в песочнице песком песочит. Да так, что элементарные действия лагают как по времен пенька. Неужели всё это не помогает?
Там же в этих браузерах песочница в песочнице песком песочит. Да так, что элементарные действия лагают как по времен пенька. Неужели всё это не помогает?
>>360505
Ты не понимаешь, что значит беды с башкой
Ты не понимаешь, что значит беды с башкой
888 Кб, 1857x1080Ну вот
Ради чего, блять
test1 - cjxl - офф конвертер - качество то же, размер с мб ушел в 333 кб
test2 - libvips - мультиконвертер с поддержкой - качество сжалось чутка, размер ушел с 1 мб в 96 кб
вот и сиди теперь
Я буду конверитить оффициалом потому что качество нужно, но это какая-то шляпа
Ради чего, блять
test1 - cjxl - офф конвертер - качество то же, размер с мб ушел в 333 кб
test2 - libvips - мультиконвертер с поддержкой - качество сжалось чутка, размер ушел с 1 мб в 96 кб
вот и сиди теперь
Я буду конверитить оффициалом потому что качество нужно, но это какая-то шляпа
>>364053
Да, можно, Я просто пока предпочитаю оффициал в любом случае пока
Да, можно, Я просто пока предпочитаю оффициал в любом случае пока
Компрессор для жпегов, примерно как jxl lossless transcode, но быстрее при той же или слегка лучшей степени сжатия:
https://github.com/microsoft/lepton_jpeg_rust
https://github.com/microsoft/lepton_jpeg_rust
>>381711
Сжимает лучше, но lepton это для архивации, ты не откроешь его ни в каком просмотрщике изображений, редакторе или браузере.
Сжимает лучше, но lepton это для архивации, ты не откроешь его ни в каком просмотрщике изображений, редакторе или браузере.
>>381750
Получается хуита без задач.
>но lepton это для архивации, ты не откроешь его ни в каком просмотрщике изображений, редакторе или браузере
Получается хуита без задач.
>>381929
Не согласен
На серверах картинкохранилищах вроде какого-нибудь imgur можно хранить архивированные (старые) фоточки и разархивировать их на лету по запросу пользователя
Конечно, в мире победившего jxl такой нужды не будет, так как у всех будут декодировщики в браузерах, но пока что имеем что имеем
Не согласен
На серверах картинкохранилищах вроде какого-нибудь imgur можно хранить архивированные (старые) фоточки и разархивировать их на лету по запросу пользователя
Конечно, в мире победившего jxl такой нужды не будет, так как у всех будут декодировщики в браузерах, но пока что имеем что имеем
>>382057
Это и есть та единственная задача, которая им решается. Спектр применения слушком узок, и даже для решения той задачи для которой он создан существуют альтернативы, пусть возможно для конкретной ситуации подходящие немного хуже, но более гибкие по своей сути.
Наверняка старые пикчи, которые ты предлагаешь архивировать, имеют нулевой трафик. Если цель - сэкономить место в датацентрах, то тот самый заблудший, случайно открывший страницу, наверняка сможет и подождать пару секунд пока его запрос сначала по всем кешам промахнется, а потом и картинка декодируется наилучшим кодеком. Ну тут впрочем без знания того как там все устроено можно только лишь прикидывать и гадать.
>На серверах картинкохранилищах вроде какого-нибудь 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
>>257646
Шакалит. Особенно градиенты. Шакалит цветопередачу. Вызывает бандинг вследствие урезания и так урезаного yuv до tv диапазона. Добавляет ложные границы на градиентах в виде горизонтальных или вертикальных прямых линий, в следствие работы механизма внутрикадрового предсказания.
Шакалит. Особенно градиенты. Шакалит цветопередачу. Вызывает бандинг вследствие урезания и так урезаного yuv до tv диапазона. Добавляет ложные границы на градиентах в виде горизонтальных или вертикальных прямых линий, в следствие работы механизма внутрикадрового предсказания.
118 Кб, 671x517В виндовсе возможно будет поддержка jxl из коробки:
https://nitter.cz/jonsneyers/status/1751453002299552202#m
https://nitter.cz/jonsneyers/status/1751453002299552202#m
>>213710 (OP)
Нахуя все это ебаное говно и дерьмо типа дерьма webp нужно, если есть православный жпег, нахуя утырки из пугла пытаются уже картинки под себя подмять? Основная нагрузка на каналы современных шизоронетов идет в виде видеотрафа, на картинки всем похуй сколько они там весят - на мобилах и десктопах уже терабайтные стораджи. Я не луддит, более того я наносек, но за этим говном нет ничего кроме скрытого стремления отдельных копрораций и купленных ими комитетов по стандартизации к технологической монополизации.
Только при существенном аппаратном прогрессе средств записи/генерации и отображения пикч потребуется новый формат, вместо эволюционно-зрелого устоявшегося жпега на котором запечатлена уже вся цифровая история человечества. Вот когда у каждого быдла в айфоне 55 ProHyperMaxKekus будет 1024-битный голографический проектор и 3D-голосканер, вот тогда и приходите.
>>415112
О Боги, неужели я встретил на сраче хоть одно адекватное мнение относительно этого уебищного энкодера.
Нахуя все это ебаное говно и дерьмо типа дерьма webp нужно, если есть православный жпег, нахуя утырки из пугла пытаются уже картинки под себя подмять? Основная нагрузка на каналы современных шизоронетов идет в виде видеотрафа, на картинки всем похуй сколько они там весят - на мобилах и десктопах уже терабайтные стораджи. Я не луддит, более того я наносек, но за этим говном нет ничего кроме скрытого стремления отдельных копрораций и купленных ими комитетов по стандартизации к технологической монополизации.
Только при существенном аппаратном прогрессе средств записи/генерации и отображения пикч потребуется новый формат, вместо эволюционно-зрелого устоявшегося жпега на котором запечатлена уже вся цифровая история человечества. Вот когда у каждого быдла в айфоне 55 ProHyperMaxKekus будет 1024-битный голографический проектор и 3D-голосканер, вот тогда и приходите.
>>415112
О Боги, неужели я встретил на сраче хоть одно адекватное мнение относительно этого уебищного энкодера.
>>418289
Ну как бы знаешь, картинки это не только фоточки. И если лично тебе не нужно, то это не значит что никому не нужно.
Да и хранить или передавать фотографические изображения на которых в фотошопе навесили альфа канал в том же PNG как то непрактично. А webp позволяет хоть криво косо, но пожать такое в lossy. И хотя в вебе это уже не так актуально, хотя-бы из-за наличия формата AVIF, но платформы такие как телега, дискорд и тот же двач поддержали только webp.
>>418292
Как то странно такое слышать от
> Только при существенном аппаратном прогрессе средств записи/генерации и отображения пикч потребуется новый формат
> альфа канал
> православный жпег
Ну как бы знаешь, картинки это не только фоточки. И если лично тебе не нужно, то это не значит что никому не нужно.
Да и хранить или передавать фотографические изображения на которых в фотошопе навесили альфа канал в том же PNG как то непрактично. А webp позволяет хоть криво косо, но пожать такое в lossy. И хотя в вебе это уже не так актуально, хотя-бы из-за наличия формата AVIF, но платформы такие как телега, дискорд и тот же двач поддержали только webp.
>>418292
> heic, поправил тебя.
Как то странно такое слышать от
> (Microsoft Windows 10: Chromium based)
>>418289
Датасеты, занимающие десятки терабайт памяти, с тобой не согласны.
Датасеты, занимающие десятки терабайт памяти, с тобой не согласны.
1006 Кб, 1000x778>>418289
Вся православность жипега в том что ты привык к его артефактам. Как привык к артефактам плёночного кино, винила, vhs и mp3. Настолько привык, что это стало частью эстетики. Что люди осознанно имитируют эти артефакты.
Привыкнешь со временим и к эстетике эпохи webp/heic с его мылом и дорисованными нейросетевыми тентаклями.
>православный жпег
Вся православность жипега в том что ты привык к его артефактам. Как привык к артефактам плёночного кино, винила, vhs и mp3. Настолько привык, что это стало частью эстетики. Что люди осознанно имитируют эти артефакты.
Привыкнешь со временим и к эстетике эпохи webp/heic с его мылом и дорисованными нейросетевыми тентаклями.
>>418491
Кстати, об артефактах, jxl намного лучше справляется с текстом.
С дефолтным -d 1 / -q 90 есть небольшие изменения цвета, но нет артефактов вокруг букв как у жпега.
Кстати, об артефактах, jxl намного лучше справляется с текстом.
С дефолтным -d 1 / -q 90 есть небольшие изменения цвета, но нет артефактов вокруг букв как у жпега.
>>418355
В 11-ой HEIC из коробки.
> Как то странно такое слышать от
> (Microsoft Windows 10: Chromium based)
В 11-ой HEIC из коробки.
>>418491
ненавижу ебаную вебрепу ака швабп
сука его ни один нормальный хуессенджер вроде дуровсрама и другого говнища не жрет искаропки и прикрепят в виде файлика,
шиндус при печате портит цвета и делает их тусклыми, я буду рад когда его добьет хуефф ака эпплоговнище и авиф который недовидеоформат статичный
ненавижу ебаную вебрепу ака швабп
сука его ни один нормальный хуессенджер вроде дуровсрама и другого говнища не жрет искаропки и прикрепят в виде файлика,
шиндус при печате портит цвета и делает их тусклыми, я буду рад когда его добьет хуефф ака эпплоговнище и авиф который недовидеоформат статичный
>>419703
Из этих двух я бы выбрал AVIF. Но тут как раз JPEG XL метит в
> буду рад когда его добьет хуефф ака эпплоговнище и авиф который недовидеоформат статичный
Из этих двух я бы выбрал AVIF. Но тут как раз JPEG XL метит в
> эпплоговнище
>>419740
это какой-то ебаный раржипег, шиндусом нормально не просматривается, а внутри в одном файле может еще что-то лежать, но посмотрети вы можете только на дорогущем оверпрайснутом говнофоне, ну или установив хакинтош...
в общем какая-то ересь, благо хоть частично в шиндусе работает
это какой-то ебаный раржипег, шиндусом нормально не просматривается, а внутри в одном файле может еще что-то лежать, но посмотрети вы можете только на дорогущем оверпрайснутом говнофоне, ну или установив хакинтош...
в общем какая-то ересь, благо хоть частично в шиндусе работает
>>420892
Речь о том, что webp, avif, heif все основаны на видеокодеках, vp8, av1 и h265 соответственно., то есть они все "недовидеоформаты".
В бесплатном линуксе тоже можно.
Речь о том, что webp, avif, heif все основаны на видеокодеках, vp8, av1 и h265 соответственно., то есть они все "недовидеоформаты".
> посмотрети вы можете только на дорогущем
В бесплатном линуксе тоже можно.
>>421011
Но это им не мешает более качественно показывать рисованные картинки, а не фотографии. В отличие от этого вашего Jpeg_Xl. Со стандартными параметрами конвертации. А то сторонники jpeg-xl любят рассказывать про особенности конвертации и ключи всякие для своего этого кодека чтобы правильно картинку конвертировать. У webp и avif это получается лучше для картинок при конвертации со стандартными параметрами.
>Речь о том, что webp, avif, heif все основаны на видеокодеках, vp8, av1 и h265 соответственно., то есть они все "недовидеоформаты".
Но это им не мешает более качественно показывать рисованные картинки, а не фотографии. В отличие от этого вашего Jpeg_Xl. Со стандартными параметрами конвертации. А то сторонники jpeg-xl любят рассказывать про особенности конвертации и ключи всякие для своего этого кодека чтобы правильно картинку конвертировать. У webp и avif это получается лучше для картинок при конвертации со стандартными параметрами.
>>425288
Не нашел такого в этом треде например.
Может быть, но где данные подтверждающие это?
> А то сторонники jpeg-xl любят рассказывать про особенности конвертации и ключи всякие для своего этого кодека чтобы правильно картинку конвертировать.
Не нашел такого в этом треде например.
> У webp и avif это получается лучше для картинок при конвертации со стандартными параметрами.
Может быть, но где данные подтверждающие это?
>>425288
Ты наверно живешь в какой-то параллельной реальности. Это для avifenc нужны параметры, для включения 10-ти битного режима, для включения адаптивного квантования, задать границы минимального, максимального и среднего квантования.
В то время как для jpeg-xl я мог бы обойтись именем входного и выходного файла. Я как то пробовал прогонять картинку через https://github.com/Blobfolio/refract, точнее несколько картинок, и -d 1 очень сложно отличить от оригинала, даже на тёмных участках. Бывало даже такое, что получалось сжать даже сильнее. А для avifenc и тем более webp приходилось завышать уровень качества. И webp в ряде случаев слишком сильно режет качество есть параметр качества там меньше 95.
> А то сторонники 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
Бамп.
>>213710 (OP)
Тут уже 300 постов насрали и думаю, что высказали такое мнение, но я всеравно досру сверху.
Эта хуйня НИНУЖНА!
Просто потому, что сейчас диски измеряются терабайтами, даже если ты хранишь кучу картинок, которые весят 10 МБ каждая, то на терабайт тебе придется 100 000 картинок.
Если ты в день будешь использовать 50 картинок, то у тебя уйдет больше 5 лет чтоб все их хоть раз открыть. Это дохуя.
У людей нет проблем с местом. Это только у всяких контор есть проблема с местом - вот щас много порногифок в виде webp представлено, чтоб экономить место на серверах, и это меня дохуя раздражает.
Эти новые форматы картинок - попытка решить проблему, которой нет. Разве что только каким-то супер узким специалистам, которые обрабатывают дохуища свадебных фотографий.
Вот видео - другое дело. Иметь возможность на двоще выкладывать 10 мб видео, которое в 4к и 60фпс длится десять минут - вот это заебись технология.
Второе:
Неудобно. Вот я чтоб найти анимированый пикрилейтед написал в гугле explanation meme gif
И я уже в результатах вижу где анимировано, а где нет. Я не тратя время уже знаю куда нажимать.
Потому что гиф уже ассоциируется с анимацией. Если все будет храниться в одном формате то придется дольше искать. То же самое с пнг. Если я пишу nasa logo png то с 90% вероятностью будет искать с альфаканалом уже вырезаное лого. Как мне блять искать это в jpgxxl ???
Перегонять из формата в формат и назад - вообще дебильная задача. Кому это нужно?
Короче, пока толку никакого, одни проблемы с совместимостью и срач среди вендоров.
Вердикт - пускай лучше для видео форматы придумывают, а тут нехуй ломать то. что не сломано.
Тут уже 300 постов насрали и думаю, что высказали такое мнение, но я всеравно досру сверху.
Эта хуйня НИНУЖНА!
Просто потому, что сейчас диски измеряются терабайтами, даже если ты хранишь кучу картинок, которые весят 10 МБ каждая, то на терабайт тебе придется 100 000 картинок.
Если ты в день будешь использовать 50 картинок, то у тебя уйдет больше 5 лет чтоб все их хоть раз открыть. Это дохуя.
У людей нет проблем с местом. Это только у всяких контор есть проблема с местом - вот щас много порногифок в виде webp представлено, чтоб экономить место на серверах, и это меня дохуя раздражает.
Эти новые форматы картинок - попытка решить проблему, которой нет. Разве что только каким-то супер узким специалистам, которые обрабатывают дохуища свадебных фотографий.
Вот видео - другое дело. Иметь возможность на двоще выкладывать 10 мб видео, которое в 4к и 60фпс длится десять минут - вот это заебись технология.
Второе:
Неудобно. Вот я чтоб найти анимированый пикрилейтед написал в гугле explanation meme gif
И я уже в результатах вижу где анимировано, а где нет. Я не тратя время уже знаю куда нажимать.
Потому что гиф уже ассоциируется с анимацией. Если все будет храниться в одном формате то придется дольше искать. То же самое с пнг. Если я пишу nasa logo png то с 90% вероятностью будет искать с альфаканалом уже вырезаное лого. Как мне блять искать это в jpgxxl ???
Перегонять из формата в формат и назад - вообще дебильная задача. Кому это нужно?
Короче, пока толку никакого, одни проблемы с совместимостью и срач среди вендоров.
Вердикт - пускай лучше для видео форматы придумывают, а тут нехуй ломать то. что не сломано.
>>436118
ух как скрепно, двачую. да и интернет ентот ваш вообще нинужен, все можно в телевизоре посмотреть.
ух как скрепно, двачую. да и интернет ентот ваш вообще нинужен, все можно в телевизоре посмотреть.
>>436217
Пукать ты знатно умеешь, а конкретно по какому-то пункту есть возражения с аргументами? Нет? Ну так иди дальше попукивай - можешь свисток в дупу себе вставить, чтоб веселее было.
Пукать ты знатно умеешь, а конкретно по какому-то пункту есть возражения с аргументами? Нет? Ну так иди дальше попукивай - можешь свисток в дупу себе вставить, чтоб веселее было.
>>436118
Первый пункт разъёбывается тем, что сегодня с изображениями пользователь взаимодействует в основном через интернет. И если ты не заметил, сайты зачастую неплохо их так шакалят для того, чтобы у пользователей с медленным прдключением был удовлетворительный пользовательский опыт.
А JXL убивает одновременно улучшает пользовательский опыт двумя фичами: прогрессивным декодированием и лучшим соотношением размера к качеству.
Картинкохранитель, пора вылезти из морозилки, эпоха интернета наступила
Первый пункт разъёбывается тем, что сегодня с изображениями пользователь взаимодействует в основном через интернет. И если ты не заметил, сайты зачастую неплохо их так шакалят для того, чтобы у пользователей с медленным прдключением был удовлетворительный пользовательский опыт.
А JXL убивает одновременно улучшает пользовательский опыт двумя фичами: прогрессивным декодированием и лучшим соотношением размера к качеству.
Картинкохранитель, пора вылезти из морозилки, эпоха интернета наступила
>>436419
Рекламой надо меньше засирать сайты, а не жать картинки.
Твой аргумент не валиден, потому что если картинка ненужная - типа шапка новости, то она может быть пожата - всем похуй. Если же человек идет именно скачать какую-то конкретную картинку, то он может и подождать чуток, но получить качественное изображение.
>удовлетворительный пользовательский опыт.
Рекламой надо меньше засирать сайты, а не жать картинки.
Твой аргумент не валиден, потому что если картинка ненужная - типа шапка новости, то она может быть пожата - всем похуй. Если же человек идет именно скачать какую-то конкретную картинку, то он может и подождать чуток, но получить качественное изображение.
>>436118
Давно пора бы понять простую истину. Высеры корпорации гугла нужны только корпорации и её сотрудникам, остальным оно не только не нужно, но и активно вредит, потому что интересы корпораций всегда идут против интересов людей. Такой сегодня мир, пора бы уже выглянуть в окно на реальность.
Давно пора бы понять простую истину. Высеры корпорации гугла нужны только корпорации и её сотрудникам, остальным оно не только не нужно, но и активно вредит, потому что интересы корпораций всегда идут против интересов людей. Такой сегодня мир, пора бы уже выглянуть в окно на реальность.
>>436581
Вы только посмотрите на этого марксиста!
>интересы корпораций всегда идут против интересов людей
Вы только посмотрите на этого марксиста!
>>436118
Анон, ты долбоеб. Чтобы например хуйню по ссылке ворочать, нужно как минимум 20 ТБ памяти просто чтобы это всё нахуй работало.
>total size is now approximately 8 terabytes (8,000 GB)
Анон, ты долбоеб. Чтобы например хуйню по ссылке ворочать, нужно как минимум 20 ТБ памяти просто чтобы это всё нахуй работало.
191 Кб, 877x835>>437615
Это мне нужно ворочать или кому? Мне нах не всралось хранить 8 гб какой-то параши. И тебе нах не всралось. Для личного пользования это никому нах не всралось. Это нужно только тем, кто арендует сервера и трафик, то есть уже не для домашнего пользованя.
Даже еслилично тебе нужно хранить все это говно, то тебе все равно нужно бует отдельное хранилище, потмоу что если это 8 т пожать вдвое то все равно будет 4 т.
Смотрим цены - примерно 200 баксов за 8 т
Ок, 4 т ты купишь за 100. Итого этот всратый формат позволит тебе сэкономить сто баксов. Оно того стоит? Сто баксов это сейчас копейки, если ты не бомж или не школьник, который на обедах экономит. Тем более что эти 100 баксов ты растягиваешь на долгие годы использования. Ты можешь пользоваться этим винтом 10 лет тогда выходит по 10 баксов в год. Это 80 центов в месяц. По текущему курсу - 70 рублей.
То есть у тебя выбор - платить 70 рублей в месяц и вообще не заморачиваться. Просто без задней мысли юзать джипеги и пнг. Открывать пеинтом за секунду, вносить правки, и тут же сохранять. Отправлять в любом мессенджере и иметь предпросмотр адекватный.
Или пердолиться с конвертациями-хуйвертациями и с софтом, который поддерживает это. Иметь проблемы с открытием где-то не на твоем ПуКа и прочие красноглазые прелести.
Ответ очевиден.
Это мне нужно ворочать или кому? Мне нах не всралось хранить 8 гб какой-то параши. И тебе нах не всралось. Для личного пользования это никому нах не всралось. Это нужно только тем, кто арендует сервера и трафик, то есть уже не для домашнего пользованя.
Даже еслилично тебе нужно хранить все это говно, то тебе все равно нужно бует отдельное хранилище, потмоу что если это 8 т пожать вдвое то все равно будет 4 т.
Смотрим цены - примерно 200 баксов за 8 т
Ок, 4 т ты купишь за 100. Итого этот всратый формат позволит тебе сэкономить сто баксов. Оно того стоит? Сто баксов это сейчас копейки, если ты не бомж или не школьник, который на обедах экономит. Тем более что эти 100 баксов ты растягиваешь на долгие годы использования. Ты можешь пользоваться этим винтом 10 лет тогда выходит по 10 баксов в год. Это 80 центов в месяц. По текущему курсу - 70 рублей.
То есть у тебя выбор - платить 70 рублей в месяц и вообще не заморачиваться. Просто без задней мысли юзать джипеги и пнг. Открывать пеинтом за секунду, вносить правки, и тут же сохранять. Отправлять в любом мессенджере и иметь предпросмотр адекватный.
Или пердолиться с конвертациями-хуйвертациями и с софтом, который поддерживает это. Иметь проблемы с открытием где-то не на твоем ПуКа и прочие красноглазые прелести.
Ответ очевиден.
>>438244
Двачую адеквата. Все убийцы популярных форматов погорели именно на этом, даже обладая объективно лучшими характеристиками.
Двачую адеквата. Все убийцы популярных форматов погорели именно на этом, даже обладая объективно лучшими характеристиками.
>>438244
Нихуя себе, в 2 раза меньше затраты на хранилище это хуйня? А ведь может оказаться что сжимать ровно в два раза и не обязательно, потому что можно сжать сильнее и с потерями, ведь качество каждой отдельной пикчи не обязательно должно быть идеальным.
Какой же ты нахуй невыносимый дегенерат, чтобы эту хуйню ворочать нужна в первую очередь ПРОИЗВОДИТЕЛЬНОСТЬ, рандомного чтения и рандомной записи, ебанат с экономфака. Твои скрипящие-пердящие свистелки упали разве что тем самым школьникам-бомжам, которые на обедах экономят и которые готовы ждать пока у них 100к файлов скопируются пока их математичка с физруком ебут сначала в шкалке а потом в продленке. Но ты всё-таки ради эксперимента прикинь хуй к носу и разузнай, в какую копеечку обойдется хотя бы 20 ТБ с приемлимой производительностью, учитывая, что это самый минимум, и нужно ещё обеспечить избыточность чтобы не проебать драгоценные данные, и собственно нужно пространство, чтобы иметь возможность хранить например модифицированные копии или более маленькие, отфильтрованные подмножества этого датасета. А потом вспомни что такое альтернативные издержки и объясни мне почему так делать экономически невыгодно, если есть возможность купить в 2 раза меньше сидюков и докинуть две б/у 3090 сверху.
Конкретно ТЫ этим не занимаешься потому что ты ТУПОЙ и это ДОРОГО или ДОЛГО. Согласен, что стоимость хранилищ - не главная проблема при тренировки нейросеток на данный момент, но это тем не менее одна из самых важных проблем.
>потмоу что если это 8 т пожать вдвое то все равно будет 4 т.
Нихуя себе, в 2 раза меньше затраты на хранилище это хуйня? А ведь может оказаться что сжимать ровно в два раза и не обязательно, потому что можно сжать сильнее и с потерями, ведь качество каждой отдельной пикчи не обязательно должно быть идеальным.
Какой же ты нахуй невыносимый дегенерат, чтобы эту хуйню ворочать нужна в первую очередь ПРОИЗВОДИТЕЛЬНОСТЬ, рандомного чтения и рандомной записи, ебанат с экономфака. Твои скрипящие-пердящие свистелки упали разве что тем самым школьникам-бомжам, которые на обедах экономят и которые готовы ждать пока у них 100к файлов скопируются пока их математичка с физруком ебут сначала в шкалке а потом в продленке. Но ты всё-таки ради эксперимента прикинь хуй к носу и разузнай, в какую копеечку обойдется хотя бы 20 ТБ с приемлимой производительностью, учитывая, что это самый минимум, и нужно ещё обеспечить избыточность чтобы не проебать драгоценные данные, и собственно нужно пространство, чтобы иметь возможность хранить например модифицированные копии или более маленькие, отфильтрованные подмножества этого датасета. А потом вспомни что такое альтернативные издержки и объясни мне почему так делать экономически невыгодно, если есть возможность купить в 2 раза меньше сидюков и докинуть две б/у 3090 сверху.
>Даже еслилично тебе
Конкретно ТЫ этим не занимаешься потому что ты ТУПОЙ и это ДОРОГО или ДОЛГО. Согласен, что стоимость хранилищ - не главная проблема при тренировки нейросеток на данный момент, но это тем не менее одна из самых важных проблем.
>>439306
Да, каждый второй дома на 20 терабайтах тренгирует нейросетки. Без этого сегодня обычному юзеру никах. Ты просто пукнутое животное.
>тренировки нейросеток
Да, каждый второй дома на 20 терабайтах тренгирует нейросетки. Без этого сегодня обычному юзеру никах. Ты просто пукнутое животное.
>>439474
Если бы ты мог, ты бы тоже попробовал, кек.
Если бы ты мог, ты бы тоже попробовал, кек.
>>213710 (OP)
ну все, пошел писать эксплойт на уровне ядра, который будет через баг с состоянием гонки писать в кернелспейс
мало вам было взлома айфона через ебучий pdf, да?
> почти полнота по тьюрингу
ну все, пошел писать эксплойт на уровне ядра, который будет через баг с состоянием гонки писать в кернелспейс
мало вам было взлома айфона через ебучий pdf, да?
>>217393
Летит "to the moon" или в канаву?
Летит "to the moon" или в канаву?
Знатоки форматов, прошу вашей помощи. Вот тут есть порно-гифка.
Она работает в браузере. Если ее сохранить и открыть в браузере, то тоже работает. А на компьютере не проигрывается анимация. Попытки сохранить в анимированый вебп а потом обратно преобразовать в гиф не помогло - все равно не проигрывается. Пишет что неизвестный формат или битый фал. Но файл не битый и формат гиф.
Как сделать так чтоб проигрывалось?
https://porngipfy.com/nia-nacci-4-51725/
Она работает в браузере. Если ее сохранить и открыть в браузере, то тоже работает. А на компьютере не проигрывается анимация. Попытки сохранить в анимированый вебп а потом обратно преобразовать в гиф не помогло - все равно не проигрывается. Пишет что неизвестный формат или битый фал. Но файл не битый и формат гиф.
Как сделать так чтоб проигрывалось?
https://porngipfy.com/nia-nacci-4-51725/
>>447653
Совершенно обычный GIF-файл, 2322056 байт, не обрезан, не испорчен, нормально импортируется в редактор и показывается. Обратись к разработчику программы, которой пользуешься для просмотра картинок, либо поставь другую, нормальную.
Совершенно обычный GIF-файл, 2322056 байт, не обрезан, не испорчен, нормально импортируется в редактор и показывается. Обратись к разработчику программы, которой пользуешься для просмотра картинок, либо поставь другую, нормальную.
>>447653
УМВР. Открыл в XnView MP и в Xviewer. Всё нормально.
Скачай нормальную прогу для просмотра фоток себе и не парь мозги людям.
>Она работает в браузере. Если ее сохранить и открыть в браузере, то тоже работает. А на компьютере не проигрывается анимация.
УМВР. Открыл в XnView MP и в Xviewer. Всё нормально.
Скачай нормальную прогу для просмотра фоток себе и не парь мозги людям.
281 Кб, 1925x1078>>318045
Теперь рилейтед поддерживает сабж форматы. Единственный барьер не быть лучшим вьювером с собственным ФМ кажется уже преодолен, вместо прошлого громоздкого пика на кутэ. Вьюверы без своих собтвенных ФМ в счет не беру, кому-то и такого достаточно, их не сравниваю.
Теперь рилейтед поддерживает сабж форматы. Единственный барьер не быть лучшим вьювером с собственным ФМ кажется уже преодолен, вместо прошлого громоздкого пика на кутэ. Вьюверы без своих собтвенных ФМ в счет не беру, кому-то и такого достаточно, их не сравниваю.
309 Кб, 1004x434Собрал ванильный хромиум с блэкджеком и шлюхами патчем для jpeg xl.
Осталось только найти вебсайты, которые выдают jxl картинки.
Осталось только найти вебсайты, которые выдают jxl картинки.
>>442735
А ждать надо от гугля. Прошлогодняя история с webp тебя ничему не научила?
>Жду эксплоита от тебя.
А ждать надо от гугля. Прошлогодняя история с webp тебя ничему не научила?
>>481769
В webp очередное си говно с переполнением буфера, тут речь про полноту по тьюрингу была.
Впрочем, libjxl на крестах написан, можешь к этому прикопаться.
В webp очередное си говно с переполнением буфера, тут речь про полноту по тьюрингу была.
Впрочем, libjxl на крестах написан, можешь к этому прикопаться.
>>484117
Есть что-нибудь, во что емакс не может?
Есть что-нибудь, во что емакс не может?
М
27 Кб, 663x345https://github.com/sylikc/jpegview
Неплохой просмотрщик изображений с поддержкой JPEG XL, HEIC, AVIF.
Оставлю тут, может кому пригодится, удобная штука.
Так же в PureREF недавно завезли поддержку JXL.
Неплохой просмотрщик изображений с поддержкой JPEG XL, HEIC, AVIF.
Оставлю тут, может кому пригодится, удобная штука.
Так же в PureREF недавно завезли поддержку JXL.
>>299989
Этот GIF уже давно устарел и не актуален
Этот GIF уже давно устарел и не актуален
>>226680
А что, в это кто-то, кроме девочек среднего школьного возраста играет? Это насколько альтернативно одарённым надо быть?
> ГЕНШИН ИМПАКТ
А что, в это кто-то, кроме девочек среднего школьного возраста играет? Это насколько альтернативно одарённым надо быть?
>>233661
А какие проблемы были с тушонкой? Юзаю её уже лет 10, особых траблов не наблюдаю. Даже флаки по кую норм нарезает в плейлисте (у фубара есть с этим проблемы местами). Тушонка охуенна, если тебе надо музычку играть при вменяемом интерфейсе.
А какие проблемы были с тушонкой? Юзаю её уже лет 10, особых траблов не наблюдаю. Даже флаки по кую норм нарезает в плейлисте (у фубара есть с этим проблемы местами). Тушонка охуенна, если тебе надо музычку играть при вменяемом интерфейсе.
>>225088
Видео отклеилос
Видео отклеилос
Ну, охуенно - потерли мой пост с вопросом и ответы на него.
6 Кб, 316x104Как же хочется поддержку jxl на дваче и в браузерах.
>>318229
Ну и складывает цифры ебаные
MS Visusl Studio.
>>По теме то, есть что сказать
Ну и складывает цифры ебаные
>>https://storage
MS Visusl Studio.
>PNG
Не заменит он его, пнг также берут чтобы фон прозрачный был, может твой жыпег так? а вот нихкя
>>514873
jxl может в прозрачность, обычный jpeg нет
jxl может в прозрачность, обычный jpeg нет
>>303594
дрочерам, хули
дрочерам, хули
>>233608
Я умею делать хорошие jpeg'и.
Я умею делать хорошие jpeg'и.
366 Кб, 2048x1421Готовятся переписывать на Rust.
Немного не в тему треда мейби
Есть оцифрованный видео-файл в формате .dv на 12Гб. Как его перекодировать в другой формат, чтобы можно было смотреть на телике?
На компе есть программа ffmpeg, но как задать правильно флаги, чтобы всё заработало, я не знаю. В интернете ничего не нашел про это.
Есть оцифрованный видео-файл в формате .dv на 12Гб. Как его перекодировать в другой формат, чтобы можно было смотреть на телике?
На компе есть программа ffmpeg, но как задать правильно флаги, чтобы всё заработало, я не знаю. В интернете ничего не нашел про это.
>>213710 (OP)
Тем временем mozjpg делает тоже самое. Вот только не забываем, что помимо таблицы хофмана они удаляют на кой то хер метаданные.
А ещё архиваторы на такие же проценты сжимают картинки уже давно, что как-бы намекает, что больше похоже на контейнер, где изображение тупо сжато.
> 20 процентов от оригинала
> никто не может
Тем временем mozjpg делает тоже самое. Вот только не забываем, что помимо таблицы хофмана они удаляют на кой то хер метаданные.
А ещё архиваторы на такие же проценты сжимают картинки уже давно, что как-бы намекает, что больше похоже на контейнер, где изображение тупо сжато.
>>213710 (OP)
Так чем. Вебп плох?
Так чем. Вебп плох?
>>555170
lossy: сжимает хуже чем jpegli
lossless: лучше чем png, хуже чем jxl - сойдет если не нужно больше 8 бит
lossy: сжимает хуже чем jpegli
lossless: лучше чем png, хуже чем jxl - сойдет если не нужно больше 8 бит
>>555537
Норм ты слился
https://web.archive.org/web/20101004134848/http://code.google.com/intl/no/speed/webp/docs/c_study.html
> тесты найди сам я ничего не пруфану
Норм ты слился
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
>>555831
Так долбаеб, мы увидим от тебя пруфы? Обычный jpeg хуже webp и он даже не обновляется. Все что я могу поверить это мозиловский. Но ты же утверждает другое
> в архив полез
Так долбаеб, мы увидим от тебя пруфы? Обычный jpeg хуже webp и он даже не обновляется. Все что я могу поверить это мозиловский. Но ты же утверждает другое
JXL это говно по сравнению с avif
Хватит пиарить этот красноглазый кал, хоть усритесь но качество в нем будет хуже на тот же размер
Хватит пиарить этот красноглазый кал, хоть усритесь но качество в нем будет хуже на тот же размер
>>559337
Мы предлагаем бесплатно пережать жпеги. А авиф твой дерьмо все равно по качеству и главное по возможностям даже если и чуть лучше сжимает. Лучше бы написали новый кодировщик например для пецификации жпг хл, если что не нравится расширьте ее вместо форсинга обрубка видеокодека.
Мы предлагаем бесплатно пережать жпеги. А авиф твой дерьмо все равно по качеству и главное по возможностям даже если и чуть лучше сжимает. Лучше бы написали новый кодировщик например для пецификации жпг хл, если что не нравится расширьте ее вместо форсинга обрубка видеокодека.