[Перевод] Почему в Chrome маленькие JPEG выглядят иначе

Как‑то я общался с коллегой у него за компьютером и заметил, что логотип выглядит не совсем так, как моём компьютере. На компьютере коллеги он казался тоньше и больше походил на исходное изображение. Он имел размер 15px; на картинке выше показана его увеличенная версия.

Примечание: показано не исходное изображение. Это было уже довольно давно, поэтому я создал новое изображение, чтобы продемонстрировать, в чём же проблема.

Если прищуриться или отойти подальше, то изображение из Chrome выглядит толще. Это немного странно, но если заменить картинку на SVG, то проблема исчезнет. Однако мне всё равно стало любопытно: почему она вообще так рендерится?

Я провёл исследование и обнаружил в Chrome изящную оптимизацию, используемую для рендеринга JPEG в мелком масштабе.

Уменьшение размеров изображений может быть затратным процессом

Для рендеринга маленького изображения из JPEG логичнее всего полностью распаковать его в память, а затем уменьшить масштаб.

Но это не всегда оказывается эффективным решением.

Представьте JPEG размером 2000 × 2000, который нужно отобразить в размере 20 × 20. После распаковки изображение занимает гораздо больше памяти, чем конечный результат. Растровые данные всего изображения занимают примерно 12 МБ, а изображению 20 × 20 требуется всего 1,2 КБ. Бо́льшая часть информации исходного изображения будет потеряна при масштабировании.

Какая информация теряется при уменьшении масштаба?

Любопытно, что теряемая информация не случайна.

При сильном уменьшении изображения в основном теряются высокочастотные подробности. Это легко заметить визуально. Представьте дерево с кучей листьев и шероховатой корой: эти детали быстро меняются от пикселя к пикселю, поэтому считаются высокочастотной информацией.

Если уменьшить дерево, скажем, до 20 × 10, то останется только зелёное пятно листьев и коричневая палка ствола. В уменьшенной версии потерялись мелкие детали, то есть высокочастотная информация.

Частично доля высокочастотной информации всё же сохраняется, потому что детали смешиваются друг с другом.

Как JPEG хранит данные изображения

Я не буду усложнять своё объяснение, но упомяну технические термины, по которым желающие смогут изучить тему подробнее. Также я не буду рассматривать большую долю всего преобразования JPEG, потому что это нам не нужно.

При сжатии JPEG изображения разбиваются на блоки 8 × 8, преобразуемые в частотный интервал. Эта операция называется DCT (Discrete Cosine Transform, дискретным косинусным преобразованием).

Блоке 8 × 8 наименьшей возможной частотой будет один сплошной цвет. Строго говоря, это даже не частота, потому что ничего не меняется; это постоянная составляющая. Наибольшая же частота представляет собой шахматный паттерн, в котором значения меняются максимально. Все частоты между этими границами относятся к остальной части частотного интервала. Они называются базисными функциями.

То есть преобразуя блок 8 × 8 в частотный интервал, мы, по сути, задаём вопрос: насколько каждый паттерн представлен в этом блоке? Эти величины называются коэффициентами.

Сжатие JPEG выполняет ещё несколько этапов для эффективного сохранения этих коэффициентов, и именно на них происходит сжатие с потерями, но к нашей теме они отношения не имеют.

Соединяем всё вместе: рендеринг JPEG в масштабе 1/8

Допустим, нам нужно уменьшить изображение в восемь раз.

Следовательно, блоки 8 × 8 можно представить в уменьшенном изображении одним пикселем. При таком размере изображению в основном требуется низкочастотная информация, потому что, как и в примере с деревом, при масштабировании высокочастотные детали по большей мере теряются.

То есть вместо распаковки всего файла JPEG можно игнорировать коэффициенты высокочастотных частей и использовать только те, которые нужны для грубой версии изображения. Так мы получим уменьшенный результат без предварительной распаковки исходного изображения.

Декодированное изображение занимает меньше места и его быстрее распаковывать, потому что мы игнорируем большую долю коэффициентов.

Этот принцип можно перенести и на другие масштабы, при условии, что это дроби с делителем 8. Технический термин для этого — partial IDCT scaling (масштабирование частичным обратным дискретным косинусным преобразованием). См. jpegclub.org (если вы почитаете информацию там, то увидите, что эту методику можно применять и для увеличения размеров изображений!).

Как с этим связан Chrome

Chrome делегирует декодирование и рендеринг изображений рендереру Skia. Для JPEG Skia использует библиотеку libjpeg‑turbo, реализующую масштабирование частичным IDCT. Это позволяет ей декодировать только данные низкой частоты, если целевой размер достаточно мал.

Иными словами, Chrome/Skia не всегда распаковывают полное изображение и уменьшают его. Рендерер вычисляет ближайшую дробь с делителем 8 и декодирует изображение в этом масштабе. Затем он дополнительно уменьшает изображение при помощи более традиционного алгоритма даунсэмплинга, пока оно не достигнет нужного размера.

Именно поэтому на моей машине изображение выглядело толще. Оно рендерилось таким маленьким, что декодировалось в масштабе 1/8 частичным IDCT. То есть единственные данные, оставшиеся из частотного представления — это постоянная составляющая; все сглаживания краёв и градиенты не применялись.

Мораль истории: не стоит использовать JPEG для значков и тому подобного. Этот формат и его оптимизации проектировались на основании того, как люди воспринимают фотографии.

В конце концов, это даже есть в его названии: Joint Photographic Experts Group.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку