Камеры ZWO ASI

[ma][im]

У меня и нативные драйвера на винде стали выставлять тоже 0-100, так же как и ascom. kstars с indi 0-700 выставляют нормально

Странно что до меня никто китайцев не запарил))) я то всего второй раз камеру включаю, а народ по всему миру уже вроде много фоткал ими..
Да, и еще заметил что байеровскую кодировку не сохраняет максим в fit, надо протестить в SharpCap. Понятно что можно выбрать вручную RGGB в пиксе потом, но почему блин везде все такое сырое

[diant]

Я месяц пользуюсь, что пока заметил в сравнении с 1600:
- очень «грязная» на горячие пикселы матрица, без дизеринга никуда.

Очень интересно, хотя и сомнительно.
Если не сложно, выложите сюда дарки с 2600 й  и 1600 й сделанные при равной выдержке (скажем 60   сек), нулевом Гейне и равной температуре. Будет очень интересно сравнить характер хотов

[Sharkу]

Если не сложно, выложите сюда дарки с 2600 й  и 1600 й сделанные при равной выдержке (скажем 60   сек), нулевом Гейне и равной температуре.

В выходные сделаю.

[pakhom]

У меня и нативные драйвера на винде стали выставлять тоже 0-100, так же как и ascom. kstars с indi 0-700 выставляют нормально

Странно что до меня никто китайцев не запарил))) я то всего второй раз камеру включаю, а народ по всему миру уже вроде много фоткал ими..
Да, и еще заметил что байеровскую кодировку не сохраняет максим в fit, надо протестить в SharpCap. Понятно что можно выбрать вручную RGGB в пиксе потом, но почему блин везде все такое сырое

Я сам через kstars снимаю, а вот прикол с гейном заметил пару дней назад на винде. Хотел было спросить, но забил

[ma][im]

Я сам через kstars снимаю, а вот прикол с гейном заметил пару дней назад на винде

С китайцами общение оказалось сложнее чем с поддержкой максимDL. Сначала меня направили писать запрос через форму на сайте zwo, раздел software. Затем через сутки ленивый китаец из разработчиков написал мне следующее:
"Hi Maxim,
We limit the gain range to 0-100. When Gain=100, the readout noise will drop a lot but the dynamic range will still be in a high standard, but with the increase of gain, the readout noise will not drop significantly, but the dynamic range will drop dramatically, so we limit the gain to 100."
Решили просто ограничить возможности камеры за 2000 долларов (гейн до 100) потому что они так видят

Чтож, написал просьбу на мейл zwo повлиять на ленивых разработчиков и исправить одну циферку.. посмотрим что ответят.

[Eddy_Em]

А смысл выставлять gain больше 20-30? Там же шумы сплошные будут. Это разве что для автогида сойдет - отсек по порогу, сделал десяток эрозий, потом десяток дилатаций, нашел 4-связные области, отсек по порогу размеров - вуаля. Мы вот проверяли на Ц-1000 баслеровскую КМОПину на автогиде (через светоделительный кубик на камеру автогида ~10% света попадает, остальное уходит на оптоволокно). За 1с экспозиции на gain=36 (предельный для баслера) вытягивалась 12^m, 14^m были на пределе обнаружения глазом (но шумов уже столько, что фильтрация минимум с полсекунды будет занимать, т.к. морфологических операций уже не хватит, нужно либо медианой фильтровать будет, либо с лапгауссом сворачивать). Сомневаюсь, что gain в сотку спас бы ситуацию. Шумов было бы совсем уж много.

[Дмитрий Неверный]

Мне вот тоже интересно зачем на 2600 ставить гейн выше 100?
На 100 еще понятно там включается хитрый режим низкого шума чтения (интересно что у них там за магия такая)
А дальше какой смысл?

[leviathan]

На 100 еще понятно там включается хитрый режим низкого шума чтения (интересно что у них там за магия такая)

Никакой магии и хитрости, HCG Mode есть на всех CMOS.

[Дмитрий Неверный]

Никакой магии и хитрости, HCG Mode есть на всех CMOS.

Не на всех такая ступенька явная (183):

1600:

[ma][im]

А смысл выставлять gain больше 20-30? Там же шумы сплошные будут. Это разве что для автогида сойдет - отсек по порогу, сделал десяток эрозий, потом десяток дилатаций, нашел 4-связные области, отсек по порогу размеров - вуаля

Зачем же так примитивно - морфологией, можно и по шумной картинке искать центроид с использованием фурье

По теме 0-700:
Как минимум компоновать объект съемки в maximDL на высоком гейне при короткой выдержке. Так же я планирую использовать для лаки высокие значения усилений. Да и мало ли зачем это может понадобиться, вопрос зачем ограничивать функционал устройства? Тем более тут явно не ограничили, а просто кто-то не затестил нормально драйвер ascom. В нативном режиме все прекрасно регулируется 0-700. Сделали бы три пресета: 0 гейн, 100 гейн и 300 например и пользовательский выбор из всего возможного диапазона 0-700.
Ладно уж, не сделают звошники - сам напишу ascom драйвер

[diant]

А дальше какой смысл?

Дальше бы не было смысла, если бы шум чтения так и оставался на уровне 1,5е. Но он падает и дальше и иногда это решающий фактор.

[Eddy_Em]

искать центроид с использованием фурье

Фурье - очень затратная. Я кучу алгоритмов перебрал, пока для автогида выдумывал метод поиска центроидов. Самыми эффективными оказались обычные морфологические операции. А фон я считаю по перегибу на гистограмме (правда, в случае сильного шума получается фигня).

Что до возможностей камеры - а почему бы просто не распаковать SDK и не проверить самостоятельно, какие значения камера принимает? У вас, правда, не линукс, ну, тут уж каждый волен сам себя уродовать, как хочет…

[ma][im]

Фурье - очень затратная. Я кучу алгоритмов перебрал, пока для автогида выдумывал метод поиска центроидов. Самыми эффективными оказались обычные морфологические операции. А фон я считаю по перегибу на гистограмме (правда, в случае сильного шума получается фигня).

Смотря на чем считать - у меня слежение за МКС реалтайм 50фпс, можно и 100 Точность субпиксельная. SNR доходит до значений когда я глазом ее не вижу Усиление на камере 290мм и 462мс доходили до 300-400.

Что до возможностей камеры - а почему бы просто не распаковать SDK и не проверить самостоятельно, какие значения камера принимает? У вас, правда, не линукс, ну, тут уж каждый волен сам себя уродовать, как хочет…

Так в том то и дело, мне не хочется лишний раз тратить время на продукт которым просто хочется пользоваться и получать удовольствие. Камера нативно принимает 0-700 (в том же SharpCap под виндовс), в надстройке аском почем-то 0-100 они просто ограничили это на уровне аском драйвера.

[Eddy_Em]

Я уже настолько привык, что под любую камеру нужно свой софт писать, что как-то и не ожидаю увидеть вдруг нечто готовое…
У нас с коллегой первый критерий рассмотрения возможности покупки нового светоприемника — это существование SDK. И уж если SDK линуксовый есть, и он не 20-летней давности, можно рассматривать характеристики светоприемника.
Даже если бы производитель и нарисовал какую-нибудь утилиту командной строки для работы со своей камерой, нам бы она в 99% случаев наверняка не подошла (да хотя бы если захочется организовать нормальный сетевой интерфейс взаимодействия, чтобы не вызывать нечто командой system(), а все параметры контролировать непосредственно в сетевом демоне).

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

[ma][im]

Я уже настолько привык, что под любую камеру нужно свой софт писать

Согласен, я тоже написал свои грабберы для zwo планетных камер, у zwo самый приятный SDK из тех что я видел. Работал с basler-ом(неплохой SDK) и qhy - смерть с глюканатом

А для дипов хотелось просто пофоткать на готовый софт за рюмкой виски, так сказать немного отдохнуть от разработок и скоростных съемок)

[Дмитрий Неверный]

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

Когда 98% пользовательской базы сидит на виндах и разработчики сфокусированы на драйверах/поддержке винды это логичный выбор минимизации проблем  
Для науки и на долгосрок - согласен vendor lock плохо.

Относительно локалхост изначально да, только Win Com но пилят уже в сторону сетевого: https://ascom-standards.org/Developer/Alpaca.htm
Если надо линукс можно Indi/Indigo посмотреть. Хотя мне по сети гонять прям не понравилось. wifi дает значительные задержки из-за объема файлов.
С собственными утилитами для науки тоже вопрос. Bus factor в одного разработчика тоже не фонтан. Лучше поверх открытых протоколов деклать имхо.

[ma][im]

С собственными утилитами для науки тоже вопрос. Bus factor в одного разработчика тоже не фонтан. Лучше поверх открытых протоколов деклать имхо.

ASCOM очень медленный, никаких реалтаймов не будет. Если делать - только с использованием SDK камеры.
Хотя все зависит от задачи, если 1фпс устраивает для считывания всей матрицы то норм

[Дмитрий Неверный]

ASCOM очень медленный, никаких реалтаймов не будет. Если делать - только с использованием SDK камеры.
Хотя все зависит от задачи, если 1фпс устраивает для считывания всей матрицы то норм

Да очевидно что работа с SDK напрямую всегда быстрее чем через прослойку. Любую. И локально всегда быстрее чем по сети.
Я когда пользовался indi по wifi - гидировать еще можно было (1 фпс как раз и файлы мелкие) а вот скачивание 40 мегабайт полного файла с камеры занимало 3-5 секунд. Даже если вайфай современный (относительно) 300 мегабит - это 1 секунда задержки. А я малину так и не смог выше 190 разогнать.

[Eddy_Em]

Если надо линукс можно Indi/Indigo посмотреть.

Дикий отстой. Прежде всего - за XML!
Мы вот планируем понемногу модернизировать системы управления БТА и Ц-1000, так про INDI никто даже и не заикался - убожество же! Будет свой собственный протокол. Но с сериализацией, не так, как сейчас (сейчас БТА управляется бинарными командами, по сути, по сети гоняется бинарная структура, что дает проблемы на "нестандартных" архитектурах; я сам убил больше пары недель, пока переделал все с 32-битной на amd64; Ц-1000 вообще на XML-RPC, ужас-ужас!).
INDI популярна лишь у любителей, которым ничего автоматизировать не нужно, а хочется мышкой потыкать.

[Дмитрий Неверный]

Дикий отстой. Прежде всего - за XML!
Мы вот планируем понемногу модернизировать системы управления БТА и Ц-1000, так про INDI никто даже и не заикался - убожество же! Будет свой собственный протокол. Но с сериализацией, не так, как сейчас (сейчас БТА управляется бинарными командами, по сути, по сети гоняется бинарная структура, что дает проблемы на "нестандартных" архитектурах; я сам убил больше пары недель, пока переделал все с 32-битной на amd64; Ц-1000 вообще на XML-RPC, ужас-ужас!).
INDI популярна лишь у любителей, которым ничего автоматизировать не нужно, а хочется мышкой потыкать.

Жесткий оффтопик пошел наверное но:
Бинарный плохо. Текстовый плохо. Не угодишь Открытый плохо ибо для аматеров, надо напилить свой чтобы сурово было. XML-RPC не канает. Я думаю что JSON-RPC тоже наверное мимо (тоже текст), gRPC, или protobuf тоже будет плохо потому что пропиетарно?