Иллюзия движения. Ч.2

Пикабу не захотел опубликовать все в одном посте, поэтому пришлось разделить его на две части.

Первая часть тут

Pulldown

Преобразовать киноматериал для NTSC, американского телевизионного стандарта, не получится простым ускорением, потому что преобразование 24 FPS в 29,97 FPS соответствует ускорению на 24,875%. Если только вы по-настоящему не любите бурундучков, это будет не лучшим вариантом.

Вместо этого используется процесс под названием 3:2 pulldown (среди прочих), который стал самым популярным методом преобразования. В рамках этого процесса берут 4 оригинальных кадра и преобразуют их в 10 чересстрочных полукадров или 5 полных кадров. Вот иллюстрация, которая описывает процесс.

3:2 Pulldown в действии. Из Википедии.

Иллюзия движения. Ч.2 FPS, Частота, Анимация, Кинематограф, Инерция зрения, Размытие, Из сети, Habr, Длиннопост, Мультфильмы

На чересстрочном дисплее (то есть ЭЛТ) видеополя посредине отображаются в тандеме, каждый в чересстрочном варианте, поэтому они состоят из каждой второй строки пикселей. Оригинальный кадр A разбивается на два полукадра, оба из которых отображаются на экране. Следующий кадр B тоже разбивается, но нечётное видеополе отображается дважды, так что этот кадр распределяется по трём полукадрам. И, в сумме, мы получаем 10 распределённых по видеополям полукадров из 4 оригинальных полных кадров.

Это работает достаточно хорошо при показе на чересстрочном экране (таком как ЭЛТ-телевизор) примерно с 60 видеополями в секунду (практически полукадрами), поскольку полукадры никогда не показываются вместе. Но такой сигнал выглядит ужасно на дисплеях, которые не поддерживают полукадры и должны составить вместе 30 полных кадров, как в самом правом столбце на иллюстрации вверху. Причина провала в том, что каждый третий и четвёртый кадры слепляются из двух разных кадров оригинала, что приводит к тому, что я называю «Франкенфрейм». Это особенно ужасно выглядит на быстром движении, когда имеются значительные отличия между соседними кадрами.

Так что pulldown выглядит изящно, но это тоже не универсальное решение. Тогда что? Неужели нет идеального варианта? Как выясняется, он таки есть, и решение обманчиво простое!

При показе: G-Sync, Freesync и ограничение максимальной частоты кадров

Вместо того, чтобы бороться с фиксированной частотой обновления, конечно, гораздо лучше использовать переменную частоту обновления, которая всегда синхронизирована с фреймрейтом. Это именно то, для чего предназначены технологии Nvidia G-Sync и AMD Freesync. G-Sync — модуль, встроенный в мониторы, он позволяет им синхронизироваться с выдачей GPU вместо того чтобы заставлять GPU синхронизироваться с монитором, а Freesync достигает той же цели без модуля. Это действительно революционные технологии, которые устраняют необходимость в «телекинопроекторе», а весь контент с переменным фреймрейтом, вроде игр и веб-анимаций, выглядит намного более плавным.

К сожалению, и G-Sync, и Freesync — относительно новые технологии и ещё недостаточно широко распространились, так что если вы как веб-разработчик делаете анимации для веб-сайтов или приложений и не можете себе позволить использовать полноценные 60 FPS, то лучше всего будет ограничить максимальный фреймрейт, чтобы он без остатка делился на частоту обновления — практически во всех случаях наилучшим ограничением будет 30 FPS.

Заключение и последующие действия

Так как достичь пристойного баланса с учётом всех желаемых эффектов — минимального размытия в движении, минимального мерцания, постоянной частоты кадров, хорошего отображения движения и хорошей совместимости со всеми дисплеями — без особого обременения GPU и дисплея? Да, сверхбольшие фреймрейты могут снизить размытие в движении, но большой ценой. Ответ ясен и после чтения этой статьи вы должны его знать: 60 FPS.

Теперь, когда вы умнее, приложите все усилия, чтобы запустить весь анимированный контент со скоростью 60 кадров в секунду.

  • Если вы веб-разработчик

    Сходите на jankfree.org, где разработчики Chrome собирают лучшие ресурсы о том, как сделать все ваши приложения и анимации безупречно плавными. Если у вас есть время только для одной статьи, то выберите отличную статью Пола Льюиса The Runtime Performance Checklist.

  • Если вы Android-разработчик

    Сверьтесь с нашими «Лучшими практиками для производительности» в официальном разделе Android Training, где мы собрали для вас список самых важных факторов, узких мест и хитростей оптимизации.

  • Если вы работаете в киноиндустрии

    Записывайте весь контент на 60 FPS или, ещё лучше, на 120 FPS, чтобы можно было свести его к 60 FPS, 30 FPS и 24 FPS в случае необходимости (к сожалению, для добавления поддержки 50 FPS и 25 FPS (PAL) придётся поднять частоту кадров до 600 FPS). Воспроизводите весь контент на 60 FPS и не извиняйтесь за «эффект мыльной оперы». Эта революция потребует времени, но она случится.

  • Для всех остальных

    Требуйте 60 FPS для любых движущихся картинок на экране, а если кто спросит почему, отправьте его к этой статье.

На этом всё! Спасибо за внимание!)

Оригинал статьи тут