Comments 67
я правильно понимаю, что если раньше можно было прятать вирусы в контейнерах картинок, то теперь сама картинка может стать вредоносной программой?
Нет, не может. Картинка всё ещё остаётся картинкой, самое вредное что она может сделать — повиснуть при открытии.
Конечно есть вероятность что не все предусмотрено, но вроде как специально проектируют с учетом, чтобы такого не случилось.
Это, конечно, довольно интересный феномен - возможность настолько сильно сжать определённые виды картинок.
Но, говоря о "недостатках" форматов, основанных на видеокодеках - что именно имеется в виду? Тот же WebP с качеством 90, визуально практически неотличимый от исходного lossless PNG, обгоняет JPEG в 2-3 раза, а не на 20%.
+ иногда нужен максимальные размер файла, CMYK, дополнительные каналы и слои (названые дополнительными каналами)
К сожалению я так понял пока потестить в реальной жизни не получится — не нашел ссылки на кодек. Из доступных сегодня потестировал AVIF (есть даже файл-плагин под Photoshop) — он дает лучший результат качество/объем — но удобство на нуле, превью при сохранении нет и ресурсоёмкий до жути.
>визуально практически неотличимый
Здесь вообще неотличмый. Mathematically lossless. Можно взять lossy jpeg и сжать, а потом расжать и получить тот же битстрим. Не уверен поддерживается ли один из многих видов lossless jpeg.
VP8, на котором основан WebP, жмёт изображение в цветовом пространстве Y'CbCr 4:2:0, то есть только информация о яркости пикселей в исходном разрешении, а разрешение у цветовой информации ниже, и это прямой недостаток WebP lossy. Не всегда это приемлемо.
Тут, скорее, наоборот: сжатая картинка первична, результат распаковки — вторичен. Эдакий трюк, «смотрите, как мы могём», чтобы увести внимание от всего лишь 20% преимущества перед стандартным JPEG на реальных изображениях. Я на 99% уверен, что кодировщик результат распаковки не ужмёт обратно в эти самые 59 байт.
А 20% — это только для безпотерьного сжатия уже существующих JPEG. И не «всего», а «целых», так как ни WebP, ни AVIF не предлагают возможность дожимать существующие JPEG без потерь. Вместе с JPEG XL вы можете взять архив из сотен гигабайт фоток в формате JPEG, и дожать их в JPEG XL не переживая что где-то будет заметная деградация качества. А потом, при необходимости, получать из них обычный JPEG обратно, опять без потерь в качестве. С WebP и AVIF так не получится.
То есть, если JPEG XL будет поддерживаться большинством браузеров, можно будет смело хранить все картинки в этом формате, а для устаревших браузеров, которых со временем будет всё меньше, на лету генерить обычный JPEG из этих JXL файлов. Можно и наоборот, хранить JPEG, и на лету генерить JXL для современных браузеров, экономя трафик пользователя (так же как сейчас странички на лету сжимаются gzip/brotli). Для этого дела даже специальный Content-Encoding предлагается добавить, чтобы пользователь даже не заметил, что ему JPEG-и на самом деле отдаются в формате JPEG XL =)
До 4100 каналов, т.е. оттенков серого или RGB, опционально альфа-канал, и до 4096 «дополнительных» каналов;
Что это фраза означает? Белиберда какая-то.
Термин "канал" в компьютерной графике обозначает представление одного формирующего цвета (или характеристики цвета) в какой-либо цветовой модели. Обычно их количество в цветовой модели от 3 до 4 (RGB, CMYK, Lab/YCbCr, HSL и т.п.). Откуда эти непонятные "4100 каналов"?
оттенков серого или RGB - так чего именно? Оттенков серого или цветов RGB? Для 8-битной модели это 256 против 16.777.216. Это как бы разница в 5 порядков.
альфа канал - окей.
4096 «дополнительных» каналов - тоже самое. О чём это вообще?
UPD: Я, конечно, понимаю что 2^12 = 4096, и очевидно речь идёт о 12-битной модели. Но можно было бы выразить это как-то более вменяемо? 12 бит, кстати, действительно принципиально позволяют получить "передачу без потерь". По крайней мере, на физиологическом уровне.
Судя по тому, что 4100 = 4096 + RGB + A, имеется в виду несколько другое. В картинку, помимо стандартных RGBA, могут быть добавлены 4096 каналов с дополнительной информацией.
Нужно это, понятное дело, не для прямого вывода на экран или бумагу, потому и в цветовое пространство оно не входит. Например, в системах компьтерного зрения дополнительным каналом может идти расстояние до объекта, полученное с лидара. А в системе трёхмерной графики в дополнительные каналы можно запихать карту нормалей.
Как-то за уши вы притягиваете. Если что-то вылезает за видимый диапазон, то логично использовать подходящее цветовое пространство (тот же Lab, например). К чему эти непонятные каналы? Так-то и в мета-инфу что угодно писать можно. Т.е. число каналов взяли с запасом на будущее, а то, как эти каналы интерпретировать для вывода - дело десятое?
В пределе, при достаточно большом количестве каналов, из такого изображения можно восстановить спектр для каждого пикселя. Модель LAB для этого не подходит совсем — в ней каждый пиксель монохроматичен by design.
"Тот же Lab" не описывает ничего за пределами видимого диапазона. Ни ИК, ни УФ в Lab не входят.
Т.е. число каналов взяли с запасом на будущее, а то, как эти каналы интерпретировать для вывода — дело десятое?
Именно так.
JPEG работает с 4 каналами. CMYK, YCCK, PhotoYCC-A и т.д.
Восприятие цвета не ограничено тремя-четырьмя каналами. Зрение того же рака-богомола значительно сложнее и информативнее человеческого и нет смысла не позаимствовать готовую идею по мере созревания соответствующих технологий. Для каких-то применений нужно максимально сжать изображение, в других случаях необходимо сохранить всю полученную информацию без потерь. К примеру, отдельно сохранять информацию с каждого типа сенсора (актуально и сейчас для различных телескопов), отдельно с каждой фасетки (в случае телескопов-интерферометров — с каждого отдельного телескопа), но в пределах одного файла, при этом сжатого для экономии дискового пространства (а его для астрономических наблюдений никогда не бывает достаточно).
Птицы ощущают линии магнитного поля — такой датчик тоже пригодится, да мало ли что ещё.
На БАКе в ходе сложных и дорогих экспериментов пишется около 5% наблюдений, считающихся наиболее интересными, остальное отбрасывается — не выплеснуть бы с водой ребёнка, ведь гарантии правильности фильтрации нет, может с отброшенными данными учёные потеряли искомые новые частицы. Кстати, тут реализация в стандарте машины Тьюринга может помочь выявлять закономерности в данных, как впрочем и в астрономии.
Новый формат можно использовать и для хранения голографических изображений, также многослойных и ёмких.
Позже подтянется пленоптика (вычислительная фотография), там будет что сжимать — и по разрешению, и по количеству вычисляемых планов.
В общем, был бы хороший бесплатный формат, а желающие им воспользоваться найдутся.
Отдельный вопрос — поддержка нового формата браузерами — она уже есть, но пока отключена по умолчанию.
Три типа колбочек в человека: SML (условно RGB)
Году в 2006 вкорячивал JPEG 2000 в систему видеонаблюдения. По сравнению с имевшимся xvid получилась заметная экономия дискового пространства при визуально лучшем качестве изображения и незначительно подросшей нагрузке на процессор. Но были же причины по которым его не внедряли массово.
JPEG-Coin'ы предчувствую я...
На сервере-то новый формат может работать со старым, это не новость. А на клиенте?
jpeg2000, да тот же webp - они уже есть, поддеерживаются почти всеми, но не всеми браузерами и кусочками ПО, и для отдачи webp нужно еще обвязку придумывать (или забивать на его поддержку). Почему судьба нового «джпега» должна оказаться лучше?
И, да, ставить браузер или плагин в браузер, чтобы у меня полныота по тьюрингу в картинке начала поддерживаться - я лично не захочу, а 90% населения сети даже не поймут, зачем вообще.
Лучшее, что я пока придумал — это создать SVG и в него запихнуть несколько картинок, закодировав в виде текстовых строк в base64, получается как-то так:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<image href="data:image/jpg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDABALDA4MCh..."/>
<image href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA88AAAMrCAYAAAB3Xq..."/>
</svg>Технически оно работает, и текст не портит, и размер файла практически идентичен сумме размеров исходных файлов. Браузеры нормально открывают. Но никакие сервисы не принимают такое — везде говорят, или давайте нормальную картинку, или извольте вам выйти вон, т. е. опять можно только где-то «у себя на страничке». А ведь, казалось бы, не такая уж экзотическая задача, должно же что-то готовое быть.
pdf, svg, html, pcl — не то, сложность полной реализации соответствующих машин далеко выходит за рамки скромного графического формата, просто содержащего в себе два слоя — сжатый растровый и несжатый векторный.
Та даже отдельного векторного формата с удобными бесплатными средствами создания индустрия не родила за десятилетия.
Впрочем, вместо векторного слоя сгодился бы и растровый в png — он идеален для синтетических изображений. К тому же, поддерживает анимацию.
Когда-то хотел видеокодек с регулируемым фреймрейтом и поддержкой картинки-в-картинке — к примеру, для записи различных докладов было бы актуально — изображение презентации на проекционном экране, обновляемое раз в несколько секунд синхронно с листанием страниц, и в окошке — докладчик с более частой сменой кадров.
Заслуженно пользуется популярностью в некоторых нишах.
Причина «невзлёта», кмк, та же что у JPEG 2000 — лицензионная политика правообладателей на этапе становления формата, она же возможно вызвала отсутствие заинтересованности браузеростроителей в интеграции формата.
У JPEG XL с этим проще, потому лучше.
avif так умеет, там можно указать min и max качество как раз для этого
min можно поставить равным 0, что будет означать lossless (но для качественных букв и min = 10 подойдет), а max допустим 10 (из 63, для убитых jpg лучше 20-25). И он как раз выберет где требуется lossless, а где можно сжать
В итоге оставит фотографию как есть, можно сказать без потерь, и резкость/качество букв оставит на уровне png
При чем это будет обычная картинка, можно использовать просто с img в html, но поддержка браузеров всего 66%. Некоторые просмотрщики картинок тоже могут его открывать, например, xnview.
И webp тоже похожее умеет, у него есть режим nearlossless (так и называется)
Да и просто webp с высоким значением q (например, 95) скорее всего тоже справится без проблем.
Но вот у него уже поддержка 91% в браузерах, в новых safari тоже работает. И даже paint его открывает на 10 винде.
Но вот чтобы прям везде — такого да, пока нет.
lossy VarDCT, lossy modular, lossy palettization, lossless palettization, lossy delta palettization, near lossless, true lossless, VarDCT with 256x256 dcts only, generative art can all be mixed and a single image can be composed from them — all with or without using patches and splinesУ формата слишком много возможностей. Кодер можно будет совершенствовать вечность =)
Каждое из них можно запрограммировать, оно обладает достаточной мощностью для запуска многих программ
Какая разница, когда драйверы видеокарты тащат с собой полноценный NodeJS, так что он установлен минимум у половины всех домохозяек мира — и записан в доверенные программы у антивирусов. Powershell хотя бы фиговым листком из Policy прикрыт.
А какой на данный момент формат является оптимальным (экономит место и широко поддерживается) для фотографий в вебе без видимых потерь качества?
Повысить качество обычных JPEG можно используя mozjpeg для сжатия. Качество сжатия очень зависит от кодера, и mozjpeg сегодня лучший для обычного JPEG.
Ну, да - изувечить артефактами сжатия равки, а потом ещё на 20% дожать - вместо того, чтобы сразу сконвертировать их в WebP, который будет занимать в два раза меньше, выглядя гораздо лучше.
Ваш случай с "архивом на сотни гигабайт джипегов" - только один из вариантов, хоть и довольно распространённый. Но хранящие изображения с изначально качественным исходником в джипеге, имхо, изначально ССЗБ и от XL будут просто чуть меньше страдать.
Над JPEG XL работают уже не первый год. В него вошли наработки автора FLIF/FUIF, Google PIX и Google Brunsli. Его уже не первый год пилят, и получается действительно что-то стоящее, а не как WebP, который в чём-то оказался даже хуже старичка JPEG. Формат назвали WebP, но он даже прогрессивную загрузку не поддерживает в принципе, ну как так можно было?
Если уж и использовать WebP, то только в режиме lossless, чтобы потом можно было без утраты цветового разрешения перегнать в какой-то более современный формат.
AVIF can reach the perceptual quality of a bad q20 jpeg in only half the bytes.И вот тут хорошая статья об этом с примерами.
JXL cannot do that (yet?), but it can reach the perceptual quality of a good q80 jpeg in only half the bytes — which is something AVIF cannot (yet?) do.
Предвижу возникновение нового жанра на демосцене: 256-byte JPEG XL
Формат JPEG XL будет полным по Тьюрингу без ограничения 1024*1024 пикселей