Исследовательский проект "Цифровая оптика" .

[Alex2013]

Текущая сборка "Подзорной трубы"...

Truba_DS_0_0059_8.7z


(Уф замахался делать скриншот (Фокус в том что я его из под Wine делал, а там что-то временами кадр переворачивает вверх ногами ) )


В окно "слежении за объектами" добавил Галку MBlur и движок управления к ней ...

Что это такое догадаться несложно обычный motion blur или "Темпоральный след " .
Я заметил что даже в полностью неподвижном кадре после поисков контуров картинка слишком "плывет".
ТС по идее должен "собирать статистику" делая неподвижное изображение более неподвижным .
Кое что получается но вот беда сильно до не разборчивости объектов размазывает любое движение .

Нужно сделать "хитрое" сложение кадров где движущийся объект смог бы рисоваться первым .

[Alex2013]

Дело движется !

Truba_DS_0_0059_9.7z
Обнаружил и прикрутил к программе некую "не известной породы" Бинаризацию
Пока лучший результат из всех опробованных фильтров !
(Фильтр Канни красив но почти бесполезен применяя "Скелетизацию" нужно еще долго возится вникая в ее возможности и тд )

Но применяя новую Бинаризацию вместе с "заслуженным гасителем звезд" MBlur и Emboss уже почти можно "грабить корованы" !

Правда неясно что ставится на входе (первый числовой параметр явно нижний порог(правда тоже "хитрый" ) а вот второй как-то связан с "радиусом адаптивности" но что это такое на самом деле не вполне понятно )

+Включил ранее опробованный поиск линий и контуров на базе OpenCv.
(Галки FContur и FLine) как и все OpenCv отдает неким гм... хаосом что-ли?

Кто не понял разъясняю :
Скрин 1 тут без всяких контурных фильтров изображение доведено до уровня
когда можно применять "поиск контуров" из моего старого проекта (Разумеется оптимизировав процесс )



Скрин 2 Поиск контуров через OpenCV (Как использовать результат пока не очень ясно )


Скрин 3 Поиск линий через OpenCV ( каша еще та но вы не вдели что было после фильтрации по Канни ... )


Скрин 4 (Ну и что ? Просмотрите следующий скрин ! )


Скрин 4 ( Вот теперь все ясно ! Буквы на предыдущем скрине (так же как и на этом ) были полностью переработаны, то есть это уже почти настоящая ДР ! )

ЗЫ
Загадочная бинаризация!
Главное в отличии от РАБОТАЕТ !
Но интересно, что это за метод ?

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

// Binarization неизвестного происхождения ...
procedure bBinarization(var  bBitmap,OutB:TBitmap;Min,Max:Integer);
var
  iX1, iY1,
  iX2, iY2,
  ii, jj,
  s, s2,
  iSum, iCount,  index,
  iHeight, iWidth : Integer;
  iSize: Integer;

  row : ^TRGBTriple;
  black : TRGBTriple;
  aIntegralIm: array  of Integer;
  aGrays : array of Byte;

  startTime : Cardinal;
  bBitmap2:TBitmap;
begin
  iWidth := bBitmap.Width;
  iHeight := bBitmap.Height;
  iSize := iWidth * iHeight;

  SetLength(aGrays, iSize);
  SetLength(aIntegralIm, iSize);

  black.rgbtRed  := (clBlack and $0000FF);
  black.rgbtGreen := (clBlack and $00FF00) shr 8;
  black.rgbtBlue := (clBlack and $FF0000) shr 16;
  bBitmap2:=TBitmap.Create;
  bBitmap2.Canvas.Brush.Color := clWhite;
  bBitmap2.SetSize(bBitmap.Width,bBitmap.Height);
  bBitmap2.Canvas.FillRect(Rect(0, 0, bBitmap2.Width, bBitmap2.Height));
  if max<1 Then Max:=1;
  s := Round(iWidth /Max);
    s2 := Round(s / 2);

  startTime := GetTickCount();

  index := 0;

  for ii := 0 to iHeight - 1 do begin
     row := bBitmap.ScanLine[ii];
     for jj := 0 to iWidth - 1 do begin
       aGrays[index] := ((row.rgbtRed * 77 + row.rgbtGreen * 150 + row.rgbtBlue * 29) shr 8);
       inc(index);
       inc(row);
     end;
  end;


  for ii := 0 to iWidth - 1 do begin
     iSum := 0;
     for jj := 0 to iHeight - 1 do begin
       index := jj*iWidth+ii;
       iSum := iSum + aGrays[index];
       if ii = 0 then aIntegralIm[index] := iSum
       else aIntegralIm[index] := aIntegralIm[index - 1] + iSum;
     end;
  end;


  for jj := 0 to iHeight - 1 do begin
     bBitmap2.BeginUpdate(False);
     row := bBitmap2.ScanLine[jj];
     for ii := 0 to iWidth - 1 do begin

       index := jj*iWidth+ii;

       iX1 := ii-s2;
       iX2 := ii+s2;
       iY1 := jj-s2;
       iY2 := jj+s2;

       if (iX1 < 0) then iX1 := 0;
         if (iX2 >= iWidth) then  iX2 := iWidth-1;
           if (iY1 < 0) then  iY1 := 0;
             if (iY2 >= iHeight) then  iY2 := iHeight-1;

       iCount := (iX2 - iX1) * (iY2 - iY1);

       iSum := aIntegralIm[iY2*iWidth+iX2]
              - aIntegralIm[iY1*iWidth+iX2]
              - aIntegralIm[iY2*iWidth+iX1]
              + aIntegralIm[iY1*iWidth+iX1];

       if (aGrays[index] * iCount) < (iSum * (100 - Min) / 100) then  row^ :=  black;

       inc(row);

     end;
   bBitmap2.endUpdate(False);
  end;

  //ePath.Text :=  'Time: ' + inttostr(GetTickCount() - startTime) + ' ms';
  OutB.Canvas.Draw(0,0,bBitmap2);
  bBitmap2.Free;
end;


[Alex2013]

Продолжение банкета ! (Приближение приближается ! ) До достижения светлой цели распознавания ДР-меток осталось совсем немного !
Truba_DS_0_0059_10.7z



Тут поймал идущий процесс поиска (видна иконка- индикатор )


Тут добавлен мой пока не очень точный метод поиска контуров .


Для сравнения тоже изображение с рекурсивным поиском ...


Truba_DS_0_0059_10. (Выдержка из readmy.... )
Уф, два дня "повисания" в процессе глубокой отладки ..
(Ну бывает... кажется вот вот "и дрогнут шведы"... ага ... вздрогнул...
бедный Ёрик… то бишь мой ну очень дальний предок из славного шведского рода Норманов в гробу перевернулся.. )

Короче, в муках прикрутил аж два своих метода распознавания контуров (не путать с контурными фильтрами ) ..
И сподобился даже многопоточность к этому делу присобачить..
Все бы хорошо да один метод рекурсивный и явно есть проблемы с переполнением стека
Что делать ? Написал свой но выясняется что проблема только отчасти связана с рекурсией ...
Есть явная и не понятная ошибка при обработке изображений с нормальным разрешением.
Камера снимает в разрешении 640Х480 но даже при уменьшении в два раза есть явные проблемы (обработка не доходит до конца кадра
что вызывает какие-то дикие ассоциации с "ручным управлением" видео адаптером в МСДОС в режиме EGA)
Так что работает только с очень сильным "Упрощением по разрешению" то бишь в 3, 4 и более раз ..
Метод с рекурсией может глючить при больших черных объектах тормозить при большом количестве мелких точек ...
Мой метод работает значительно быстрее и не виснет но результаты есть только "в тепличных" условиях
(Пару простых контуров может распознать более менее точно но результат нестабилен )...

Мда чтобы описать, что и как работает, скоро нужно будет писать несколько страниц инструкций …
И так в окно «слежение за объектами» добавил кнопку “RR” галку “RRV” и «MSOBJ»
Всё это «богатство» работает при включенном «Упрощении разрешения» начиная 3 раз и «Пороге бинаризации» с подбором уровня двумя движками в правом верхнем углу окна.
Галка “RRV” включат и выключает(выключает с очисткой) просмотр найденных контуров .
Галка «MSOBJ» включает не рекурсивный метод поиска
(Более быстрый и более надежный, но пока неточный)

[Alex2013]

Банзай товарищи !
Truba_DS_0_0059_11_2.7z



"Какой-же день там был тогда... ах да среда! " Да я знаю что сегодня уже четверг ... но куда я среду посеял ?
А вот сюда !
Версия Truba_DS_0_0059_11_2.
В общем начал я прикручивать распознавание меток
(в отличии от предыдущего захода в тему "Дополнение к реальности" в реальном времени )
Не шатко не валко что-то даже работнет (иногда… )
В промежуточной сборке был еще поиск метки повернутой под углом но в том виде от него проку мало .
(Только демонстрация процесса красивая )

И так в "слежение за объектами" опять добавил новую галку "Панель распознавания метки" которая как нетрудно понят включает ее показ.
Там есть выбор масштаба для загруженной метки , показ метки , кнопка «новая метка» и галка "Включить распознавание".
Кроме того, выводится инфа о найденной метке (Пока ищет только одну)
Цифры
1 Номер контура в списке ...
2 Уровень шума в %. (Меньше лучше )
3 Совпадение с меткой в %.. (Больше лучше)
4 Должен быть угол поворота но пока просто случайное число единственная польза которого в том что видно что поиск идет на каждом
кадре, а не повис ..


Что бы увидеть действие предварительной версии распознавания метки нужно:
1 Выставить пороги бинаризации
2 Найти контуры (Кнопка "RR")
3 Включить "Панель распознавания метки"
4 Поставить галку "Включить распознавание" ..
"По вкусу" можно включить MBlur и второй порог, а также настроить "упрощение по разрешению".
Все прочее на уровне работает на уровне "проиграться с фильтрами" и особого смысла для данного метода поиска метки не имеет..

Вот например цифровая зарисовка на тему "Трофейный процессор арабского терминатора " ...
Бесполезно но красиво ! (Вам тут невидно, а у меня еще все шевелилось и загадочные символы "арабской вязью" ползли ... типа "телеметрия" ! )


Метод поиска меток пока сильно чувствителен к искажениям и повороту…
Но в принципе понятно, что с этим делать.
Еще где-то есть сбои с перезапуском поиска и найденная метка «зависает» не смотря на обновление списка контуров …
(Пока помогает только перезапуск программы )

[Alex2013]

Truba_DS_0_0059_11_5.7z

Ай.. Ай... Кеп ! вас узнали ...


"Черная звезда"... ужос звездоплавателей !


Лучший кадр !


Truba_DS_0_0059_11_5.
"Ух понастроено, прямо так и понастроено! "(с)Дерёвня
Изменения? мдя.. Проще сказать, что не изменилось!
Ну ладно кратко ...
1 Главное добавил полуавтоматический режим поиска контуров ... (Галка "FRR" ).
2 Вращение работает быстрее но все равно тормоз ! (Для ручного режима (поиск контуров кнопкой RR) более мнение )
3 Куча новых настроек в "Панели распознавания метки"
4 Режим наблюдения .(полезен для подкручивания порогов распознавания )

В общем, все постепенно упростился, а пока 'жуткие навороты'...

Но наконец можно двигать метку (пока не особенно в широких границах и параллельно камере ) и программа САМА следит за ней ...
(Гоняя распознавание, раз в заданное число кадров.. меньше 3 ставить, не рекомендую!)

Хотел приделать промежуточный поиск сдвигов через ОpenCV но пока устал и обломался на пересчете координат.

Еще пытался повторить успешный опыт с потоком и для распознавания метки, но завяз в "глубинах инкапсуляции" точнее при попытке "всплыть".
Надо будет сделать создание метки прямо из кадра (А то рисуешь, одно камера видит другое, а распознавать пытается третье !... )

Зы
Итак программа "увидела свою тень" ! Полный оборот в спирали развития проекта завершен !
Функционал из предыдущего проекта полностью воспроизведен на качественно новом уровне .
Зы Зы
Если бездумно клацаць галками (особенно RRV при включенном распознавании ) возможен вылет из программы или провисание смены кадров в окне ...
Но для "лабораторного монстрика" это прямо таки верх стабильности .
(Разумеется в дальнейшем постараюсь "выправить мозги" и в этой мелочи )

Добавлено спустя 19 часов 30 минут 54 секунды:

Truba_DS_0_0059_12.7z





Truba_DS_0_0059_12.
"Понедельник начался вовремя..."
Сегодня "работа над ошибками" и
Панель создания метки (галка Создание метки)
(Перед использованием включайте Порог Бинаризации!)
На панели кнопки сохранения и прямого использования, метки для поиска.
+ галка "Режим захвата метки"(включив которую, можно мышкой прямо из текущего кадра выбрать нужный блок изображения.)

[Alex2013]

Ау Сонное царство ... а я тут новую в сборку сделал ... (и даже не одну но не все сразу! )

Truba_DS_0_0059_12_1.7z


Truba_DS_0_0059_12_1.
Возился много, а результат так себе ...
Хотя это как поглядеть !
Код распознавания метки стал значительно стабильнее .
Выбросил (точнее переписал) совершенно дикий кусок с вращением и заполнением списка повернутых меток .
Нет, логика там какая-то была ...
Но даже компилятор похоже не смог однозначно транслировать это "байто- раздирающие зрелище" в нормальный машинный код...
+ ещё разные мелкие правки .

Фильтры в помощь ! (Код стал стабильнее теперь можно поэкспериментировать . )


Я крут ! ОpenCV не обнаружил контур а мой метод нашел!

Что явно напрашивается по результатам испытаний:
1 Для реального применяя нужно хоть как то решить проблему проективных искажений метки...
2 Оптимизировать все что только можно особенно вращение и поиск контуров

[Alex2013]

Truba_DS_0_0059_12_2.7z





Truba_DS_0_0059_12_2.

Оптимизаторы, да не покинет вас оптимизм !

1 Поиск контуров: убрал поток
(делал его для возможности наблюдать процесс и без него поиск определенно работает быстрее )

2 Снова переписал вызов вращения меток (теперь он только там где нужно )

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

+ сделал остановку поиска при первом же удачном значении "Уровня шума " и "Уровня совпадения"...
( Так и не понял работает остановка или нет )

4 Блокировал изменение потенциально "глюкоопасных" параметров вовремя работы распознавания метки.

5 Добавил галку "Чистый кадр" для полного возвращения не фильтрованного изображения перед показом результатов поиска контуров и меток(А то на после фильтрации на глаз бывает понять трудно, что там за кадр был изначально ... да и вообще, что это за ДР где реальности невидно ? )
Зы
Кстати, с меткой в виде буквы "С" приключился у меня эпический прикол ...
Дело в том что оказалось что ее можно распознать под любым углом без вращения (не включай соответствующую галку ).
А тут "такой я" этого разумеется сразу не заметил . думаю "о как круто моя оптимизация работает, тормоза пропали !"
Но внеся мелкие правки запускаю снова и на это раз все делаю правильно ... ТОРМОЗА снова на месте, а я в "глубоком отрицании " начинаю "лопатить код" результатов нет ... час ..два... три... потом начинает мчать смутное сомнения ... может я какую-то "волшебную" комбинацию фильтров случайно подобрал ? ... еще час ... Начинаю "тихо сходить с ума" и пробовать ВСЕ возможные и не очень варианты настроек ... и "злобная эврика " все-же пришла ... Толку правда от нее мало .

Результате появилась какая-то невнятная идея "А что если "как-то" определять угол поворота контура ДО его его сравнения с меткой ?" Но ладно если контур прямоугольник : точка сверху точка снизу -> уравнение прямой -> и угол пресечения с осями у нас в кармане ... а если контур вообще буква "S" или еще что ? Как можно узнать угол поворота ПРОИЗВОЛЬНОЙ фигуры ?
Допустим можно получить "центр масс" фигуры но это ТОЧКА а где мне вторую взять ?

[Pavia]

Может проще QR-код? Вот тут не плохо алгоритм расписан.
http://dxdy.ru/topic118782.html

[Alex2013]

Может проще QR-код? Вот тут не плохо алгоритм расписан.
http://dxdy.ru/topic118782.html

Спасибо! Посмотрю ...
Но вообще задача чуть другая . Мне нужно не читать код и даже распознавание метки задача второстепенная .
Мене нужно вычислить 3д координаты метки и привязать к ним нечто "Расширяющие реальность"(Вроде виртуальной клавиатуры или окна произвольной программы ) + возможно реальное "слежение за объектами" то есть навел на что-то в кадре и включил лог перемещений, а потом смотришь их схему ...

Разумеется интересует и создание "реальной" 3д модели окружения на основе нескольких кадров снятых из разных точек опять же с привязкой к некой метке с известным размером .
ЗЫ
Пока для ускорения поиска метки придумал вот что :

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

// Отношение  заполненных пикселей к их максимально возможному количеству в процентах;
Function  FastStat( Bitmap: TBitmap;CC:Integer):Byte;
Type
RGB1=Record  B,G,R  : byte; end;
var
  X, Y,Sum:Integer;
  PixelPtr: PInteger;
  PixelRowPtr: PInteger;
  BytePerPixel: Integer;
  BW:Byte;
  PRGB:^RGB1;
  begin
  Result:=0;
  If   Bitmap.Width*Bitmap.Height=0 then exit;
  try
    Sum:=0;
    Bitmap.BeginUpdate(False);
    PixelRowPtr := PInteger(Bitmap.RawImage.Data);
    BytePerPixel := Bitmap.RawImage.Description.BitsPerPixel div 8;
    for Y := 0 to Bitmap.Height - 1 do begin
      PixelPtr := PixelRowPtr;
      for X := 0 to Bitmap.Width - 1 do begin
       PRGB:=Pointer(PixelPtr);
       With PRGB^ do begin
                      If rgb(R,G,B) =CC then Sum:=Sum+1;
                   end;
        Inc(PByte(PixelPtr), BytePerPixel);
      end;
      Inc(PByte(PixelRowPtr),Bitmap.RawImage.Description.BytesPerLine);
    end;
  finally
   Bitmap.EndUpdate(False);
  end;
If   Sum <>0  then
     Result:=Trunc(Sum /(Bitmap.Width*Bitmap.Height)*100);
end;



Это Необходимое но НЕ Достаточное условие, позволяет отсеять изображения которые "ну совсем не похожи"
и при этом "забить" на вращение и прочие искажения (Вертикальное и горизонтальное сжатие/расширение у меня тупо приводится к размеру шаблона ) ... Кроме того можно "бесплатно" (от есть "попутным циклом" )считать количество пикселей при рекурсивном обходе контура(Причем получается точнее правда с искажениям дело обстоит чуть хуже ) ....

[Pavia]

Результате появилась какая-то невнятная идея "А что если "как-то" определять угол поворота контура ДО его его сравнения с меткой ?" Но ладно если контур прямоугольник : точка сверху точка снизу -> уравнение прямой -> и угол пресечения с осями у нас в кармане ... а если контур вообще буква "S" или еще что ? Как можно узнать угол поворота ПРОИЗВОЛЬНОЙ фигуры ?
Допустим можно получить "центр масс" фигуры но это ТОЧКА а где мне вторую взять ?

Чем меньше точек тем быстрее работает перебор.
Если мы берём сплошняком шаблон то это 100х100 точек и для каждой подозрительной 640х480 (100х100х640х480)
Число точек надо уменьшать. Выделяем кляксы будем работать только с ихними точками нас это ускорит ну не более 3-х раз.(0٫3*100х100х640х480)
Тогда уменьшим ещё число точек возьмём контуры. это нас ускорит в 100 раз. (100х640х480)
Далее можно выделить углы. Это нас ускорит ещё в 25 (4х640х480)
У буквы S углов нету. Но что нам мешает взять цетнр фигуры и пустить из него лучи через каждые 45°? А ничего не мешает. 360/45 и по 2 точке на луче (16х640х480)

Развитием этой идеи служат методы RANSAC. Точки берутся произвольным образом. Так же можно распределить точки по квадрату так что-бы они были на равном удалении.

Как ещё можно уменьшить число точек? Так же можно удалять пиксели с каждой второй строчки и каждого второго столбца. С точки зрения теории ЦОС это не хорошо так как возникают ложные частоты. Поэтому лучше сделать правильно сгладить перед прореживанием. Получаем алгоритм обычное уменьшение размера изображения

Пирамида изображений. На её построение конечно потратиться много времени. Но в итоге она позволяет ускорить обработку в 4-16 раз.
------------------------
Распознавание обычно занимает уйму времени 100-800 мс. Один раз распознав объект за ним просто дальше следят не прибегая к распознаванию, а вычисляя его перемещения.

Есть такая вещь как оптический поток. Обычно этот алгоритм применяют для вычисления положения камеры. Но так же его можно применять для положения объекта для не подвижной камеры.

Оптический поток и его брат близнец градиент изображений. Несколько похожи.
Оптический поток - изображение делится на квадраты 8х8 или 16х16. (640x480/8/8=40x30)
Для каждого квадрата мы можем подсчитать центр масс. Если вычесть координаты центра масс из предыдущего значения(для предыдущего кадра), то мы получим вектор. А если нарисовать их в масштабе 30, то получим векторное поле.
Опять таки подсчитываем среднее значение по x, y мы сможем вычислить куда сместилась камера. Или решая систему линейных уравнения сразу вычислить куда сместилось и как повернулась камера.

Точно так же для объекта, только для него ограничивается зона векторов - зоной интереса. А перемещение объекта только обратное значение.

[Alex2013]

Что-то похожие я планирую сделать ...
1 Слежение за сдвигом объекта без распознавания уже есть (Для чего OpenCV пока почти исключительно и переменяется ).
2 Уже сейчас программа заточена на проверочное распознавание через несколько кадров .
3 Думаю перейти к одно-битовому или хотя-бы одно-байтовому формату данных
4 Разные "мип-левелы" не только ускоряют но и УСЛОЖНЯЮТ обработку что не есть гут .
5 Еще есть "стратегический резерв " в виде нескольких ядер процессора (ИМХО : Не использовать ТАКОЙ "рояль в кустах" глупость немереная )
6 А еще я беру и резко уменьшаю разрешение исходной картинки перед началом обработки В метре-двух можно отлично обойтись картинкой с разрешением 160х100 или даже 128х98 ....

Но вообще я понимаю, что в таком виде програмулина все равно мало что может .

Во первых нужно сменить метод распознавания мое "патентованное сравнение" слишком примитивно хотя и как результат работает просто и быстро (но нужно подготовить как можно мене искаженное изображение, что резко снижает скорость обработки ).

Во вторых нужно более полно применить OpenCV ( изобретать велосипед полезно для общего развития и лучшего понимания но НЕ для практического применения )
Зы
Сделал еще две сборки но пока еще не залил их на ЯД ...

Добавлено спустя 17 часов 54 минуты 9 секунд:

Внимание экспериментальное видео!

(Скринов для пояснения явно становится мало ) ...

Скорее всего в дальнейшем буду заливать обновление в шапку темы ....
(После включения окна "слежение за объектами " трачу немного времени на восстановление "исходного состояния" , а было бы непонятно что и как настраивается для получения результата )
Screen_9-26-2017_Test_2.avi 97 мб почти полный показ возможностей программы ...
(аж 25 минут рекомендую просто проматывать "нудоту "я там постоянно по галкам и кнопкам мышкой не попадаю (рекодер все тормозит) ... )

Вообщем первый блин !
ЗЫ
Кто знает чем можно нормально делать "динамический скрин" без жутких тормозов и объемов записи? (желательно только нужное окно или часть экрана )

Добавлено спустя 40 минут 49 секунд:
Собственно свежая сборка ....
Truba_DS_0_0059_12_4.7z

Truba_DS_0_0059_12_3.

Ускорение должно ускорять ...
Сделал предварительный анализ (по отношению закрашенных пикселей к размеру поля)
Можно сделать еще быстрее если заранее просчитать значений в общий список для всех контуров
Пока результат виден только при включенном вращении .


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

Добавлено спустя 10 часов 38 минут 31 секунду:

Труба на трубе !

Screen 9 26 2017 Test 2

Добавлено спустя 10 часов 50 минут 34 секунды:
Операция "сам себе режиссер" продолжается ...
(Сразу залил на youtube )
Screen 9 27 17 Дополнеие OpenCV в TrubeDS D2
Ролик 12 мегов идет около 4х минут
+ более быстрый и сильнее жмущий кодек, а также меньшее исходное разрешение (800х600)
Все-бы хорошо но есть артефакты сжатия и "замерзание" кадра
(хотя кое где я сам по кнопкам вслепую не сразу попадаю... Десу ! ).
ЗЫ
Да ! На "трубе" можно выставить просмотр с удвоенной скоростью ... Рекомендую ! ( особенно в первом ролике )
Зы Зы
Ролик с опечаткой в названии файла убрал ... мда "погода была прекрасная - принцесса была ужасная "
...типа "ночная сборка", ога !

[Alex2013]

Truba_DS_0_0059_12_5.7z
Поточное производство на марше ...



Truba_DS_0_0059_12_5.
"Перестройка должна перестраивать."
Много мелких правок и одна реально полезная: Упрятал поиск меток в отдельный поток .
Сделал довольно грубо с сохранением старого кода...
Но с почти полностью локальными данными поиска
(Кадр и два списка КОПИРУЮТСЯ в поток, а все прочие или блокировано или не существенно )
Так что теперь поиск метки происходит отдельно от потока кадров .
(Не знаю насколько ускоряет исполнение на других ядрах, но почти нет видимой задержки обработки основного потока (время на поиск расходуется но частота кадров если и снижается то равномерно )
...
Брр.... Оказывается поток можно остановить в произвольной точке (а не только по завершению итерации как я наивный думал)...
Поставил ожидание СВОЕГО флага после остановки потока и жду жду жду ... не дождался, однако!
И т.д. отладка потока это ловля багов в «четвертом измерении»! (Все время нужно держать голове, что где-то там, за пределами ткущего кода "в другом измерении течет бурный поток" )
(Все ошибки не выловил но поймал и профиксил много! )

[Alex2013]

Truba_DS_0_0059_12_6.7z
Truba_DS_0_0059_12_6. (02.10.2017)


(Видно что программа по разному загружает первое и второе ядро процессора
+ четко видно момент включения второго потока (начало графика ))

"Если вам кажется, что все работает как надо, то это значит вы что-то не заметили"(С)Законы Мерфи
Вправил мозги потоку ... ну это я так думал ...
...потому как внезапно оказалось , что и основной программе правка не помешает
Теперь прибываю в легкой форме "синдрома параноидального программиста" типа "слишком тут тихо - жди беды"!
Но вообще целенаправленно клацая всеми галками настроек поиска метки вызвать исключение не удалось .
Так что пока считаю, что глюков несовместимых с работой в поиске меток нет ...
Оказывается, чтобы ждать изменения состояния флага внутри потока нужно постоянно возвращать "нервный-тик" системе
While SMT.ProcessRUN do application.ProcessMessages;// так не виснет !

[Alex2013]

Новая сборка пока ничем кроме визуальных эффектов особо не похвастать может .
Поэтому просто выкладываю пару скриншотов ...





Хотя чувствуется, что очередная "микро сингулярность" (более высокий уровень приближения к "заветной ДР" ) где-то рядом !

[Alex2013]

Уф !
После долгого и нудного подбора программного обеспечения мне удалось добиться :

1 Чтения изображения с камеры смартфона ( DroidCam http://www.dev47apps.com/)

2 Создания "виртуальной камеры" на планшете ( через DroidCam Client )
( как качать с официального сайта напрямую не понял однако нашел обход
http://soft.mydiv.net/win/files-DroidCam.html (как говорится "на свой страх и риск" но вроде ативирус молчит... ) )

3 Обработки изображения на планшете (в моей программе Truba_DS_0_0059_12_7)

4 ...и вывода обработанного изображения на экране сарматфона.
(TrinusVR с поддержкой псевдо-стерео режима для "водолазной маски" VR гарнитуры )

Для чего вся эта докука ? Все просто, теперь можно попробовать сделать "допиленную реальность "(ДР) боле приближенную к настоящей
(причем все это " программное безумнее" работает без проводов !)

Добавлено спустя 2 часа 34 минуты 9 секунд:
А вот и скриншот ... (умучился пока делал, но без иллюстрации понять о чем речь трудно. )


Справа видно экран смартфона через VNC ( повернутый на 90 градусов ) то есть то что видно в маску "стереоскопа "...
Вверху панель TrinusVR ...
Левее DroidCam Client...
+ видно что в первом окне "подзорной трубы " есть выбор дополнительных камер и весь это "ужос" крутится на планшет к которому по HDMI подключен монитор .