6 заметок с тегом

jpeg

Какие ещё графические форматы поддерживает ваш браузер?

Переложил на хостинг «Гитхаба» свой проект семилетней давности — «Какие графические форматы поддерживает ваш браузер?». Я его иногда обновляю и мне было бы проще это делать через репозиторий.

Из всего, что я там проверяю, сразу не сработала только проверка на AVIF — это новейший формат, у меня на компьютере его поддерживает пока только «Файерфокс», ему важно указание типа содержимого, а «Гитхаб» передаёт неправильное значение.

Браузеры (сверху вниз): «Сафари» 13, «Файерфокс» 78 и «Опера» 69

Я подумал, что наверняка есть какой-то способ указать правильный тип в файле конфигурации сайта, но нет, так это не работает, такой настройки в нём нет. В принципе, известно откуда «Гитхаб» берёт свою базу типов содержимого — из проекта mime-db. Но этот путь тоже не сработал — я добавил туда тип для AVIF больше недели назад, но ничего не изменилось. Видимо синхронизация изменений происходит нечасто.

Пришлось идти другим путём — вместо того, чтобы загружать файл картинки, внедрил его внутрь при помощи протокола data:, это позволило обойти проблему. Можете протестировать на своём браузере.

Ссылка на проект: https://bolknote.github.io/detect-browser-graphics-formats/
Ссылка не репозиторий проекта: https://github.com/bolknote/detect-browser-graphics-formats

JPEG: арифметическое кодирование

Редактор «ГИМП» умеет открывать джейпеги с арифметическим кодированием

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

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

WebP едва появился в большинстве браузеров, а уже предлагается добавить поддержку BPG и FLIF. На фоне этой всей движухи неясно почему почти никто не обращает внимание на арифметическое кодирование в старом-добром джейпеге.

Этот метод кодирования изначально был защищён патентами компании «АйБиЭм» и поэтому декодеры его не реализовывали, но несколько лет назад патенты истекли и теперь вполне можно было бы добавить его в браузеры, жаль, что пока никто этого не сделал.

Эксперимент по использованию различных оптимизаторов джейпега

Меня привлекают в арифметическом кодировании две вещи: почти моментальная скорость преобразования без потерь из «традиционного» джейпега и бо́льшая эффективность кодирования.

Для эксперимента я взял первый попавшийся джейпег, который лежал у меня в папке «Загрузки» и попробовал сравнить результат арифметического кодирования и другие методы оптимизации в различных сочетаниях. На скриншоте выше example0 — исходный файл, example1 и example2 — результаты арифметического кодирования, остальные файлы применением других оптимизаций.

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

Как починить PNG и JPEG

Недавно мне нужно было восстановить несколько сотен картинок в формате PNG и JPEG силами командной строки — часть содержимого в файлах испорчена и задача была вытянуть хоть что-нибудь.

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

Заклинания для восстановления звучат так:

optipng -fix broken.png -out fixed.png
jpegtran -outfile fixed.jpg broken.jpg

Первая утилита распространяется самостоятельно, вторая — в составе libjpeg или mozjpeg.

 Нет комментариев    31   2018   jpeg   png

mozjpeg 3.3.1

Заворачивал в пакет для седьмой ЦентОСи относительно свежий mozjpeg. В теории всё просто, на практике просто так пакет не собрался, пришлось корректировать руками. Запишу себе сюда, чтобы не забыть что делал.

Нужно отредактировать в двух местах файл mozjpeg.spec.in (ниже готовый патч под утилиту patch):

diff -urd --ignore-blank-lines --minimal a/release/mozjpeg.spec.in b/release/mozjpeg.spec.in
--- a/release/mozjpeg.spec.in	2017-07-10 13:58:14.000000000 +0300
+++ b/release/mozjpeg.spec.in	2018-10-12 12:30:04.172828265 +0300
@@ -8,7 +8,7 @@
 %define _datadir %{__datadir}

 # Path under which docs should be installed
-%define _docdir /usr/share/doc/%{name}-%{version}
+%define _docdir /opt/mozjpeg/doc/%{name}-%{version}

 # Path under which headers should be installed
 %define _includedir %{__includedir}
@@ -35,7 +35,7 @@
 Release: @BUILD@
 License: BSD-style
 BuildRoot: %{_blddir}/%{name}-buildroot-%{version}-%{release}
-Prereq: /sbin/ldconfig
+Requires(pre,preun): /sbin/ldconfig
 %ifarch x86_64
 Provides: %{name} = %{version}-%{release}, @PACKAGE_NAME@ = %{version}-%{release}, libturbojpeg.so()(64bit)
 %else

Дальше запустить:

autoreconf -fiv
./configure
make rpm

И получится пакет.

Предложил авторам утилиты правку на «Гитхабе», посмотрим примут ли.

Дополнение: ура, патч приняли в репозиторий, теперь можно не патчить самостоятельно.

cjpeg-dssim

У меня давно, во времена работы над книгой, возникла идея — попробовать подбирать параметр качества для джейпега автоматически так, чтобы глаз не улавливал разницы между оригиналом и результатом. Правда я не был уверен насчёт метрики, мне виделось это как вычитание одной картинки из другой с какой-то интегральной оценкой результата.

На днях я про эту идею вспомнил и, как это обычно и бывает, оказалось, что существует и метрика, и утилита для её снятия, и утилита для подбора параметра качества.

На «Маке» всё необходимое для работы утилиты для подбора элементарно ставится из «брю», вот результат обработки картинки из предыдущего моего поста:

$ ./cjpeg-dssim jpegoptim test/2018.02.17.1@2x.jpg
$ ll -h test
total 584
drwxr-xr-x+ 4 bolk  staff   128B 18 фев 12:09 .
drwxr-xr-x+ 7 bolk  staff   224B 18 фев 12:09 ..
-rw-------@ 1 bolk  staff   187K 18 фев 12:00 2018.02.17.1@2x.jpg
-rw-r--r--+ 1 bolk  staff   102K 18 фев 12:09 2018.02.17.1@2x_cjpeg_dssim.jpg

Экономия 85 килобайт, это очень существенно, при этом разницу на картинке я и правда не вижу. Буду теперь обрабатывать иллюстрации этой утилитой.

Обработка дополнительно утилитой jpegtran из пакета mozjpeg даёт ещё два килобайта экономии.

 7 комментариев    40   2018   jpeg

Сжатие картинок

Вчера попробовал натравить инструменты для оптимизации картинок на свой каталог с картинками этого блога. Результат следующий: выигрыш составил около 10 процентов (больше всего у меня JPEG-файлов). Немного, но и не мало в некоторых ситуациях. Я использовал только утилиты для командной строки.

PNG. Для сжатия PNG использовался известнейший pngcrush. Интересен в режиме «brute force» (перебора), где перебираются комбинации фильтров (фильтры — это специализированные методы сжатия, например, для градиента и т. д.). Я запускал сделующим образом: «pngcrush -brute -fix -e .png1 *.png». В итоге, все файлы png у меня в папке получают свою оптимизированную копию с расширением png1. Есть опасный момент — если у вас есть файлы APNG, pngcrush их превратит в файл без анимации. Экономия получилась порядка 7%.

JPEG. В JPEG’e особо оптимизировать нечего, формат сжатия с потерями, поэтому оптимизацию без участия человека не произвести — трудно просчитать насколько критично изменился рисунок. Оптимизировать тут нечего, но можно убрать мусор — многие программы записывают в файл комментарии, лишнюю информацию. Я использовал для чистки PureJPEG, после него прошёлся своим Photoshop Crap Remover, чтобы дочистить файл. Формат запуска PureJPEG следующий: «dir /B /S /A-D *.jpg | purejpeg», в итоге все файлы с расширением jpg будут вычищены. Моя утилита написана на PHP, так что я даже не буду упоминать как её запустить — кому надо разберётся, остальным объяснить очень трудно. Экономия — около 10%.

GIF. Несмотря на то, что утилите GIFLite уже около 12 лет, мне она кажется лидером по переупаковке GIF. Утилита написана White River Software, её разработка начата ещё в 1992 году и она рабоатет под DOS, т. е. должна запускаться даже в Linux из-под какого-нибудь DOSEmu. Утилита платная, но кому платить уже непонятно — никаких координат этой фирмы в сети нет. Поэтому ищем любой ключ, запускаем giflite с ключём /R и «регистрируемся».

Запускать её сложнее, чем предыдущие — в 1992-м году длинных имён не было, да и перебирать свои методы она не умеет. Поэтому я написал небольшую batch-программу. Она проходит по всем GIF-файлам в папке, применяет на каждый один из четырёх методов (видимо выбирается какая-то стратегия для выбора словаря в LZW-сжатии), после чего выбирает файл с наименьшим размером. Экономия составила около 8%.

giflite.cmd:

@ECHO OFF
REM Написал Евгений «BOLK» Степанищев. 2007.

MKDIR GIFLITE.$$$ 2>nul

REM Основной цикл обработки файлов GIF
FOR /R %%N IN (*.gif) DO @CALL :method %%N

REM Удаляем весь мусор, который мог остаться
DEL /Q giflite.tmp 2>nul
RMDIR /S /Q GIFLITE.$$$
EXIT

:method
REM Перебираем методы
FOR %%M IN (0 1 2 3) DO @CALL :giflite %%M %%~s1 %1

REM Сортируем полученное по размеру и забираем последний (наименьший) файл
FOR /F "usebackq skip=3" %%R IN (`DIR /B /O-S GIFLITE.$$$`) DO @CALL :getresult %%R %1
GOTO :EOF

:getresult
REM Переписываем файл на место прежнего, удаляем мусор
MOVE /Y GIFLITE.$$$%1 %2
DEL /Q GIFLITE.$$$*.*
GOTO :EOF

:giflite
REM Запускаем преобразование
GIFLITE.EXE -t -h -m%1 -o %2 GIFLITE.$$$%1 >nul 2>nul