Создаем систему каталогизации астрофотографий

[deymos34]

   Господа, на форуме подробно освещены, пожалуй, все аспекты работы с астрофотографиями – кроме одного. Полностью обойден молчанием вопрос их каталогизации. А это ведь ничуть не менее важный этап, чем все остальные, ибо позволяет сохранить и эффективно использовать результаты напряженного труда. Особенно в том случае, если фотографий скопилось уже много. Если пренебречь их систематизацией, они превратятся просто в груду красивых картинок – да и то конкретное изображение сложно будет найти. Если же снимки как следует учесть, то перед нами откроется масса впечатляющих возможностей.
   Итак, каковы требования к системе каталогизации? Что она должна уметь?
   Система должна быть максимально независимой от конкретных образчиков ПО. Она должна легко имплементироваться в разнообразные программы, как то вьюеры и онлайн-фотогалереи. Причем для ее функционирования должно быть достаточно даже штатных возможностей неспециализированного ПО. Например такого, как Adobe Lightroom, Apple Aperture, Google Picasa, IrfanView, ACDSee и других подобных.    При этом не должно возникать привязки к используемой программе, миграция должна быть максимально легкой и безболезненной. Необходима также возможность использования нескольких программ параллельно, ибо они могут в некоторых случаях дополнять друг друга.
   Система должна быть максимально независима и от конкретных образчиков аппаратуры. То есть она должна позволять использовать самые разные типы носителей информации – жесткие диски, DVD-R, Blu-Ray, флеш-карточки, даже ленточные накопители. При этом должна быть возможность искать контент и на не подключенных в данный момент к компьютеру устройствах.
   Система должна быть максимально простой в освоении, но в то же время весьма мощной и гибкой в использовании. Требуется создать ее так, чтобы изменения приходилось вносить предельно редко. То есть необходим и некий задел на ближайшее будущее, которое, несомненно, принесет нам некоторые новые возможности по части работы с астрофотографиями.
   Наконец, система должна содержать в себе и некоторые возможности по работе и с неастрономическими медиаматериалами. Ибо большинство людей, скажем, снимают, помимо астрономических, еще и обычные фотографии. А разделять архив на две независимые части далеко не всегда резонно.

   И какие же у нас есть возможности для претворения в жизнь всех этих требований? Взять хотя бы первое из них – независимость от той или иной программы. Очевидно, в этом случае мы не можем хранить информацию в базе данных, ибо при ее использовании мы будем крепко-накрепко привязаны. Даже в том случае, если есть утилита экспорта информации – просто потому, что структура БД у каждой программы своя, и полный перенос информации ввиду этого не всегда возможен.
   Поэтому данные о картинках – метаданные – нам надо хранить в самих же картинках. Благо возможности для этого есть во всех популярных форматах, таких как JPEG, FITS и TIFF. Есть, правда, и важное исключение – RAW. Ввиду того, что никакого единого формата у файлов этого типа нет, с имплементацией информации, кроме как осуществляемой самим же приемником изображения, возникают серьезные проблемы. Но это не страшно – хранить все необходимые сведения можно в результирующем изображении, а исходники трогать необязательно.
   Наиболее перспективным представляется использование для хранения метаданных механизма ключевых слов – просто потому, что с ним умеют работать любые сколько-нибудь серьезные программы. При этом имеет смысл работать с двусоставными словами, например «RImessier M31». Префикс – RI – нужен для того, чтобы эффективно отделять каталогизационные данные от обычных ключевых слов. Слитно с ним пишется название самого тега, раскрывающего, что за информация в нем заключена. В данном случае это номер объекта в каталоге Мессье. Ну и наконец, идут сами данные – в данном случае каталожный номер.
   Использование механизма ключевых слов позволит нам быть независимыми от базы данных той или иной программы – но совсем отказываться от ее использования было бы глупо. Не стоит забывать, что быстрый поиск достижим только при использовании БД, да и накопитель с желаемой фотографией может быть в настоящий момент недоступен – прежде всего в том случае, если используются сменные носители. Поэтому база данных должна заполняться – но на основе предварительно внесенных в фотографии спецтегов. Например, в отдельную группу могут быть вынесены все объекты каталога Мессье. И все галактики. И все водородные туманности. И все планетарки. Благо современный софт позволяет абсолютно элементарно делать выборки по ключевым словам, и выделить фотографии, несущие в себе ключевое слово «RImessier*» или «RIobjType galaxy» - это вопрос пары кликов мышкой. Таким образом мы сочетаем стабильность ядра системы с ее предельной гибкостью – базовая информация, заключенная в фотографии, практически никогда не меняется, а вот методика сортировки может быть элементарно скорректирована в любой момент.
   Теперь необходимо составить список тегов, используемых в нашей системе. Это именно тот этап, где я более всего рассчитываю на помощь многоуважаемых форумчан, ибо одному все вспомнить сразу невозможно, а по ходу дела хотелось бы вносить минимальные изменения. Итак:

Информация об объекте
RIobjName(xy) – Название объекта. Например: Сатурн, Туманность Андромеды, Плеяды.
RIobjType(xy) – Тип объекта. Например: планета, галактика, рассеянное звездное скопление.
RImessier(xy) – Номер объекта в каталоге Мессье. Например, М31, М45.
RIngc(xy) – Номер объекта в каталоге NGC. Например, NGC 3982.
RIcaldwell(xy) – Номер объекта в каталоге Калдвелла. Например, С101.
RIconstell(xy) – Созвездие, запечатленное на снимке. Например: Волк, Весы.

Информация о сетапе
RIlens(xy) – Использовавшийся при съемке объектив или телескоп. Например, Canon 18-135mm/3.5-5.6, Celestron Advanced C6-SGT XLT.
RIaperture(xy) – Относительное отверстие. Например, f/5.6.
RIapertureA(xy) – Апертура в миллиметрах. Например, 200mm.
RIfocus(xy) – Фокусное расстояние. Например, 135mm.
RImount(xy) – Использовавшаяся монтировка. Например, Sky-Watcher EQ-6 Pro SynScan.
RIcamera(xy) – Использовавшаяся для съемок фото-, видео-, веб- или ПЗС-камера. Например, Canon 350Da.
RIexposure(xy) – Экспозиция. Поле в разработке.
RIguiding(xy) – Гидирование. Например: нет, ведение, ручное, автогид.
RIguideCam(xy) – Гидирующая камера.
RIguideLens(xy) – Гидирующий телескоп. Например, Sky-Watcher 80ED, off-axis.

Информация о наблюдательных условиях
RIdt(xy) – Дата и время наблюдений. Поле в разработке.
RItemp(xy) – Температура воздуха, в градусах Цельсия. Например: +20, -5.
RIpressure(xy) – Давление воздуха, миллиметров ртутного столба. Например: 750мм.
RIsky(xy) – Состояние неба на момент наблюдений, описывается в произвольной форме.
RIskyglow(xy) – Засветка. Например: конус 40° на юго-востоке.
RIbortle(xy) – Оценка качества неба по шкале Бортля. Например, 5.5.
RImoon(xy) – Фаза Луны на момент наблюдений. Например: под горизонтом, первая четверть, полнолуние.
RIturb(xy) – Турбуленция. Поле в разработке.

Информация о месте наблюдений
RIcountry(xy) – страна, на территории которой проводилось наблюдение. Например: Россия, Украина.
RIregion(xy) – Регион. Например: Краснодарский край, Крым.
RIplace(xy) – Место наблюдения. Например: Майданак, КРАО.
RIlat(xy) – Широта места наблюдения.
RIlong(xy) – Долгота места наблюдения.
RIalt(xy) – Высота места наблюдения над уровнем моря. Например: 345м.

Информация об обработке
RIprog(xy) – Программа, использовавшаяся для обработки снимка. Например: Photoshop CS2, Registax 4.
RIaction(xy) – Действия, выполнявшиеся в программе, например: деконвлюция, вейвлеты.

Прочие данные
RIauthor(xy) – Автор снимка. Например: Иван Иванович Иванов.
RIlicense(xy) – Правовой статус снимка. Например: GNU GPL, Creative Commons 2.5, Public Domain.

   Постфикс (xy) означает необязательный буквенно-цифровой код (например, А1), позволяющий группировать связанные между собой теги, прежде всего в том случае, если надо задать для одного и того же тега разные значения. Например, итоговый снимок создан из материалов, полученных двумя людьми в разное время, в разных местах и на разном оборудовании. В этом случае теги, содержащие данные от первого фотографа, имеют постфикс А1, а те, которые содержат информацию от второго – соответственно, B2. А если один человек использовал два телескопа, то для первого из них применяем постфикс А1, а для второго – А2. Хотел бы, кстати, поинтересоваться мнением форумчан, куда именно стоит эти постфиксы вставлять – после тега, после его значения, или, может быть, перед? Главная задача – упростить поиск фотографий, равно как и обработку метаданных.
   Также стоит проработать вопрос и с сохранением времени съемки. При этом у нас должна быть возможность работать и со сложными случаями – когда снималось много кадров с разными выдержками. То есть банальным указанием тайминга начала первой экспозиции никак не обойтись. К тому же требуется поддержка как UT, так и местного времени.
   Какие будут относительно всего этого соображения, господа?

[deymos34]

"Много букв, ниасилил"

Судя по всему, не вы один. И в самом деле, первый пост получился длинноват. Сейчас исправлюсь.

Что-то не понял, это предлагается сайт сделать?

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

Заполнять все пункты совершенно нереально, 5-10 не больше.

Резонное замечание. Я, собственно, об этом писал - предполагается выделить те самые 5-10 пунктов в качестве рекомендуемого минимума. Хотя каждый сам волен выбирать, какие пункты заполнять, а какие нет - все они факультативны. Но потребности у всех разные, к тому же часть данных получится вносить практически в автоматическом режиме - о сетапе, например, или об астроплощадке. Ибо меняются они редко, и потому можно механически проставлять однажды введенные значения. Вот почему я и хочу одновременно создать, по-сути дела, две спецификации - краткую и подробную. Дабы развивать ее сугубо эволюционно, дабы при добавлении новых функций не было б никаких проблем с уже каталогизированными фотографиями. Но изначально, конечно, заполняться будет небольшое количество пунктов.

[deymos34]

для кого облегчить поиск, архивирование и обмен?

Для любителей астрономии.

кто заказчик?

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

массы впечатляющих возможностей не узрел. 

Ну, интересные возможности там есть. Речь прежде всего о скорости поиска - если фотографии должным образом упорядочены, найти любую из них можно за несколько секунд. Если нет - можно и часы на это потратить, при условии что архив достаточно разросся. Планируются и другие "вкусности" - например, полуавтоматизированный подсчет и проверка контрольных сумм файлов, дабы не прозевать порчу физических носителей информации.

зачем это нужно, к примеру, мне я не очень понимаю.

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

кроме того, большая часть информации уже вносится автоматически в заголовок fit файлов

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

[deymos34]

Если свербит и очень хочется, то проще всего будет расширить возможности mapivi с помощью cfitsio.

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

[deymos34]

То есть, если фотограф, например, снял портрет, то:
RIobjName(xy) – Название объекта. Маша
RIobjType(xy) – Тип объекта. Девушка
Соответственно, номер в каталоге Мессье не указывается. 
Так?

Неа. Под обычные фото должны быть выделены другие теги. Эти - только для астрофото.

возможно, было бы удобнее разделить фотографии на астрономические и не астрономические.

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

[deymos34]

А какие поля будут ключевыми?

Никакие, разумеется - это набор тегов, а не реляционная БД.

[deymos34]

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

Согласен. Именно поэтому у меня в мыслях не было отказываться от СУБД. Но вноситься в базу информация будет из тегов, записанных в само изображение. Благодаря этому мы можем использовать любую программу-каталогизатор по своему вкусу. Можем в любой момент без проблем его сменить.

Чтобы решить проблему отдельно взятого ЛА по домашнему хранению изображений? Да они и без вских программ разбираются и делают так, как им удобнее.

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

А люди все - разные, одному удобнее "так", а другому - "эдак"

Безусловно. Однако ж дело в том, что создание системы "под себя" требует немалых трудо- и времязатрат. Да, гипотетически самостоятельно можно сделать очень крутое зеркало - но большинство любителей предпочитает иметь дело с уже готовым телескопом. Потому как при самостоятельном изготовлении мы либо получим неудовлетворительный результат, либо затратим слишком много ресурсов.

Для создания централизованной БД?

Такое тоже не исключено - в перспективе. Ибо форум с функциями хранения и обмена астрофото не справляется, найти что-либо не слишком свежее в огромных темах малореально.

[deymos34]

Я как раз на днях выложил описание своего домашнего фотоархива.

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

[deymos34]

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

И в мыслях не было - просто потому, что система сия нужна мне-любимому. Да, матерые ЛА уже каталогизировали свои архивы - но я-то нет. И делать это придется вне зависимости от того, понадобятся ли кому-нибудь еще мои наработки, либо нет. Понадобятся - замечательно, нет - тоже не страшно.

Успехов...

Спасибо на добром слове.

[deymos34]

observationManager уже смотрели? а COMAST?

О, Александр, огромное спасибо за наводку!
Естественно, подобные программы и стандарты я искал - однако ж не нашел. Возможно, потому, что COMAST родом из Германии, и англоязычной информации по нему маловато. Буду изучать.