Как сделать трекинг в mocha

Добавил пользователь Алексей Ф.
Обновлено: 10.09.2024

Трекинг - очень полезная и незаменимая вещь для настоящего монтажера!
В этом видео я расскажу вам про планарный трекинг в Mocha Pro.
Также, советую заценить курс по анимации в AE от ArtCraft: bit.ly/3a4qmsL

Главное отличие Mocha заключается в том, что она делает планарный трекинг. Что это такое? Вместо того, чтобы отслеживать пиксели на видео, как делает After Effects, плагин Мока Про следит за определенной областью, за текстурой. Таким образом трекинг получается делать в разы легче и качественнее. Данный плагин использовался во многих голливудских фильмах для композитинга и имплементации 3D-объектов. В этом же уроке у нас будет два простых примера - нам нужно будет заменить экран на ноутбуке и привязать логотип к коптеру. Файлы для урока а также остальные ссылки вы сможете найти ниже.

Музыка из ролика: ?Epidemic Sound, по ссылке вы получаете 1 месяц бесплатно: bit.ly/2O5iTBI

Ссылки на уроки по теме:
Трекинг в After Effects: brbil.info/cycle/video/nGmRpKKWg6ZqtJ8
3D-трекинг в After Effects: brbil.info/cycle/video/uYGNmK-DqaB4mXU

Publicado em Anos atr?s

Coment?rios: 410

Если хочешь чтобы уроки по Mocha вышли скорее - ставь лайк видосу! Также, напиши, какие уроки ты больше хочешь: вставка видео в экран девайса с тыканьем пальцев, клинап (удаление лишнего\ненужного из видео), стабилизация видео с помощью Мокка, или же ротоскопирование (вырезание человека или что-то другого из видео, или удаление фона без хромача).

Привет Роман! Сделай, пожалуйста, обзор про использование mesh в mocha pro. Посмотрел несколько уроков и все равно не получается. Может что упускаю?

@Roman Bolharov Рома, очень поможешь если скажешь как отследить точные контуры лица. Не точки трассировки а прямо очертить края до пикселя. У меня куча персонажей которым надо перекрасить лица. Беру из готовых фильмов, хромки нет. Ещё бы, если можно, плагин, отслеживающий контуры глаз автоматом - их тоже перекрашиваю.

Больше уроков по ротоскопингу. .

Помогите пожалуйста, я когда сделал трекинг прямоугольный по экрану ,сам зеленный готовый экранчик меньше по форме чем я рисовал.Почему так?

Во что в Battle net играешь?)

Очень важное личное наблюдение. Когда мы после трекинга в моке переходим в ае и делаем create track data, то выскакивает окошко с названиями слоёв. Нужно не просто нажать на нужный слой, а поставить напротив него шестерёночку. Я пока до этого дошёл, кучу времени потратил, потому что в уроке это неочевидно. В остальном -спасибо за урок, очень познавательно.

Спасибо, очень помогло, а то я уже потратил час на это

@Максим Цой Не за что))) Ташкенту привет из Москвы))

Незнаю Кто ты. Но лично от меня тебе +++++ в карму и ещё++++++. Солнечный Ташкент Респектует ТЕБЕ!

Спасибо огромное, а то я чуть голову не сломал уже

Спасибооооо. Я так расстроилась! Целый день работы, готова была забросить всё нафиг, думаю, напишу комент и попался твой. ООО боги, поставила шестеренку и у меня наконец-то этот слой отобразился! Я благодарюююю тебя! Роман, вам вообще респект и уважуха, без вас мы бы точно отупели. У вас и стиль, и голос, и манера, и подача всё отлично - зэ бэст!

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

Спасибо за видео! Хочу еще уроки в mocha по вставке видео в экран девайса с тыканьем пальцев, клинапе и ротоскопированию))

Важное место при разработке на Node.js занимает тестирование. И в данном случае гораздо легче воспользоваться имеющимися фреймворками, которые упрощают процесс тестирования. Одним из таких фреймворков является Mocha. Подробнее о фреймворке можно узнать на официальной странице Mochajs. В данном же случае мы рассмотрим некоторые базовые стороны работы с ним.

Определим в папке проекта новый файл package.json со следующим содержимым:

Далее добавим в проект пакет mocha с помощью следующей команды:

Так как фреймворк Mocha необходим только для тестирования приложения, то он добавляется в файле package.json в секцию devDependencies с помощью команды --save-dev .

Для тестирования определим простейший модуль. Для этого добавим в проект файл operations.js со следующим содержимым:

Здесь определена функция умножения двух чисел.

Для тестирования этого модуля добавим в проект новый файл operations.test.js :

Рассмотрим этот тест. Для тестирования результата применяется функция it() , которая предоставляется фреймворком Mocha.

Эта функция принимает два параметра: текстовое описание тестируемого действия, по которому его можно идентифицировать, и саму тестирующую функцию.

К примеру, нам надо проверить работу выше определенной функции multiply() , которая умножает два числа. Для этого в эту функцию надо передать два числа и сравнить ее результат с ожидаемым. Если результат не совпадает с ожидаемым значением, то генерируется ошибка.

Для упрощения запуска тестов изменим файл package.json следующим образом:

Здесь добавляется секция "scripts" , в которой определяется команда "test" . Эта команда выполняет команду "mocha *.test.js" , которая запускает тестирование с помощью mocha, передавая фреймворку все файлы, которые оканчиваются на ".test.js"

Если у нас один файл теста, то мы могли бы сразу указать полное имя файла, типа mocha operations.test.js

Далее в командной строке перейдем к папке проекта и выполним команду:

В данном случае консоль указывает, что тест пройден.

Но, если мы изменим код теста:

То тест не будет проходить, так как результат - 15 не равен ожидаемому результату - числу 16 . И консоль уведомит об этом при повторном запуске теста:

Подобным образом мы можем определять и другие тесты. Например, изменим файл модуля operations.js :

Теперь в файле была добавлена функция для сложения чисел. Протестируем ее в operations.test.js :

Тестирование асинхронных функций¶

Немного отличается тестирование асинхронных функций. Например, определим в модуле operations.js асинхронную функцию:

Протестируем эту функцию в operations.test.js :

Особенностью тестирования асинхронных функций является то, что чтобы они завершились до завершения теста, в тестирующую функцию передается функция done() . Причем при окончании тестирования нам надо вызвать эту функцию. Тем самым через подобную функцию Mocha сможет контролировать выполнение теста.

Если мы не передадим функцию done в тест, тогда тест завершится раньше, чем завершится асинхронная функция.

В этом уроке рассказываю как прикрепить объект в ваш футаж с помощью трекинга в Mocha в программе Adobe After Effects 2020.

Mocha AE - это планарный трекинг, т.е. трекинг по плоскости. Обычный же трекинг в After Effects работает по пикселям.

?Таймкоды:
00:00 - Превью
00:55 - Начало работы
01:31 - Лого на объекте. Первый футаж
10:53 - Замена экрана монитора. Второй футаж
15:28 - Финал

НЕ СОМНЕВАЙТЕСЬ И РАЗВИВАЙТЕСЬ! У ВАС ВСЁ ПОЛУЧИТСЯ! :)
Желаю приятного обучения! ?

Перевод руководства Samuele Zaza. Текст оригинальной статьи можно найти здесь.

Я до сих пор помню восторг от возможности наконец-то писать бекэнд большого проекта на node и я уверен, что многие разделяют мои чувства.

А что дальше? Мы должны быть уверены, что наше приложение ведет себя так, как мы того ожидаем. Один из самых распространенных способов достичь этого — тесты. Тестирование — это безумно полезная вещь, когда мы добавляем новую фичу в приложение: наличие уже установленного и настроенного тестового окружения, которое может быть запущено одной командой, помогает понять, в каком месте новая фига породит новые баги.
Ранее мы обсуждали разработку RESTful Node API и аутентификацию Node API. В этом руководстве мы напишем простой RESTful API и используем Mocha и Chai для его тестирования. Мы будем тестировать CRUD для приложения "книгохранилище".

Как всегда, вы можете все делать по шагам, читая руководство, или скачать исходный код на github.

Mocha — это javascript фреймворк для Node.js, который позволяет проводить асинхронное тестирование. Скажем так: он создает окружение, в котором мы можем использовать свои любимые assert библиотеки.

Mocha поставляется с огромным количеством возможностей. На сайте их огромный список. Больше всего мне нравится следующее:

простая поддержка асинхронности, включая Promise
поддержка таймаутов асинхронного выполнения
before , after , before each , after each хуки (очень полезно для очистки окружения перед тестами)
использование любой assertion библиотеки, которую вы заходите (в нашем случае Chai)

Для этого руководства я выбрал Chai:

PREREQUISITES

Node.js: базовое понимание node.js и рекомендуется базовое понимание RESTful API (я не буду сильно углубляться в детали реализации).
POSTMAN для выполнения запросов к API.
Синтакс ES6: я решил использовать последнюю версию Node (6..), в которой хорошо реализована интеграция ES6 features для лучшей читаемости кода. Если вы еще не очень дружите с ES6, вы можете почитать отличные статьи (Pt.1, Pt.2 and Pt.3). Но не беспокойтесь, я буду давать пояснения когда встретится какой-нибудь особенные синтаксис.

Настало время настроить наше книгохранилище.

Структура папок

Структура проекта будет иметь следующий вид:

Обратите внимание, что папка /config содержит 3 JSON файла: как видно из названия, они содержат настройки для различного окружения.

В этом руководстве мы будем переключаться между двумя базами данных — одна для разработки, другая для тестирования. Такие образом, файлы будут содержать mongodb URI в JSON формате:

dev.json и default.json :

Обратите внимание на файл /test/book.js , в котором будут все наши тесты.

package.json

Создайте файл package.json и вставьте следующее:

Для mocha я добавил флаг --timeout 10000 , потому что я забираю данные из базы, расположенной на mongolab и отпущенные двух секунд по умолчанию может не хватать.

Ура! Мы закончили скучную часть руководства и настало время написать сервер и протестировать его.

Давайте создадим файл server.js и вставим следующий код:

Нам нужен модуль config для доступа к файлу конфигурации в соответствии с переменной окружения NODE_ENV. Из него мы получаем mongo db URI для соединения с базой данных. Это позволит нам содержать основную базу чистой, а тесты проводить на отдельной базы, скрытой от пользователей.
Переменная окружения NODE_ENV проверяется на значение "test", чтобы отключить логи morgan в командной строке, иначе они появятся в выводе при запуске тестов.
Последняя строка экспортирует сервер для тестов.
Обратите внимание на объявление переменных через let . Оно делает переменную видимой только в рамках замыкающего блока или глобально, если она вне блока.

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

Модели и роутинг

Настало время для описать модель книги. Создадим файл book.js в папке /app/model/ со следующим содержимым:

У нашей книги есть название, автор, количество страниц, год публикации и дата создания в базе. Я установил опции versionKey значение false , так как она не нужна в данном руководстве.

Необычный callback в .pre() — это функция стрелка, функция с более коротким синтаксисом. Согласно определению MDN: "привязывается к текущему значению this (не имеет собственного this , arguments , super , or new.target ). Функции-стрелки всегда анонимны".

Отлично, теперь мы знаем все что нужно о модели и переходим к роутам.

В папке /app/routes/ создадим файл book.js следующего содержания:

Все маршруты стандартные GET, POST, DELETE, PUT для выполнение CRUD.
В функции updatedBook() мы используем Object.assign , новую функцию ES6, которая перезаписывает общие свойства book и req.body и оставляет.остальные нетронутыми
В конце мы экспортируем объект с использованием синтаксиса "короткое свойство" (на русском можно почитать тут, прим. переводчика) чтобы не делать повторений.

Мы закончили эту часть и получили готовое приложение!

В командной строке выпоним

GET /BOOK

В POSTMAN выполним GET запрос и, если предположить что в базе есть книги, получим ответ:
:

Сервер без ошибок вернул книги из базы.

POST /BOOK

Давайте добавим новую книгу:

PUT /BOOK/:ID

Давайте поменяем количество страниц в книге и посмотрим на результат:

Отлично! PUT тоже работает, так что можно выполнить еще один GET запрос для проверки

GET /BOOK/:ID

Теперь получим одну книгу по ID в GET запросе и потом удалим ее:

Получили правильный ответ и теперь удалим эту книгу:

DELETE /BOOK/:ID

Посмотрим на результат удаления:

Даже последний запрос работает как и задумано и нам даже не нужно делать еще один GET запрос для проверки, так как мы отправили клиенту ответ от mongo (свойство result), которое показывает, что книга действительно удалилась.

При выполнении тестом через POSTMAN приложение ведет себя как и ожидается, верно? Значит, его можно можно использовать на клиенте?

Давайте я вам отвечу: НЕТ!!

Наши действия я называю наивным тестированием, потому что мы выполнили только несколько операций без учета спорных случаев: POST запрос без ожидаемых данных, DELETE с неверным id или вовсе без id.

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

Давайте сделаем что-то лучшее, чтобы тестировать наше приложение.

Во-первых, давайте создадим файл books.js в папке /test :

Как много новых штук! Давай разберемся:

Все начинается с блока describe , который используется для улучшения структуризации наших утверждений. Это отразится на выводе, как мы увидим позже.

beforeEach — это блок, который выполнится для каждого блока описанного в этом describe блоке. Для чего мы это делаем? Мы удаляем все книги из базы, чтобы база была пуста в начале каждого тесте.

Тестируем /GET

Итак, у нас есть первый тест. Chai выполняет GET запрос и проверяет, что переменная res удовлетворяет первому параметру (утверждение) блока it "it should GET all the books". А именно, для данного пустого книгохранилища ответ должен быть следующим:

Статус 200.
Результат должен быть массивом.
Так как база пуста, мы ожидаем что размер массива будет равен 0.

Обратите внимание, что синтаксис should интуитивен и очень похож на разговорный язык.

Терерь в командной строке выпоним:

и получим:

Тест прошел и вывод отражает структуру, которую мы описали с помощью блоков describe .

Тестируем /POST

Теперь проверим насколько хорош наш API. Предположим мы пытаемся добавить книгу без поля `pages: сервер не должен вернуть соответствующую ошибку.

Добавим этот код в конец блока describe('Books') :

Тут мы добавили тест на неполный /POST запрос. Посмотрим на проверки:

Статус должен быть 200.
Тело ответа должно быть объектом.
Одним из свойств тела ответа должно быть errors .
У поля errors должно быть пропущенное в запросе свойство pages .
pages должно иметь свойство kind равное required чтобы показать причину почему мы получили негативный ответ от сервера.

Обратите внимание, что мы отправили данные о книге с помощью метода .send().

Давайте выполним команду еще раз и посмотрим на вывод:

Перед тем, как писать следующий тест, уточним пару вещей:

Во-первых, почему ответ от сервера имеет такую структуру? Если вы читали callback для маршрута /POST, то вы увидели что в случае ошибки сервер отправляет в ответ ошибку от mongoose . Попробуйте сделать это через POSTMAN и посмотрите на ответ.
В случае ошибки мы все равно отвечаем с кодом 200. Это сделано для простоты, так как мы только учимся тестировать наш API.

Однако я бы предложил отдавать в ответ статус 206 Partial Content instead

Давайте отправим правильный запрос. Вставьте следующий код в конец блока describe(''/POST book'') :

На этот раз мы ожидаем объект, говорящий нам, что книга добавилась успешно и собственно книгу. Вы уже должны быть хорошо знакомы с проверками, так что нет нужды вдаваться в детали.

Снова запустим команду и получим:

Тестируем /GET/:ID

Теперь создадим книгу, сохраним ее в базу и используем id для выполнения GET запроса. Добавим следующий блок:

Через asserts мы убедились, что сервер возвратил все поля и нужную книгу (id в ответе от севера совпадает с запрошенным):

Вы заметили, что в тестированием отдельных маршрутов внутри независимых блоков мы получили очень чистый вывод? К томе же это эффективно: мы написали несколько тестов, которые можно повторить с помощью одной команды

Тестируем /PUT/:ID

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

Мы хотим убедиться, что поле message равно Book updated! и поле year действительно изменилось.

Мы почти закончили.

Шаблон очень похож на предыдущий тест: сначала создаем книгу, потом ее удаляем с помощью запроса и проверяем ответ:

Снова сервер вернёт нам ответ от mongoose , который мы и проверяем. В консоли будет следующее:

Восхитительно! Наши тесты проходят и у нас есть отличная база для тестирования нашего API с помощью более изысканных проверок.

В этом уроке мы столкнулись с проблемой тестирования наших маршрутов, чтобы предоставить нашим пользователям стабильный API.

Мы прошли через все этапы создания RESTful API, делая наивные тесты с POSTMAN, а затем предложили лучший способ тестирования, являлось нашей основной целью.

Написание тестов является хорошей привычкой для обеспечения стабильности работы сервера. К сожалению часто это недооценивается.

Всегда найдется кто-то, кто скажет что две базы — это не лучшее решение, но другого не дано. И что же делать? Альтернатива есть: Mockgoose.

По сути Mockgoose создает обертку для Mongoose, которая перехватывает обращения к базе и вместо этого использует in memory хранилище. К тому же он легко интегрируется с mocha

Примечание: Mockgoose требует чтобы на машине, где запускаются тесты была установлена mongodb

Читайте также: