Организация PDF Association, занимающееся стандартизацией технологий PDF, добавила поддержку формата изображений JPEG XL в спецификацию PDF. По словам технического директора PDF Association, в PDF назрела потребность в отображении контента с расширенным динамическим диапазоном яркости (HDR) и JPEG XL выбран в качестве предпочтительного решения. Предполагается, что использование в PDF станет стимулом для более широкого распространения формата JPEG XL, несмотря на отказ Google от его поддержки в браузере Chrome, объяснив своё решение низким интересом со стороны разработчиков и пользователей...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64220
Я напомню у них там jpeg2k (который ты больше нигде не найдёшь). А сабж идеальный формат на сегодня, естественно, гулаговские не хотят, чтобы все увидели, какой хлам их вебп -- это же отличный вендор лок. Это не первый позор, вы только посмотрите, как они поддержку расширенных атрибутов удаляли из хромого. Но, правда, вебп всё ещё меньше мыло и меньше вымывает цвета, чем avif.
JPEG2000 даже по современным меркам тормозной. Internet Archive использует его в архивных целях и, если при помощи img2pdf склепать из JPEG2000 книжку, то даже на относительно быстром CPU оно будет некомфортно медленным при пролистывании.WebP же со своим субсэмплированием цвета не должен был появиться вообще. Но Google смог его пропихнуть и некоторым даже нравится.
JPEG XL годен, можно без потери пережать старые JPEG... но поддержка пока никакая.
Ты про XR забыл
>поддержка пока никакаяДля фоточек на диске и не нужна поддержка браузерами. А в вебе пускай что угодно используют, трафик безлимитный.
> Для фоточек на диске и не нужна поддержка браузерами.Ты разнообразия для поинтересуйся поддержкой сабжа в ОС и утилитах просмотра этим самых фоточек.
> А в вебе пускай что угодно используют, трафик безлимитный.
А канал резиновый у хостеров и ISP, или всё же нет?
У меня в кедах и на винде открывает, мне этого достаточно. Место экономится, а если потребуется переслать кому то, то всегда можно оригинальный jpg восстановить. Не зря ж эту фичу сделали.
> Ты разнообразия для поинтересуйся поддержкой сабжа в ОС и утилитах просмотра этим самых фоточек.Отличная поддержка: вон, начиная с iPhone 16 камера в него снимает, и, соответвенно его поддержка есть во всем яблочном софте и стороннем ПО для обработки фото. Теперь вот в PDF добавили.
https://petapixel.com/2024/09/18/why-apple-uses-jpeg-xl-in-t.../
А что там Гугл со своим хромом мутит - я хз, кому это интересно. Уж точно не потребителям, которые открывают готовые сайты и не парятся, какой у него там формат картинок.
> А что там Гугл со своим хромом мутит - я хз, кому
> это интересно.Да, никому не интересно. Особенно если учитывать, что 9 из 10 перепаковывают наработки Google в области браузеростроения.
> Да, никому не интересно.Да, не интересно. Те, кому было интересно, включая Apple, Samsung, Adobe и т.д. - те уже давно поддержку запилили. Именно ради своих пользователей. А вот пользователи браузеров не является такой ЦА - они вообще о офрматах ничего не знают и никакой визуальной разницы между ними не видят.
> Отличная поддержкаМессенджеры не поддерживают, браузеры не поддерживают (dev-ветки мне не надо предлагать, я в курсах), смотрелки документов не поддерживают. А так да, отличная поддержка.
> Мессенджеры не поддерживают, браузеры не поддерживаютЯ уже писал выше ситуацию с браузерами - ты читал? Для мессенджеров она такая же: потребитель не создает картинки - он их использует готовые из инета и понятия не имеет о форматах. И уж точно он не в состоянии принимать технические решения на этот счет, поэтому почти все твои мессенджеры по умолчанию все равно пережмут твою картинку, даже если ты загрузишь PNG.
Поэтому плевать на мессенджеры. Кстати, удачи тебе загрузить в свой любимый мессенджер банальный TIFF.
> смотрелки документов не поддерживают
Вранье. Все смотрелки картинок (которые развиваются, конечно) JPEG XL открывают без проблем. Софт для редактирования фото - тоже, включая Photoshop и GIMP.
> Кстати, удачи тебе загрузить в свой любимый мессенджер банальный TIFF.Зачем? Ты в курсе как расшифровывается TIFF и зачем он создавался? Это контейнер...
> Ты в курсе как расшифровывается TIFFTag Image File Format. "Image", понимаешь?
> Это контейнер...
Для чего контейнер, лол? Не для изображений, случайно?
> Tag Image File Format. "Image", понимаешь?А стандарт кодирования изображений какой прописан? TIFF - это формат "обёртки", а не стандарт кодирования изображения. Вот то, что ты называешь "файл JPEG", на самом деле является форматом JIF, внутри которого изображение закодированное при помощи JPEG. А внутри TIFF может быть и факс, и raw изображение с камеры в проприетарном формате, и JPEG, и RLE, и JPEG XL, JPEG2000... более того, может быть многостраничный документ.
Теперь смекаешь, почему его в браузерах нет?
> А внутри TIFF может быть и факс, и raw изображение с камеры в проприетарном формате, и JPEG, и RLE, и JPEG XL, JPEG2000...Круто. А в контейнере MP4 могут быть только аудио, только видео, или все вместе. И каждое - в своем формате кодирования. И MP4 при этом поддерживается упомянутыми тобой браузерами и мессенджерами.
Ты экспертизой выпендриться хотел или что?
> Ты экспертизой выпендриться хотел или что?Я просто указал причины, по которым поддержка TIFF ограничена там, где ты её ожидал...
> Я просто указал причины, по которым поддержка TIFF ограничена там, где ты её ожидал...Причина, которую ты привел (расширяемость) не имеет никакого отношения к неподдерживаемости этого формата браузерами и мессенджерами. Я тебе даже в качестве контрпримера привел еще более расширяемый MP4, но, похоже, ты не способен следить за нитью обсуждения.
А почему TIFF не поддерживется - я тебе уже два раза написал аналогию JPEG XL. Повторяю в третий раз: потому что его сейчас нет на девайсах потребителей.
> А почему TIFF не поддерживется - я тебе уже два раза написал
> аналогию JPEG XL.Ты формат файла от алгоритма сжатия не отличаешь. Что ты можешь рассказать?
> Ты формат файла от алгоритма сжатия не отличаешь. Что ты можешь рассказать?Я как раз отличаю, и даже привел тебе по аналогии с TIFF формат контейнера MP4, в котором видео и аудио модет быть в огромном количестве алгоритмов сжатия. Ты уже забыл? Это СДВГ, или как объяснить то, что ты не в состоянии держать в голове контекст из более двух сообщений?
> Это СДВГ...Ты ещё и диагнозы ставишь? Ну так ты это, почитай, в каком возрасте СДВГ диагностируют, проффэсор. А после попробуй головушкой стукнуться о земь, глядишь, и врачевательные способности обнаружатся )))
> Ты ещё и диагнозы ставишь?Я не ставил - я у тебя спросил, почему ты не в состоянии держать минимальный контекст обсуждения и отвечать по сути. Да, это выглядит как разговор с СДВГшником.
> Ну так ты это, почитай, в каком возрасте СДВГ диагностируют, проффэсор
После 12 лет. А что? Я таки угадал?
> Ну так ты это, почитай, в каком возрасте СДВГ диагностируют, проффэсор
> После 12 лет. А что? Я таки угадал?Сядь, успокойся, попытайся сосредоточиться и перечитай ещё раз статью - https://ru.wikipedia.org/wiki/%D0%A1%D0%...
На айфонах свет клином не сошёлся. Было бы круто, если в гугл камере сделали поддержку jxl.
Вот только фоточки нужно смотреть в т.ч. и через браузер, в чатах, и т.д. Я в курсе, что ТЕБЕ ЛИЧНО это не надо. Но есть еще и нормальные люди.Формат отличный, но пока его везде не будет -- пользы ноль.
Чтобы смотреть в вебе, в мессендерах и т.п. сперва нужно ПЕРЕСЛАТЬ их туда, что можно и в исходном jpeg сделать, получив его из jxl.
> Но есть еще и нормальные люди.Я то как раз нормальный юзкейс описал. Если снимаешь много фото, то ХРАНИТЬ лучше в том формате, который занимает меньше места. Задачи "чтобы везде открывалось" не стоит, т.е. польза УЖЕ есть. А от AVIF польза только всяким гуглам и операторам связи.
> трафик безлимитныйПользователям мобильного интернета расскажите.
И на мобильном безлимит бывает.
А бывает, что и не бывает.
Ну и честный безлимит на обычных тарифах фактически недоступен.
P.S.: ну и вопрос скоростей на мобильном интернете часто стоит весьма остро, не у всех девайс с 5G и соответствующая БС в ста метрах.
5Г - не про скорость так-то. Линк ОпСоСа в инет от номера Г не меняется. Даже меньше скорость с 5Г может получиться из-за возросшего кол-ва клиентов.
У пчёл 1ТБ/мес - считается безлимом?
Торренты работают?
WireGuard работает.
> Торрентыработают, если умеешь клиент настроить.
> JPEG2000 даже по современным меркам тормозной.Скорость была. Только не там. Сначала платный Kakadu, потом AGPL-ный Grok, который из-за лицензии не приняли в ffmpeg[0].
> WebP же со своим /неотключаемым/ субсэмплированием цвета /в lossy-режиме/ не должен был появиться вообще
Как нишевая вещь он работал, но он недостаточно хорош, чтобы вытеснить JPEG+PNG и полную поддержку в браузерах (Firefox+Safari) получил уже тогда, когда пора на пенсию.
Неотключаемость 4:2:0 подпирается опцией sharp_yuv. Но UX-проблема - гугл не стал рассматривать sharp_yuv как обязательную часть медленных пресетов (method 6 там как -preset placebo).
[0] "But using such a resultant mixture of licenses isn't something we want our users, personal or enterprise, to deal with". https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192620....
> Неотключаемость 4:2:0 подпирается опцией sharp_yuv. Но UX-проблема - гугл не стал рассматриватьНичего оно не лечится. На всяких картинках с тонкими линиями, шрифтах и проч - это дико рушит все что содержит интенсивные цвета.
Поэтому вещи типа скриншотов с компа оно может здорово похабить даже на максимальном качестве. В этом смысле AVIF куда более разумная штука.
А стандарт который в вебе не представлен - это извините фэйспалм. Примерно 90% успеха JPEG - основаны на том что его поюзали в вебе. Без этого он бы использовался на уровне TIFF какого-нибудь.
> Ничего оно не лечится.Потому говорю - подпирается. Костыли не лечат, но пользу приносят.
> Примерно 90% успеха JPEG - основаны на том что его поюзали в вебе.
Ему предначертано было, ибо где конкурирующие форматы с DCT в 90-е? И он future-proof оказался, так и jxl нужен, чтобы забыть о проблеме на очередные 30 лет.
JPEG2000 из-за патентов никто не пытался оптимизировать особо. Патенты истекли, но желающих нет.Для отсканированных текстов и чёрно-белых чертежей вэйвлеты гораздо лучше косинусоид. WebP с качеством 76 выглядит гораздо чище, чем JPEG и JPEG XL с качеством 80, и при этом размер в несколько раз меньше, чем JPEG и JPEG XL с качеством 50. Возможно, DjVu был бы не хуже, но он почему-то непопулярен. ImageMagick 7.1.2.
Единственное достоинство JPEG XL — пережимать накопленные JPEG без потерь.
> Для отсканированных текстов и чёрно-белых чертежей вэйвлеты гораздо лучше косинусоид.Да, согласен, вейвлеты и сейчас неплохо смотрятся, если бы их оптимизировали. Но там по определению много вычеслений в сравнении даже с арифметическим преобразованием, которое опцией в JPEG есть и которое почти никто не поддерживает (например Firefox со своим WONTFIX).
> Возможно, DjVu был бы не хуже, но он почему-то непопулярен.
DjVu сами загнали себя в прокрустово ложе сканированных книжек и сфейлили, когда оказалось, что замена "B" на "8" в сканированных документах может не только люто бесить, но и быть официальной причиной отказа в использовании формата в кач-ве архивного.
> Единственное достоинство JPEG XL — пережимать накопленные JPEG без потерь.
Да, это вин.
> там по определению много вычеслений в сравнении даже с арифметическим преобразованием
> которое опцией в JPEG есть и которое почти никто не поддерживаетНо надо прояснить - от поддержки отказались, чтобы не плодить файлы, несовместимые со старыми декодерами, которые не поддерживали арифметическое кодирование (вместо хаффмана) из-за патентов. Связи со скорость нет.
> DjVu сами загнали себя в прокрустово ложе сканированных книжек
А куда его ещё? С PDF после открытия его в 2008 он не смог бы конкурировать.
> оказалось, что замена "B" на "8" в сканированных документах может не
> только люто бесить, но и быть официальной причиной отказа в использовании
> формата в кач-ве архивного.Это про lossy-режим в JB2(DjVu)/JBIG2(PDF). Lossless-режим запретили за компанию:
- у госархивов много денег
- выяснять режим кодирования может быть непросто
- у госархивов высокие требования к качеству, а это 1-битный формат
> вэйвлеты гораздо лучше косинусоид. WebP с качеством 76Только в WebP (в VP8) нет никаких вейвлетов. Там тот же DCT, только на 4x4 вместо 8x8 и поверх добавлены макроблоки 16x16, предсказание внутрикадровое; есть WHT, но это тоже не вейвлеты и он навешан поверх DCT (сжимает DC-коэффициенты яркости в макроблоке).
А вейвлеты в DjVu не используются для текста и графики с чёткими контурами - они в JB2, а вейвлетный IW44 используют, чтобы курочить фон и картинки (не попадалось ни одной качественной картинки в IW44).
WebP обязан сжимать эффективнее JPEG из-за разницы в 15-20 лет.
> отсканированных текстов и чёрно-белых чертежей
Если они чистые, то lossless-кодеки (PNG с палитрой, например) не догнать.
Если они грязные, то их можно почистить.
Если они смешаны с ценным фоном и/или изображениями, то их надо разделять (Mixed Raster Content) как позволяет PDF или DjVu. Получается гора близких друг другу задач, на которые опенсорс не замахивается (хотя... есть это[1]) и нужен Adobe с его ClearScan или что-то от ABBYY или много ручной работы.Судя по https://squoosh.app, на текстах AVIF лучше, чем JXL, который лучше, чем WebP. Для JXL хорошо поднять edge preserving filter.
> Возможно, DjVu был бы не хуже, но он почему-то непопулярен
По возможностям он как подмножество PDF. В PDF есть аналогичный JBIG2.
Добавлю более обоснованного скепсиса к JXL:> 19th March 2022. Jon Sneyers: Reaching libjxl 1.0 will certainly happen this year (I hope before summer).
> jonsneyers on Nov 3, 2022: we are aiming to reach the libjxl 1.0 milestone within a reasonable timeframe, i.e. somewhere in 2023, preferably first half.Тем временем конец 2025 и про релиз перестали говорить. В багтрекере обсуждают регрессии по степени сжатия в lossless-режиме между 0.8-0.11, в lossy-режиме он конкурирует с AVIF и если AVIF где-то отстаёт, у него в запасе трюк времён x264 - 10-битный режим повышает эффективность сжатия 8-битных исходников.
https://encode.su/printthread.php?t=3397&pp=30&page=5
https://news.ycombinator.com/item?id=33442281
> естественно, гулаговские не хотятНе хочет их хромлаг, а их цюрихлаг вкладывается в JPEG XL и старый JPEG (создаёт jpegli).
Не знаю зачем и кому это нужно. JPEG у меня был ещё в Фотошопе под Windows 3.11, как сейчас помню, как пересохранял рисунки дочери из Paint, чтобы экономить место (вместо BMP).
Т.е. исходник перегнал в формат с потерями? Ну, хоть дочь умная, явно не в тебя.
Ну ты хоть статью прочти, а потом строчи)>Снижение размера до 60% по сравнению с изображениями JPEG идентичного качеств
> идентичного качествидентичного или побитовое совпадение?
Снижение размера за счёт больших тормозов. А нужно ли ещё меньше размер, если оно итак почти ничего не весит, с нынешними то размерами дисков. Вот где вопрос.
> в Фотошопе под Windows 3.11, как сейчас помнюНу хорошо, что хоть не на 3.10, а то бы я совсем не поверил. В реальности же, если покупался Фотошоп в то время, то к Шопу покупали Мак, который тогда на CPU от Motorola пыхтел. Шоп под венду стал популярен с выходом Windows 95.
В реальности фотошоп под винду был доступен ещё с версии 2.5, а версией 3.0 пользовались уже вовсю, и совершенно непонятно, зачем для него нужно было бы покупать мак.
И совершенно непонятно, зачем в РФ на него нужно было покупать лицензию для домашнего пользования?
> И совершенно непонятно, зачем в РФ на него нужно было покупать лицензию
> для домашнего пользования?1) Потому что адоб иначе будет делать гадости. И имеет на то полное право. EULA читайте.
2) Какой смысл для домашнего использования осваивать крутой профессиональный тул?Может вы еще и экскаватор со стройки угоните? Так, поржать, огородик копнуть, лица соседей посмотреть? Не, не надо? Заодно и управление экскаватором подучить можно. Примерно такого же смысла действо будет.
> В реальности фотошоп под винду был доступен ещё с версии 2.5, а
> версией 3.0 пользовались уже вовсю, и совершенно непонятно, зачем для него
> нужно было бы покупать мак.В реальности вендой до 3.0 версии включительно пользоваться было нельзя. Но нубы из википедии знания черпают. Они ещё не знают, что там и русского не было... и был отдельный тип забытого айтишного бизнеса. А ещё русские шрифты в знакогенератор (шта эта?) надо было грузить...
Так и знал, что кто-нибудь не догонит, что речь про версию фотошопа.
> Так и знал, что кто-нибудь не догонит, что речь про версию фотошопа.Третий шоп гоняли на Вин 95. А это уже другая совершенно история.
Ничего, что он чуть ли не на год раньше вышел, чем Win 95?
> Ничего, что он чуть ли не на год раньше вышел, чем Win
> 95?Ничего, если знать реалии того времени. Третий шоп - это линейка, это не выпуск нового айфона, который через год все обзовут старьём. Третий шоп и в конце 90-х вполне себе использовался. Нужно знать реалии того времени - MTU был маленьким, а онлайн тарифицировался по времени (и его не было у 90% населения даже в 98 году), Win 95 вполне себе ставился на новые компы в 98 и даже 99 году, т.к. обновки раньше появлялись на "развалах", чем в СМИ. Да и смысл на 32 мегабайта и 4 гига HDD ставить 98-ой? В 90-х всё было эклектично. У одних стоял PC DOS и Лексикон с Norton'ом, у других бездисковые станции с 4 мегабайтами ОЗУ, а в университетской типографии Макинтош с 32 мегабайтами, а обыватель думал, мигрировать ли ему с 3.11 на 95 в 97-ом году.
А ещё были книжки Фигурнова, по которым страна осваивала писюки в 99-году... а в них была Win 3.11 ))
Очень познавательно, но не понятно, с чем вы спорите.
> Ничего, что он чуть ли не на год раньше вышел, чем Win 95?Это никак не мешало запускать его на Win 95. Я с этой версии фотошопа как раз начинал.
Ну ты явно не застал времена палаток, ларьков, раскладок в переходах и метро с CD-дисками на которых было 100500 программ включая ФШ.
> Ну ты явно не застал времена палаток, ларьков, раскладок в переходах и метро с CD-дисками на которых было 100500 программ включая ФШ.Я до сих пор иногда, проходя по улице или в общественном транспорте, встречаю мужчин предпенсионного и пенсионного возраста, у которых ещё будучи школотой покупал на развалах варез... и по привычке здороваюсь. Знал бы я разницу между 3.10 и 3.11, если бы не приносил на дискетах Венду в класс бездисковых станций, чтобы установить её на грузившийся по коаксиалу MS DOS...
Он просто перепутал с PaintSHop Pro.
В те времена многие его использовали, он был ShareWare.
Да,да охотно верим, с учетом того что картинки были от 4 до 16 цветов (у особо зажиточных 256 цветов) и разрешения от 320х240 до 640х480, да и c учетом этих характеристик jpeg не умел сжимать цвета, так как был 16 битным минимум
> Да,да охотно верим, с учетом того что картинки были от 4 до
> 16 цветов (у особо зажиточных 256 цветов) и разрешения от 320х240
> до 640х480, да и c учетом этих характеристик jpeg не умел
> сжимать цвета, так как был 16 битным минимумВсё прекрасно смотрелось на видеокартах с 512к оперативки. На видюшках можно было RAM'у добавлять. Dithering тоже почти все умели для эмуляции полутонов в графич. режиме. Да, было 640х480, а 320х240 для игрушек было. Были экзотические режимы с неквадратным пикселем, но то или для древности лютой железа, или для экзотики.
> Не знаю зачем и кому это нужно
> пересохранял [...], чтобы экономить местоСам спросил - сам ответил?
Кого сегодня с nvme на пару терабайт волнует на сколько килобайт будет меньше весить джепег? А вот тормозов добавит однозначно, особенно на "устаревшем" железе типа 775 сокета, который корпорации пытаются всякими левыми способами состарить.
> Кого сегодня с nvme на пару терабайт волнует на сколько килобайт будет меньше весить джепег?Сегодня это волнует всех по тем же причинам, по которым волновало 30 лет назад. Потому что объем дисков-то увеличился, но также в несколько раз увеличелось разрешение фоток.
Комитет(с) Добавил(тм).
Теперь интересно, адоби это добавит? С автоконвертацией изображений в хэлэ.
Ну и да, господа, ставки-ставочки, к какому году это будет реально (программы будут генерировать содержимое с XL) использоваться:
- 2027
- 2029
- не раньше 2030х
- мы все сгорим в ядерном огне до этого
- формат как впилили, так тихо и выпилят в 31-33х
- а в пдф нужно добавить скрипты на раст, да и сам PS заменить на раст
> Теперь интересно, адоби это добавит?В Photoshop есть поддержка avif/xl.
> В Photoshop есть поддержка avif/xl.А в братце-акробатце и его утилитах?
та не, ты шо, adobe тут вообще ничего не решает> - а в пдф нужно добавить скрипты на раст, да и сам PS заменить на раст
чтобы было по стандарту на pdf-ку. конкуренция - это здорово
Специально для тёмных, недалёких и невнимательных: чуть раньше, в 2023, Adobe™ добавили поддержку JPEG XL в формат .DNG.Сами добавили, а вовсе никакой не комитет. Наверное, кумекают там чего, в форматах изображений–то.
Да, очевидно, что браузеры все подмяты гуглём, а без браузеров массового распространения не будет. Но кому профессионально нужно — будут использовать, как раньше пользовались TIFF'ами при необходимости.
Но да, траллировать — не мешки ворочать, мыша не болит.
>уменьшение размера JPEG до 21% c возможностью восстановления исходного состоянияВот это либо чушь, либо ошибка перевода, либо и то и другое. Там ничем не ограничено уменьшение размера файла и уж точно некорректно сказать, что это до 21.567%. Так же, исходный файл не восстанавливается, насколько я знаю. Восстановленный может быть похожим или даже одинаковым, но там не bit perfect кодирование без потерь.
Лучше говорить про "на 60% эффективнее png" и значительно более lossless чем png. Но это тоже не совсем правда: палитированный пнг фотошопа всё ещё более эффективный (палитирование в сабж только собирались добавить).
В pdf по ссылке:> Key features of the JPEG XL codec are:
> lossless JPEG transcoding
> In terms of compression performance, key results are:
> Lossless JPEG transcoding reduces JPEG size by around 16% to 22%
Это средние значения для пачки средних файлов (не каких-то конкретных). Если жпег однотонный, то сжатие будет 99.9%.
> Moreover, JPEG XL includes several features that help transition from the legacy JPEG coding format. Existing JPEG files can be losslessly transcoded to JPEG XL files, significantly reducing their size (Fig. 1). These can be reconstructed to the exact same JPEG file, ensuring backward compatibility with legacy applications. Both transcoding and reconstruction are computationally efficient. Migrating to JPEG XL reduces storage costs because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients. This provides a smooth transition path from legacy JPEG platforms to the modern JPEG XL.
>> Moreover, JPEG XL includes several features that help transition from the legacy JPEG coding format. Existing JPEG files can be losslessly transcoded to JPEG XL files, significantly reducing their size (Fig. 1). These can be reconstructed to the exact same JPEG file, ensuring backward compatibility with legacy applications. Both transcoding and reconstruction are computationally efficient. Migrating to JPEG XL reduces storage costs because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients. This provides a smooth transition path from legacy JPEG platforms to the modern JPEG XL.Там немного маркетологи постарались. По правде, я не знаю, будет ли "exact same" транскодированный jpeg (скорее всего, нет, там много тонкостей форматов и фич этого jpeg). Но вот, то, что lossless режим для png не восстановит изображение бит в бит, это точно (хотя, выглядеть будет ровно так же). Метаданные тоже могут пострадать (хоть и меньше чем с png), там столько особенностей, что постоянно с чем-то приходится сталкиваться. Необходимо это учитывать.
Это развитие того, что даёт jpegtran -arithmetic.
Это операция без потерь.
Без потерь в нормальном смысле этих слов (битмап побитово сойдётся), не в смысле того анона, который "png - это lossy-формат, его стандарт врёт".
Побитово в случае с jpegxl не сойдётся. В декодированном raw формате должен по идее, в этом весь смысл. В случае с jpegtran, подозреваю, зависит от версии. И это всё хорошо, но пнг лишь технически лосслесс. Что до транскодирования, банально оригинал может иметь дополнительные функции/фреймы/параметры, и восстановленная версия будет без них. То же самое с цветовыми пространствами, png исключительно rgb/grayscale (ещё палетирование, но только в фотошопе нормально работает). Какой же это лосслесс. Стандарт не врёт, просто некоторые люди не способны понимать прочитанное.
Побитово - битмап, а не файл.Это форматы сжатия изображений, они не должны воспроизводить порядок расположения метаданных оригинала, их выравнивание или ещё что-то такое.
> Стандарт не врёт
> Какой же это лосслессА если общепринятые определения, а не свои уникальные?
Есть lossless/lossy/uncompressed в контексте сжатия. Есть lossy-преобразования вроде оцифровки, понижения разрядности, смены цветовых пространств.Тип сжатия во flac - lossless.
Он может сжать float32-исходник? Нет. Сначала нужно lossy-преобразование в i32 или i24.> png исключительно rgb/grayscale (ещё палетирование
Оно тоже RGB.
Вообще в пнг недавно почти добавили yuv, но
"RGB is currently the only supported color model in PNG, and as such Matrix Coefficients shall be set to 0" https://www.w3.org/TR/png-3/#cICP-chunk
Когда кодируют аудио-файл во флак, подразумевается, что при декодировании получится тот же вариант. Даже хеши у потока совпадут. Вот это означает лосслесс. В рассматриваемом случае с изображениями, это не так, восстановит файл до pixel-perfect состояния, не bit-perfect. В этом отличие побитово от попиксельно.
1. Я ошибся, JXL должен восстанавливать файлы побитово, с выравниваниями, лишними нулями, данными в хвосте файла и прочим (через "jbrd" box, ограничения перечислены тут[1])
2. Если бы он этого не делал, всё равно бы замену энтропийного кодирования (отмена хаффмана и замена на своё) называли lossless-преобразованием.
3. "Даже хеши у потока совпадут. Вот это означает лосслесс." - прямо как у png, который по-твоему недостаточно lossless уже не помню почему.[1] https://github.com/libjxl/libjxl/issues/895#issuecomment-991...
4 года назад "вроде, наверно, но может быть" это, конечно, да. Несколько не актуально, с тех пор уже много раз всё разнесли до основания. Кому должен, где это задокументировано? Там много таких ситуаций, когда не получится. Выравнивания это не то, о чём стоит заботиться (тут формат оригинального формата накладывает ограничения).А что до png, даже если перегонять png в png, информация легко будет утеряна, это уже с потерями. Потеря информации при перекодировании это сжатие с потерями. Мы же не рассматриваем ситуацию, когда png перед тем только что создан этой же программой, то они вполне вероятны. И да, я не считаю изменение стратегии кодирования (pngcrush) потерями, потери -- это невосстановимая утрата данных, и в данном случае потерь не происходит (во всяком случае, не должно).
> 4 года назад "вроде, наверно, но может быть" это, конечно, да
> Кому должен, где это задокументировано?В смысле?
- Там жалуются, что энкодер не даёт перекодировать - или побайтово точно, или никак (сейчас есть --allow_jpeg_reconstruction=0).
- С тех пор стандарт приняли.
- Более реальная проблема (чем перечисленное там) - перекодирование новых старых JPEG с HDR, изобретённых через несколько лет после JXL: https://github.com/libjxl/libjxl/issues/3882> даже если перегонять png в png, информация легко будет утеряна
Даже если перегонять flac в flac, информация легко будет утеряна.
Какая именно информация будет утеряна при перекодировании flac в flac разными программами (какими)? Что там можно потерять.
Мы же не рассматриваем ситуацию, когда flac перед тем только что создан этой же программой, то они вполне вероятны. Какая именно информация будет утеряна при перекодировании png в png разными программами (какими)? Что там можно потерять.
> Мы же не рассматриваем ситуацию, когда flac перед тем только что создан
> этой же программой, то они вполне вероятны. Какая именно информация будет
> утеряна при перекодировании png в png разными программами (какими)? Что там
> можно потерять.Нет-нет, ты не виляй и ответь на вопрос. Понятно, что 1 и та же программа и кодировать декодировать будет совершенно одинаково. Если тебя так заинтересовал пример с flac, то ffmpeg кодировал некорректно и хэши не сходились после декодирования, hence не bit perfect и не lossless. С png нечего обсуждать, каждый кодирует и декодирует как хочет.
> Если тебя так заинтересовал пример с flac, то ffmpeg кодировал некорректно и хэши не сходились после декодирования, hence не bit perfect и не lossless."Некорректно" - это как? Не в соответствии со спецификацией? Ну, тогда это был баг в ffmpeg, очевидно.
> хэши не сходились после декодирования
Хэши чего ты проверял? FLAC гарантирует lossless сжатие для сырых PCM данных. Их и надо проверять.
> С png нечего обсуждать, каждый кодирует и декодирует как хочет.
Нет, PNG кодируется и декодируются строго в соответствии со спецификацией. Файл, закодированный с нарушением спек попросту не декодируется корректно в программе, соответствующей этим спекам.
Округления у ffmpeg некорректные были. По мнению референсной реализации, и в целом чексуммы не бились с исходником. Такое регулярно с ffmpeg. Разные программы будут работать в даннами по разному и годами никто на это не обратит внимание. Что до метаданных, то это отдельная боль. Они могут иметь значение как при кодировании, так и при декодировании, и ошибка работы с ними на любом из этапов приводит к потере данных. В случаях, когда спецификации не отражают реалий, получается очередной tiff, где у каждого производителя свои костыли. Ну а что, зато стандарт прекрасный, всё по спекам работает. Формат всё же должен быть унифицированным.
> В случаях, когда спецификации не отражают реалий,FLAC как формат гарантирует отсутствие потерь только для PCM данных - и ничего более. Все претензии по поводу кривых кодировщиков нужно предъявлять авторам этих кодировщиков, а не самого формата. FLAC не становится lossy лишь от того, что вы юзаете кривой софт. То же самое и с PNG.
Ну так flac хотя бы гарантирует bit perfect для поддерживаемого формата потока в теории, т.е. декодированный файл _должен_ полностью соответствовать оригиналу (не исходнику, исходник может быть в неподдерживаемом формате, тогда такое кодирование не lossless). В случае с jpegxl, требования bit perfect нет, исходные данные никто не обещает. В случае png и с не к ночи помянутым tiff, работа с файлом будет в меру возможностей приложения/библиотеки, и этот вопрос как раз решается стандартизацией в jpegxl. Хоть он и не гарантирует восстановить исходный файл, он гарантирует корректно его обработать и сохранить (чего png/tiff сделать не способны).
Нечего обсуждать - с flac, потому что не все энкодеры поддерживают копирование метаданных. Нет метаданных - нет правильной громкости (ReplayGain), правильного расположения каналов (WAVEFORMATEXTENSIBLE_CHANNEL_MASK), нет разбиения на треки (embedded CUE), нет картинок.Декодируют его как хотят - по ссылке десятки нарушений стандарта (проблемы с стандартными, они же subset, они же --no-lax файлами).
https://wiki.hydrogenaudio.org/index.php?title=FLAC_decoder_...
> В рассматриваемом случае с изображениями, это не так, восстановит файл до pixel-perfect состояния, не bit-perfect.Извини, но ты какой-то бред несешь. Видимо, не понимая технических деталей. Пиксели физически не могут быть идентичны исходным, если не идентичны биты, которыми они закодированы.
Ну, судя по отзывам, bit-perfect получается только после двойного транскодирования (после первого хэши не совпадут). И, если понимать _технические детали_, в этом ничего странного.
> bit-perfect получается только после двойного транскодирования (после первого хэши не совпадут)Что ты имеешь в виду под "двойным транскодированием" и хэши чего именно ты проверял?
> И, если понимать _технические детали_, в этом ничего странного.
Человк, понимающий технические детали, никогда бы не ляпнул "pixel-perfect не bit-perfect". ТЫ и бит от байта, похоже, не отличаешь.
Двойное транскодирование подразумевает использование программы, приводящей данные в данном случае пикселей к униформному виду, при котором они интерпретируются однозначно идентично. Хэши сравниваются у декодированных данных.Bit perfect подразумевает равнозначные оригинальным хеши после декодирования, pixel perfect это вероятное совпадение данных при декодировании определённым декодером, но без гарантий полного совпадения оригиналу -- как именно данные были кодированы в оригинале никому не известно (кроме программы, которая это делала).
> pixel perfect это вероятное совпадение данных при декодировании определённым декодером, но без гарантий полного совпадения оригиналуСори, но это опять какая-то белиберда. "Совпадение без гарантий полного совпадения".
У вас есть оригинал, и есть декодированные данные. Это две кучи бит (PCM в случае FLAC и пиксельная сетка в случае PNG), которые либо побитово равны, либо нет. А все эти россказни про "bit-perfect" vs "pixel-perfect" звучат как паль в глаза от гуманитария.
Различие, на мой взгляд, тут вполне конкретное, что именно не ясно? Bit perfect кодирование позволяет восстановить оригинальные несжатые данные, pixel perfect позволяет только декодировать данные в нечто, декодирующееся в оригинальные данные. У первого совпадёт хэш двоичных данных после декодирования в raw, у второго такой гарантии нет.
Совпадение у конкретной реализации. По её мнению. Вон у jpeg2k тоже вроде есть стандарт, а ни одна (включая референсные) реализация работать с ним не умеет, лол. А узнать, как конкретно и чем был кодирован оригинал, ты достоверно не можешь, следовательно, оригинальные бинарные данные при всём желании не восстановишь. То же самое с png, там может быть чёрте что напихано в данные фреймов в оригинале, и при повторном перекодировании референсной реализацией эти данные теряются. В этом отличие.Это не важно на первый взгляд, но может оказаться критичным для программы, которая делала не референсное кодирование по какой-то причине. На практике, ситуация, когда кодировщик не следуют референсу, обычное дело. Для примера, есть кодеки h265 (мне кажется, это хороший пример).
> lossless режим для pngУ PNG и нет других режимов.
> png не восстановит изображение бит в бит, это точно
В смысле "не восстановит"? Типа пиксели будут отличаться от оригинального изображения, из которого кодировался PNG файл?
>Типа пиксели будут отличаться от оригинального изображения, из которого кодировался PNG файл?Неоригинальные фотоны будут отображать эти пиксели.
А теперь посмотрим на рабочию практику, Steam сохраняет HDR скриншоты именно в AVIF.
> А теперь посмотрим на рабочию практику, Steam сохраняет HDR скриншоты именно в AVIF.А комера Айфона 16 и новее - в Jpeg XL. Ну, и что дальше?
https://petapixel.com/2024/09/18/why-apple-uses-jpeg-xl-in-t.../
А Samsung сохраняет в HEIC. И что?
> А Samsung сохраняет в HEIC. И что?Нет, дружок, начиная с S24 Samsung тоже использует JPEG XL для режима Expert RAW.
https://r2.community.samsung.com/t5/CamCyclopedia/JPEG-XL-Im...
Это такая подстава. В браузерах есть смотрелки для PDF. Теперь получается, что эти смотрелки не смогут работать без поддержки этого формата. Решили уколоть гугол?
Ну и тут возможна и обратная ситуация. В Adobe Reader неявно используется хромиум. Если в хромиуме не будет поддержки этого формата, то и в Adobe Reader это изменение никто принимать не будет.
Ну, вполне от адоби может быть запрос вида
"ребяты, по-браццки верните либу, а? Мы вам денюжков отсыпем и человечка кабанчиком метнём на суппорт, в отличие от всяких мутных гитхабовских человечков, а то фура на владик не уходит".
В PDF много чего есть. Как-то раз встроенное Flash-аудио видел.
Поддерживать это необязательно.
Ммм... бизапастнасть...
В PDF doom можно сделать, очнись )
https://github.com/ading2210/doompdf
Решили уколоть людей, принудив обновить в очередной раз искусственно состаренное железо. Или думаешь эти финтиплюшки не добавят тормозов?
Все эти смотрелки поддерживают довольно ограниченное подмножество PDF. Но этого почти никто не замечает, поскольку этого подмножества достаточно для 99% задач.
Смотрел из бразера и сейчас поддерживают 10% из возможностей pdf, даже "нормальные" смотрелки мягко скажем далеко не всё поддерживают, всё поддерживает только акробат. Это типишная наша "бага" - "ой мой pdf у вас не отображается как надо" и навороченный pdf.
Зачем в PDF HDR?
Модно.
Для внедрения требовалась next big thing, чтобы убедить манагера как из комиксов Дилберта.
Написали "ИИ". Но манагер не оценил и пришлось срочно переделывать на "HDR".
95%, что было так!
> next big thingHDR был next big thing лет 10-15 назад.
В фотиках HDR появился еще в середине 2000х, в фотошопе CS2 и в десяточке из коробки.Так что тут было наоборот, их спросили "У вас что, нет поддержки HDR?! А ну бегом добавляйте!"
> HDR был next big thing лет 10-15 назад.А ИИ - сегодня. Хочешь JPEG AI?
https://jpeg.org/jpegai/
> Зачем в PDF HDR?Что значит зачем? А как иначе ты туда добавишь HDR фотку?
В обычном мире HDR довольно есть практически в каждом не6omжацком телефоне.
Во многих ноутах он тоже есть, про ТВ вообще молчу (большие ТВ используются в тех же митингрумах)Но линуксопрдлики до сих пор не могут понять зачем нужен HDR))
А печатать какими красками?
HDR красками, вестимо :)))
> А печатать какими красками?А какими красками печатать видосы и кнопки, запрограммированные JavaScript-ом? Ведь это все есть в PDF уже много лет.
> А какими красками печатать видосыТеми же, что и флеш-приложения, которые тоже являются частью rich media в pdf.
Или теми же, что и "Попытки получить доступ к системным настройкам или изменить их / доступ к внешним ресурсам", о которых предупреждает[1] Adobe.
Расширенная функциональность в pdf выглядит как вирусня, вызывает отвращение и будет отключена у многих пользователей.
[1] https://helpx.adobe.com/acrobat/desktop/protect-documents/mi...
Фотку обработать каким-нибудь логарифмирующим алгоритмом, чтобы сжать динамический диапазон.
Так даже обычный sRGB с CMYK не совпадает, а уж если дополнительными красками печатать… Но печатают же.
>> Зачем в PDF HDR?
> Что значит зачем? А как иначе ты туда добавишь HDR фотку?Человек попросту не понимает, что PDF-файл может быть предназначен для прсмотра на экране.
> Зачем в PDF HDR?Наивный, ты не в курсе, что в PDF уже кучу лет как можно вставлять видео и 3D модели.
> Наивный, ты не в курсе, что в PDF уже кучу лет как
> можно вставлять видео и 3D модели.Вот все это JXL будет юзаться - примерно настолько же насколько видео и 3D модели в PDF.
Не, конечно экскаватором можно и воду возить - черпнул в ковш и повез. Но это немного не майнстримно. Модели и видео в PDF где-то там же.
> Отсутствие необходимости выплаты патентных отчисленийКто ISO после зашквара с OOXML и H.26x теперь поверит на эту тему... как всегда стоит только что поюзать - вылезет половина мемберов стандарта и начнет наглый рэкет.
> Сжатие JPEG без потерьСпасибо, вы сделали мой день!
Да вот и я подумал, что это: сжатие сжатого второй раз алгоритмом без потерь?
> Да вот и я подумал, что это: сжатие сжатого второй раз алгоритмом
> без потерь?Это скорее не сжатие, а реорганизация блоков. Отличная вещь и быстро отрабатывает, можно разом уменьшить файлы на 1/5 размера (если их много, это приятно). В принципе jpeg файлы не слишком ценные, особых проблем с транскодированными данными не помню (главное не потерять icc профили в процессе).
> Это скорееА поточнее? Что там делают?
>> Это скорее
> А поточнее? Что там делают?Декодируют файл и укладывают заново с новой структурой, заголовки можно сжать при этом. Визуально отличий 0, просто меньше размер и читается теперь другой либой.
> Визуально отличий 0А по факту? Получается, уже не побитовое совпадение.
Не важно, даже если так. Потому что magick "${of}" "${if}" -metric PAE -compare -format '%[distortion]' info: для декодированного файла покажет, что отличий 0. Для файла с потерями полное совпадение не имеет особого смысла, важно, чтобы на глаз отличий не было. Ни сейчас, ни в будущем: с hief уже было, что старые файлы начали отображаться некорректно. А среди кодировщиков с потерями, лучше jpegxl с качеством больше 94-96 тут никто не справляется на сегодня.
Именно побитовое совпадение разжатого изображения. И совпадение результатов разложения Фурье. Но для сжатия этих данных используются более эффективные методы, чем алгоритм Хаффмана. Именно в этом киллер-фича JHL.Можно использовать другие размеры блоков, какие-то ещё ухищрения, размер будет ещё меньше, но уже без побитового совпадения.
>> Сжатие JPEG без потерь
> Спасибо, вы сделали мой день!https://en.wikipedia.org/wiki/Lossless_JPEG
... но в дикой природе ты JPEG2000 гораздо чаще встретишь.
пора бы добавить анимированные gif - вот было бы круто pdf документы с анимированными gifами...
> пора бы добавить анимированные gif - вот было бы круто pdf документы
> с анимированными gifами...jpegxl анимированный
Потом захочется мигающий текст, а потом и встроить простой язык программирования, чтобы писать небольшие макросы.
PostScript - это язык программирования.
pdf "поддерживает" javascript и очень давно. Всё давно украдено.
Браузер просто научить читать сайты из zip. Зачем усложнять?
Почему бы не сделать такой формат файлов в которые можно быо бы запихать сколько угодно картинок в каких угодно форматах и отдавать ккртинку нужного формата по запросу программы?
> Почему бы не сделать такой формат файлов в которые можно быо бы запихать сколько угодно
> картинок в каких угодно форматах и отдавать ккртинку нужного формата по запросу программы?А "сколько угодно картинок в каких угодно форматах" сколько будут весить?
Какие форматы? Вот все-все-все которые когда-либо делали?
> Почему бы не сделать такой форматНазовём его к примеру файловая система или база данных.
... или ZIP-архив! 😉
>> Почему бы не сделать такой формат
> Назовём его к примеру файловая система или база данных.А программа отдающая эти файлы - http сервер например. Даже на опеннете работает! Конечно формат картинок предпочитают тот который ALL потом еще и смотреть сможет сразу, без упражнений с скачкой и запуском внешней программы. И вот уже опеннетчики почти изобрели веб заново :)
- У нас есть 20 форматов, нужно сделать универсальный!
...
(у нас есть 21 формат)
> - У нас есть 20 форматов, нужно сделать универсальный!
> ...
> (у нас есть 21 формат)В данной ситуации был оригинальный jpeg (1992), какие-то неудавшиеся эксперименты и провалившиеся попытки навязать вендорлок, пачка мусора на базе видекодеков. Теперь у нас есть jpegxl и пачка мусора на базе видекодеков, как видишь, уменьшается число стандартов.
Этого никогда не будет. Каждый хочет иметь свой кусок. В целом достаточно трех форматов. JPEG, TIFF и gif. Остальное мусор.
>> такой формат файлов в которые можно быо бы запихать сколько угодно картинок в каких угодно форматах
> Этого никогда не будет
> В целом достаточно
> TIFFТак это самый расширяемый формат. LibTIFF поддерживает WebP в TIFF.
> В целом достаточно трех форматов.И 640кб тоже достаточно? Зачем же ты проц сменил?
> JPEG, TIFF и gif. Остальное мусор.
А как же божественный png???
tiff ему не замена, вот никак.
Не понял, а как же QOI? ImageMagick и всё на базе ImLib2 поддерживает.
> Не понял, а как же QOI?Это (TGA+PNG)/2 в плане сжатия.
лучше бы javascript убрали.
В нынешнем вэбе тормозит не джаваскрипт. Тормозит dom и внезапно... css. А джаваскрипт очень сильно оптимизировали за последние годы и это наименее тормозная часть в браузере (если код написан не китайцем).
Сейчас есть тенденция создавать DOM и стили через JS... И это не китайцы.
> Сейчас есть тенденция создавать DOM и стили через JSПотому что это работает быстрее.
> Потому что это работает быстрееДля сервера, а не клиента.
>> Тормозит dom и внезапно... css.Кто вам мешает лису вместо хрома использовать? Да и будем честными - не настолько у вас там старое оборудование чтобы что-то тормозило. А даже если и старое, то и новые версии хрома и лисы у вас просто не встанут без колдовства. А с колдовством ничего существенного не покажут в производительности, но вовсе не по причине dom и css
Кто пользуется современными цифровыми аппаратами? Формат JPEG XL в них может взлететь?У меня цифровой фотоаппарат нулевых годов. Поэтому о современности ничего сказать не могу.
Сегодня 99% фото в инстаграме делается на айфоны с его божественной ИИ обработкой. И 1% для полиграфии на супердорогие профессиональные беззеркалки (и чаще дороже не аппарат, а сменная оптика к нему).
> Кто пользуется современными цифровыми аппаратами? Формат JPEG XL в них может взлететь?Именно современные аппараты - это почти всегда (полу-)профессиональные фотоаппараты, в которых используется RAW. А "мыльницы" с JPEG-ами почти вымерли - обыватели вместо них пользуются телефонами, и JPEG XL уже взлетел на камерах у iPhone 16 и Samsung S24.
В 2025 году, можно ли сравнивать камеры таких смартфонов, как iPhone 16 и Samsung S2 с цифровыми фотоаппаратами? Или, прогресс достиг того, что уже сравнения со смартфонами приемлемы.
> В 2025 году, можно ли сравнивать камеры таких смартфонов, как iPhone 16 и Samsung S2 с цифровыми фотоаппаратами?99% потребителей именно так и делают. А что? Да, на телефонах качество фото - это днище по сравнению с профессиональными фотоаппаратами, но тех самых потребителей это не волнует. Для Инстаграма и просмотра фоток на экране 9 см в ширину - пойдет.
В фотоаппаратах сейчас активно внедряется формат HEIF.В дополнение к уже имеющимся JPEG и RAW.
Что теперь Гугл будет делать, чтобы не поддерживать JXL в хромом? Признает PDF недостаточно нужным и выпили поддержку?
DJVU внезапно начнёт поддерживать)))
Тэкс, вот железяка лет десяти, принтер в смысле, умеет принимать PDF на вход. С этим вот новьём что за картинка будет на выходе? Ничего? Отлично, блин :(
Странный, даже абсурдный аргумент. А то что у PDF есть несколько различных стандартизированных версий вас не смущает? То, что может быть включён исполняемый яваскрипт? Внедрённый медиа–контент? Видео, звук, трёхмерные объекты. А шифрование? Да даже банально внешние шрифты.Уповать, что чахленький процессор принтера всё это поддерживает и прожуёт произвольный PDF–файл — наивно и нелепо. Если нужно — есть разновидность формата PDF/A, специально предназначенная для архивирования и печати и в которую можно пересохранить документ при вящей необходимости.
А новые расширения ситуацию нисколько не изменят — принтеры как раньше не поддерживали формат во всей его полноте так и продолжат не поддерживать далее.
> Уповать, что чахленький процессор принтера всё это поддерживает и прожуёт произвольный
> PDF–файл — наивно и нелепо.Так-то первый Postscript-принтер имел спецификации не хуже того компьютера (была даже опция HDD для шрифтов), с которым продавался (а кач-ве демки Apple использовала налоговую декларацию США). Принтеры c поддержкой Postscript и PDF до сих пор имеют вполне приличный объём RAM и более-менее быстрый CPU. Да и принтер реализует конкретное подмножество стандарта PDF (PDF генетически связан с Postscipt). При печати всё неподдерживаемое конвертируется в нужную версию драйвером или фильтром, который дёргает Ghostscript зачастую.
> принтер реализует конкретное подмножество стандарта PDF
> …
> При печати всё неподдерживаемое конвертируется в нужную версию драйвером или фильтром, который дёргает Ghostscript зачастую.Так о том и речь. На печать отправляется уже специально подготовленный для принтера файл, а не произвольный. Даже если пользователь об этом не подозревает. А об абсолютной поддержке формата во всей его полноте речи ни шло никогда, уже, наверное, начиная с 1.5 версии, когда завезли формы и прочие проприетарные расширения.
Это я уж молчу о том, что формат по сути интерпретируемый («Script» в постскрипте не просто так) и памяти для отрисовки странички, густо обвешанной фильтрами, может потребоваться куда больше любых «вполне приличных объёмов». Да что там, в PDF даже зипбомбы есть (https://www.pdf-insecurity.org/pdf-dangerous-paths/attacks.html#deflate-bomb).
Ты прав лишь отчасти. В реальности можно отправить голый PS и PDF, только не надо удивляться, если вылезут пустые места вместо картинок, формат сжатия которых не поддерживается, или шрифты будут не те, т.к. соотв. ресурса нет в исходном файле. Если дров по какой-то причине к принтеру нет, то можно ничтоже сумняшеся поставить имеющийся везде драйвер от Apple LaserWriter практически с любым PS принтером. Там даже на такие случаи был Generic Postscript Printer... Драйвер же, когда конвертирует, тоже не всё молотит и, что самое главное, объём данных, передаваемых по кабелю, гораздо меньше. Будешь смеяться, но на винпринтер уходит по сути большой битмап с управляющими кодами принтера. А там иногда сотни мегабайт выходят. Буфера у винпринтера такого нет, поэтому печатает он "наживо", что иногда может привести к затупам, т.к. данные по шине по какой-то причине перестают поступать...
>> А об абсолютной поддержке формата во всей его полноте речи
> ни шло никогда, уже, наверное, начиная с 1.5 версии, когда завезли
> формы и прочие проприетарные расширения.Абсолютной никогда и не было нигде, кроме Adobe. Ghostscript реализует лишь подмножество стандарта, там даже 1.5 в полной мере не реализован. То же управление цветами в PDF до сих пор через пень-колоду то работает, то не работает в некоторых софтинах.
А есть же вообще экзотические реализации, вроде встроенного просмотрщика PDF в браузеры. Там вообще иногда каки-маляки выходят. Можешь в трэкер Мозиллы для интереса глянуть, сколько там багов 8-10 летней давности есть.
По–моему, мы говорим об одном и том же разными словами. =)Напомню, что началось всё с ответа на пост «не надо мне этих ваших новых спецификаций, у меня принтер старый, он мне ничего напечатает вместо картинки».
Мой же посыл в том, что шанс получить «блистательное ничего» есть и так, даже со старыми спецификациями. И если сильно надо, неплохо бы предпринять некие телодвижения и озаботиться проверкой PDF–ки c конвертацией по необходимости, а не пихать в принтер что попало.
А вот PDF–ки с картинками без артефактов, которые быстро распаковыаются и не весят как бегемот — это круто и прям очень давно назрело.
> А вот PDF–ки с картинками без артефактов, которые быстро распаковыаются и не
> весят как бегемот — это круто и прям очень давно назрело.PDF, который не весит, как бегемот... - это немного оксюморон. Строго говоря, PDF создавался как подмножество PS, в котором, для уменьшения нагрузки на CPU, разворачивались циклы, встраивались шрифты, иногда даже вектор в битмап конвертировался и делались прочие оптимизации, увеличивавшие размер данных. Да-да, туда добавили алгоритмы сжатия развёрнутых данных и пр... - я в курсе. Но суть генезиса формата была именно в создании подмножества дорогого в реализации на железе PS.
Есть банально бытовая проблема с тем, что в jxl будет доступно сразу сжатие с потерями и без - не получится отличать файлы чисто по расширению.
> Есть банально бытовая проблема с тем, что в jxl будет доступно сразу
> сжатие с потерями и без - не получится отличать файлы чисто
> по расширению.Проблема в том, что так везде сделали - .j2k, .webp, .bpg, .avif.
Вот анимацию выделяли расширением в apng (иногда ещё .heifs, .avifs).
В медиаконтейнерах хорошая традиция характеризовать содержимое: .ogv (ogg с видео), .m4a (mp4 без видео), .mka (матрёшка без видео).
j2k, webp, bpg и avif никто специально не использует. Либо кладут в PNG и не парятся, формат поддерживает альфу и открывается везде, либо жмут в жипег, причём зачастую в mjpeg. И то, что они разное содержимое обозначают одинакого им не помогает. docx и odt тоже всего лишь зипки, или логи программы (.log) и её конфиг (.cfg) тоже всего лишь текмтовые файлы в (надеюсь) utf-8 (без BOM и прочего дебилизма).
Я: не сложилось традиции уточнять lossy/lossless через расширение файла, хотя было бы полезно.Ты: *марково-цепочный ответ про то, что jpeg используют для видео, отсутствие пользы не помогает, а расширения используют для удобства пользователя*
???