| >> |
No.19334
Автор рецепта http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html сообщает также, что https://en.wikipedia.org/wiki/Ordered_dithering по алгоритму Байера не только устраняет проявления https://en.wikipedia.org/wiki/Colour_banding (появление монотонных цветовых полос на том месте, где в первоисточнике идут переливы цвета между оттенками, отсутствующими в палитре), но и уменьшает объём GIF (хотя в кадре появляется мешанина цветов, она не случайна, а с математическою строгостью выбирает в каждом месте наиболее подходящий из предопределённых узоров, имеющих согласно https://ffmpeg.org/ffmpeg-all.html#paletteuse равные размеры 8×8 пикселов и ввиду предсказуемости хорошо сжимаемых LZW-алгоритмом в GIF), тогда как принятый по умолчанию в GIF-генераторе у FFmpeg алгоритм «Sierra» устраняет узорчатость, но хуже передаёт разницу между оттенками цвета и притом (ввиду случайности и вызванного ею роста информационной избыточности) пагубно влияет на сжатие («it completely kills the compression of GIF»). Наглядно убедившись на опыте в том, что Sierra способна бесследно съесть небольшую разницу между цветовыми оттенками, когда те не настолько популярны в изображении, чтобы заслужить у палитрогенератора каждый по цвету в палитре (а именно таким цветом, например, в кадре у реплики >>19332 выкрашена левая дужка очков, которые носит Цубаса Курата: эту дужку мы видим только в небольшом углу его очков, на которые притом лёг блик от экрана, сквозь который дужка имеет вид, еле отличающийся по цвету), а также убедившись и в том, что байеровские узоры сжимаются лучше, я задал соответствующие параметры GIF-генератору: не только включил алгоритм Байера, но даже и снизил до нуля порог появления узорчатости (чтобы не засорять кадр искусственными границами между узорчатыми и неузорчатыми полосами, притом передвигающимися в ходе анимации, а покрыть вместо того весь кадр узорами 8×8 и дать зрению привыкнуть к наличию этих квадратиков).
Справедливости ради надо отметить, что рецепт http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html оканчивается серией наглядных примеров различного подхода к переводу иллюстрации в ограниченную цветовую палитру, но всѣ они отвратительно далеки от наглядности ввиду того, что первоначальное изображение само по себе содержит неестественные монотонные цветовые полосы (будучи, вероятно, кадром из недесятибитного аниме, павшим жертвою агрессивного видеосжатия).
Так как ограничение цветности является наиболее существенным и заметным ограничением GIF, то я не стал предусматривать в тексте команд никакого способа для экономии объёма файла за счёт дальнейшего уменьшения количества цветов в палитре: уродливые плоды такой экономии слишком заметны, так что уменьшение высоты кадра почти всегда следует предпочесть уменьшению палитры. Предложенный в рецепте http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html способ уменьшения объёма GIF путём искусственного снижения частоты кадров также показался мне дающим некрасивые результаты по отношению к аниме, так как частота кадров многих сцен в аниме и без того невелика, насколько это возможно, а тут они становятся и вовсе какими-то дёргаными.
Примерно как и в случае с репликою >>18676, получающуюся анимацию можно без труда снабдить субтитрами из файла-первоисточника, изменив всего одну команду простою допискою. В данном случае к «flags=lanczos» достаточно приписать «,subtitles=%~nx1» (непременно через запятую); для невиндовых систем аналогом «%~nx1» является, вероятно, опять же «$1». Всѣ оговорки из реплики >>18676 о том, что в таком случае исходный видеофайл не должен содержать спецсимволов в имени, справедливы и в этом случае (то есть много проще дать файлу простенькое имя наподобие «src.mkv», чем разбираться с тем, как у FFmpeg экранируется квадратная скобка или пробел в имени у источника субтитров).
Напоследок уместно подчеркнуть, и подчёркиваю, что указанный способ создания GIF универсален: он годится, разумеется, не для одних только тех досок Ычана, на которых WebM или MP4 не сделались ещё внедрёнными, но также и для других имиджборд в Интернете, лишённых поддержки WebM и MP4, но принимающих GIF и притом нередко ограничивающих размер GIF не таким строгим ограничением, каковы ычанские полтора мегабайта — следовательно, щедро допускающих более длительную анимацию или более крупный размер кадра в GIF.
|
