Свободные программы для цифровой фотографии

Алексей Федорчук и Владимир Родионов
30 августа 2005 г

Введение

Покупатель современной цифровой фотокамеры в комплекте со своим агрегатом получает, как правило, некий джентльменский набор программ — вьювер графических изображений, более или менее продвинутый редактор растровой графики и так далее, — как правило, достаточный для любительского применения. Однако вот беда — все эти программы работают под управлением совершенно определенной операционной системы — и несложно догадаться, что системой этой оказывается Windows. Хотя кое-какие камеры (преимущественно вышесреднего ценового диапазона) комплектуются и софтом для MacOS — но вот программ для свободных операционок POSIX-семейства мы к коробке не увидим наверняка. Так что же — пользователи Linux или BSD будут лишены доступа к достижениям современной цифро-фотографической мысли?

Отнюдь — ответим мы со всей определенностью. Ибо один из принципов сообщества Open Sources — «Дело спасения утопающих — дело рук самих утопающих». И если производители «железа» не проявляют склонности к заботе о свободолюбивых пользователях — они позаботятся о себе сами. А как они это делают — мы постараемся продемонстрировать в этой статье.

В качестве объекта для упражнений была выбрана довольно редкая пока операционка POSIX-семейства — DragonFlyBSD (сведения о ней в англоязычном исполнении можно найти на сайте проекта, а по русски — например, на этом сайте). Почему такая экзотика? Во-первых, как сказал бы товарищ Сталин, другой ОС у нас под рукой не было. А во-вторых, мы пытались показать, что даже в столь молодой и мало распространенной ОС, если разобраться, ни малейших сложностей при работе с цифровыми фотоматериалами не возникает. Так что не следует ожидать их и во FreeBSD и, тем более, в любом user-ориентированном дистрибутиве Linux. А вообще особенности, специфичные для каждой ОС, будут, при необходимости, по ходу дела отмечаться отдельно.

В качестве сравнительного (а местами и основного) материала использовались также версии программ, собранных для ОС Windows. Да-да, и для этой платформы существует немало программ для обработки цифровых фотографий, причем столь же свободных, как и их Unix-аналоги..

Важно подчеркнуть, что все программы, упомянутые в этой статье, принадлежат к числу свободных (Free Software — что не следует путать с понятием FreeWare), распространяемых на условиях лицензии GNU (General Public License) или лицензий BSD-стиля. Вдаваться в детали лицензионной политики тут неуместно — для пользователя важно лишь, что любая из них позволяет свободное копирование и распространение программ, причем — абсолютно безвозмездно, то есть даром. Детали можно посмотреть в книге «Введение в POSIX’ивизм», онлайновая версия.

Далее, все рассматриваемые программы доступны в исходных текстах — собственно, это и есть основной способ их распространения (Open Source). И, соответственно, могут быть скомпилированы для любой POSIX-совместимой платформы, и даже для работы в ОС семейства Windows (оставаясь даже в последнем случае такими же свободными и бесплатными). Что отнюдь не должно устрашать пользователя, не испытывающего тяги к программированию. Ибо «можно» в данном случае не означает «обязательно нужно»: такая работа уже была проделана разработчиками большинства популярных дистрибутивов Linux, майнтайнерами портов FreeBSD и так далее. Так что, скорее всего, пользователь будет иметь уже готовый к употреблению продукт, и от него потребуется лишь изучить возможности оного. Что в общем случае делается просто — с помощью документации (man имя_программы, например), сопровождающей практически все свободные программы. Тем не менее, если у него возникнет тяга к совершенствованию имеющегося софта, пользователь сможет не только перекомпилировать программу с нужными ему опциями, но даже внести изменения в исходники.

Подключение

Мы вряд ли ошибемся, если допустим, что почти любая только что купленная в магазине цифровая камера предусматривает подключение к компьютеру по 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. Получить ее в исходных текстах можно с сайта проекта). Входит она также в состав портов и пакетов 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. Теоретически есть такая возможность и в DragonFlyBSD, и во FreeBSD — посредством включения в ядре т.н. PIXEL_MODE.

Для просмотра изображений в графической консоли предназначена программа fbi, функции библиотеки SVGAlib задействованы в программе zgv — и ту, и другую можно обнаружить в «больших» дистрибутивах Linux. Впрочем, обе они не блещут богатством возможностей, так что задерживать ваше внимание на них мы не будем, оставив их как предмет самостоятельного изучения для заинтересованных лиц.

Подавляющее большинство вьюверов растровых изображений рассчитаны на работу в оконной системе X. Среди них заслуживают упоминания KView — штатный вьювер из интегрированной среды KDE (рис. 1), и GQview, основанный на библиотеке Gtk (рис. 2). В любой из них можно просмотреть снимки с «камерного» носителя, перенести их в иные части файловой системы и, при необходимости, выполнить минимальную обработку: смасшабировать или обрезать изображение, подправить яркость или контрастность, повернуть или зеркально отразить картинку. Причем GQview допускает подключение для этой цели внешнего растрового редактора, в том числе такого мощного, как Gimp (о котором говорилось в предыдущейй статье). А в KDE для редактирования растровых изображений имеется штатное средство — KolourPaint, возможностей которого более-менее хватает для любительской работы (рис. 3).

Рис. 1. Kview — штатный графический вьювер среды KDE

Рис. 2. GQview — еще один вьювер, уже на Gtk

Рис. 3. KolourPaint — просто, но часто достаточно

Наконец, в качестве вьювера можно использовать и Gimp (хотя это несколько напоминает обстрел одинокой чайки из главного калибра линкора). Однако когда дело дойдет до серьезной обработки изображений — Gimp окажется незаменимым.

Что делать дальше?

Камера — это измерительный прибор для регистрации изображения. Результатом ее работы является raw-массив — необработанная последовательность чисел (raw — сырой, необработанный), каждое из которых зарегистрировано соответствующим чувствительным элементом камеры. Этот массив существует всегда — в памяти или оформляется в виде файла. Программа для работы с ним тоже нужна всегда. Она может выполняться камерой или внешней большой ЭВМ, но она всегда присутствует. В предельном случае ее выполняет экспериментатор, замеряя напряжение на фотоприемниках и закрашивая разграфленную на квадраты миллиметровку в соответствии с полученными значениями. Для того чтобы превратить массив данных в изображение, нужно знать параметры матрицы, как минимум число чувствительных элементов в строке и направление строк относительно кадра. Как с помощью Photoshop в этом случае получить черно-белое изображение, описано в статьях: Клад, зарытый Casio) и Цифровой задник Leaf valeo 11) . Чтобы восстановить цвет, надо еще знать цвет и порядок расположения фильтров перед чувствительными элементами. Если камеры записывают необработанные данные только для внутренних целей, то файл с ними обычно устроен очень просто, но если его собираются отдать фотографу, то его структура усложняется, производится сжатие без потерь, записывается дополнительная информация о параметрах съемки, может помещаться миниатюра для предварительного просмотра. Обычно камеры сразу внутренними средствами преобразуют исходные данные в цветное изображение, но часть информации при этом теряется. Поэтому у фотографа, привыкшего самостоятельно проявлять пленку, возникает естественное желание получить полный контроль над обработкой исходных данных.

Для полного контроля нужно знание операций, производимых с данными программой, и конструкции камеры. Этим условиям отвечает известная с 1997 года программа DCRAW Д. Коффина (Dave Coffin), которая содержит, кроме алгоритма обработки, и информацию о конструкции огромного количества камер. Ее можно найти на сайте автора).

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

Как следует из текста на странице автора, код этой программы используется почти во всех альтернативных (программам производителя) программах преобразования RAW файлов в цветное изображение. В том числе, и в таких, в целом, платных программах, как Photoshop. Сам модуль преобразования Photoshop Camera Raw plug-in , впрочем, для Photoshop CS, распространяется свободно). Используется эта программа и в прекрасном бесплатном редакторе GIMP).

Программа DCRAW существует в виде исходного кода на C. Все остальное сделали другие люди. Программа на сегодняшний день (26.08.2005) поддерживает 183 камеры, и число это постоянно возрастает. В том числе, большинство RAW форматов, которые могут быть вызваны только из служебного меню. Например: Casio Exlim Pro 700! Включенная в Photoshop часть этой программы позволяет преобразовывать только официальные файлы RAW, их в последней версии лишь 70. Поскольку программа написана на С, то в случае появления новой камеры, со слегка отличающимися параметрами, модернизировать программу для работы с этой камерой может любой, более-менее знакомый с этим языком.

В прекомпилированном виде эта утилита включена во многие дистрибутивы Linux, имеется в портах FreeBSD, в качестве бинарного пакета есть и для DragonFlyBSD. Существует даже версии ее и для DOS.

Самая простая реализация этой программы позволяет запустить ее из командной строки таким образом:

$ dcraw file_name

Что на выходе даст одноименный (не считая суффикса) файл в формате PPM (Portable Pixel Map), который был предложен Джефом Посканзером (Jef Poskanzer) в 1988 году (старожилы могу припомнить, что это был родной формат замечательного растрового редактора Picture Publisher). Для работы с форматом PPM существуют библиотеки на С — pbmplus и libnetpbm. То есть на такой конвертированный файл можно обрушить, например, всю мощь Gimp’а. Что уже само по себе неплохо…

DCRAW располагает достаточно обширным набором опций. Ознакомиться с ними можно на man-странице — man (1) dcraw. Или — просто запустив эту программу без опций и аргументов. Попробуем проделать это и мы, разумеется, сопроводив вывод комментариями на рiдной мове (русскоязычного хелпа эта программа, вроде бы, пока не имеет):

• -i идентификация raw-файла, данного в качестве аргумента команды, без его конвертации; вывод ее выглядит примерно так:
  имя_рек.raw is a Casio EX-P600 image
• -c конвертация raw-файла с направлением результата на стандартный вывод; очевидно, что в ответ последует сообщение о невозможности вывода изображения на терминал; однако если перенаправить вывод в файл — эту команду в форме
  dcraw -c file_name.raw > file_name1.ppm
  можно использовать для присвоения выходному файлу произвольного имени;
• -v вывод сообщений в ходе конвертации;
• -f интерполяция RGBG как 4—цветного изображения (Interpolate RGBG as four colors);
• -d конвертация в черно-белое изображение в режиме документа (Document Mode (no color, no interpolation));
• -q быстрая, низкокачественная интерполяция цветов (Quick, low-quality color interpolation);
• -h (Half-size color image (3x faster than -q));
• -g установка показателя степени гамма (Set gamma (0.6 by default, only for 24-bpp output));
• -b установка значения яркости (Set brightness (1.0 by default));
• -a использование автоматического баланса белого (Use automatic white balance);
• -w (Use camera white balance, if possible)
• -r (Set red multiplier (daylight = 1.0))
• -l (Set blue multiplier (daylight = 1.0))
• -2 запись ppm-файла в формате 8 бит на канал, опция по умолчанию (Write 24-bpp PPM (default))
• -3 запись PSD-файла в формате 16 бит на канал (Write 48-bpp PSD (Adobe Photoshop))
• -4 запись ppm-файла в формате 16 бит на канал (Write 48-bpp PPM)

Возможности у dcraw, как видно, неслабые. И, теоретически рассуждая, вполне доступны для пользователя. Вот только использовать их непосредственно из командной строки не так уж и просто. Не из-за какой-то особой сложности опций самих по себе, а в принципе: подбор тех же значений гамма-коррекции, да еще без визуального контроля получившегося результата, — дело не очень тривиальное. И возникает вопрос — а нельзя ли к dcraw прикрутить какой-нибудь графический интерфейс для упрощения таких действий? Ведь даже самый ярый приверженец командной строки согласится с тем, что кесарево — кесарю, а слесарево — слесарю…

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

Gimp

А вот тут пора бы и вспомнить о давно обещанном Gimp’е. Тема эта несколько сложна для рассмотрения. С одной стороны, за что ни возьмись в растровой графике — Gimp окажется при деле, и хоть пару слов о нем сказать можно. С другой же — сразу оказывается, что пары слов будет мало, и приходится говорить еще и еще. Поэтому собственно о Gimp’е речи тут не пойдет — лишь о том, как прикрутить его к обработке кадров цифровых камер.

Так выглядит интерфейс GIMP. Даже из этой картинки легко заметить, что все необходимое в нем есть, и построен он весьма логично. Учитывая, что вместе с необходимой библиотекой он занимает всего 10Мб, стоит скачать и попробовать самому :-)
Готовая к установке программа по адресу: http://gimp-win.sourceforge.net/stable.html
Около 10 Мб двумя файлами: GTK+ 2 for Windows (version 2.4.14) и The Gimp for Windows (version 2.2.3)

Одна из отличительных особенностей Gimp’а — его практически неограниченная расширяемость, вытекающая из его природы: открытые исходники, однако же… И реализуется эта расширяемость двумя способами: с одной стороны, через так называемые script-fu (то есть программы, написанные на языках сценариев типа Perl или Sheme), с другой — plug-in’ами, небольшими Си-программами, требующими автономной компиляции, но естественным образом интегрируемыми в общую структуру Gimp’а.

Так вот, dcraw и может выступить в качестве одного из таких Gimp plug-in’ов. Для этого достаточно установить все тот же пакет dcraw. после чего попытка открыть посредством Gimp’а любой из raw-форматов, ранее безуспешная, вызывает панель следующего вида

Так Gipm plug-in открывает raw-файлы

Ничего нового, собственно говоря, мы на этой панели не увидим: переключатели соответствуют описанным выше опциям командной строки dcraw, и то не всем. Однако она избавляет от необходимости их запоминания. А главное, подбирать яркость или баланс цветов, щелкая по стрелкам, несколько проще, чем задавать их вручную. Правда, функции предпросмотра получившегося результата мы не обнаруживаем — все равно придется выполнить конвертацию. Но, тем не менее, некий визуальный контроль все же имеет место быть. Вообще с задачей графического интерфейса этот вариант справляется плохо, поэтому рассмотрим еще два из них, скомпилированные для Windows. Естественно, близкого результата можно добиться и для других ОС, просто разделение труда между авторами статьи привело к тому, что эта часть тестировалась на машине, умеющей работать только с окнами.

RawPhoto GIMP-2.0 plug-in

Итак, RawPhoto GIMP-2.0 plug-in, сочиненный Полом Джочимом (Pawel T. Jochym, за точность транскрипции не ручаемся):

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

UFRaw

Программа UFRaw (автор — Udi Fuchs, это мы даже и пытаться не будем транскрибировать) содержит код dcraw внутри себя, имеет более богатые настройки, отображает две гистограммы яркостей — до и после преобразований. Эта программа может работать и независимо от GIMP и сохранять результаты в файле. Обработка проводится с 16 битными числами и только затем перед передачей в GIMP числовые значения округляются до 8 бит. 8 бит — это, пожалуй, единственное, что меня останавливает от полного отказа от Photoshop. Любопытно, как эта программа обрабатывает экзотический снимок камеры FUJIFILM FinePix F700).

Описанные программы предполагают, что с их возможностями вы будете разбираться самостоятельно, потому только обращу внимание на параметр: Clip Saturated pixels в первой программе и Unclip во второй. Он отвечает за то, что делать, если в одном из каналов сигнал зашкалил – отбросить и значения в других каналах или дать, как есть. Если сравнивать с тем, как этот файл обрабатывает Photoshop Camera Raw plug-in, то легко заметить, что есть разница.

Что лучше, я судить не берусь, но есть повод задуматься, какую программу лучше использовать в каждом конкретном случае. В дополнение отмечу, что Photoshop Camera Raw plug-in имеет больше возможностей, относящихся к дополнительной обработке. Можно регулировать подавление шумов и попытаться исправить хроматические аберрации, причем иногда весьма успешно.

	До коррекции
	После коррекции. Изображение при верстке увеличено в 2 раза.

Как это собрать

Выше мы неоднократно подчеркивали, что все упомянутые здесь программы доступны в виде прекомпилированных пакетов для подавляющего большинства дистрибутивов Linux и BSD-систем. Однако возможно, что по закону всемирного свинства именно для вашей системы их и не окажется. Или — в ней будет устаревшая версия. Или, наконец, вы захотите добавить какие-либо функции. В общем, причин для самостоятельной сборки программ из исходников может быть множество — вплоть до оптимизации под наличное «железо». Так что уделим этому вопросу несколько слов.

Подавляющее большинство исходных текстов свободных программ распространяется в виде тарбаллов — tar-архивов, сжатых с помощью утилит компресии gzip или bzip2, и имеющих вид *.tar.gz или *tar.bz2, соответственно. Так что первый шаг после получения такого тарбалла из Сети — его распаковка в подходящее место:

$ tar xzvf name.tar.gz

или

$ tar xjvf name.tar.bz2

соответственно, и переход в образовавшийся подкаталог командой cd name. А дальше все происходит посредством трех волшебных слов — команд

$ ./configure
$ make
$ make install

Первая команда выполняет сценарий предварительного конфигурирования (создание такового — задача разработчика), вторая осуществляет собственно сборку программы, третья интегрирует образовавшиеся исполнимые бинарники, библиотеки, документацию и прочее в должные места файловой системы (по умолчанию обычно — в подкаталоги каталога /usr/local, такие, как /usr/local/bin, /usr/local/lib, и так далее.

Правда, сначала неплохо выполнить еще одно предварительное действие — команду

$ ./configure --help

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

Таким образом собирается большинство программ, вплоть до очень сложных, вроде Gimp’а. Однако если обратиться к вышеупомянутой страничке Дэвида Коффина, то можно увидеть, что его программа dcraw представляет собой всего один файл — исходный текст на языке Си под именем dcraw.c. И — ни малейшего сценария конфигурирования…

В этом случае дело обстоит еще проще — напрямую вызывается компилятор языка Си (и в Linux, и BSD-системах им будет gcc) с аргументом — именем файла исходника, и опцией, значением которой будет имя целевого бинарника:

$ gcc -o dcraw dcraw.c

Правда, в такой форме мы немедленно получим сообщение об ошибке — ибо для сборки и работы dcraw необходимы некоторые библиотеки (в частности, графических форматов, типа libjpeg), о местоположении которых в самом исходнике, естественно, не сказано ни слова (нахождение нужных библиотек — одна из задач сценария конфигурирования). Что ж, укажем пути к библиотекам явным образом. В Linux это, скорее всего, будет каталог /usr/lib, в BSD-системах в данном случае потребуется /usr/local/lib. А еще потребуются пути к так называемым заголовочным (header) файлам (своего рода оглавлениям библиотечных функций) — это, скорее всего, будут /usr/includes и /usr/local/includes, соответственно. И в итоге команда для сборки dcraw примет (в BSD, точная форма команды в Linux предоставляется фантазии читателя:-)) следующий вид:

$ gcc -I /usr/local/include/ -L /usr/local/lib/ -o dcraw dcraw.c

Теперь остается только скопировать получившийся бинарник в подходящее место — например, в /usr/local/bin. Правда, таким путем мы получим только сам конвертор raw-файлов, пригодный для использования в командной строке. Чтобы встроить его в Gimp и получить, таким образом, доступ к графическому интерфейсу, потребуется еще и собственно программа-plugin — rawphoto. Это точно такой же одинокий файл — rawphoto.c, который также берется со страницы Дэвида Коффина. И поступить с ним нужно точно так же — скомпилировать с указанием соответствующих путей и имени целевого бинарника rawphoto. Только вот поместить последний нужно в каталог для plug-in’ов Gimp — например, в ~/.gimp-2.2/plug-ins для пользования собой, любимым, или куда-нибудь типа /usr/X11R6/share/gimp/plug-ins — чтобы сделать достоянием всех пользователей (пример дан для файловой иерархии DragonFlyBSD, во FreeBSD — аналогично, в Linux путь будет иным, зависящим от дистрибутива).

Заключение

В этой статье описаны далеко не все свободные программы, которые могут быть использованы для работы с цифровыми фотографиями. А посему дополнения принимаются и приветствуются.