Благодаря помощи [profile] alextutubalin, код утилиты для работы с all-sky теперь полностью свободен. Я добавил дебайеризацию посредством libraw. Вот такие jpeg'и теперь может генерировать сетевой клиент (помимо сохранения "сырых данных" в tiff, fits и raw dump):

Камеру можно будет водрузить на ее законное место, временная заглушка для информационных панелей уже будет работать, останется настроить сервер БД для хранения данных (чтобы иметь возможность оценить небо в любой момент времени из архивных данных).
Еще остается подключить болтвудовский датчик, но это не так критично, как нормальный all-sky.
Итак, поковырявшись немного с libraw, я плюнул: разобраться в недрах такого бешеного количества кода просто нереально! Поэтому пока выбираю более медленную, но все-таки работающую "Self Similarity Driven Demosaicking". В принципе, цветопередача получается вполне нормальная, я вывел на монитор эту картинку и после обработки получил:
img

Саму утилиту тоже чуть подправил: добавил простой "калькулятор экспозиций" (надо его по звездному небу проверить, в комнате он давал сходимость на 3-5 итерациях).
Еще )
Итак, я продолжаю допиливать свой велосипед для работы с фитсами. Теперь добавлены еще кое-какие полезные штуки. Глядишь, до нового года хотя бы процентов 10 предполагаемого функционала запилю. А там еще немного — и будет автомат для технических ночей (а то и не только).
Дальше )
Для обработки FITS-файлов обычно используются пакеты MIDAS или IRAF. Однако, они довольно тяжеловатые для сравнительно простых задач (которые возникают у меня при технических наблюдениях), а также тяжеловаты для написания своих собственных методик обработки изображений. Поэтому я решил написать простой конвейер, позволяющий удалять шумы с изображений, вычислять и вычитать фон, выделять объекты, строить изофоты и т.д., и т.п.
В результате получилась вот такая штука. Пока еще это — только пре-пре-пре-альфа версия, добавлять нужно еще очень много разных вещей. Но уже кое-что оно умеет (хотя и не исключены сегфолты на малейший чих, тестов пока маловато проведено).

Итак, для образца возьмем длиннощелевой спектр:
Original

и будем всячески его преобразовывать.
Далее )
Вот такую штуку подсказал аноним с ЛОРа для наискорейшего поиска выпуклой оболочки набора точек:
http://en.wikibooks.org/wiki/Algorithm_Implementation/Geometry/Convex_hull/Monotone_chain

// нужно будет для определения площади, занимаемой произвольной гартманнограммой.
Что-то опять у ЖЖшки беда с загрузкой картинок, поэтому пришлось использовать imageshack.
текст )


В предыдущей записи [livejournal.com profile] vlkamov попросил меня немного разбавить текст картинками, что я и сделал. А сейчас я хочу на примере моделированного среза изображения показать, в чем же заключается суть алгоритма.
Все подробности — под катом. А здесь же для того, чтобы разжечь интерес читателя, покажу один график:
Signal_filtered
Уровни интенсивности оригинального ("Original") и восстановленного по "фотографиям" с разными экспозициями ("HDR") сигнала.

Подробности )

Про HDR

May. 11th, 2013 12:32 pm
Вот посмотрел я сегодня еще раз те жалкие картинки, которые мне сделал hugin вместо HDR, и подумал, что надо бы все-таки реализовать свою HDR-собиралку (теоретически, т.к. hugin — всего лишь обертка, запускающая консольные утилиты, можно ей вместо hugin_hdrmerge свое подсунуть).
Теорию я уже приводил на ЛОРе, да и частично реализовывал при анализе камеры Apogee. Т.к. здесь работа ведется с png-файлами, все сильно упрощается (правда, надо где-то сохранять сведения об экспозиции каждого кадра, иначе ничего не получится): открываем одновременно все файлы, затем построчно считываем их, строка за строкой заполняя результирующее HDR-изображение. Обработка элементарная: отбрасываем значения ЧБ-интенсивности, близкие к 0 или 255; далее делим оставшиеся интенсивности на экспозиции; вычисляем медиану; сохраняем логарифм полученного значения во временный файл (лучше, пожалуй, double использовать), параллельно вычисляя максимальную и минимальную величину логарифма. В другой или этот же файл сохраняем данные о цвете, которые берем из того изображения, где уровень серого в данном пикселе лежит где-нибудь так в диапазоне 176..230 (надо экспериментально подобрать).
По окончании обработки всего изображения преобразуем наш бинарник в нормальный png-файл.
Такой способ обработки все шумы максимально уменьшит, кроме шумов на уж очень темных местах (т.е. на темных участках изображения с максимальной экспозицией). Их придется восстанавливать, предварительно пройдясь медианным фильтром.

В общем, если не забуду об этой идее, как-нибудь от скуки реализую. UPD )
Итак, как я уже говорил в предыдущей записи, за время, бесцельно проведенное в Нижнем Новгороде, кое-что полезное я таки сделал. В этой записи расскажу о реализации операций эрозии и диляции.
Подробности )
В следующей заметке изложу эпопею поиска оптимального алгоритма выделения связанных областей. Но для начала надо отрихтовать "китайский" вариант, чтобы работал правильно. Ну и подумать насчет параллелизации (мало ли: вдруг на пару порядков быстрей будет).
Только я пожаловался, что давненько не писал, как — вуаля. Решил поделиться. Итак, проверил я алгоритм, про который в предыдущей заметке писал (по статье Ruijters, Romeny & Suetens «Efficient GPU-Based Texture Interpolation using Uniform B-Splines»). Получается действительно черт знает что:
idata-bad
odata-bad
Плохой алгоритм. Сверху — исходные данные, Снизу — интерполяция.

дальше ) Тесты на время выполнения (завал на графике ГСЧ на GPU — из-за моей ошибки):
randnum
Генерирование случайных чисел.
interplin interplog
Интерполяция. Справа — в логарифмическом масштабе.
Я уже, наверное, с неделю пытаюсь набрести на более-менее приличный алгоритм аппроксимации дуги окружности вида (x²+y²=R²), но только сегодня набрел на отличную книгу, написанную автором уймы статей на подобную тематику — Николаем Черновым. Самой приятной неожиданностью было то, что помимо этой замечательной книги, в которой автор исследует множество алгоритмов аппроксимации прямых и окружностей, на его домашней страничке есть и готовый код к книге.

Чуть подробней )

Итак, нагулявшись в отпуске я таки решил вернуться к своим баранам.
Прежде, чем начать писать что-то для разложения нормалей к волновому фронту по упомянутым раньше функциям Жао, я решил попробовать обычное разложение. Для этого с сайта mathworks был сворован исходник функции zernfun2 (которая вычисляет полиномы), а также deco (которая выполняет декомпозицию).
Функцию deco пришлось маленько подправить (она вычисляла коэффициенты на основе двойного численного интегрирования, что крайне медленно). Но получилось довольно-таки сносно.



Чуть подробней )
Хоть нормальных наблюдений вчера провести не удалось (погода была ужасной), мы успели по крайней мере снять несколько гартманнограмм Веги для измерения точного положения фокальной плоскости для нового светоприемника (многострадального Apogee).
Подробности ) В итоге получили, что нам надо отрезать 14мм от стоек крепления светоприемника. Отрежем, а на следующую техническую ночь проведем повторные измерения. Если все будет ОК, сделаем уже нормальный прибор, с турелью фильтров. И будем раз в месяц-два проводить позиционные измерения и снимать гартманнограммы. Правда, еще бы найти время, чтобы довести до ума восстановление профиля зеркала по гартманнограмме + автоматизировать позиционные измерения.
Решил я (в основном - для себя, чтобы не забыть) описать результаты тестирования светоприемника Apogee Alta U16M с матрицей Kodak KAF-16803 (судя по стоимости светоприемника — немногим более 10 килобаксов, матрицу эту подобрали на помойке). Начальство поручило нам с Тимуром проанализировать, насколько поганый этот светоприемник и можно ли его использовать для ненаучных задач (например, для оценки экстинкции). В конце марта-начале апреля мы провели нужные измерения, а потом долго их обрабатывали.
Подробности )
P.S. К сожалению, у ЖЖшки отвалилась функция добавления картинок в сам ЖЖ, так что пришлось все кидать на imageshack.
P.P.S. Сегодня (10 мая) я таки умудрился домучить libapogee2.2 (которую нашел где-то на просторах интернета), чтобы она считывала мне кадр с ПЗС. Однако, несмотря на то, что экспозиция протекает нормально, температура устанавливается какая надо, все пиксели полученных изображений содержат 65535.
Буду доламывать дальше: все-таки, эта камера нам нужна будет для работы и надо обязательно научиться полностью управлять ею.
В связи с тем, что я уже пятый день мучаю тех. задание на систему регистрации ИК-спектрофотометра, у меня возникли кое-какие соображения касательно фильтрации шумов на изображении.
Соображения )
Продолжу цикл своих публикаций относительно мытарств с обработкой гартманнограмм.
Ранее я уже описывал, как получить модели пред- и зафокальных гартманнограмм. Теперь пора перейти к следующему этапу - определению координат центров пятен и получению значений нормалей к проекции волнового фронта, например, на предфокальное изображение (оно не зеркалировано, так что его использовать удобнее для расчета отклонений формы зеркала от идеальной).

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

А секретов-то и нет! )

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

Хреновый метод )

В общем, метод себя не оправдал. Буду курочить матричный (итерациями).

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

Здесь я опишу реализацию алгоритмического метода и сравню его с методом определения центра вращения по пересечениям радиусов окружности.

Поехали! )

В прошлой записи я пытался при помощи Octave найти центр вращения поля, исходя из координат объектов на снимках, полученных последовательно с некоторым интервалом времени. Тот метод был непригоден в случае, если поле не только вращалось, но и смещалось. Здесь я изложу некоторые соображения, которые позволят (возможно) найти нужные параметры.

Немного алгебры )

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

September 2017

S M T W T F S
     1 2
3456789
1011 12 13141516
17181920 212223
24252627282930

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 25th, 2017 04:24 am
Powered by Dreamwidth Studios