Познакомившись в конце августа позапрошлого (2018) года с утилитою OptiPNG, способною уменьшать объём графических файлов в формате PNG без внесения потерь в них (а только за счёт прямого перебора настроек сжатия графических данных для поиска наиболее подходящей для конкретного файла комбинации настроек), я без промедления упомянул о ней тремя абзацами в Фидонете и затѣмъ ещё в Твиттере — и начал ею в дальнейшем пользоваться. Подобная оптимизация файлов полезна и в сайтостроении (чтобы быстрѣе доставлять иллюстрации читателям), и в Твиттере (вѣдь въ послѣдніе годы Twitter ввёл такие правила, согласно которым любой публикуемый файл PNG, превосходящий размѣры 900×900 пикселов, будет на стороне сервера принудительно сжат в формат JPEG с качеством, равным 85 пунктам — то есть с внесением потерь — если только не был заранее оптимизирован до такой степени, что упомянутое переужатие в JPEG привело бы к росту его объёма), и на имиджбордах (особенно тѣхъ, которые ограничивают объём файла всего-навсего нѣсколькими мегабайтами) — всюду, всюду полезна.
Однако по опыту употребления OptiPNG нельзя не замѣтить два крупных недостатка OptiPNG.
Первый недостаток — однопоточная конструкция: даже работая в том режиме, которым предполагается перебор болѣе тысячи комбинаций настроек («-o7 -zm1-9»), утилита OptiPNG перебирает их послѣдовательно, не пытаясь распараллелить своё занятие и получить выгоду от многоядерности современных процессоров.
Второй недостаток — происхождение: нельзя не видѣть, что большинство перебираемых настроек имѣетъ отношение к работе библиотеки zlib: какой у ней используется уровень сжатия, какая стратегия сжатия, сколько употребляется памяти. В общем-то, таковы вообще всѣ перебираемые OptiPNG настройки, за исключением одного только выбора из шести вариантов настройки фильтрации PNG (пять вариантов «один фильтр на весь файл», шестой — эвристический метод Крокера для выбора фильтра отдѣльно для каждой строки пикселов). Это значит, что само по себе появление OptiPNG (и других аналогичных оптимизаторов) вызвано прежде всего тѣмъ, что zlib ведёт себя не логично и предсказуемо («задай максимальный уровень сжатия и количество памяти — получи наилучшее сжатие»), а слишком случайно — достаточно случайно для того, чтобы побуждать к тому, чтобы попробовать настройки похуже и поглядеть, не получится ли результат получше.
Получается, что для решения именно этой задачи — для оптимизации файлов PNG — была бы в среднем куда полезнѣе не такая реализация алгоритма DEFLATE, которая побуждает попробовать десятки вариантов настройки и иногда получить оттого неожиданно хороший результат (как zlib), а такая реализация, которая всегда работает въ нѣсколько десятков раз медленнѣе, но зато всегда же (а не время от времени) получает болѣе сжатые графические данные, получает меньший объём файла.
И что же, есть ли такая реализация с открытым исходным кодом? — оказывается, есть: Zopfli. Статья в Википедии сообщает, что появление Zopfli относится к 2013 году. Того же года статья в австралийском «Лайфхакере» свидетельствует, что работа Zopfli на реальных текстовых данных (взятых из статей Википедии) была раз в восемьдесят медленнее аналога (gzip), но зато и объём получающегося архива был на 1½% меньше.
Но это на текстовых данных, не на графических — а пытались ли примѣнить Zopfli к сжатию файлов PNG? Оказывается, в том же году (в 2013 году) появилась утилита ZopfliPNG (от создателей Zopfli), которая как раз и должна была примѣняться для оптимизации файлов PNG; но мнѣ достаточно было одного взгляда на её файл README, чтоб разочаровать себя пониманием того, что утилита ZopfliPNG не удобна для реального использования. Слишком уж она, как это называется? — opinionated: стремится навязать пользователю своё мнение.
Напримѣръ, ZopfliPNG по умолчанию убирает из файла метаданные и не имѣетъ такой простой настройки, которая позволила бы не убирать (а имѣетъ сложную: прочтите документацию по формату PNG, составьте список идентификаторов сохраняемых метаданных). Нѣтъ и настроек (для OptiPNG привычных) для пересохранения файла в чересстрочном виде (Adam7).
Однако по опыту употребления OptiPNG нельзя не замѣтить два крупных недостатка OptiPNG.
Первый недостаток — однопоточная конструкция: даже работая в том режиме, которым предполагается перебор болѣе тысячи комбинаций настроек («-o7 -zm1-9»), утилита OptiPNG перебирает их послѣдовательно, не пытаясь распараллелить своё занятие и получить выгоду от многоядерности современных процессоров.
Второй недостаток — происхождение: нельзя не видѣть, что большинство перебираемых настроек имѣетъ отношение к работе библиотеки zlib: какой у ней используется уровень сжатия, какая стратегия сжатия, сколько употребляется памяти. В общем-то, таковы вообще всѣ перебираемые OptiPNG настройки, за исключением одного только выбора из шести вариантов настройки фильтрации PNG (пять вариантов «один фильтр на весь файл», шестой — эвристический метод Крокера для выбора фильтра отдѣльно для каждой строки пикселов). Это значит, что само по себе появление OptiPNG (и других аналогичных оптимизаторов) вызвано прежде всего тѣмъ, что zlib ведёт себя не логично и предсказуемо («задай максимальный уровень сжатия и количество памяти — получи наилучшее сжатие»), а слишком случайно — достаточно случайно для того, чтобы побуждать к тому, чтобы попробовать настройки похуже и поглядеть, не получится ли результат получше.
Получается, что для решения именно этой задачи — для оптимизации файлов PNG — была бы в среднем куда полезнѣе не такая реализация алгоритма DEFLATE, которая побуждает попробовать десятки вариантов настройки и иногда получить оттого неожиданно хороший результат (как zlib), а такая реализация, которая всегда работает въ нѣсколько десятков раз медленнѣе, но зато всегда же (а не время от времени) получает болѣе сжатые графические данные, получает меньший объём файла.
И что же, есть ли такая реализация с открытым исходным кодом? — оказывается, есть: Zopfli. Статья в Википедии сообщает, что появление Zopfli относится к 2013 году. Того же года статья в австралийском «Лайфхакере» свидетельствует, что работа Zopfli на реальных текстовых данных (взятых из статей Википедии) была раз в восемьдесят медленнее аналога (gzip), но зато и объём получающегося архива был на 1½% меньше.
Но это на текстовых данных, не на графических — а пытались ли примѣнить Zopfli к сжатию файлов PNG? Оказывается, в том же году (в 2013 году) появилась утилита ZopfliPNG (от создателей Zopfli), которая как раз и должна была примѣняться для оптимизации файлов PNG; но мнѣ достаточно было одного взгляда на её файл README, чтоб разочаровать себя пониманием того, что утилита ZopfliPNG не удобна для реального использования. Слишком уж она, как это называется? — opinionated: стремится навязать пользователю своё мнение.
Напримѣръ, ZopfliPNG по умолчанию убирает из файла метаданные и не имѣетъ такой простой настройки, которая позволила бы не убирать (а имѣетъ сложную: прочтите документацию по формату PNG, составьте список идентификаторов сохраняемых метаданных). Нѣтъ и настроек (для OptiPNG привычных) для пересохранения файла в чересстрочном виде (Adam7).