DSLRobot v0.1.2

3.3. Известные особенности и проблемы

Дмитрий Пашко
29 июля 2008 года

 
<< На главную страницу
 

В этой части описаны разные особенности работы DSLRobot. Одна часть из них связана с моим несколько косоватым программированием: ну мало было времени на "честную" разработку. Другую — можно отнести на своеобразное видение проблемы инженерами Canon: то ли руки местами кривые были, то ли национальные японские особенности, кто теперь разберет. Я тут попытался выписать грабли, о которые сам лоб набил. Настоятельно рекомендую почитать, чтобы не биться по второму кругу.

  1. Все проверять. Во избежание накладок любой скрипт нужно проверять. По состоянию на сейчас Canon API работает примерно через раз. В спокойных условиях — еще более-менее. Но в условиях быстрой съемки все достаточно сильно нагружено, и вероятность ошибки довольно высока. Способ убедиться, что оно работает только один — многократная проверка. Увы, иначе никак.
  2. Альтернативные решения.

    Да, их есть. Лучшее, на мой взгляд — DSLR Remote Pro компании Breeze Systems.

    Она позволяет много чего, в том числе делать брекетинг на 15 ступеней от 1/3 до 2 стопов. Можно также задать серию таких мега-кадров и время их запуска.

    Что еще хорошо: лаконичный, но вполне удобный оконный интерфейс, возможность сохранения кадров на диск, модные фичи вроде Live View и т.д. По скорости съемки DSLR Remote Pro и DSLRobot похожи, и обе сильно медленнее съемки самой камерой. Тут, похоже, основной лимит — Canon API.

    В чем же преимужество DSLRobot? А вот в чем. Во-первых, DSLR Remote стоит денег — $95. В принципе, вполне адекватная цена за то чтобы не болеть головой. DSLRobot — бесплатен. Во-вторых, DSLRobot позволяет выстраивать более сложные последовательности экспозиций, или даже поиграть на ходу чем-нибудь вроде ISO. DSLR Remote Pro в этом смысле проще — гонит себе от самого длинного к самому короткому снимку.

    В общем, можно пользоваться тем, можно другим — кому что ближе.

  3. Ошибки по ходу съемки. Бывают и довольно часто. Бывают трех видов.

    Критичные — камера выдала сообщение об ошибке. Лечится только отключением всего, причем часто еще и с выниманием аккумулятора. Беда.

    Неприятные — API выдает сообщение об ошибке, но все снимает, хотя и с пропусками. Скорее всего камера сильно перегружена, нужно уменьшать темп съемки. Хотя и придури API тоже могут иметь место. Кстати, после таких ошибок камеры, работающие по т.н. legacy-протоколу, оказываются в состоянии Busy. Лечится выключение и включением, но в принципе скрипт отрабатывает.

    Пропуск кадра или настройки — так тоже бывает. Тоже, как правило, перегруз, но в мягкой форме. Обычно все равно приходится в скрипт ставить паузы, на них оно сходится.

  4. Какой протокол выбирать. Речь о выборе протокола взаимодействия камеры и компьютера. Есть родной протокол имени Canon (aka Legacy), есть универсальный PTP. Новые камеры идут, как правило, с поддержкой исключительно PTP, и он хороший. Старые камеры были только с Legacy, или с тем или другим в зависимости от настроек. Там где есть выбор, я бы рекомендовал Legacy, ибо от PTP там реализовано только подмножество функций. В таких случаях управлять камерой не получится. Но все обязательно нужно проверять.
  5. Неправильные параметры. Canon API устроено так, что сказать ему можно все что угодно. Т.е. приложение может попросить абсолютно любых настроек. Но на самом деле может быть установлено какое-то совсем другое. API скажет — OK, даже если Вы просите чего-то совсем несуразного вроде установки неверного значения диафрагмы (ну не поддерживает ее Ваш объектив!) или выдержки при заданном приоритете диафрагмы. Просто в этом случае будут подобраны какие-то другие значения, иногда внятные, иногда нет.

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

  6. Шаг шкалы: 1/3 или 1/2 стопа. В зависимости от этой неприметной настройки часть параметров может оказаться недоступной. Например, на 20D при шкале в 1/2 стопа нельзя выставить Tv=1/100 — вместо нее ставится Tv=1/90. С другой стороны, если в ответственный момент все рухнет, может оказаться, что лучше иметь шкалу в 1/2 стопа. Это даст сэкономить на переключениях при ручной съемке. Тут каждый выбирает для себя.
  7. Время на съемку кадра.

    Canon API так устроен, что команда на съемку кадра является асинхронной, т.е. после отправки команды, управление немедленно возвращается в программу независимо от состояния камеры и результата съемки. И это правильно. Но нет никакого сигнала о том, что кадр снят, и камера готова к новой съемке (при этом она еще может обрабатывать какие-то другие кадры или вести запись на карточку). Есть другой сигнал — о том, что начата запись картинки на карточку. Однако этот сигнал при большой загрузке может быть задержан или объединен с другим таким же сигналом. Соответственно, если хочется снимать быстро, то строго ждать этого сигнала нельзя, а надо действовать как-то еще.

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

    Собственно парамерты ShotTime и ShotMul нужны для построения оценки времени съемки. Время съемки оценивается примерно по такой формуле:

    Время съемки = Tv * ShotMul + ShotTime.

    ShotTime задается в миллисекундах, ShotMul — число с плавающей точкой. Значения параметров подбираются опытным путем.

    Для Canon 20D можно ориентироваться на следующие довольно разумные значения: ShotTime=450...600, ShotMul от 1 (при съемке без подавления шума на камере) до 2.2...2.5 при включенном подавлении шума (там еще и темновой кадр снимается!). При слишком низких (слишком оптимистичных) значениях парамеров, камера будет пропускать кадры. При высоких — вероятность пропусков будет минимальна, но возможны паузы в работе камеры (задержался сигнал). На мой взгляд истину нужно искать где-то посредине.

  8. Где взять значение BufSize.

    Без этого параметра не наломать дров тяжело. Canon API по совершенно невинным поводам начинает кидать сообщениями вроде Internal Error или Memory allocation error, а камера в конце концов зависает. И тем не менее в API параметр не выведен. Видимо в Canon предполагали, что другого способа управиться с камерой, кроме как последовательно снимать и загружать картинки, людям не потребуется. Но камера сама по себе работает не так! Вот и приходится просить пользователей ввести заветное число.

    Где это число взять. За всю Одессу не скажу, но на 20D и 40D его просто показывают в видоискателе на шкале внизу — 6 и 17 соответственно. Обратите внимание на крайнее правое число — вот оно и есть.

    И что-то мне подсказывает, что на других камерах должно быть что-то похожее. Вряд ли есть смысл перепридумывать вполне разумный интерфейс в этом месте. Если кто-то обнаружит, что на другой модели все это устроено по другому — сообщите, пожалуйста. Вдруг кому пригодится.

  9. О блокировании интерфейса.

    Попросили меня (вполне убедительно) не блокировать органы управления камеры при съемке. Что мог отпустил, но все &mdash не смог. Сейчас объясню почему.

    Во-первых, PTP-камеры (а это все новьё), блокируют свой интерфейс сразу по включению шнурка в порт компьютера. Так они устроены.

    Более старые камеры с Legacy-протоколом позволяют блокировать интерфейс когда удобно. Можно не блокировать вообще. Вот только одна беда — установка параметров камеры начинает в этом случае работать не то что через раз, а раза так c пятого-десятого. Может, конечно, я чего намудрил. Но включаешь блокировку управления — и все как миленькое ставится.

    После недолгих раздумий было решено сделать так: интефейс таки блокировать, но отпускать на время всех операций wait.

  10. Управление затвором камеры через COM-порт.

    Есть такая возможность: с помощью специального кабеля присоединиться к разъему удаленного спуска затвора камеры. Этим разъемом пользуются, например, штатные пульты удаленного управления камерой вроде Canon Timer Control TC-80N3 и ему подобных. Часть полезных операций с камерой, вроде съемки с предварительным подъемом зеркала, можно сделать только через этот интерфейс.

    Обратите внимание, при такой работе камера соединяется с компьютером двумя проводами: команды на спуск затвора идут через COM, а управление настроками — через USB/IEEE 1384.

    Как этом управлять с компьютера мне рассказал Павел Бахтинов, за что ему отдельное спасибо.

    Как я понял, дело обстоит примерно так. Камера подключается к компьютеру с помощью специального шнурка: на одной стороне COM-порт, на другой — разъем удаленного управления камерой. Чтобы произошло срабатывание затвора нужно выставить на COM-порт сигнал RTS, который через кабель передается на камеру и камера воспринимает его как нажатие кнопки спуска. После снятия сигнала камера считает, что кнопку отпустили. Тем самым производится съемка.

    Эта последовательность действий реализована в DSLRobot. Но есть одно "но". У меня нет шнурка, чтобы попробовать это в реальной жизни. Максимум, что удалось проверить — что COM-порт открыт, что порт устанавливается в состояние RTS_CONTROL_ENABLE, а потом (через заданное время) это состояние снимается (RTS_CONTROL_DISABLE). Это все вроде работает. Но вот это ли состояние надо было выставить и в том ли порядке — вопрос открытый.

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

 
<< На главную страницу
 


Copyright © 2008, Дмитрий Пашко <>.