Конференция VBStreets

Не знаю, как такие фотографии называются правильно, я условно называю их split-фотографиями.
Это когда с одной точки делается серия фотографий (либо в течение дня с определенной периодичностью, либо каждый день в одно и то же время), а затем все эти фотографии объединяются в одной, с каждой берется небольшая узкая вертикальная полоска.
В моем случае это IP-камера, с которой каждые 5 минут снимается скриншот. Я хочу склеить из этих скриншотов цельную фотографию, на которой будет фиксироваться минувший суточный интервал.

На сервере каждые 5 минут запускается скрипт, который получает скриншот с камеры.
Затем он делает следующее (скрипт bash):

Код: Выделить всё

DIR=/data/sites/.../www/img/live
SRC="$DIR/live_c01.jpg"
DST="$DIR/mix_c01.jpg"

let MIX=60
let NOW=`date +"%s"`-`date --date="00:00" +"%s"`
let NOW/="(86400/$MIX)"
read PRV < /tmp/lastrun.tmp
if [ "$NOW" = "$PRV" ]; then exit ; fi
echo $NOW > /tmp/lastrun.tmp

let MW=`identify -format "%w" "$SRC"`
let MH=`identify -format "%h" "$DST"`
let MS="($MW/$MIX)"
let ML="$MS*($NOW-1)"
let MR="($MS*$NOW)-1"
if [ $NOW -eq $MIX ]; then let MR="$MW-1" ; fi
composite <options> "$SRC" "$DST" "$DST"


Логика здесь следующая.
1. Определяется количество секунд с начала суток.
2. Сутки делятся на 60 интервалов, определяется текущий интервал.
3. Если скрипт уже запускался в текущем интервале, его работа завершается, иначе во временном файле фиксируется текущий интервал.
4. $SRC исходный файл (текущий скриншот с камеры), $DST результирующий файл (split-фотография). Определяем размеры файла (разрешение).
5. Для текущего интервала определяются координаты фрагмента, который нужно вырезать из скриншота.
6. Выполняется наложение с помощью ImageMagick.

Мне не нравится реализация пункта 5.
Если ширина фрагмента получается дробной (то есть ширина файла не делится нацело на количество интервалов), то тут будет накапливаться ошибка округления. Частично она у меня компенсирована (последний интервал занимает весь остаток), но это как-то кривовато.
Для таких случаев обычно используют алгоритм Брезенхэма, но на bash неудобно работать с математикой.

И вопрос с пунктом 6.
Не подскажите ключи для ImageMagick, чтобы выполнить необходимое (то есть наложить на одно изображение фрагмент другого)?
Сейчас я делаю это в два захода (convert -crop, а затем composite), но хотелось бы в один заход и без временных файлов.

Код: Выделить всё

    convert "$SRC" -crop ${MS}x${MH}+${ML}+0 "$TMP/crop.jpg"
    composite -geometry +${ML}+0 "$TMP/crop.jpg" "$DST" "$DST"


Скрипт отработал примерно половину суток и что-то мне не нравится его результат.

Сейчас сутки поделены на 60 интервалов, то есть ширина каждой полоски 24 минуты.
Это все-таки многовато, слишком резкие переходы, особенно на рассвете.
Видимо буду рисовать фрагменты при каждом запуске скрипта, тогда полоски будут 6-7 пикселов.
Пока не решил два вопроса:
1. Рисовать полоску между прошлым запуском и текущим или с текущим на +5 минут?
2. Если скриншот отсутствует (нет связи), продолжать предыдущий или рисовать черную полоску?

alibek писал(а):Скрипт отработал примерно половину суток и что-то мне не нравится его результат.

А что вообще в результате должно получиться (в идеале)? Никак не могу понять общий смысл всей затеи. Для чего это вообще нужно и где такой подход применяется?

Что-то типа такого: http://www.priroda.su/item/2136

alibek писал(а):Что-то типа такого: http://www.priroda.su/item/2136

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

С более «узкими» интервалами смотрится в целом получше.

Но все равно есть два не очень приятных момента.
Во-первых, фотография выглядит грязноватой из-за того, что освещенность постоянно меняется и полосы получаются разной яркости.
А во-вторых, на фотографиях иногда в виде артефактов проявляются кратковременные явления. Например тонкая темная вертикальная полоса на дороге это проехавший автомобиль. Ну и двигающиеся в течение дня тени тоже выглядят необычно (более широкая темная синяя полоса).
Наверное нужно эмулировать долгую выдержку фотоаппарата. Например делать 10 скриншотов в течение 10-20 секунд, а затем их объединять, используя от каждого скриншота по 10% интенсивности. Тогда постоянные элементы будут выглядеть как есть, а двигающиеся будут малозаметны и полупрозрачны. И кроме того нужно яркость выравнивать. Тогда должно получиться более симпатичное и правдоподобное изображение.

Скрипт используется примерно такой:

Код: Выделить всё

#!/bin/bash

let INT=120
let NOW=`date +"%s"`-`date --date="00:00" +"%s"`
URL="http://1.2.3.4//cgi-bin/snapshot.cgi"
DIR=/data/sites/mysite/www/img/live
IMG="live"
MIX="mix"

let MW=`identify -format "%w" "$DIR/$MIX.png"`
let MH=`identify -format "%h" "$DIR/$MIX.png"`
let MX0=`calc "int(${MW}*${NOW}/86400)"`
let MX1=`calc "int(${MW}*(${NOW}+${INT})/86400)-1"`
if [ $MX1 -ge $MW ]; then let MX1=$MW-1; fi
let MW1=$MX1-$MX0+1
let MX2=`calc "int(${MW}*(${NOW}+2*${INT})/86400)-1"`
if [ $MX2 -ge $MW ]; then let MX2=$MW-1; fi
let MW2=$MX2-$MX0+1

calc() { awk "BEGIN{print $*}"; }

convert "$DIR/$MIX.png" -fill black -draw "rectangle ${MX0},0 ${MX2},${MH}" "$DIR/$MIX.png"
wget -4q --tries=2 --timeout=10 -O "/tmp/snapshot.jpg" $URL
if [ $? -eq 0 ]; then
  mv -f -T "/tmp/snapshot.jpg" "${DIR}/$IMG.jpg"
  convert -geometry +${MX0}+0 "$DIR/$MIX.png" \( "$DIR/$IMG.jpg" -crop ${MW1}x${MH}+${MX0} \) -composite "$DIR/$MIX.png"
fi
convert "$DIR/$MIX.png" "$DIR/$MIX.jpg"


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

Снова вернусь к этому вопросу.
Со split-фотографиями (представляющими собой композицию из вертикальных полос, каждая из которых соответствует определенному временному интервалу) я разобрался. Оптимальным оказался двухминутный интервал (который дает 720 интервалов, по два с половиной пиксела на интервал для FHD), при более частом опросе картинка кажется просто грязной или испорченной, при более редком опросе между полосами слишком резкие переходы и картинка не воспринимается цельной.
Однако теперь у меня другая идея. Продолжая традицию, назову это mix-фотографией.
Если брать аналогию из традиционной фотографии, это должно быть похоже на очень долгую выдержку, на которой быстро двигающиеся объекты будут малозаметны (или незаметны), а неподвижные объекты будут экспонированы нормально.
Технически это будет выглядеть так — я беру 720 фотографий за сутки (на каждые 2 минуты) и последовательно накладываю их на исходно черный фон с прозрачностью примерно 0,1389% для каждой фотографии. Но при такой реализации это будет генерировать очень большую вычислительную нагрузку на сервер.
Чем-то это похоже на вычисление скользящего среднего — будь это числа, я бы между вызовами просто суммировал бы значения рядов и инкрементировал количество рядов, а для получения среднего значения просто бы делил текущую сумму на текущее количество.
Но к изображениям такой подход не применить, у них конечная разрядность для каждого пиксела.
В качестве "костыля" я попробую на каждой итерации «затемнять» итоговое изображение на 0,1389%, а затем накладывать на него текущее изображение с прозрачностью 0,1389%. Теоретически следы суточной давностью полностью сойдут на нет и должно получится что-то более-менее похожее на сверхдолгую выдержку.
Но может быть у кого-нибудь есть другие идеи?

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

А кто мешает суммировать в своём формате? DWord на пиксель, к примеру.

alibek писал(а):В качестве "костыля" я попробую на каждой итерации «затемнять» итоговое изображение на 0,1389%, а затем накладывать на него текущее изображение с прозрачностью 0,1389%.

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

Mikle писал(а):А кто мешает суммировать в своём формате? DWord на пиксель, к примеру.

Отсутствие утилит, которые бы работали с таким форматом.
Сейчас подготовительные операции выполняет bash-скрипт, а непосредственно манипуляции с изображениями он делает, используя ImageMagick.
В качестве промежуточного изображения (к которому применяются манипуляции) используется PNG, теоретически я могу использовать PNG48 (по 16 бит на компонент, без прозрачности), но еще не пробовал.

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

В том смысле, что для целочисленных значений компонентов X*0,001389 будет в основном получаться 0?
Да, об этом я уже думал. Если в качестве промежуточного файла использовать 16-битную глубину цвета, то должно получиться.
Иначе действительно нужно будет итеративно обрабатывать весь набор, объединяя файлы попарно и сводя к единственному результату — что делает невозможным экономить вычислительные ресурсы на использовании ранее полученных данных.

Если перейти на 16 бит, это придётся хранить до 720 изображений, да ещё и в таком увеличенном формате, а потом для вычисления результата вычислить 719 полусумм. И при этом теряется минимум 2 бита, если считать исходное изображение 8 бит на канал.
Лучше сделать как-то так, псевдокод на VB6:

Код: Выделить всё

Dim Ar(9) As tPic

Sub AddPic(Pic As tPic, ByVal Ind As Long)
  If Ar(Ind) Is Nothing Then
    Set Ar(Ind) = Pic
  Else
    Set Pic = Add2D(Ar(Ind), Pic) 'полусумма
    Set Ar(Ind) = Nothing
    AddPic Pic, Ind + 1
  End If
End Sub


При получении новой картинки выполняем AddPic Pic, 0. Биты не теряются, можно работать в восьмибитном формате. Хранится всего до 10 восьмибитных изображений, для получения результата требуется сделать до 10 суммирований хранящихся изображений.

Если я правильно понял псевдокод, то это не совсем то, что мне нужно.
1. Если я правильно понял алгоритм формирования изображения, то текущий микс получается как среднее между предыдущим миксом и текущей картинкой. То есть в конечном изображении доля текущего скриншота будет составлять 50% (1/2), доля предыдущего скриншота будет 25% (1/4) и т.д., доля последнего десятого скриншота будет составлять 1/1024 и его влияния практически не будет заметно.
Такой алгоритм позволит получить фотографию с постепенно исчезающими "хвостами" двигающихся объектов. А мне нужно эмулировать долгую выдержку.
2. Ну и десять фотографий это мало, нужно хотя бы 288 (пятиминутные интервалы в течение суток), а это большая вычислительная нагрузка, каждые 5 минут накладывать 288 фотографий.

Сейчас я пришел в следующему алгоритму.
Есть исходное изображение (jpg), есть буферное изображение (png48), есть конечное изображение (jpg).
Я беру два исходных изображения: текущее (new) и суточной давности (old).
Затем вычитаю из буфера изображение old и накладываю изображение new. Точнее (с использованием этих терминов) делаю substraction, затем addition, используя коэффициент 1/288.
Ну а затем полученный буфер конвертирую в обычный jpg.

Математически это получается (для каждой компоненты цвета): mix = mix - old/288 + new/288
Практически это соответствует скользящему среднему, если при вычислениях mix хватает разрядности.
И вместо 288 наложений используется только два.

alibek писал(а):Если я правильно понял псевдокод

Неправильно. Это даст полный аналог этого:

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

Только всё, что можно, будет вычисляться заранее.
Этим можно сложить до 1024 изображений.

Видимо я неправильно понял псевдокод.
Ar() — это массив промежуточных значений
Ar(0) — текущее изображение
Ar(1) — микс текущего и предыдущего
Ar(2) — микс текущего и трех предыдущих
...
Так?

Не совсем.
Ar() — это массив промежуточных значений
Ar(0) — предыдущее изображение
Ar(1) — микс предыдущей пары
Ar(2) — микс предыдущей четвёрки
А текущее в массиве не хранится. Когда мы миксуем текущее с предыдущим, то отправляем в слот для микса пары, если он занят - миксуем пары и отправляем в микс четвёрки, рекурсия.
Если число изображений равно степени двойки, то в последнем элементе массива получаем готовый микс всей кучи.
Я сделал пример на SR2D, работает:

Да, понял.
Хорошая идея. Жаль что для оптимальной работы число изображений в серии должно быть кратно степеням двойки.
У меня скорее всего будет 288, 720 или 1440, и обработка "остатков" съест всю выгоду.
Ну или нужно будет период подбирать, например получать скриншоты каждые 84 секунды.
Проверю оба варианта, мой с двумя наложениями и этот.

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

alibek писал(а):Жаль что для оптимальной работы число изображений в серии должно быть кратно степеням двойки.

alibek писал(а):обработка "остатков" съест всю выгоду.

Там те остатки уже в виде полуфабриката лежат в массиве, их максимум 10, обработать их не сложно, могу дописать к примеру.

Ну например 720 интервалов — это 512+128+64+16 или 1024-256-32-16.
В обоих вариантах степени двойки (9, 7, 6, 4 или 10, 8, 5, 4) не являются последовательными, у них есть разрыв.
То есть уже готовые миксы использовать не получится, нужно помимо основного буфера использовать минимум два вспомогательных (правда им на вход можно будет подавать готовые миксы из основного буфера).
И логика существенно усложняется, и промежуточных буферов (файлов) нужно будет много, и количество промежуточных вычислений существенно увеличивается.
Вообще интересно будет сделать оптимизированный подобный алгоритм, но я первым скорее всего сделаю свой вариант (с использованием хвостового и текущего кадров), а уже потом буду для сравнения использовать подобный буфер.

Вот примеры скриншотов: https://yadi.sk/d/-53gSPMehSkeuQ

Mikle писал(а):Я сделал пример на SR2D, работает:

А результата отдельно нет?
А то у меня и VB нигде не установлен.

Никакие вспомогательные буферы не нужны, получить результат можно на любом (например, 633-м) шаге, сделав не более 10 сложений изображений.

alibek писал(а):А результата отдельно нет?
А то у меня и VB нигде не установлен.

Перезалил там же, теперь EXE в комплекте.

alibek писал(а):Вот примеры скриншотов:

Интересно, сейчас попробую обработать.

Неплохо получилось.

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

Mikle писал(а):Никакие вспомогательные буферы не нужны, получить результат можно на любом (например, 633-м) шаге, сделав не более 10 сложений изображений.

По-моему нет.
Например 448 изображений это 256+128+64.
Соответственно можно сразу использовать значения из буфера (элементы 8, 7, 6).
Однако если взять число, которое не раскладывается на последовательные степени двойки — например 633=512+64+32+16+8+1 — то нельзя будет использовать значения элемента буфера 6, поскольку в нем будут находится полусуммы других изображений (не смежных с текущим).
Поэтому для несмежных промежуточных значений нужно будет использовать отдельные буферы, хотя в качестве стартового значения для них можно использовать одно из промежуточных значений основного буфера.

Всё там получается.
Переделал под твои данные, добавил функцию расчёта результата. Твои картинки должны лежать рядом с EXE в папке timelapse.
Результат внешне от твоего не отличается.

Mikle писал(а):Всё там получается.

Покажу на примере.
Допустим есть 13 изображений: a, b, c, ..., k, l, m.
Результирующий файл z должен получится как (a+b+c+...+k+l+m)/13.

Используемый код:

Код: Выделить всё

  For i = ...
    AddPic <picture>, 0
  Next i
...
  ii = 0
  For i = 0 To 7
    If Flag(i) Then
      Ar(i).BlendFactor = Int((1 - 0.5 ^ (i - ii)) * 255) * &H10101
      ii = i
      Spr.Draw Ar(i), 0, 0, OpBlend
    End If
  Next i
  <save Spr to result file>
...
Sub AddPic(Pic, Ind)
  If Flag(Ind) Then
    Pic.Draw Ar(Ind), 0, 0, OpAdd2D
    Flag(Ind) = False
    AddPic Pic, Ind + 1
  Else
    Ar(Ind).LoadFromSprite Pic
    Flag(Ind) = True
  End If
End Sub


В столбцах таблицы запись abcd означает (a+b+c+d)/4, или точнее ((a+b)/2 + (c+d)/2)/2.

Код: Выделить всё

#  0  1   2     3
-  -- --- ----- ---------
a  a
b  -  ab
c  c  ab
d  -  -   abcd
e  e  -   abcd
f  -  ef  abcd
g  g  ef  abcd
h  -  -   -     abcdefgh
i  i  -   -     abcdefgh
j  -  ij  -     abcdefgh
k  k  ij  -     abcdefgh
l  -  -   ijkl  abcdefgh
m  m  -   ijkl  abcdefgh


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

Код: Выделить всё

1*m 4*ijkl 2*abcdefgh

Здесь число это коэффициент для блендинга, вычисляется как (2 ^ (i - ii))
То есть полученное изображение соответствует формуле ((a+b+c+d+e+f+g+h)/4+(i+j+k+l)+m)/7
Это не совпадает с (a+b+c+...+k+l+m)/13.

Эту же таблицу можно получить в Excel, вставив следующий код в модуль:

Код: Выделить всё

Option Explicit

Dim a(7) As String
Dim f(7) As Boolean

Sub test()
  Dim p As String
  Dim i As Long
  Dim c As Long
  Dim ii As Long
  Dim k As Long
  Dim m As String
  For c = 0 To 7
    ActiveSheet.Cells(1, 2 + c).Value = c
  Next c
  For i = 0 To 12
    p = Chr$(Asc("a") + i)
    ActiveSheet.Cells(2 + i, 1).Value = p
    add p, 0
    For c = 0 To 7
      If f(c) Then
        ActiveSheet.Cells(2 + i, 2 + c).Value = a(c)
      Else
        ActiveSheet.Cells(2 + i, 2 + c).ClearContents
      End If
    Next c
  Next i
  ii = 0
  m = ""
  For i = 0 To 7
    If f(i) Then
      k = (2 ^ (i - ii))
      ii = i
      m = m & k & "*" & a(i) & " "
    End If
  Next i
  ActiveSheet.Cells(20, 1).Value = m
  End
End Sub

Sub add(ByVal p As String, ByVal i As Long)
  Dim m As String
  If f(i) Then
    m = a(i) & p
    f(i) = False
    add m, i + 1
  Else
    a(i) = p
    f(i) = True
  End If
End Sub


Верно, я не совсем правильно учёл весовые коэффициенты, но вопрос то был в том, что в массиве уже есть всё нужное, и никаких дополнительных данных держать не нужно.
Правильно так:

Понял о чем речь.
Речь о том, что любое число можно будет разложить по степеням двойки и в буфере для каждого слагаемого уже есть соответствующий микс.
Но я имел ввиду, что у каждого такого микса будет разная степень "разбавления" и прежде чем суммировать миксы нужно будет привести к одинаковой степени "разбавления".
В приведенном примере это решается операцией blend и весовыми коэффициентами.
Но я не уверен, что blend даст тот же результат, что add2d.
Например на последнем шаге получилось m, ijkl, abcdefgh.
В примере они смешиваются как blend(1*m, 4*ijkl, 8*abcdefgh) — где множители это слагаемые 13, разложенного по степеням двойки 8+4+1.
Я говорил о том, что более правильным было бы считать как: add2d(m, add2d(add2d(add2d(a,b),add2d(c,d)),add2d(add2d(e,f),add2d(g,h)), add2d(add2d(i,j), add2d(k,l)))) — а это потребует дополнительных буферов.

Как раз Add2D неприменим, когда Cnt не степень двойки. Предположим, мы суммирует 3 картинки: a, b и c.
В результате должно выйти (a+b+c)/3. Как это представить с помощью Add2D? Никак.
А у меня получается Blend(Blend(a, b, 1/2), c, 2/3).
Сама функция Blend выглядит так: Blend(a, b, k) = a*k + b*(1-k)

Возможно, нужно будет применить это все к серии изображений и посмотреть результат вживую.
Может быть придется функцию объединения изображений поменять, которую будет проще реализовать.
Например mix = mix/2 + new/2 мне кажется даст интересный результат, зато с ее реализацией никаких сложностей.