Насчёт утилиты pngquant, упомянутой в предшествующем сообщении, хочется прибавить (и прибавляю) три послѣсловія:
① Я обратил внимание на pngquant, руководясь анонимною наводкою, которая чуть болѣе ¼ года тому назад (14 ноября 2021 года) была оставлена в одном анонимном обсуждении на 4channel, которое давно уж стёрто оттудова, но скриншот до сих пор сохраняется на Nowere. Нѣсколько позже (2 января) я упомянул на 410чанѣ примѣръ такого малоцвѣтнаго изображения (3169 цвѣтовъ), на 4channel в том обсуждении разсмотрѣннаго, которое при обработке в pngquant не только достигает значительной информационной плотности (менѣе ⅔ бита на пиксел), но и по метрике PSNR (по соотношению сигнала и шума) превосходит сжатие WebP почти на четыре децибела при ≈равном объёме файла.
② Движок, служащий в pngquant собственно для «квантования» изображений (для продуманного приведения к ограниченной палитре цвѣтовъ), нынешним разработчиком был переписан на языке Rust и в качестве отдѣльной библиотеки (libimagequant) может употребляться для этой же цѣли в задачах, ужé не связанных с кодированием PNG. Хорошим примѣромъ этого является утилита gifski, сочинённая этим же разработчиком для создания таких анимированных GIF, каждый кадр в которых использует свою собственную палитру (продуманно подобранную в libimagequant), а внесённая ошибка перераспредѣляется во времени, по возможности компенсируясь слѣдующими кадрами. Постоянные читатели моего канала могут помнить, что я ужé упоминал про gifski в позапрошлом (2020) году, когда въ послѣднемъ абзаце вон того сообщения досадовал о том, что разработчики Телеграма напрасно воздерживаются от поддержки анимированных PNG и анимированных WebP (даже не перегоняют такие анимации в формат MP4, хотя перегоняют GIF), как будто надѣются на то, что пользователи самостоятельно возьмут FFmpeg да начнут, скажем, перегонять APNG в MP4 — а меж тѣмъ пользователи вполне способны вмѣсто того перегонять в GIF и для того задѣйствовать gifski, руководясь привлекательностью результатов и притом ничуть не сдерживаясь двухгигабайтовым-то ограничением объёма файлов GIF в Телеграме; правда, нѣкоторые клиентские программы откажутся анимировать GIF (и предложат вмѣсто того скачать файл) гораздо раньше, чѣмъ GIF успѣетъ сдѣлаться двухгигабайтовым. Упомянутая привлекательность столь значительна, что кадры GIF, создаваемые в gifski, кажутся болѣе многоцвѣтными, чѣмъ на сáмомъ дѣлѣ — так, напримѣръ, упоминаемая в Википедии технология создания реально многоцвѣтныхъ изображений GIF (в которые каждый кадр анимации, сам по себе 256-цвѣтный, притаскивает содержимое небольшой доли изображения — одной ячейки в матрице 4×4 или в матрице 3×3) показалась автору вон той страницы вики BasicSR используемою и в gifski. (На дѣлѣ же gifski не тратит болѣе одного 256-цвѣтнаго кадра GIF на один кадр исходной анимации, ограничиваясь временны́м перераспредѣленіемъ погрѣшностей палитры. Болѣе того: ещё в 2012 году вон тѣмъ изслѣдованіемъ и затѣмъ вон той демонстрациею показано, что браузеры не отображают болѣе 50 кадров GIF в секунду — слѣдовательно, не то что в 4×4 раза или в 3×3 раза, но даже и двукратно увеличить частоту кадров для лучшей цвѣтопередачи не получится, если исходная анимация ужé использует болѣе 25 кадров в секунду. Попытки сдѣлать больше 50 кадров в секунду во браузерах наказываются замедлением, что было видно у Степанищева и на Хабре, но не совершенно понято ими.)
③ В июле позапрошлого (2020) года я рѣшилъ, что впредь буду использовать oxipng для сжатия файлов PNG. Но для итогов работы pngquant я перемѣнилъ это рѣшеніе и намѣренъ использовать утилиту Efficient Compression Tool, которая сжимает сильнѣе и быстрѣе, чѣмъ oxipng. Прежде я избѣгалъ ECT, видя неспособность ECT прибѣгнуть к алгоритму Adam7, который ещё до окончания скачивания файла позволяет зрителю возымѣть нѣкоторое впечатление о содержимом файла — но послѣ pngquant файл PNG чаще всего не превосходит мегабайта и вскоре скачивается цѣликомъ. И для сжатия тѣхъ из сшивок кадров аниме, которые не превосходят мегабайта, я с января также начал примѣнять ECT (без pngquant) вмѣсто oxipng.
① Я обратил внимание на pngquant, руководясь анонимною наводкою, которая чуть болѣе ¼ года тому назад (14 ноября 2021 года) была оставлена в одном анонимном обсуждении на 4channel, которое давно уж стёрто оттудова, но скриншот до сих пор сохраняется на Nowere. Нѣсколько позже (2 января) я упомянул на 410чанѣ примѣръ такого малоцвѣтнаго изображения (3169 цвѣтовъ), на 4channel в том обсуждении разсмотрѣннаго, которое при обработке в pngquant не только достигает значительной информационной плотности (менѣе ⅔ бита на пиксел), но и по метрике PSNR (по соотношению сигнала и шума) превосходит сжатие WebP почти на четыре децибела при ≈равном объёме файла.
② Движок, служащий в pngquant собственно для «квантования» изображений (для продуманного приведения к ограниченной палитре цвѣтовъ), нынешним разработчиком был переписан на языке Rust и в качестве отдѣльной библиотеки (libimagequant) может употребляться для этой же цѣли в задачах, ужé не связанных с кодированием PNG. Хорошим примѣромъ этого является утилита gifski, сочинённая этим же разработчиком для создания таких анимированных GIF, каждый кадр в которых использует свою собственную палитру (продуманно подобранную в libimagequant), а внесённая ошибка перераспредѣляется во времени, по возможности компенсируясь слѣдующими кадрами. Постоянные читатели моего канала могут помнить, что я ужé упоминал про gifski в позапрошлом (2020) году, когда въ послѣднемъ абзаце вон того сообщения досадовал о том, что разработчики Телеграма напрасно воздерживаются от поддержки анимированных PNG и анимированных WebP (даже не перегоняют такие анимации в формат MP4, хотя перегоняют GIF), как будто надѣются на то, что пользователи самостоятельно возьмут FFmpeg да начнут, скажем, перегонять APNG в MP4 — а меж тѣмъ пользователи вполне способны вмѣсто того перегонять в GIF и для того задѣйствовать gifski, руководясь привлекательностью результатов и притом ничуть не сдерживаясь двухгигабайтовым-то ограничением объёма файлов GIF в Телеграме; правда, нѣкоторые клиентские программы откажутся анимировать GIF (и предложат вмѣсто того скачать файл) гораздо раньше, чѣмъ GIF успѣетъ сдѣлаться двухгигабайтовым. Упомянутая привлекательность столь значительна, что кадры GIF, создаваемые в gifski, кажутся болѣе многоцвѣтными, чѣмъ на сáмомъ дѣлѣ — так, напримѣръ, упоминаемая в Википедии технология создания реально многоцвѣтныхъ изображений GIF (в которые каждый кадр анимации, сам по себе 256-цвѣтный, притаскивает содержимое небольшой доли изображения — одной ячейки в матрице 4×4 или в матрице 3×3) показалась автору вон той страницы вики BasicSR используемою и в gifski. (На дѣлѣ же gifski не тратит болѣе одного 256-цвѣтнаго кадра GIF на один кадр исходной анимации, ограничиваясь временны́м перераспредѣленіемъ погрѣшностей палитры. Болѣе того: ещё в 2012 году вон тѣмъ изслѣдованіемъ и затѣмъ вон той демонстрациею показано, что браузеры не отображают болѣе 50 кадров GIF в секунду — слѣдовательно, не то что в 4×4 раза или в 3×3 раза, но даже и двукратно увеличить частоту кадров для лучшей цвѣтопередачи не получится, если исходная анимация ужé использует болѣе 25 кадров в секунду. Попытки сдѣлать больше 50 кадров в секунду во браузерах наказываются замедлением, что было видно у Степанищева и на Хабре, но не совершенно понято ими.)
③ В июле позапрошлого (2020) года я рѣшилъ, что впредь буду использовать oxipng для сжатия файлов PNG. Но для итогов работы pngquant я перемѣнилъ это рѣшеніе и намѣренъ использовать утилиту Efficient Compression Tool, которая сжимает сильнѣе и быстрѣе, чѣмъ oxipng. Прежде я избѣгалъ ECT, видя неспособность ECT прибѣгнуть к алгоритму Adam7, который ещё до окончания скачивания файла позволяет зрителю возымѣть нѣкоторое впечатление о содержимом файла — но послѣ pngquant файл PNG чаще всего не превосходит мегабайта и вскоре скачивается цѣликомъ. И для сжатия тѣхъ из сшивок кадров аниме, которые не превосходят мегабайта, я с января также начал примѣнять ECT (без pngquant) вмѣсто oxipng.