[proxy3d]

luckylamer (03 Декабрь 2013 - 17:58) писал:

по идее таки да поляризованный нужен. не поляризованный так и так от поляризатора отразится. но это уже не суть важно поскольку яркость исходного изображения должна быть в N раз выше отражаемого.

я не совсем понял. Мне нужно использовать поляризованный свет, и показать
1) яркость света пропущенного матрицей, когда матрица выключена
2) яркость света пропущенного матрицей, когда матрица включена
3) яркость света отраженного матрицей, когда матрица выключена
4) яркость света отраженного матрицей, когда матрица включена

я правильно понял?

[luckylamer]

если интересна идея то да.

[proxy3d]

luckylamer (03 Декабрь 2013 - 18:33) писал:

если интересна идея то да.

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

[luckylamer]

https://www.spaceglasses.com/

[proxy3d]

luckylamer (19 Декабрь 2013 - 13:29) писал:

https://www.spaceglasses.com/

видел .. реклама нормальная.. но само устройство не впечатлило.. SDK ни какой.. большие.. то ли на базе Moverio сделаны то ли LUMUS.

Опыт так и не провел еще, занимался оптимизацией вывода. Добавлял аппаратную поддержку для самого вывода.
1) Open GL ES - Linux, Android, Win, Mac, IOS... на WinCe как японрял она софтварная
2) DirectShow - WinCe, Win
от DirectShow использую только вывод в видео-буфер, так как там можно получить доступ в видео буферу напрямую, безо всяких танцев с буном, пока отлаживаю. Так как нужно сразу получить аппаратную поддержку и в WinPhone последней

Так же оптимизировал передачу видео... сейчас на 500 Мгц.. получение кадров доходит до 24.. на вывод идут только 10 FPS, больше не справляется система. Вывожу практически в видео буфер но через библиотеку посредника GD.. но она имеет ограничение на размер области экрана. Поэтому сейчас отлаживаю DirectShow, чтобы нормально выводить напрямую. Тогда FPS дойдет на SoftWare до 15, я полагаю.
Под линуксом думаю будет больше но не намного.. максимум наверное получить прирост 2-3 FPS.

Далее на других платах буду тестировать с аппаратной поддержкой вывода OpenGL ES.
Следом при подключении API GStreamer , поулчить аппаратную поддержку на кодирование и декодирование.

Видео всего этого пока не снимал, не фоткал.. так как нужно посмотреть скорость при использовании видео буфера.
Так же попробовал разные варианты сжатия.. от тупого в лоб BMP кадры.. до сжатых BMP, вейвлетовое, .. сейчас исправляю PNG(по сути BMP упакованный в ZIP). В лоб BMP... это вообще Ж.. полная оказалась...
Пробовал так же передавать изображение с экрана ноута и выводить.. нормальная скорость только при 50% сжатии изображения... ри Jpeg кодировани.
Сейчас исправлю DirectShow и тогда смогу использовать аналог MPEG, когда кодируются только движущиеся части изображения.
Так же еще не оптимизировал место .. где происходит восстановление оазнцы между кадрами.. поэтому не могу этим воспользоваться.. тут нужно на уровне ASM наверное выполнять операции... буду смотреть ASM под ARM, желательно с ускорениями какими нибудь.

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

Насчет ссылки на те очки.. может тоже начать запускать сайт)) и пиариться

[luckylamer]

очень похоже на люмусовский OD32 тех характеристики те же да и внешне похоже. но минус тот же что и у моверио - шнурок, хотя Core i5 заставляет задуматься. но цена в 2985$ это что то запредельное

[proxy3d]

luckylamer (20 Декабрь 2013 - 17:27) писал:

очень похоже на люмусовский OD32 тех характеристики те же да и внешне похоже. но минус тот же что и у моверио - шнурок, хотя Core i5 заставляет задуматься. но цена в 2985$ это что то запредельное

Они больше позиционируются как видео очки для чего то. но не для ношения. Мне так кажется.. сел, подключил, посмотрел фильм.
Более того, самым оптимальным является передача видео по вафле, а звука по блютузу... так как это проже всего реализовать аппаратно (по сути как обычная гарнитура), универальсная передача звука под любой гаджет.. достаточно к разъему наушникво подклчить.. в своем можно просто сделать разделение разъема... один на выход, другой на передачу по блютузу. По сут аппаратная реализация.
Вторй плюс в том, что можно задействовать второе ухо, либо оба уха... при этом не соединяя их. Либо у каждого уха своя батарея, либо (что более выгодно).. с одной сторны палат для видео.. с другой блютуз плата со своей батареей.. Универсальность, дольше времени работы, лучше весовой баланс.. так как вес с обоих сторон проще скомпенсировать.

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

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

[Riki]

Всем Салам! я новичек тут. не пенайте если что не туда пишу. я не магу найти френель, у меня есть идея без френеля зделат проектор, как вам такая идея поставить отражатель от ВАЗ 07 или от камаза и поставить 100w ОСРАМСКИ лапочку.как знаете вар от машины тоже хорошо светит и 50W. или кто то пробавал такое.

[luckylamer]

можно только отражатель размером в тазик будет

[proxy3d]

Пробовал эксперимент с матрицей. Результат ни какой. Его даже можно упростить: просто пропускать поляризованный свет через матрицу.
Берем источник свет: лазер + поляризованная пленка или светодиодная панель + поляризованная пленка
TFT матрица.

Светим на матрицу когда она выключен: 0-градусов пропускает этот свет, при развороте поляризованной пленки на 90-не пропускает этот свет.
Светим на матрицу когда она выключена: аналогично как при выключенной. Разница лишь в том, что в тех местах где у экрана картинка - свет проходит лучше.. и она видна. А так - углы не инвертировались(то есть так и осталось 0-градусов пропускает этот свет, при развороте поляризованной пленки на 90-не пропускает).

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

Сообщение отредактировал proxy3d: 21 Декабрь 2013 - 13:13

[proxy3d]

Вот эти очки что вы упоминали, в реальности...


явно не для повседневной носки. И хорошо видно, что в них LUMUS.
Цена 3000$ конечно смешит немного.
Потех характеристикам:
1.5GHz Core i5 computer
128GB storage
4GB RAM
Bluetooth 4.0
802.11n Wi-Fi capability

но как я понимаю проц в отдельно гаджете.
http://www.augmented...e-for-3000.html
Управление с помощью движения руками.. по мне это бред. Как доп. управление - ок.. но как основное бред.
Область просмотра видео составляет 15 раз больше, чем Google Glass (The video viewing area is 15 times that of Google Glass.)
у гугла она была 16 или 20 градусов... а тут 200 градусов?)))))))))) посмеялся)

Разобрался на тестах с DirectShow, осталось перенести в сам движок. Для разрешения 800x480 на 500Мгц, выходит 11мсек на кадр для 800x480 и 3мсек для 320x240. Выходт что на 25 кадров нужно где то 260 мсек. Декодирование немного, но сколько по времни нужно посмотреть снова в тесте (но декодировал я не аппаратно).
Правда нужно помнить еще про передачу данных. Чем меньше объем, тем меньше время на принятие и тем больше скорость вывода (то тем хуже качество). Ни чем не сжатые изображения - просто ставили систему в ступор (даже 10 кадров в сек для 320 на 200 получалось несколько мегабайт).
Так как все это cross-plаatform, интересно будет посмотреть на все это в Linux и android и ios.

Далее будет проще. Просто тестирование на других платах. Ни чего нового писать не придется. Сначала на 800 Мгц затем на 1000Мгц.

НО перед этим добавлю аппаратное декодирование и кодирование через Gstreamer на базе платы Virt2Real (виртурилки). У них просто уже лежит готова прошивка с аппаратной поддержкой и плату я уже купил.
Далее тест на китайском свистке.
http://dx.com/ru/p/n...a-silver-182786
Там Rockchip RK3066 252MHz ~ 1608MHz, поддержка OpenGL ES (Mali-400). Камера в нем есть. Пока даже не включал его, лежит в коробке.
ПО идеи у него тоже должна быть аппаратная поддержка кодирования и декодирования.

Ну и самое вкусное в конце, GUMSTIX и Torpedo... так как они на базе процессоров TI, то по идеи gstreamer с аппаратной поддержкой от виртурилки должен подойти и для них.
После этого "хеппи енд" программной части.
Сейчас планирую взять, N8971 MTK6589 четырех-ядерный процессор Android нонейм...
https://dx.com/p/n89...ps-white-225635
Чтобы попробовать использовать его как миниPC (передавать видео рабочего стола на видео очки).
Из ОС хотелось бы конечно не андроид, а Ubuntu. ЧТобы позиционировать как PC с возможностью телеФона, а не как телеФон в роли PC.

Так же присмотрел умные часы, для управления у TI. Но есть минус.. экран не цветной, и проц. слабый.
С китайские все на базе ОС MTK, и исходники ее под свое устройство не дают. ТО есть нельзя ничего изменить. Только дизайн устройства.
Если только откинуть идею встроить в часы камеру, а использовать их только как мышку.
Хотя думаю пока использовать в качестве платы для часов - виртурилку. Она как раз отлично для этого подход (кроме размера). А там уже будет требования для аналогичной платы. Тем более что они сейчас делаю виртурилку-нано.
Я пока ставлю только 1-2 датчика для чтения ЭЭГ (чтобы они вообще не были видны)... поэтому глаза отслеживать в этой версии видео очков не буду... только эмоции (мимику лица) и состояние активности мозга (внимание, напряжение, расслабленность, сосредоточенность).

Сообщение отредактировал proxy3d: 23 Декабрь 2013 - 03:09

[luckylamer]

"Область просмотра видео составляет 15 раз больше, чем Google Glass (The video viewing area is 15 times that of Google Glass.)"
по общей площади. весь вопрос что такого можно на них показать что бы трех килобаксов не жалко было.

[proxy3d]

luckylamer (23 Декабрь 2013 - 17:45) писал:

"Область просмотра видео составляет 15 раз больше, чем Google Glass (The video viewing area is 15 times that of Google Glass.)"
по общей площади. весь вопрос что такого можно на них показать что бы трех килобаксов не жалко было.

думаю ничего. так как уж лучше моверио. Думаю львиную долю тут играет стоимость LUMUS... наверняка евреи (а LUMUS израильская разработка) запросили за свое ноу-хау прилично денег.
Сегодня буду из тестов переносить DirecShow в рабочую версию. Посмотрим какой прирос даст отрисовка. И заодно будет доступен режим передачи передачи только изменений изображения ( до этого нельзя было, так как мог в видео отрисовывать только определенную область быстро.. из за ограничений библиотеки GD)

[luckylamer]

виндоус это тупик.

[proxy3d]

luckylamer (24 Декабрь 2013 - 18:31) писал:

виндоус это тупик.

тут дело не в винде. Дело в том что код компилируется под разные ОС. Разница в модулях камеры, звука, вывода. И любые грабли вызывают тормозят под любой ОС.
Например я добавил дирекХ и к своему удивлению обнаружил что на тестах вместо 3мсек для 320x240.... выдается 64мсек для 320x240. Перерыл все, дла замеры.. выснл что так как экран 16 битный, а изображение 24 битное.. то прямой вывод создает сильные тормоза на уровне АPI конвертировании 24 в 16 во время вывода.
Поэтому сейчас изменяю этот участок кода, чтобы на экран выводилось то изображение которое соответствует текущим параметрам экрана.
Это еще пару дней отладки, так как это отражается и на выводе через OpebGL. Поэтому отладка под винсе, это не столь отладка под виндой, сколько наиболее простой поиск ошибок. Кроме того, Windows Phone 8 от Microsoft занимает свою нишу, и его нельзя игнорировать. А DirectX в нем такой же как и в WinCe.
Так же хотелось повториться, что под Linux это все компилируется. Под андроид нужно немного адаптировать, под MаcOS и IOS пока не смотрел.

кстати вот еще одни


их сборы
http://www.indiegogo...ave-superpowers

Сегодня ездил насчет мениск... нужно было некоторые уточнения. С удивлением обнаружил, что мениски мне вытачиваются из пластиковых линз. Хотя может это и к лучшему. Заодно отвез им стеклянный мениск с напылением, чтобы они сказали смогут ли вырезать из него и за сколько. Теперь жду звонка от них...

Сообщение отредактировал proxy3d: 25 Декабрь 2013 - 00:10

[luckylamer]

что то на какой то японский патент смахивает. 65 градусов хорошо, только интересно чем они дисторсию лечат.

[proxy3d]

Доделал вывод с DirectX в винсе.. FPS где то в среднем 10 FPS на UDP (до этого на UDP было 4-5 FPS) на TCP еще не смотрел (должно быть в 1,5 раза больше из за того что там один поток на принятие данных, а ни несколько - до этого как раз на TCP было где то 10 FPS). Но все это в режиме целого кадра - по сути MJPEG. Правда нужно кое что еще поправить.. и посмотреть почему вывод кадра целиком выдает больше FPS, чем вывод только изменившихся областей (правда я смотрел в UDP сегодня буду смотреть в TCP - на UDP возможны потери кадров, что снижает кол-во FPS).
Затем очень хочется постараться оптимизировать участок который восстанавливает кадр по разнице изображений... из кадра в котором передается разница изменений, а то там тормоза ужасные.
Потом буду пробовать передавать одновременно и видео и звук. Ночью баловался пробовал передавать картинку с происходящего на экране... запускал видео на ютубе... ну в среднем 10-11 FPS.. при сжатии 50%.
Вот интересно.. чем то можно замерить максимальную пропускную способность канала связи между устройством и компом... посмотреть.. может из за того что все передается через роутер.. и при этом ноут запускает видео с ютуба по вайфаю в нормальном качестве + антивриусник... это нагружает сетку. Нужно попробовать слать на прямую.
Так же доделаю кодирование кадра в формате PNG, так как он более легковесный, чем JPEG в плане декодирования... и для рабочего стола качество лучше... насчет размера.. то в некоторых случаях он веси меньше... если картинка имеет много монотонных цветов (например окна в винде). Хотя реальный результат узнаю только, когда доделаю.

Сообщение отредактировал proxy3d: 26 Декабрь 2013 - 14:54

[proxy3d]

Хотя больше сейчас жду мениски.. так как хочется протестировать все.
ПО скорей бы уже все отладить и попробовать в линуксах. В скоростной андроид как то слабо вериться.

Сообщение отредактировал proxy3d: 26 Декабрь 2013 - 13:12

[proxy3d]

Сделал простую тестовую программу, чтобы посмотреть скорость передачи данных. Вышло что по TCP скорость менее 100 килобайт в секунду. По UDP 100 кб в сек. Удивился.. полез смотреть документация по модулю WiFi на плате. Должно быть до 1 Мегайбайт. Начал выяснять причину... в принципе она достаточно очевидная - это размер пакета.
Максимальный размер пакета для UDP - 8 килобайт - скорость 200 килобайт в секунду, для 4 килобайт - 100 килобайт в сек.
Максимальная скорость для UDP - тут больше зависит от устройства. Но выставив 20 килобайт (4096*5). локально получил 26 Мегабайт в сек.
Между устройствами конечно такой скорости не будет, максимум 1 Мегабайт.. но причина скорости передачи в этом.
Сейчас делаю так, чтобы эти настройки можно было менять. Это должно отразиться на FPS.

Ну и пока смотрю как же можно оптимизировать функцию слияния разницу между двумя кадрами.

Сообщение отредактировал proxy3d: 27 Декабрь 2013 - 15:18

[proxy3d]

Сделал возможность изменения Buffer для передачи данных. Скорость повышается, но при этом появляется отставание видео.
Для UDP - Buffer:
Для 4096 байт - отставание не замечал, но маленькая пропускная способность. 100 кб в секунду, но с учетом других операций кроме приема данных выливается в 50--70 кб в секунду. Отставаний видео нет.
Для 8192 байт - есть небольшое отставание, но пропускная способность выше. 200 кб в секунду, в реальности остается 100-110 кб. в секунду на видео.
Больше для UDP буфер увеличивать нельзя, Windows не разрешает (на Linux не знаю, есть такие ограничения или нет).

В случае UDP, если нельзя использовать отставания, то нужно уменьшать объем передаваемых видео данных. Либо жертвовать отставанием видео, но тоже быстро достигается предел.

Теперь об уменьшении объема данных.
Передавал видео с экрана, запустил кино в плеере.
1) При передаче кадра целиком, где то 6-8 кадров. Доходит до 10 FPS. При передачи видео с веб камеры - 10 FPS
2) При передаче только изменившихся областей в кадре, где то 8-12 кадров. Доходит до 16 FPS. При передачи видео с веб камеры - 10-12 FPS. Про камеры: делал ночью.. поэтому из-за бликов, кадр практически всегда меняется полностью (нужно настраивать отсечение этих бликов). Авто режим пока не придумал.
3) При добавлении к п. 2, режима - передача разницы между кадрами:
3.1) Кадр целиком -> разница между кадрами. То есть передается один исходный.. а следующий передается как разница кадров. FPS вырос на 1-2, объем данных уменьшился.
3.2) Кадр целиком -> разница между кадрами -> разница между кадрами. FPS стал падать. Объем данных уменьшился.
3.3) Кадр целиком -> разница между кадрами -> разница между кадрами -> разница между кадрами -> разница между кадрами и так 10 раз. FPS упал до 6-8. Максимум 10 FPS, но редко. При том объем данных сократился на 50%-70% (в худшем случае 25%) по сравнению с п.2.
Причина падения видео для пункта 3 простая. По UDP пакеты могут теряться, что приводит к потери промежуточного кадра. Например если передается цепочка из 10 кадров.. и 4-ый кадр потерялся, то последующие 6-ть кадров будут проигнорированы, так как не из чего их будет восстанавливать.
Если на экране практически ни чего не изменилось, то FPS вырастает и до 20.

Для TCP буду смотреть сегодня.
Там проблемы, которая возникает в пункте 3, быть не должно. Так же там нет таких ограничений на TCP - Buffer. Для TCP - Buffer на тестах мне удалось получить максимальную скорость 620 килобайт в секунду, но какие при этом будут задержки у видео я не представляю.

Сообщение отредактировал proxy3d: 28 Декабрь 2013 - 19:24