У меня есть набор фотографий, сделанных с определенным интервалом в течение суток (например каждые 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 с определенным коэффициентом прозрачности (тогда чем изображение свежее, тем у него будет больший вес), а арифметические операции вычитания и сложения над изображениями, умноженными на константу (тогда у всех изображений будет равный вес).