Относительно опорного кадра, последующие (только изменения) занимают меньший объём.
Не Вы ли раньше писали:
Вот именно в этом и сжатие. А если подробнее, нужно читать про LZW. Это, кстати, не так страшно, как кажется. Гораздо сложнее оптимизировать палитру под конкретное изображение.
Т.е. опорный кадр вообще один?
Можно и один взять. Но в видеопотоках, как правило, через N дополнительных один опорный идёт. Потому что начать смотреть могут не с начала.
Точнее, что наступит раньше: N-й кадр после опорного или “смена кадра”.
Если плюнуть на всю теорию - то как делать?
Берём к примеру 8 фоток-кадров, переводим в массивы, неким способом определяем совпадения данных во всех и получаем базовый недокадр. Аналогично формируем по несовпадениям 8 добавок. И выдумываем как это всё совместить ?
Если плюнуть на теорию, то лучше вообще ничего не делать, т.к. ничего хорошего все равно не получится.
И еще: базовый кадр не нужно “получать”, он берется из видеопотока.
Это как? Взял смартфон, снял свечу очередью из 10 кадров. И как взять, в потоке?
Кому попкорн, господа? Пива захватите, плз!
1 лайк
Ну, и?
я - чисто зритель. Иногда учить - только портить. 
Нет, так нет. Сам Вы непорченый 
Почитайте уже книжки
Уж чего чего, а методы упаковки видеоряда придуманы ещё в 90х, литературы вагон.
Шоп ты не обижался, я тебе последовательность распишу., но без комментариев вообще. Комментарии не дам даже за деньги, так как нет времени и желания.
Итак.
Имеет последовательность из нескольких кадров одного МЕДЛЕННО изменяющегося процесса. Например твои 10 кадров свечи.
- пропускаем через хороший фильтр цифровой стабилизации, На предмет убрать низкодетерминантные афинные искажения от дрожания камеры. Таких фильтров полно в сети.
- Вычисляем базовый кадр. Например среднее арифметическое, среднее “хренотическое”. Просто первый. Тут есть много способов выбора и много критериев.
- Остальные переводим в разностные матрицы.
- Разницу пересчитываем в HSV. яркостный канал оставляем - остальное прореживаем, да еще и с нелинейным Сигма преобразованием.
- По каждой матрице считаем jpeg-преобразование с соответствующим квантованием (тоже предмет выбора).
- каждый полученный вектор сжимаем без потерь с LZW.
ПРОФИТ!
Гы…!
Это только вариация mJpeg… С мпегом все еще интереснее. Но для 10 кадров, возможно не надо…
Зачем Вам это?
Если хотите попрактиковаться, разберитесь, как кодируется JPEG. И только потом можно будет переходить к тому, как кодируется видео.
И, кстати, советую все-таки поразбираться в теории: даже то, как Вы ставите вопрос, говорит, что Вы этим ранее даже не интересовались. Поток у Вас был, когда Вы “снимали очередью”. Когда появилось 10 кадров, поток уже закончился.
Зачем, зачем…
Просто думал, что есть иной реализованный доходчивый способ анимации кроме быстрого перебора почти одинаковых картинок. Ну мысль я понял, надо идти и учиться.
Я не первый задумчивый такой
Lilik, я ещё на старом форуме писал: нужна постановка конкретной задачи.
Именно от этого искать решение.
А все остальное это натягивание абстрактной совы на глобус.
Да как её конкретизируешь? Вроде влезает в есп 25-28 фоток цветных 160Х128. Много!, но в гифке 48 картинок, места мало. Доступно 1,3 Мб из 4. Сколько в настройках не пробовал больше не получается.
Оказывается (всё уже сделано) сжатые форматы картинок хранят в плате и есть библиотеки (какая то файловая система ити её)
Но не факт, что после долгих мучений гифка заработает на нужной скорости.
Неужели нельзя написать конвертер массивов сжатого хранения с функцией распаковки в динамичный массив 16 бит на пиксель и выводить из него. Хотя опять же выяснится, что скорость отрисовки падёть до неприличия.
Ну вот опять
Внимательно посмотрите на свою gif ку.
А лучше в замедленном просмотре.
Я вижу картинку дороги, авто, столба, одноцветную города.
Т е если выводить их в определённом месте, правильно инвертировать цвета, в определённой последовательности - получите тот же результат.
Но сомневаюсь что ардуинка всю эту математику вытянет.