Покупатель современной цифровой фотокамеры в комплекте со своим агрегатом получает, как правило, некий джентльменский набор программ — вьювер графических изображений, более или менее продвинутый редактор растровой графики и так далее, — как правило, достаточный для любительского применения. Однако вот беда — все эти программы работают под управлением совершенно определенной операционной системы — и несложно догадаться, что системой этой оказывается Windows. Хотя кое-какие камеры (преимущественно вышесреднего ценового диапазона) комплектуются и софтом для MacOS — но вот программ для свободных операционок POSIX-семейства мы к коробке не увидим наверняка. Так что же — пользователи Linux или BSD будут лишены доступа к достижениям современной цифро-фотографической мысли?
Отнюдь — ответим мы со всей определенностью. Ибо один из принципов сообщества Open Sources — «Дело спасения утопающих — дело рук самих утопающих». И если производители «железа» не проявляют склонности к заботе о свободолюбивых пользователях — они позаботятся о себе сами. А как они это делают — мы постараемся продемонстрировать в этой статье.
В качестве объекта для упражнений была выбрана довольно редкая пока операционка POSIX-семейства — DragonFlyBSD (сведения о ней в англоязычном исполнении можно найти на сайте проекта, а по-русски — здесь). Почему такая экзотика? Во-первых, как сказал бы товарищ Сталин, другой ОС у нас под рукой не было. А во-вторых, мы пытались показать, что даже в столь молодой и мало распространенной ОС, если разобраться, ни малейших сложностей при работе с цифровыми фотоматериалами не возникает. Так что не следует ожидать их и во FreeBSD и тем более в любом user-ориентированном дистрибутиве Linux. А вообще особенности, специфичные для каждой ОС, будут при необходимости по ходу дела отмечаться отдельно.
И еще одно предварительное замечание. Все программы, упомянутые в этой статье, принадлежат к числу свободных (Free Software — что не следует путать с понятием FreeWare), распространяемых на условиях лицензии GNU (General Public License) или лицензий BSD-стиля. Вдаваться в детали лицензионной политики тут неуместно — для пользователя важно лишь, что любая из них позволяет свободное копирование и распространение программ, причем — абсолютно безвозмездно, то есть даром (детали можно посмотреть здесь: http://unix.ginras.ru/saga/002.html.
Далее, все рассматриваемые программы доступны в исходных текстах — собственно, это и есть основной способ их распространения (Open Sources). И, соответственно, могут быть скомпилированы для любой POSIX-совместимой платформы, и даже для работы в ОС семейства Windows (оставаясь даже в последнем случае такими же свободными и бесплатными). Что отнюдь не должно устрашать пользователя, не испытывающего тяги к программированию. Ибо «можно» в данном случае не означает «обязательно нужно»: такая работа уже была проделана разработчиками большинства популярных дистрибутивов Linux, майнтайнерами портов FreeBSD и так далее. Так что, скорее всего, пользователь будет иметь уже готовый к употреблению продукт, и от него потребуется лишь изучить возможности оного. Что в общем случае делается просто — с помощью документации, сопровождающей практически все свободные программы… Тем не менее, если у него возникнет тяга к совершенствованию имеющегося софта, пользователь сможет не только перекомпилировать программу с нужными ему опциями, но даже внести изменения в исходники.Подключение
Мы вряд ли ошибемся, если допустим, что почти любая только что купленная в магазине цифровая камера предусматривает подключение к компьютеру по USB-интерфейсу. Так что первая задача, которая встает перед фото-пользователем свободной POSIX-системы — это доступ к отснятым материалам. И для ее решения нужно знать несколько простых вещей.
Первое — то, куда записываются отснятые кадры, представляет собой встроенный или (что в последнее время бывает чаще) съемный твердотельный накопитель типа Compact Flash и так далее — нынче имя им легион. Детали реализации их нас не волнуют — достаточно того, что принципиально они ничем не отличаются от флэшки с USB-разъемом. Так что в дальнейшем будем называть их просто «камерными» накопителями.
«Камерный» накопитель, вне завивисимости от его типа, несет на себе файловую систему — и ею будет какой-либо вариант FAT (VFAT при объемах до 2 ГБ и FAT32 — на более емких носителях). Так что проблема доступа к «камерному» носителю информации сводится просто к монтированию его файловой системы в общую файловую иерархию нашей ОС — будь то Linux или любой представитель BSD-семейства.
Конечно, бывают камеры и с накопителями как бы без файловой системы, но это — явление относительно редкое. Да и впечатление об отсутствии файловой системы — лишь кажущееся. Ведь, коль скоро отснятые кадры предстают в конечном счете в виде файлов соответствующих графических форматов, файловая система будет иметь место в любом случае. Просто реализация USB-интерфейса конкретной модели камеры может быть такова, что она не дает пользователю прямого доступа к файловой системе своего носителя. Однако это не повод для отчаяния, и методы борьбы с таким безобразием мы рассмотрим ниже.
А тем временем вступает в силу второй момент: по исторически сложившимся причинам, в POSIX-системах любые устройства хранения информации, интерфейс которых не IDE/ATA, предстают в качестве винчестеров SCSI — в том числе и все USB-накопители. Соответственно, и монтироваться они должны как обычные SCSI-диски — то есть блочные устройства, которым соответствуют файлы типа /dev/sda# (в Linux) или /dev/da# (в BSD).
Третий заслуживающий внимания момент — был ли «камерный» накопитель размечен в качестве дискового раздела, или файловая система создавалась непосредственно на цельном (raw) устройстве. Определить это можно либо соответствующими командами типа fdisk, disklabel или bsdlabel (в зависимости от операционной системы), либо методом ползучего эмпиризма, либо, если в данной ОС используется файловая система устройств devfs или (в Linux) механизм udev, просмотром содержимого каталога /dev до и после подключения цифровой камеры к машине — появившиеся после файлы устройств и будут отвечать «камерному» накопителю и его разделу.
Предположим, проблему идентификации имени файла устройства, соответствующего «камерному» накопителю и подлежащего монтированию, мы благополучно разрешили (поверьте, на практике это гораздо проще, чем на словах). И теперь приступаем к собственно монтированию. В Linux это будет выглядеть так: $ mount -t vfat /dev/sda /mnt_point
где значение опции -t определяет тип файловой системы, /dev/sda — имя файла несущего ее устройства (в примере — не размеченного как дисковый раздел), а /mnt_point — существующий (и, желательно, пустой) каталог — так называемая точка монтирования (например, /mnt/dc — именно в подкаталоги каталога /mnt принято монтировать всякого рода сменные накопители).
В BSD-системах нет единой команды для монтирования файловых систем разных типов — за каждую из них отвечает собственная программа. И потому процедура монтирования будет чуть иной: $ mount_msdos /dev/da0 /mnt_point
где mount_msdos — команда монтирования файловых систем FAT-семейства, а /dev/da0 — имя файла SCSI-устройства (от Direct Access). Возможна и иная форма: $ mount -t msdos /dev/da0 /mnt_point
Здесь опция -t общей команды mount вызывает программу для монтирования соответствующей файловой системы.
В обоих примерах в качестве носителя файловой системы фигурирует накопитель, не размеченный как дисковый раздел (raw-устройство). Если же раздел на нем был создан — то имя соответствующего файла будет вроде /dev/sda1 в Linux и /dev/da0s1 в BSD. Цифра 1 в качестве идентификатора не обязательна — встроенный накопитель может быть размечен и как 4-й, например, первичный раздел (почему — тайна сия велика есть).
Если подключение цифровой камеры осуществляется регулярно, можно упростить ввод соответствующих команд монтирования — для этого нужно вписать в файл /etc/fstab строку вроде /dev/sda1 /mnt/dc vfat noauto,user 0 0
в Linux или /dev/da0s1 /mnt/dc msdos rw,noauto 0 0
во FreeBSD (и DragonFlyBSD). И теперь для монтирования нашего «камерного» устройства в качестве аргумента команды mount достаточно указать точку монтирования, а необходимости в каких-либо опциях не будет вообще: $ mount /mnt/dc
Обратим внимание на слово user в примере для Linux — эта опция позволит выполнять монтирование «камерного» накопителя обычному пользователю, не имеющему полномочий администратора. В BSD-системах аналогичного результата можно добиться с помощью команды $ sysctl vfs.usermount=1
Да, еще: монтирование USB-носителей в качестве SCSI-устройств требует, чтобы ядро системы было собрано с поддержкой («жесткой» или модульной) соответствующих опций, то есть: общей поддержки SCSI, поддержки SCSI-дисков, USB-интерфейса вообще и USB-«хранилищ» (usb mass storage) в частности, не говоря уж о файловой системе FAT и ее модификации VFAT. Впрочем, заморачиваться этим пользователю особо не нужно: прекомпилированные ядра современных user-ориентированных дистрибутивов Linux собираются именно так. А во FreeBSD и DragonFlyBSD умолчальное ядро GENERIC поддерживает все необходимое в качестве модулей, которые даже не требуют ручной загрузки — она происходит автоматически при обращении к соответствующим устройствам и файловым системам.
С файловой системой смонтированного «камерного» носителя можно поступать точно также, как и с любым каталогом нашей общей файловой системой, то есть просматривать ее с помощью команды типа $ ls /mnt/dc
копировать с нее файлы в свой домашний каталог или куда угодно еще, и даже записывать файлы на нее. Нужно только помнить, что собственно файлы отснятых кадров могут быть закопаны достаточно глубоко во вложенных подкаталогах внутри /mnt/dc.
Описанная процедура была проделана нами в DragonFlyBSD для оказавшихся под рукой камер: Casio QV4000 и Minox Leica M3. В первой в качестве носителей использовался Compact Flash 512 (число — объем в мегабайтах), вторая сменного носителя не имеет (только встроенный накопитель). Ни малейших проблем замечено не было…
Теперь рассмотрим ситуацию, когда после подсоединения камеры смонтировать ее накопитель в качестве дискового устройства так и не удалось, и команда mount выдает сообщение об ошибке типа mount: /dev/da0s1: Device not configured
Именно такая ситуация возникла, когда мы попытались получить доступ к тому же CompactFlash в камере Canon EOS D60. Причем в DragonFlyBSD (и FreeBSD также) ее вполне можно предугадать в момент подключения — в этих ОС информация о любом устройстве «горячего подключения» выводится на первый виртуальный терминал, исполняющий роль системной консоли. И если для камер, не маскирующих файловую систему своего накопителя, это сообщение будет выглядеть примерно как umass0: OnSpec USB 2.0 Storage Device, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 38154MB (78140160 512 byte sectors: 255H 63S/T 4864C)
то в случае с камерой типа Canon EOS D60 ответом будет радостное сообщение о подключении некоего абстрактного устройства ugen# (USB Generic номер такой-то), являющегося устройством символьным и, соответственно, не могущим быть смонтированным.
К решению этой проблемы можно подойти двумя путями. Первый — просто вынуть «камерный» накопитель и вставить его в кард-ридер — благо последних нынче немало, все они ориентированы на множество форматов и, обычно, имеют USB-интерфейс. В частности, мы воспользовались устройством All-in-Black 12 in 1 USB2, воспринимающим, как можно понять из его имени, карты 12 форматов. В результате бывший «камерный» накопитель был благополучно смонтирован в качестве SCSI-диска, примерно так, как было описано выше: $ mount -t msdos /dev/da0s1 /mnt/dc
К слову сказать, такой способ пригоден и для доступа к любым «камерным» накопителям, если их физически можно извлечь из камеры. Преимущество его, перед прямым подключением камеры к компьютеру, заключается в том, что считывание происходит по интерфейсу USB2: по не вполне понятной причине, сами по себе камеры, даже не из числа дешевых, по сию пору оснащаются только разъемом USB1.Доступ к кадрам: программный путь
Однако что делать, если а) «камерный» носитель несъемный (хотя такое нынче встречается не очень часто), б) под рукой не имеется кард-ридера подходящего формата, или в) просто лениво вытаскивать карточку из камеры и вставлять ее куда-то?
В этих случаях на помощь придет программа, специально предназначенная для «снятия» кадров с цифровых фотокамер — gphoto2. Получить ее в исходных текстах можно с сайта проекта (http://www.gphoto.org/). Входит она также в состав портов и пакетов FreeBSD, а также в поставку распространенных дистрибутивов Linux. Это утилита командной строки, которая, будучи запущена с должными опциями, выполняет сканирование портов, к которым может быть подключена цифровая камера (USB или, для любителей архаики, сериальных), автоматическое определение поддерживаемых устройств и подключение соответствующего драйвера (а список камер, с которыми эта программа работает, весьма обширен) и их перекачивание на локальную машину — подобно тому, как это делают обычные ftp-клиенты для файлов с удаленных серверов.
Опции команды gphoto2 весьма многочисленны, с ними подробно можно ознакомиться на man-странице — man (1) gphoto2. Поэтому задержим внимание только на некоторых из них.
Для автоматического подключения камеры команда gphoto2 дается таким образом: $ gphoto2 --auto-detect
Сработает он, однако, только в том случае, если камера входит в список поддерживаемых программой устройств. Что можно выяснить с помощью такой команды: $ gphoto2 --list-cameras
которая выведет список примерно в 500 позиций — от весьма древних моделей до вполне современных.
Наконец, самая интересный способ запуска программы такой: $ gphoto2 --shell
В этом случае программа gphoto2 предлагает в распоряжение пользователя собственный, весьма удобный, shell-подобный интерфейс, дающий доступ к встроенным командам. В их числе — команды для перехода в подкаталоги «камерного» носителя и локальной файловой системы (cd и lcd, соответственно), просмотр их содержимого (ls), получение кадров в стандартном для данной формате, в виде микроиконок (thumbnails) или в т.н. «сыром» (raw) формате (get, get-thumbnail и get-raw, соответственно; ну а что это такое raw - было подробнее рассмотрено в предыдущей статье), удаления ненужных кадров (delete) и так далее. Полную справку по встроенным командам gphoto2 можно получить с помощью команды help (или ее эквиваленту — вводу символа ?), а также на упомянутой ранее man-странице.Просмотр изображений
Фотографии обычно снимают для того, чтобы их смотреть:-) — в распечатанном ли виде, или прямо с экрана. Вообще-то, цветная, тем более фотореалистическая, печать из Linux сотоварищи — тема отдельного разговора, и затрагивать ее здесь мы не будем. Отметив только, во избежание иллюзий, что для всамделишней фотореалистической печати в настоящее время лучше подыскать другую платформу…
А вот с просмотром отснятого хозяйства никаких проблем не возникнет: выбор вьюверов растровых изображений в свободных POSIX-системах весьма обширен. В Linux просмотр графики возможен даже без запуска оконной системы X — достаточно лишь поддержки т. н. «графической консоли» (Frame Buffer — по умолчанию включена в большинстве user-ориентированных дистрибутивов) или установки библиотеки SVGAlib.
Для просмотра изображений в графической консоли предназначена программа fbi, функции библиотеки SVGAlib задействованы в программе zgv — и ту, и другую можно обнаружить в «больших» дистрибутивах Linux. Впрочем, обе они не блещут богатством возможностей, а zgv, вероятно, прекратит свое развитие, вместе со своей базовой библиотекой. Так что задерживать ваше внимание на них мы не будем, оставив их как предмет самостоятельного изучения для заинтересованных лиц.
Подавляющее большинство вьюверов растровых изображений рассчитаны на работу в оконной системе X. Среди них заслуживают упоминания KView — штатный вьювер из интегрированной среды KDE (рис. 1), и GQview, основанный на библиотеке Gtk (рис. 2). В любой из них можно просмотреть снимки с «камерного» носителя, перенести их в иные части файловой системы и, при необходимости, выполнить минимальную обработку: смасшабировать или обрезать изображение, подправить яркость или контрастность, повернуть или зеркально отразить картинку. Причем GQview допускает подключение для этой цели внешнего растрового редактора, в том числе такого мощного, как Gimp (о котором говорилось в предыдущейй статье). А в KDE для редактирования растровых изображений имеется штатное средство — KolourPaint, возможностей которого более-менее хватает для любительской работы (рис. 3).
Рис. 1. Kview — штатный графический вьювер среды KDE
Рис. 2. GQview — еще один вьювер, уже на Gtk
Рис. 3. KolourPaint — просто, но часто достаточно
Наконец, в качестве вьювера можно использовать и Gimp (хотя это несколько напоминает обстрел одинокой чайки из главного калибра линкора). Однако когда дело дойдет до серьезной обработки изображений — Gimp окажется незаменимым.
