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

[Alex2013]

Смотрится просто отлично для 2017 года.
Но сайт не работает уже,и в комментах говорят что код данного чуда был украден у разработчиков Окулуса.

Немного боян ... у меня вроде даже где-то исходники валяются .. главное препятствие хитрая стерео камера которую фиг где найдешь и хотя принципе у меня есть "стерео дальтоник" WМR но там все работает немного по другому.
.
Кстати Oculus для шлема Квест 2 несмотря на похожий "дальтонизм" делает
Infinite Office

[IvoX]

А я тут смотрел скорости доступа к пикселям различными методами,сравнивал сканлайн и SetDiBits(на запись)...
Получились интересные результаты.
У сканлайна 92 такта на пиксель,это с учётом создания изображения Bitmap в памяти ~ 3.7 наносекунд /пиксель
А у SetDiBits 10 тактов на байт, и в среднем 42 такта на пиксель при 32-битной цветности. Но только при полном помещении картинки в кеш процессора + размер инструкций.
В моём случае при кеше 64к размер картики до 117х129 х32Bpp=60372 байта.Рисовал кстати сразу на экране примерно 35000 FPS получалось
при 509х240 х32Bpp 14000 FPS.
Средствами GDI 3700-4200 FPS тот же размер.
И получается для обраьотки изображения выгоднее вычитывать его в массив,либо работать напрямую с его памятью через свои функции.
Тогда неизбежно будут потери времени при конвертации в формат OpenCV ,у них если не ошибаюсь это массив Double.Или писать своё которое не факт что будет быстрее

BT_FAST.7z

[Alex2013]

В начале выложу очередной обещанный "микро релиз"...

Truba_DS_0_0059_14_3_2M0 (12.10.2020) Понедельник
"Лучше поздно, чем позабыл! "

Окно "слежение за объектами"...
'Отделение фона'- пробная версия(за то с прозрачностью ).
Кнопка "Получить фон" - задать фон
Галка "Отделить фон" - включить режим отделения фона
Движок "Приближение" - близость цвета пикселя к фону
Движок "Прозрачность" - прозрачность показа образца фона
(Примечание ! Перед сменой фона нужно отключать галку "Отделить фон" )



Окно "Цифровые эффекты" дополнение
Раздел "Software"
'Отделение фона'
Настройки ('Кадров до захвата') - задержка до захвата
('Кадров после захвата') - задержка до рабочего режима
('Фон из файла')- загрузка фона из файла (не проверял!)
('Имя Файла' ) - Имя Файла с фоном
('Приближение') - близость цвета пикселя к фону



Раздел "OpenCV"
'cvPyrMeanShiftFilter' - очень ресурсоемкий метод "сегментации"
(Соседние близкие по цвету пиксели сливаются, а цвет усредняется
- выходит что-то вроде цветной бинаризации )

Настройки
'SP'(предположительно порог срабатывания),
'SR'(предположительно радиус срабатывания),
'Max_level'(предположительно глубина обработки)

Truba_DS_0_0059_14_3_2M0_bin.7z
Truba_DS_0_0059_14_3_2M0_SRC.7z

Суть возни с "отделением фона" и 'cvPyrMeanShiftFilter' в попытке улучшить надежность распознавания ладони .
С cvPyrMeanShiftFilter все ясно! "Красиво но тормоз!" (а фокс со снижением разрешения для распознавания ладони некатит по причине того что ладонь нужно распознать на заметном расстоянии от камеры )

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

Называется FastCompAndCutBW...

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

Procedure FastCompAndCutBW(C:Byte;Var  Bitmap,B: TBitmap);
// Сравнение двух кадров с вырезанием (ЧБ вариант)
Type
RGB1=Record  R,G,B  : byte; end;
Const
  DT:Boolean=false;
var
  MinX, MinY: Integer;
  MaxX, MaxY: Integer;
  X,Y: Integer;
  PixelPtr,PixelPtr2: PInteger;
  PixelRowPtr,PixelRowPtr2: PInteger;
  BytePerPixel: Integer;
BW,bw2:Byte;
PRGB,PRGB2:^RGB1;
  begin
  try
    Bitmap.BeginUpdate(False);

    PixelRowPtr := PInteger(Bitmap.RawImage.Data);
    PixelRowPtr2 := PInteger(B.RawImage.Data);
    BytePerPixel := Bitmap.RawImage.Description.BitsPerPixel div 8;
    minX:= Bitmap.Width; MaxX:=0;
    minY:= Bitmap.Height; MaxY:=0;

    for Y := 0 to Bitmap.Height - 1 do begin
      PixelPtr := PixelRowPtr;
      PixelPtr2 := PixelRowPtr2;

      for X := 0 to Bitmap.Width - 1 do begin
       PRGB:=Pointer(PixelPtr); PRGB2:=Pointer(PixelPtr2);
        BW:=(PRGB^.R+PRGB^.G+PRGB^.B) div 3;
        BW2:=(PRGB2^.R+PRGB2^.G+PRGB2^.B) div 3;

      If    ( Abs( bw - bw2 ) <C ) then
                   begin
                     PRGB^.R:=0;
                     PRGB^.G:=0;
                     PRGB^.B:=0;
                   end ;

        Inc(PByte(PixelPtr), BytePerPixel);
        Inc(PByte(PixelPtr2), BytePerPixel);
      end;
      Inc(PByte(PixelRowPtr),Bitmap.RawImage.Description.BytesPerLine);
      Inc(PByte(PixelRowPtr2),Bitmap.RawImage.Description.BytesPerLine);

    end;
  finally
    Bitmap.EndUpdate(False);
  end;
end;


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

Добавлено спустя 1 час 26 минут 20 секунд:

А я тут смотрел скорости доступа к пикселям различными методами,сравнивал сканлайн и SetDiBits(на запись)...
Получились интересные результаты.
У сканлайна 92 такта на пиксель,это с учётом создания изображения Bitmap в памяти ~ 3.7 наносекунд /пиксель

ИМХО реально намерять 3.7 наносекунды можно только "статистическим способом" а это все-же всегда "температура по больнице" .

А у SetDiBits 10 тактов на байт, и в среднем 42 такта на пиксель при 32-битной цветности. Но только при полном помещении картинки в кеш процессора + размер инструкций.

А тут все упирается в оптимизацию и процессор (до видео и любой другой памяти ВинАПИ-шные функции доходят очень не быстро - у них задача работать максимально быстро никогда не стоит . )

В моём случае при кеше 64к размер картинки до 117х129 х32Bpp=60372 байта.Рисовал кстати сразу на экране примерно 35000 FPS получалось
при 509х240 х32Bpp 14000 FPS.
Средствами GDI 3700-4200 FPS тот же размер.
И получается для обработки изображения выгоднее вычитывать его в массив,либо работать напрямую с его памятью через свои функции.

Ч.Т.Д. (Что и требовалось доказать! )

Тогда неизбежно будут потери времени при конвертации в формат OpenCV ,у них если не ошибаюсь это массив Double.Или писать своё которое не факт что будет быстрее

BT_FAST.7z

По хорошему "конвертации в формат OpenCV" вообще не нужна! То есть как запустил OpenCV так и пользуешься только его форматами данных.
Это у меня все еще гибрид "бульдога с носорогом", но чисто, по причине того, что начинал я свой проект задолго, до того как начал разбираться с OpenCV ... Да что там OpenCV! Первый этап вообще был с канвасом и без Реал-Тайма.

(см тему Серия проектов "Дополнение к реальности ")

[IvoX]

"плывет" яркость ВСЕЙ картинки

Ну ,возможно камера баланс постраивает? или я код слишком быстро проглядел,и чего-то не заметил.

'cvPyrMeanShiftFilter' - очень ресурсоемкий метод "сегментации"

Я ещё надеюсь найти(или придумать) сносный по скорости "усреднитель цвета-бинаризатор" для цветных картинок.а вот сегментировать не думал как.
проблема общая наверно для них:больше пикселей берём в расчет -точнее сглаживание цветов если не менять исходное разрешение.
А если менять то теряется высокочастотная составляющая,ну и как вы сказали- на расстоянии это важно для мелких объектов.

0.jpg

Вот тут говорят что сравнивают частично форму
https://www.youtube.com/watch?v=_N41CP0f0Mg
Попробую покопать в этом направлении.
Оказывается раньше я буквы в своих тестовых программах сравнивал вычисляя почти "моменты Ху"(попроще конечно),а писал просто по наитию,прикинув на глазок что не будет изменяться при повороте и масштабировании,не зная что такое есть уже.

Добавлено спустя 3 минуты 43 секунды:

По хорошему "конвертации в формат OpenCV" вообще не нужна!

я так и не смотрел его...
Т.Е. подключаем библтотеку и она сама всё может? и получать изображения с камер,экрана файлов?
Тогда получается она преобразование в свой формат один фиг делает внутри себя.

Добавлено спустя 12 минут 32 секунды:

(см тему Серия проектов "Дополнение к реальности ")

Прочитал полностью,и бывает что-то перечитываю

Добавлено спустя 6 минут 6 секунд:

ИМХО реально намерять 3.7 наносекунды можно только "статистическим способом"

да,к сожалению предел 10 мегегерц таймера 100 нс но по крайней мере они честные и не прыгают как все остальные таймеры(очень надеюсь) по моим замерам небыло пропуска таймера ни разу за 3 часа

[Alex2013]

Вообще-то идеальная сегментация получается "автоматом" при составлении "карты глубины" . (Если использовать подвижную камеру или отслеживать объекты в движении то по идее можно обойтись одной камерой . ) Но это такая нагрузка на ЦПУ что у меня в программе при попытке строить что-то "отдаленно напоминающее КГ" интерфейс программы стопорился "в у смерть " (Пришлось прятать в отдельный поток чтобы вообще хоть что-от увидеть... и то получилось так сказать "слайд шоу с лектором" )

[IvoX]

идеальная сегментация получается "автоматом" при составлении "карты глубины"

Я пока ещё только с 2D пробую... может потом,дойду и до 3D, чувствую для меня оно будет непросто...
Пока не разобрался с SetWorldTransform даже, ввиду отсутствия у меня теоретических знаний.
Думаю работать с проекциями всё-же попроще, и при небольших искажениях 2D алгоритмы будут "узнавать" 3D объекты.
Ведь контур горшка останется контуром горшка,как его не крути(исключение верх и низ конечно) но тут возможно помогут полярные координаты(чувствую чушь несу,так как не уверен).
Но в привычном то окружении мы редко смотрим на горшок снизу...А вот с руками в 3D всё становится намного интересней.Нужно как то определять и саму руку ведь?правая-левая,и сторону ладони...ох ,а эти понятия неразрывно связаны.

Добавлено спустя 7 часов 43 минуты 28 секунд:
Вы наверное уже читали?
https://arxiv.org/ftp/arxiv/papers/2007/2007.09859.pdf
Использование Ху моментов для распознавания языка глухих.
Само собой в реальном времени.
Там даже предлагается некоторое улучшение,насчет пропорциональности жестов рук,так как Ху выдаёт одинаковые результаты при вращении руки в плоскости камеры.

Добавлено спустя 1 минуту 39 секунд:
Из недостатков сильная зависимость от освещения

[Alex2013]

я так и не смотрел его...
Т.Е. подключаем библтотеку и она сама всё может? и получать изображения с камер,экрана файлов?

Именно так! Даже рисовать можно (есть OpenCV аналог функций канваса, а если немного "помучатся дурью" то можно рисовать даже в 3D! Но разумеется без 3д-акселерации )

Тогда получается она преобразование в свой формат один фиг делает внутри себя.

Нет, суть в том, что вцелом "аппаратно-системный формат" совпадет с форматами данных любых библиотек , что в VCL(LCL)-канвасе, что в "Вынь API", что в OpenCV бинарный формат один и тот-же .

Что я делаю для преобразования ТBitmap(класс "картинка" в LCL) в IplImage (класс "картинка" в OpenCV )?
Тупо копирую данные через Move !

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

Move(b.RawImage.Data^,Frame.ImageData^, Frame.ImageSize);

(Разумеется, для подобного фокуса с копированием, нужно чтобы настройки "метрики" совпадали но это уже "не существенные детали" )
То есть "бинарные данные", почти всегда, теже самые, меняется только "обвязка" .

[IvoX]

Переписывал с реализации на java и видимо нужно нормализовать моменты но работает,даже по времени наверное не медленно

2020-10-13_115803.png

HUMOMENT.7z

Добавлено спустя 2 минуты 57 секунд:
с 24 битными конечно работает но желательно бинаризацию сделать...

Добавлено спустя 3 минуты 32 секунды:

То есть "бинарные данные" почти всегда теже самые меняется только "обвязка"

Вот те на, надо запомнить на будущее

[Alex2013]

Хм интересно ! Но не понятно ... (Сходу в код не вник. )

[IvoX]

Я читал про моменты,но нигде нет описания...
Вроде бы первый это площадь фигуры,и возможно инвариантная даже
Вот PDF на русском с тестами
https://drive.google.com/file/d/1JxZKF4 ... sp=sharing

[Alex2013]

Я пока ещё только с 2D пробую... может потом,дойду и до 3D, чувствую для меня оно будет непросто...

В "чистом виде" 3д сейчас почти не встречается, а "на уровне ОpenGL" все не так уж страшно .

[IvoX]

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

https://drive.google.com/file/d/1JxZKF4 ... sp=sharing

возьму только несколько моментов(1-4 наверное)меньше вычислений
,это повысит скорость обработки

[Alex2013]

Мечты мечты ! "Вот бы SLAM сделать ..." https://habr.com/ru/post/373707/
Карта глубины это все-же другое !

[IvoX]

Да кстати,самое дешевое сейчас решение это купить где нибудь Кинект на авито (1500-3000р).
С ним результаты распознавания всего- намного точнее хоть и 320*240 говорят разрешение,у первых Айфонов вообще FaceDetect на 0,3Мп сенсоре был сделан
ошибся 0,03Mp

[IvoX]

Что я делаю для преобразования ТBitmap(класс "картинка" в LCL) в IplImage (класс "картинка" в OpenCV )?
Тупо копирую данные через Move !

нашел кое что...

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


procedure MoveMMX(Src, Dest: Pointer; Size: UInt64); stdcall;
asm
  mov rsi, Src
  mov rdi, Dest
  mov rdx, Size

// Получаем количество 64х-байтных блоков:
  mov rax, rdx
  shr rax, 6 // Делим на 64
  test rax, rax
  jz @Block_64_Skip
  mov rcx, rax

@Block_64:
// Чтение:
  mov rbx, rsi
  movq mm0, qword [rbx]
  movq mm1, qword [rbx + 8]
  movq mm2, qword [rbx + 16]
  movq mm3, qword [rbx + 24]
  movq mm4, qword [rbx + 32]
  movq mm5, qword [rbx + 40]
  movq mm6, qword [rbx + 48]
  movq mm7, qword [rbx + 56]
......


FastestMove.7z