Собственный софт для управления астрокамерой - сложно ли это?

[diant]

Кто сам пишет софт по управлению и захвату изображений с астрокамер (конкретно ZWO), растолкуйте в двух словах, это сложно? Для человека, который давно не брал в руки шашки не занимался программировнием и вообще не знает современных платформ, типа питонов и т.п. Я даже не знаю, куда ткнуться, чтобы что-то понять в этом деле и подсмотреть, как это делается. Поэтому ссылки для меня тоже полезны.

[user340]

diant, Еслиб мне полная власть над пикселями нужна была-бы (в том виде, в котором её производитель сенсора задумал) и полное понимание того, что происходит, я бы ещё на уровень ниже спустился (мимо ZWO, Touptek и прочих вендоров) и подумал бы о работе напрямую с сенсором.
И да, такая задача не будет простой прогулкой.

А если просто конкретной моделью камеры ZWO управлять и изображения с неё получать и что-то с ними делать, то наверное, даже-бы и не брался, т.к.:
1. Можно вендорлокнуться ненароком.
2. Да и просто время жалко на проприетарщину, которая через год-другой устареет, или будет изменена по велению левой пятки ZWO и прочих вендоров.

P.S. Сужу только со своей колокольни и конечно, могу ошибаться.

[6271912]

Все начинается с изучения SDK камеры, там есть все, что необходимо для управления камерой, весь прикладной софт работает через него.

[huch]

Все начинается с изучения SDK камеры, там есть все, что необходимо для управления камерой, весь прикладной софт работает через него.

Я б еще добавил, что тот SDK свободно раздается на сайте ZWO. Под все распространенные платформы и с примерами использования (примеры на C++)

[diant]

И да, такая задача не будет простой прогулкой.

Вот это меня беспокоит больше всего. Я надеялся весной посвятить этому пару недель, но теперь не уверен, что за это время я что-то простое сваяю.

1. Можно вендорлокнуться ненароком.

Не боюсь даже девайслокнуться.

2. Да и просто время жалко на проприетарщину, которая через год-другой устареет, или будет изменена по велению левой пятки ZWO и прочих вендоров.

Эта проприетарщина будет исключительно домашним веником или карманным гаечным ключом. Ее никто никогда не увидит, кроме разве что жены. За это можно не волноватья.

Все начинается с изучения SDK камеры, там есть все, что необходимо для управления камерой, весь прикладной софт работает через него.

Я б еще добавил, что тот SDK свободно раздается на сайте ZWO. Под все распространенные платформы и с примерами использования (примеры на C++)

Вот это для меня информация на вес золота. Значит, как я теперь понимаю, я должен пойти на сайт ЗВО и там искать этот самый СДК с примерами? С++ не боюсь, писал когда-то на нем чего-то, может быть и не раз. А какую платформу для этого С++ надо ставить? Наверное какую-то визуал-среду?

И еще вопрос знатокам железа.
Я хочу в своей программе подключаться к камере, выставлять ее настройки и стартовать съемку ливстеком, но без всякого выравнивания и отбора, потому что сниматься будут неподвижные люминесцирующие (фосфоресцирующие) объекты. По задумке программа должна перед каждым кадром подавать сигнал на мощную импульсную лампу-осветитель (десятки нс импульс и гарантированное гашение хвоста за десятки-сотни нс), после чего тут же подавать команду на открытие электронного затвора (начало съемки) глобал-шаттер камеры. И так в каждом цикле, то есть на каждом кадре. Ливстек позволит поднять snr, если люминесценция слабая или быстро затухает. Так вот вопрос - в софте я наверное смогу реализовать работу по таймеру с точностью до мкс, может быть даже точнее и выдавать команду на импульсную лампу и съемку с достаточно малым интервалом (м.б. даже нс). Но! Есть ведь еще ОС и железо. Пока эти команды пройдут в соответствующие USB порты и будут выставлены как реальные сигналы на USB шине, время может сильно измениться. Как с этим быть? Насколько Винда позволяет софту точно по времени работать с шинами USB портов? При этом мне не важен параллельный сдвиг по времени, но важно, чтобы не началось временное рассогласование команд на лампу и на камеру. Например я пошлю сигнал зажигания лампы на 1 мкс раньше сигнала открытия затвора, а в реальности он придет позже - такое в Винде тоже может быть?

[huch]

Я надеялся весной посвятить этому пару недель, но теперь не уверен, что за это время я что-то простое сваяю.

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

[huch]

. А какую платформу для этого С++ надо ставить? Наверное какую-то визуал-среду?

мне хватило самого примитивного текстового редактора и компилятора gcc (g++ если точнее).

[6271912]

SDK не обрабатывает изображение, он скорее "принеси  и подай" с задаными параметрами, его задача отдать вам сырой кадр, а что вы будете делать с ним и как, это ваши проблемы.

[huch]

я должен пойти на сайт ЗВО и там искать этот самый СДК с примерами?

текущая версия SDK лежит тут.
https://dl.zwoastro.com/software?app=DeveloperCameraSdk&platform=windows86&region=Overseas
Но лучше поищите на сайте. версии обновляются часто

[huch]

SDK не обрабатывает изображение, он скорее "принеси  и подай" с задаными параметрами, его задача отдать вам сырой кадр, а что вы будете делать с ним и как, это ваши проблемы.

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

[huch]

Например я пошлю сигнал зажигания лампы на 1 мкс раньше сигнала открытия затвора, а в реальности он придет позже - такое в Винде тоже может быть?

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

[diant]

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

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

Сколько там по времени кадр считывается, меня не волнует совсем. Пусть даже 1 сек. Я ведь должен его стартовать через фиксированный малый интервал после импульса лампы подсветки, а когда он закончится и считается - это уж как получится. Мне нужно управлять только зажиганием импульсной вспышки и стартом экспозиции на камере, и делать это с фиксированной временной задержкой. Как быть с этим? Если винда не про это, моя затея в корне порочна и все можно на этом похоронить.
Вот на STM411 я могу управлять портами с той точностью, с какой хочу, это я уже умею. Точность и согласованность до 10нс гарантированно. Но! С STM411 я не могу управлять стартом камеры без внешнего триггера (а камеры ZWO все такие). Какой-то заколдованный круг получается...

Может быть в Винде достижима хотя бы согласованность между выводом на два ЮСБ порта? Пусть управляющие сигналы задержатся ОС или железом на 1мс, или даже 100мс, не важно, но выйдут согласованно - так, что интервал между сигналами не исказится. Или как раз это тоже реализовать в Винде невозможно?

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

[huch]

винда это не операционная система реального времени. и никогда ей не была. и никогда перед ней такие задачи не ставились.
вот вы поставили в программе микросекундную задержку. померили ее исполнение осциллографом. и 100 раз у вас эта задержка уложилась в требуемые рамки. а на 101 раз эта ваша микросекунда пришлась на обращение к диску, который заблокировал ядро процессора на время ожидания шины. и ваша программа поехала на исполнение на другое процессорное ядро. и вам осциллограф показал не 1 микросекунду, а 100. или в браузере рекламный блок решил обновиться или еще что-то произошло. вы никогда не получите гарантированной микросекунды.
все что вы можете это провести 100 экспериментов, в каждом измеряя фактические импульсы на usb и отбрасывая кадры, в которых сигналы выходят за допустимые границы. а еще я бы посомневался, что полученные кадры с правильными задержками можно усреднять. ибо камера от первого кадра к 100 нагреется. исследуемый образец будет в это время иметь разную длительность послесвечения из-за сквозняка из приоткрытого окна. и еще по десятку причин.   
ЗЫ. и таки да. камера вам тоже не даст гарантии, что с момента прихода команды на считывание матрицы до начала реального считывания пройдет какое-то строго фиксированное время. и что разница по времени между считыванием условно первой строки кадра и условно последней строки будет постоянной.

[diant]

Понял, ситуация патовая. Хотя камера будет с глобальным завтором и стабилизирована пельте холодильником. Сквозняки? - Да я им голову оторву! Так что некоторые "но" отпадают. А вот винда все портит. Ну тогда даже не знаю, как эту задачу решить простым путем....

[huch]

А вот винда все портит.

а вы попробуйте уйти от винды. взять самый тупой одноплатник. типа orange pi zero. на нормальную ОСРВ вы драйверов для камеры не найдете конечно, но на  линухе вы камеру на этом одноплатнике заведете. никаких лишних устройств - usb, ethernet (не wifi) и gpio. да, он будет медленнее. но зато гораздо предсказуемее. впрочем микросекунду все равно тяжело будет обеспечить. да и ливстек вряд ли пролезет в эти ограничения.

или поставить тот же линух на x86-64. поотключать в ядре все лишние устройства, не ставить графический интерфейс, отключить лишние сервисы, запретить свап и кеш...

[diant]

Понял, спасибо. Задача оказалась не столь проста, как я думал.

[huch]

Понял, спасибо. Задача оказалась не столь проста, как я думал.

А вы не пробовали порешать обратную задачу? Не обеспечивать задержки между событиями, а измерять их? Записываете видеоролик с фиксированной выдержкой, на каждый кадр ставите временную метку, в произвольный момент включаете вспышку, от засвеченного кадра начинаете измерять уровни послесвечения...

[Дмитрий Маколкин]

Спасет аппаратное решение - промышленная камера с внешним запуском (через отдельный контакт) экспонирования кадра.
Basler, Point Grey, первое что вспомнилось...

[diant]

Спасет аппаратное решение - промышленная камера с внешним запуском (через отдельный контакт) экспонирования кадра.
Basler, Point Grey, первое что вспомнилось...

Дима, я тебе в телеге ответил, спасибо.

А вы не пробовали порешать обратную задачу? Не обеспечивать задержки между событиями, а измерять их? Записываете видеоролик с фиксированной выдержкой, на каждый кадр ставите временную метку, в произвольный момент включаете вспышку, от засвеченного кадра начинаете измерять уровни послесвечения...

Не понял? У нас разве FPS камер измеряется МГц? Пока еще реальность - около 100FPS, то есть если N-й кадр, допустим, засвечен, тогда N+1-й уже идет со сдвигом по времени на 10мс от начала засвеченного - для многих субстанций это вечность в мире люминесценции. Средняя задержка тут будет 5мс (в зависимости от того, куда придется вспышка на засвеченном кадре).

[huch]

Да, я ошибся. Я привык к экспозициям 30-40 секунд.