У меня есть набор фотографий, сделанных с определенным интервалом в течение суток (например каждые 5 минут, всего 288 фотографий).
Мне нужно сделать из них что-то вроде фотографии со сверхдлинной выдержкой, на которой неподвижные объекты будут отображены почти нормально, а движущиеся объекты будут малозаметны или незаметны. Для реализации я предполагаю взять изначально черный фон, а затем последовательно наложить на него все 288 фотографий серии, с прозрачностью примерно 0,3472% каждая. Но такая реализация будет генерировать очень большую вычислительную нагрузку на сервер.
Я бы хотел не накладывать все 288 фотографий каждый раз, а при каждой итерации накладывать только текущую фотографию. Чем-то нужное мне поведение похоже на вычисление скользящего среднего — будь это числа, я бы между вызовами просто суммировал бы значения рядов и считал количество рядов, а для получения среднего значения просто бы делил текущую сумму на текущее количество.
Но к изображениям такой подход не применить, у них конечная разрядность для каждого пиксела.
Как черновой вариант я попробую на каждой итерации «затемнять» итоговое изображение на 0,3472%, а затем накладывать на него текущее изображение с прозрачностью 0,3472%. Теоретически следы суточной давностью полностью сойдут на нет и должно получится что-то более-менее похожее на сверхдолгую выдержку.
Но может быть есть другие способы решения такой задачи?

Может я что-то не понял.
Если перейти на 48-битную глубину цвета, то разрядности хватит только на 256 сложений, на 288 уже не хватит.
А про использование float я не понял. Это в каком формате файлов такое возможно? Или речь о том, чтобы не использовать графические файлы, а сохранять значения пикселов в своем файле данных?

То есть предлагается просто суммировать значения, то есть new = old+current, а не new = old + 256*i*current?
По-моему это неверно и будет искажать итоговое изображение, нарушать баланс цветов.
Но даже если так сделать, то переполнение будет событием высокой вероятности.
Во-первых это будет OSD (наложенные на кадр дата/время, обычно белого цвета).
Во-вторых, летом светлое время суток составляет почти 20 часов и в кадре будет много светлых областей, которые переполнят разрядность пиксела.
Ну и в третьих, это в принципе ограничивает применимость этого способа 5-минутным интервалом. Если я захочу делать фотографии каждую минуту (1440 фотографий), то 48-битная глубина цвета уже не поможет.

Пока что я пришел к тому, чтобы из текущего суммированного изображения вначале вычитать хвостовую картинку, а затем накладывать текущую. То есть в виде формулы это получится выражение: mix = mix - old/288 + new/288.

32 бита на каждый компонент? То есть 128 бит на пиксел?
Я бы с радостью, если подскажите формат файла, который это предусматривает, и утилиту, которая с таким файлом может работать.
Сейчас я использую ImageMagick, 48-битный PNG он теоретически умеет.

exp98Видим также, что чем свежее картинка, тем больший у неё вес в общей сумме.
Э... Нет.
Если алгоритм объединения (преобразования) записать в виде формулы (где img0 это текущий скриншот, img1 предыдущий скриншот, img2 это скриншот 10 минут назад и т.д.), то нужный мне вариант выглядит так:
А процитированное соответствует формуле:
Вообще такое преобразование выглядит интересным и я позже хочу посмотреть, как оно выглядит вживую с реальными фотографиями (это должно быть что-то вроде фотографии, на которой проявляются следы недавних движений), но первоначально мне нужно другое, мне нужно получить усредненное за сутки изображение.
Указанная выше формула mix = (img0+img1+...+img287)/288 гарантированно его получает, но требует значительного объема вычислений на каждой итерации (на каждой итерации нужно выполнять 288 операций наложения).
Моя оптимизация заключается в том, чтобы использовать такую формулу:
Математически это правильный алгоритм, причем экономный в плане вычислительной нагрузки — на каждой итерации выполняется только две операции наложения. Но поскольку в случае с изображениями используются целочисленные 8-разрядные вычисления, этот способ использовать напрямую нельзя, погрешности округлений сделают результат бесполезным.
Можно промежуточное изображение (mix) привести к 48-битной глубине цвета (по 16 бит на каждую компоненту, например в формате PNG48), тогда этот алгоритм можно будет использовать. Правда на каждой операции будет теряться 1-2 значащих бита, но думаю, что в итоговом изображении это будет незаметно. И кроме того точность этого способа будет сильно падать в увеличением количества изображений в серии (например для 1440 поминутных фотографий на каждой итерации будет теряться до 4-5 значащих битов).
Еще более правильным было бы использовать такую формулу:
Это был бы идеальный вариант, в котором значащие разряды не теряются, но тогда придется забыть про использование готовых инструментов/утилит. Чтобы использовать такой подход с изображениями. нужна минимум 72-битная глубина цвета (по 24 бита на каждую компоненту), а это возможно разве что в TIFF, причем не факт, что GD или ImageMagick с таким форматом сможет работать.

Но кроме таких "лобовых" алгоритмов мне подсказали довольно интересный альтернативный способ.
Для него я использую буфер промежуточных вычислений/изображений.
В виде формулы его можно записать как:
То есть в буфере хранятся результаты попарных наложений изображений, а на каждой итерации они сдвигаются вниз по стеку и суммируются с предыдущими изображениями:
Буфер на 10 элементов позволяет хранить до 1024 промежуточных изображений, из которых можно будет сформировать любое требуемое количество объединенных фотографий.
Этот способ не очень удобен в применении и его сложно оптимизировать, а кроме того количество операций наложения в худшем случае будет log2(288), но зато в нем нет погрешности вычислений и его можно применять с любым количеством изображений в серии.

exp98Ты уж определись, что более важно и насколько.
Как обычно, нужен разумный баланс.
Обрабатываться будет на более-менее производительном сервере, так что даже если я буду тупо каждый раз обрабатывать все изображения, он наверное будет успевать это делать.
Но зачем вхолостую греть воздух, если можно оптимизировать процесс без ухудшения качества?

maytonА есть обучающая выборка картинок? Для тренировки
Есть, если пережать в 720p, то примерно 30 МБ за сутки.
Если интересно, могу выложить минут через 20.

Нужно только A — усреднение всех изображений за сутки.
Ограничения реализации: обработка изображений будет выполняться bash+ImageMagick, поэтому реализация должна быть манипуляциями с изображениями (а не сохранение значений пикселов в CSV и работа с dword/float).
Пожелания: разумная оптимизация, чтобы не пересчитывать заново то, что можно не пересчитывать.

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

Alibek B.Если интересно, могу выложить минут через 20.
Вот пара семплов:
https://yadi.sk/d/Cw6Z_rZvq82AtQ
https://yadi.sk/d/_wnpz7jGOQ3l5A

В аттаче пример того, что у меня получилось.

Сервер — в смысле Яндекс.Диск?
Только что попробовал открыть ссылки, все открылось.

Alibek B.В аттаче пример того, что у меня получилось.
И кстати, возможно что усреднение изображения (среднее арифметическое) будет не совсем правильным.
При долгой выдержке темные кадры не влияют на изображение, а при усреднении изображения они будут затемнять итоговое изображение (поэтому на изображение на фотографии выглядит хмурым и пасмурным).
Скорее всего мне нужно изображения не складывать, а умножать. Но экспериментировать с функциями (для подбора наиболее красивой картинки) я буду после того, как в целом оптимизирую скрипт обработки изображений.

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

maytonа лучше брать взвешеное среднее (с колокольчиком типа Гаусса где максимум приходится где-то на 288 / 2 среднюю картинку)
Возможно, оптимальную функцию я думаю подбирать опытным путем, на реальных изображениях.
Но мне кажется, что средневзвешенное будет терять информацию.
Мне кажется, что самый интересный результат должна дать функция mix=mix/2+img/2.
Или точнее, mix=mix*k+img*(1-k) (при k=0.5 предыдущие изображения будут слишком быстро затухать, оптимальное k должно быть где-то около 0.81, чтобы следы двухчасовой давности были заметны где-то на 25%).

exp98И всё же нет, не Союз - там другая растительность.
Ностальгия это святое. Но это не Кабардино-Балкария, это Архыз.

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

Что касается алгоритма работы с серией изображений, то я пока вижу два варианта:
1. Брать предыдущий результат, отменять на нем воздействие хвостового элемента (вычитать устаревшее изображение) и применять воздействие нового элемента (прибавлять текущее изображение).
2. Сохранять промежуточные вычисления, чтобы на каждой итерации обрабатывать минимум изображений (в одежде - одно).

И чем больше рассматриваю, тем больше склоняюсь ко второму варианту.
В виде псевдокода его можно записать так:
И на каждой итерации вызывать добавить(изображение, 0).
И добавить постообработку, когда число изображений в серии не равно степени двойки.

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

Вот про видео не понял.
Все эти усреднения изображений имеют смысл только при условии стационарной неподвижной камеры.
Из обычного видео получится только шум.

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