Новые кандидаты в планетные камеры - Basler, серия ACE.

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

Если вы снимали без роллинг-шаттера, то экспозиция врятли была более 1/300.

Правильно ли я Вас понимаю, что при выдержке больше 1/300сек, т.е. например, при 1/50сек я перехожу в режим роллинг шаттер? Честно коворя, я такого не видел.

На такой частоте кадров большая часть времени тратится на считывание.

На какой частоте? на 100к/сек?

Просто в камеру заложены шикарные возможности, и было бы неправильно использовать ее не разобравшись. Например, вы отказались бы от возможности увеличить чувствительность в 2-2,5 раза, заимев гипотетический эффект роллинг-шаттера, который будет незаметен на этой камере? Да и не воспользоваться аппаратным RoI при съемке планет было бы глупо...

Честно говоря, я не очень вижу, где идут потери. Сколько времени занимает считывание кадра по Вашей оценке?

ROI там есть, и использовать его по самым ярким объектам типа Венеры вполне можно.

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

Кстати, автор FireCapture сделал поддержку АСЕ в своей программе, и уже приводит первые результаты: http://forum.astronomie.de/phpapps/ubbthreads/ubbthreads.php/topics/726230/Re_Jupiter_mit_Basler_Ace
Он там пишет, что артефакт не обнаружен. Это радует.

[Serj]

Я имею на руках лишь примерное руководство пользователя, скаченное с сайта производителя, и там не все однозначно, поэтому и спрашиваю. На стр. 68 этого руководства есть пример расчета максимальной частоты кадров, при ограничевающем факторе - времени считывания. Формула выглядит так (на память):
Fmax=1/([число строк в кадре]*C1+C2)
где для нашей камеры C1=16.99us C2=1376.35us
Таким образом я делаю вывод, что при на считывание полного кадра уйдет 9769.41 мкс. Т.е. я погаречился на счет выдержки 1/300с, если следовать инструкции, получается что на 100к/с выдержка никак не может быть больше 230мкс! Если это так, то камера действительно уникальная по своей чувствительности.
Что, никому не интересно в циифирках поковыряться и со мной подискутировать?

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

...
Таким образом я делаю вывод, что при на считывание полного кадра уйдет 9769.41 мкс.

Согласен.

если следовать инструкции, получается что на 100к/с выдержка никак не может быть больше 230мкс! Если это так, то камера действительно уникальная по своей чувствительности.
Что, никому не интересно в циифирках поковыряться и со мной подискутировать?

Не согласен. Если реализован алгоритм считывания экспонированного кадра одновременно с экспонированием следующего (такая возможность есть в даташите), то при кадровой скорости 100к/сек можно иметь выдержку в 1/100сек, и при этом практически не будет потерь.

[Serj]

Так я же о том и толкую! Только еще не изобрели матрицу, способную экспонировать кадр целиком во время считывания предыдущего. Вместо этого экспонирование и считывание ведется построчно, это и называется роллинг-шаттер. В общем, после получения камер нужно будет выяснить все эти нюансы. Возможно результаты будут еще более впечатляющими чем у голландца с переделанной DMK.

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

Как и предполагалось, в FireCapture 1.1 введена поддержка Basler ACE.
http://firecapture.wonderplanets.de/

[kryptonik]

Сроки поставки не очень выдерживаются, похоже, придется подождать лишний месяц. Ажиотажный спрос.

[Алексей Юдин]

Эх... дюфсит!!! 

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

Сроки поставки не очень выдерживаются, похоже, придется подождать лишний месяц. Ажиотажный спрос.

У нашего заказа аналогично, ждём отгрузку производителем 19 августа.
Похоже, за камерами выстроилась большая очередь...

[Mihail Sedyh]

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

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

[Serj]

Возможно, но разве ICX618 черезстрочная? И каким образом реализован тот режим, о котором мы говорили выше?

[Mihail Sedyh]

Есть два термина: interlace и interline. Оба на русский обычно переводятся одинаково - черезстрочный,  но смысл совершенно разный и обусловлен контекстом. Первый относится к режимам считывания (развертки) и противопоставляется  прогрессивному. Второй описывает тип физической структуры матрицы, а именно, как распологаются служебные/траспортные ячейки относительно светочувствительных. По данному критерию различают еще, например, матрицы с кадровым переносом и некоторые другие типы.
Так что 618 - черезстрочная (вообще, физически правильнее было бы назвать черезстолбцовой) матрица с прогрессивным типом считывания.

[Serj]

А, догнал! Значит я был не прав на счет "не изобрели". Михаил, не могли бы вы прокомментировать физический смысл переменных C1 и C2 из руководства Basler? И всетаки, какой будет перерыв между экспонированием двух последовательных кадров в режиме буферизации?

[Mihail Sedyh]

Попробую описать работу матрицы.
Пусть есть ряд дли-и-и-нных столов (столбцы матрицы), на которых с некоторым интервалом стоят ящики (фоточувствительные ячейки). Вдоль каждого стола двигается транспортный конвейер (V-драйвер или вертикальный конвейер). Двигаются они рывками и полностью синхронно. Каждый рывок по длине соответствует интервалу между ящиками. В конце всех конвейеров и поперек них двигается еще один конвейер (Н-драйвер или горизонтальный конвейер). Он подхватывает все, что приехало на вертикальных конвейерах и отправляет, э-э-э-э, на последующую переработку. Этот конвейер двигается намного быстрее и успевает за время одного рывка вертикальных конвейеров сбросить все, что на нем было. Соотношение скоростей конвейеров жестко фиксировано (числено примерно равно количеству пикселей по горизонтали кадра, включая неэффективные, ну или обратной величине).
В ящики сверху падает...., ну скажем картошка (фотоны). Также есть некий механизм, который может ОДНОВРЕМЕННО и очень быстро скинуть содержимое ВСЕХ ящиков на ВСЕХ столах либо на соответствующие конвейеры (сигнал считывания), либо на пол (что упало, то пропало). Обращаю внимание: картошка сыплется непрерывно, конвейеры тоже двигаются непрерывно, единственное на что можно влиять - моменты сброса картошки и направление сброса (на конвейер/ на пол).
Вот такая модель получилась... Посмотрим как работает... В начальный момент на конвейерах ничего нет, в ящиках что-то есть. Сбрасываем все на вертикальные конвейеры (устал писать, далее ВК) : в ящиках пусто, на горизонтальном конвейере (далее ГК) пусто, на ВК - кучки картошки. В этот же момент ящики начинают снова наполняться (начало следующей экспозиции), т.к. картошка сыплется непрерывно. ВК продвигаются на одну позицию: на ГК попадают кучки картошки, которые лежали в ящиках, ближних к концам столов, ГК уносит их на переработку. ВК сдвигаются еще на шаг - на ГК попадает картошка из вторых ящиков (считывание второй строки) и т.д...... Когда вся картошка с конвейеров переработана (время считывания кадра), продолжаем ждать когда в ящиках накопится достаточно картошки (окончание экспозиции), конвейеры продолжают в это время работать вхолостую, и снова сбрасываем картошку на конвейеры.
Это вариант, когда экспозиция больше или равна времени считывания. Очевидно, что в этом режиме потери картошки стремяться к нулю. В Баслере такой режим реализован.
Но тут есть еще такой момент. Чем быстрее движутся конвейеры, тем больше страдает картошка. Кучки растрясаются, некоторые картофелины могут попасть в соседние кучки или совсем свалиться с конвейера (шум считывания), поэтому, если экспозиция много больше времени считывания, и периоды ожидания с холостой работой конвейеров велики, то было бы грамотно замедлить работу конвейеров для уменьшения шума (можно вспомнить характерное время считывания камер, заточенных под дипскай). Вот этот вариант не реализуется почти никогда из-за технической сложности. В том числе и в Баслере, т.е. время считывания кадра жестко фиксировано независимо от режимов и экспозиции и составляет чуть меньше 10мс.
Что делать, если нужна экспозиция меньшая времени считывания кадра? В этом случае, за заданное время до окончания считывания кадра вся картошка из ящиков вываливается на пол (конвейеры продолжают транспортировать предыдущий кадр) и при следующем считывании на конвейеры попадет только то, что успело накопиться за это заданное время.
Это принцип работы электронного затвора. Потери картошки при этом, очевидно соответствуют соотношению времени экспозиции и времени считывания кадра.

Это два основных режима работы матрицы. Если обсуждались еще какие-то режимы, то я не совсем уловил, какие именно.....   

[Mihail Sedyh]

Михаил, не могли бы вы прокомментировать физический смысл переменных C1 и C2 из руководства Basler?

С1 - очевидно время считывания одной строки (время между теми самыми "рывками" вертикальных конвейеров).
С2 - некая "постоянная времени", необходимая для считывания служебных сигналов (чтоб электроника поняла, где начало и конец кадра), считывание неэффективных пикселей и т.д.

И всетаки, какой будет перерыв между экспонированием двух последовательных кадров в режиме буферизации?

Что такое режим буфферизации? Если просто хранение в отдельной памяти кадра для оптимизации передачи данных в комп, то при достаточном быстродействии дисковой подсистемы времена никак не бедет отличаться от режима реального времени. А именно, при выдержках больших или равных времени считывания кадра, перерыв будет принебрежимо мал (скорее всего, та самая постоянная С2). Если работать на коротких выдержках, то добавиться еще разница между экспозицией и временем считывания.

[Serj]

Спасибо за развернутый ответ, Михаил! Получается, что C2 это время, необходимое на высыпание картошки из ящиков на ВК.  Только непонятным остается, для чего реализованы два режима "non-overlapped exposure and readout" и "overlapped...". Чем первый режим может быть лучше второго, раз он используется по-умолчанию?

[Mihail Sedyh]

Спасибо за развернутый ответ, Михаил! Получается, что C2 это время, необходимое на высыпание картошки из ящиков на ВК.

Нет. Вываливание картошки на ВК или очистка ячеек происходят очень быстро, время процесса порядка десятков наносекунд.
С2 - это совокупность некоторых подготовительных, завершающих и служебных операций электроники камеры, необходимых за номального считывания кадра, не хочется углубляться. По аналогии, это время на открытие и сохранение файла, а уж сразу мы его закроем или будем 2 часа редактировать - не важно.
В прикладном смысле  можно воспринимать эту константу, как абсолютный предел частоты кадров. Для данной камеры получается 1/С2 = 730к/с.

Только непонятным остается, для чего реализованы два режима "non-overlapped exposure and readout" и "overlapped...". Чем первый режим может быть лучше второго, раз он используется по-умолчанию?

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

[Mihail Sedyh]

Только непонятным остается, для чего реализованы два режима "non-overlapped exposure and readout" и "overlapped...". Чем первый режим может быть лучше второго, раз он используется по-умолчанию?

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

Неправильно сказал. Это относится к режимам Overtriggering для внешней синхронизации, короче очень частный случай.

В non-overlapped (без перекрытия) режиме следующая экспозиция может начаться только после полного считывания предыдущего кадра (вся картошка уехала на конвейерах, все, что накопилось в ящиках за это время выбрасываем на пол, ждем время экспозиции и только после этого снова загружаем конвейеры). При коротких выдержках потери фотонов могут достигать очень больших величин. При выдержке, равной времени считывания кадра (10мс) потери составят около 50% по сравнению с режимом overlapped (с перекрытием), где потерь почти нет.  Нам такой режим не очень интересен, но видимо, обработка сигнала в таком режиме намного проще. Есть масса програмируемых настроек всяких задержек, режимов внешней синхронизации и т.д., значения которых должны быть тщательно подобраны под конкретную задачу. А режим "без перекрытия" гарантирует отсутствие дропов кадров в любом случае, да и потери фотонов для неастрономических целей не так важны. Видимо поэтому его и выбрали умолчальным. 

[Mihail Sedyh]

По результатам дискуссии я что-то реально заморочился реализацией режима ROI (или в данном случае AOI) с обменом размера кадра на скорость....
Если обмена на скорость нет, то все функционирует в штатном режиме и кадр обрезается уже либо на выходе матрицы, либо вне ее. Это происходит однозначно с обрезанием горизонтального размера кадра, который на скорость не влияет. При таком раскладе мы получает только экономию места на диске ( ну и упрощение схемы камеры, понятно).
А вот если, скорость увеличивается, то возникают некоторые вопросы....
Заряды могут считываться только одним путем: ф\ч ячейка - ВК-ГК-выходной усилитель матрицы. По-другому - никак, причем 10 строка никогда и никак не сможет попасть на ГК, пока на него не попала 9-я строка (т.к. горизонтальный размер окна на скорость не влияет, буду говорить о строках). С одной стороны вышеупомянутая формула (с С1 и С2) подразумевает, что время на перемещение и считывание "неинтересных" строк равно 0. С другой стороны, исходя из физической структуры матрицы, это невозможно (собственно это меня и озадачило). Порыл немножко документы: подробно нигде не написано, но сложилось стойкое впечатление, что строки вне ROI просто прокручиваются на более высокой скорости. По величине это ускорение должно составлять по меньшей мере 2 порядка, чтобы примерно соответствовать "ширпотребовским" формулам. Если так ускорить всю схему, то частота ГК составит единицы гигагерц, что нереально, соответственно ускоряются только ВК. 
Т.е. если мы хотим считать средние 80 из 480 строк, то работа представляется следующим образом: поступает сигнал считывания и заряды попадают на ВК; ВК работают, скажем, в 500 раз быстрее обычного и первые 200 строк вываливаются на ГК; понятно, что нормально ГК переварить такое не в состоянии и все, что на него попало, каким-то образом утилизируется (сигналы ResetGate скорее всего); при подходе первой строки с полезной информацией ГК чист, а ВК замедляются до обычного состояния; далее 80 строк считываются точно также, как и в полнокадровом режиме; а далее либо (вариант А) последние 200 "неинтересных" строк утилизируются также, как и первые, либо (вариант Б) подается общий сигнал очистки матрицы (и ячейки и конвейеры). По варианту Б, я не совсем уверен, что сигналом SUB можно очистить и ВК, но если можно, то очевидно , что режим "с перекрытием - overlapped" в этом случае невозможен. Итого время считывания такого оконного кадра не превышает времени считывания 80+1 строки в полнокадровом режиме, чем можно пренебречь для упрощения формул.
Во-о-от... Такая реализация оконного режима на текущий момент мне представляется наиболее достоверной.

Наверное уже кто-то догадался, к чему я веду...  В процессе ускоренного считывания первых 200 строк 80 строк с полезной информацией перемещались по ВК со скоростью в 500 раз больше номинальной, что по идее должно привести к росту шумов считывания.

Напугал? Не все так страшно... эта повышенная скорость примерно равна скорости перемещения зарядов по ГК. Однако относительные доли шума, вносимые ВК и ГК я оценить затрудняюсь. Может шум усилится на 1%, а может на 50%, что уже не очень приятно.

Посему было бы неплохо провести эксперимент по считыванию, скажем, 50 первых и 50 последних строк и как-нибудь сравнить шумы. Если  будет заметная разница, то выгоднее прислонять окошко к началу кадра, чтобы весь полезный сигнал считывался на штатной скорости. Конечно, это относится не только к Баслеру, но и к любым камерам, где реализован режим ROI с увеличением частоты кадров.

ЗЫ Что-то тема все больше напоминает мой блог.....

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

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

Пока по существу могу сказать, что при переходе от режима 640х480 к 320х240 WDM-драйвер вырезает левый верхний угол картинки, а скоросто при этом возрастает до 200 с лишним к/сек. Все эти режимы я уже описывал в этой теме выше.

Что же касается твоих соображений по скорости считывания и шумам - будем проверять!