Comments 20
почему мы до сих пор на JPEG?
Проприеритарное очевидно сразу идет лесом каким бы прекрасным оно ни было, WebP не настолько лучше жмет чтобы стоило заморачиваться, а все остальные либо слишком недавно созданы либо вообще про них мало кто знает. Кроме того, не веб браузерами едиными, принося файл на флешке в копицентр хочется быть уверенным что его там распознают и напечатают адекватно.
современные все умеют нормально WebP
Firefox 140
Chrome 138
…и это главное свойство этих форматов — в них напихали столько всего, что к каждой Торе надо ещё пять раввинов прикладывать, чтобы суметь это трактовать. TIFF появился давно, но многие ли его широко используют? А многие ли вообще способны прочитать любой стандартный TIFF?
JPEG и GIF, при всех недостатках, лаконичны. Я ж не просто так не стал изобретать велосипед, а стал придумывать расширенные чанки в рамках стандарта, да ещё и желательно с максимальным реюзом имеющихся.
Блин, какой-то день самопиара у меня сегодня — второй каммент подряд ссылаюсь на «себя великого». Пойду чаю попью, мож отпустит.
Качество: Без потерь, лучше PNG
Если и там и там без потерь, то как оно может быть лучше/хуже? Если мы условную Lena.raw конвертим,
Патентованная (HEVC требует роялти)
На самом деле не так - ВОЗМОЖНО требует роялти, но это не точно, т.к. достоверно неизвестно используется ли что-то патентованное.
~50% лучше JPEG и WebP
а это как понимать? допустим webp = jpeg - 50% = jpeg/2, а avif тогда как? (webp + jpeg) - 50% то есть примерно на 75% лучше jpeg и на 25% лучше webp?
Вторая картинка гуляет по интернету в чистом png (не jpg) и с копирайтом Photutorial.com, который её создал без эксплуатации органических нейросетей, как заявлено в их статье:
Format comparison
JPG vs. JPEG
The main difference between JPG and JPEG is that JPEG is a file format, while JPG is a 3-letter file extension for JPEG
...
JPEG is better suited for lossless compression of photos
...
WebP produces smaller file sizes than AVIF
> Mozilla выступает за JPEG XL
Они выступают за всё хорошее и против всего плохого. Они поддерживают вообще всё что могут по закону)
Они высказывались против. Ну, формально, "нейтрально", но с подтекстом, что будут делать как Google.
Ну так. В чем хранить фотографии. Джипег можно без потерь. В джипеге есть немаленький экзиф.
Джипег ограничен по динамическому диапазону обычным монитором и превышает кратно диапазон отпечатка.
Наверное, лучше хранить сразу сжатый рав. Но тогда нужен стандарт преобразования в диапазон монитора, точно воспроизводящий джипен, плюс стандарт для мониторов, способных отображать бОльший динамический диапазон?
Плюс, если я не расситывал на бОльший диапазон, я должен дополнительно этим всем управлять? Иди его растянут на тот диапазон, в котором он будет выглядеть непонятно как?
Короче, большинство фотографов предпочтëт не экспериментировать, а дождаться четкого стандарта, который
Может хранить 12-14 бит на канал;
Может это отображать на любом мониторе заранее выбранным способом, в том числе разными способами на разных мониторах;
Может это печатать заранее обозначенным способом;
Совместим по екзив плюс дополнительные поля.
И то, это представляете, каким монстром надо быть, чтобы под разные устройства разную обработку делать, да ещë и в один файл это паковать...
этак вы новый вид DNG изобретете.
Да я немного не про то. Не буду фото пытаться загружать, просто картина Куинджи - Ночь на Днепре. Яркостью всего 4 стопа. И вот пусть это фотография, и в ней реально 14 бит. И ее отобразили на соответствующем мониторе. В тенях мы увидели бы "кашу" из шума. А луна? На ней рельеф непредусмотренный появится? А градиенты Днепра и облаков пойдут цветными пятнами?
Я это при редактировании не увижу.
Или увижу, но не увижу отображения на обычном мониторе.
Поэтому проще зашить всë в понятный старообрядческий джипег.
Жанр народного негодования имеет право на жизнь, но ведь не всегда уместен.
Выше так же зря "на публику" спросили, почему формат картинок с поддержкой float128 остался нишевым. Я однажды задумался - должны же быть вещи, которые в TIFF не влезут, которые он не способен вместить.
Иди его растянут на тот диапазон, в котором он будет выглядеть непонятно как?
HDR в экранах должен работать как в старом добром 2017 году, тут нет новостей.
Но в хранении HDR-изображений появился новый подход:
SDR + Gain Map
...который лучше решает проблему отображения в SDR и не требует новых файловых форматов - годится всё тот же JPEG.
Новые форматы создают ради сжатия.
Сжатие да, бесплатно хранить тонны картинок, это такое себе. Но вот идея фрактального сжатия (через уменьшение визуальной резкости) я так понял, так и не реализовано?
Фракталы для сжатия - не знаю, в мейнстрим такое не попало (и даже вейвлеты после JPEG2000 - где они?).
Но зато сжатие для фракталов... то есть в JPEG XL есть мощный режим (в основном для lossless), с помощью которого можно фрактал нарисовать.
картинка
Формально это всё умеет JPEG XL.
Если честно, из этого всего, кроме jpg я знал WebP (потому что в него сохраняются иногда картинки с браузера, а потом надо во что-то конвертить ибо никуда не воткнешь) и HEVC (потому что имел с ними гемморой после получения фото от счастливых обладателем ифонов, а потом надо во что-то конвертить ибо никуда не воткнешь).
jpeg бывает разный, сильно зависит чем кодируете. есть конвертер mozjpeg который жмет в jpeg на уровне webp, из-за чего webp теряет смысл существования
mozjpeg
Потом ещё был гугловский jpegli, который выше оценивали. Там и декодер доработанный, и опциональное улучшение в энкодере, завязанное на встраивание ICC-профиля.
Посмотрел свою последнюю ссылку - в небольшом тесте на 4 картинках с этой опциональной возможностью он бьёт вообще всех, кроме JXL. Наверное, потому что лишь 4 картинки и 1 метрика без субъективных сравнений и детального перебора настроек, но всё равно впечатляет.
Скрытый текст
Ещё есть jpeg2000/wavelet, не делающий jpeg-артефактов (мазни на контрастных границах и повтора контуров). Умеет лослесс. Умеет видео. Но не судьба, не успел на поезд.
Проблема действительно в распылении ресурсов и конфликте интересов.
Jpg вызрел к моменту, когда пригодился. Он был и остаётся неплохим вариантом, по большому счёту устраивающим всех (крупных игроков), и останется ещё долго. Потому что не накапливается критической воли для перехода на что-либо другое, нет единой точки принятия решений.
Можно без последствий вырезать ftp-клиента из браузера - исчезающе малое количество заинтересованных в устаревшем протоколе найдут, чем его заменить.
Но вырезать поддержку jpg, gif, png? Это как в анекдоте со старым диваном, заражённым клопами - хозяева не в первый раз его выбрасывают, а клопы заносят обратно.
Совсем другое дело вопрос с видеокодеками, так как он затрагивает вопрос монетизации контента и напрямую влияет на стоимость его хранения. Тут гугл, никого особо не спрашивая, перевёл свои сервера на AV1, и не важно сколько видеокарт с аппаратной поддержкой h264/h265 остались не у дел, или сколько мониторов с разрешением ниже 4k av1 просто не нужен.
Такой ситуации с изображениями может и не сложиться, т.к. нет монополиста по их хранению, который мог бы взять на себя столь важный шаг.
Некоторые из виденных сайтов с большим количеством картинок, внедрившие webp, пока не впечатляют качеством картинки - похоже, что контент был перекодирован в пакетном режиме из jpg, уже замыленного, что не добавило ни качества, ни энтузиазма по поводу перехода.
Потому что не накапливается критической воли для перехода на что-либо другое, нет единой точки принятия решений.
Так там не просто недостаток воли, там ещё прямой саботаж (дропнутая поддержка jpeg xl в хроме).
Ещё есть jpeg2000/wavelet, не делающий jpeg-артефактов
У него видится фатальный недостаток.
ffmpeg у меня декодирует его в 15 раз медленнее, чем jpeg92.ffmpeg -hide_banner -benchmark -i test.jp2 -f null -
1.5 секунды vs 100 мс на десяти мегапикселях. FastStone Image Viewer задумывается на 3 секунды. А теперь перенесёмся в нулевые...
Ускорять платным декодером - спасибо. Ускорять с потерей качества - тоже (впрочем, ускоренное подмножество выделили в 2019 - HTJ2K).
Можно поискать другие реализации.
Где-то в 2006 заменял им xvid в системе аналогового видеонаблюдения - при незначительно возросшей нагрузке на процессор качество поднялось существенно. Правда не помню уже конкретную библиотеку, и да, наверно она была платная, но тогда это меня не особо волновало.
Перепробовал тогда все попавшиеся под руку кодеки, в том числе из K-Lite Codec Pack - в нём, кстати, немало платных кодеков было в то время.
Ну, среди свободных / бесплатных знаю родной ffmpeg'овский (-vcodec jpeg2000) и сторонний OpenJPEG (-vcodec libopenjpeg). Сторонний декодер был ещё медленнее и его удалили в 2023 в рамках решения оставлять только собственные декодеры их при наличии. Энкодер оставили.
Документация пропитана презрением - родной энкодер более-менее задокументирован только на сайте, а сторонний, наоборот, там не упоминается и не имеет описания параметров в хелпе или исходниках.
В lossless-режиме по степени сжатия оба не обгоняют png (медленный пресет выставил бы, если бы его можно было настроить). Из одного крупного бенчмарка lossless-кодеков его выкинули, не впечатлившись результатами (какой именно кодек - не знаю, но явно не платный).
______
Про Motion JPEG 2000 - до этого знал только про применение в кино, его там в DCP используют.
Современные форматы изображений или почему мы до сих пор на JPEG?