eddy_em: (Default)
[personal profile] eddy_em
В связи с тем, что я уже пятый день мучаю тех. задание на систему регистрации ИК-спектрофотометра, у меня возникли кое-какие соображения касательно фильтрации шумов на изображении.

Итак, принцип работы КМОП-мультиплексоров таков, что позволяет производить в процессе накопления недеструктивные считывания сигнала. Пошукав по литературе и пообсуждав этот факт, было решено добавить в систему регистрации фильтрацию изображения посредством линейной аппроксимации сигнала в каждом пикселе изображения. А вот как эту аппроксимацию сделать - уже особый разговор.
Допустим, что мы делаем экспозицию в 1 час с квантом времени в 5с на считывание промежуточных изображений. В итоге получаем 3600/5=720 16-битных картинок размером 1024х1024, на хранение которых понадобится 1024*1024*2*720=1.5ГБ (плюс еще какое-то место на «шапки»)! Теоретически, все их можно «запихать» в оперативку, для этого рассчитаем предельный размер оперативной памяти: если экспозиция будет длиться всю ночь (самая длинная ночь у нас — где-то 15 часов, вычтя время на сумерки и всякие подготовки, получим в пределе часов 13), квант времени будет равен 1с, то максимальное количество файлов составит 13*3600=46800 и займут эти файлы как минимум 93ГБ! Есть материнки, поддерживающие 128ГБ оперативки, т.е. теоретически такой компьютер собрать можно, практически же стоить он будет слишком дорого. Поэтому идем другим путем.
Другой путь — складывать все временные файлы на диске (лучше всего - на SSD, для увеличения скорости доступа). Т.е. каждое промежуточное изображение с соответствующей шапкой мы сохраняем на диск (всю шапку заполнять не надо - только меняющиеся данные, вроде температур и т.п. параметров, а также - времени от предыдущего считывания, т.к. выдержать требуемый квант с точностью в микросекунды вряд ли получится; постоянные параметры достаточно занести в шапку только первого файла). В итоге по окончании экспозиции у нас на диске получается n-е количество FITS-файлов, которые можно в фоновом режиме, не мешая наблюдениям, обработать и отдать под утро наблюдателю все его файлы в «чистеньком» виде.
Для обработки нам надо для каждого пикселя проанализировать кривую зависимости уровня сигнала от времени экспозиции (в основном - ее линейную часть, аппроксимирующуюся выражением I=I₀+ΔIt), выдернув оттуда такие параметры, как bias (I₀), произведение gain на освещенность в данном пикселе (ΔI), предел линейности (тот участок графика, где наша кривая начинает «загибаться» вправо) и уровень насыщения (предельный уровень сигнала в пикселе, не изменяющийся при повышении времени экспозиции). Нелинейные параметры, в принципе, наблюдателю неинтересны, поэтому расчет их можно сделать опциональным. Помимо этих характеристик обработка позволит выявить «горячие» пиксели (находящиеся в насыщении вне зависимости от уровня сигнала), «битые» пиксели (вроде «горячих», но с низким уровнем сигнала) и «неправильные» пиксели (с нелинейной характеристикой или прочими проблемами).
Теория, конечно, хороша, но опять вернемся к нашим баранам: современные компьютеры пока еще не позволяют за разумные деньги сделать такие вычисления без ухищрений. Во-первых, cfitsio не позволяет открыть такое количество файлов (а если бы библиотека и позволяла, ее особенности в том, что она, по сути, mmap'ит файлы в память - а то и просто копирует их туда, так что, оперативки не хватит), следовательно, если захотеть открывать эти файлы «разом» и поочередно считывать, придется писать свой FITS-парсер (чего делать не хочется — это во-вторых). В-третьих, можно придумать еще уйму «отмазок», чтобы закончить эти размышления и послать все нафиг. Но работать-то надо!
Итак, единственным более-менее приличным (и легко реализуемым) вариантом предварительной обработки данных мне предоставляется следующий:
  1. создать во временной директории (назовем ее пока /tmp) 1024 (в общем, в зависимости от количества строк) поддиректории, в каждой из которых завести по 1024 (в зависимости от количества столбцов) файла;
  2. открыть очередной FITS-файл;
  3. прочитать «шапку» и сохранить в оперативке динамические данные (статику возьмем из нулевого изображения);
  4. перейти к сегменту данных изображения и начать их попиксельное считывание;
  5. значения интенсивности в пикселе с координатами (X, Y) дописать в файл /tmp/Y/X;
  6. считать так все пиксели изображения;
  7. перейти к следующему изображению;
В результате мы получаем 1048576 (в общем, X·Y) временных файла, которые уже можно будет обрабатывать.
До обработки создаем итоговый FITS и заполняем его шапку: заносим всю статику, обрабатываем динамику и заносим туда же экстремальные, средние и медианные значения, а также стандартное отклонение. Далее начинаем заполнять данные изображения:
  1. открываем очередной файл /tmp/Y/X;
  2. считываем все данные в оперативку (или просто mmap'им его);
  3. получаем графики первой и второй производных;
  4. из анализа графиков производных находим точки перегиба (определяя таким образом участок «разгона», линейный участок, переход в насыщение и собственно насыщение);
  5. если мы не имеем в пикселе линейного участка — определяем, «горячий» он или «битый», увеличивая соответствующий счетчик и занося в соответствующий пиксель 65535 или 0 (плюс можно создавать дополнительные изображения-маски, в которых помечать все «косяки») и переходим к следующему пикселю;
  6. аппроксимируем линейный участок, вычисляем требуемые параметры (I₀, ΔI и т.п.) и заносим в очередной пиксель итогового изображения значение, равное ΔI·T (T — время экспозиции), производя таким образом сразу же очистку от bias'а; сопутствующую информацию можно записывать в дополнительные файлы;
  7. переходим к следующему пикселю.
Симуляции я еще не прогонял, так что прикинуть, сколько времени займет обработка часовой экспозиции, пока не могу. Однако, если эту обработку запускать в фоновом режиме, я уверен, что как максимум к моменту своего пробуждения после наблюдений астрофизик получит чистенькие и красивенькие изображения, которые сможет обрабатывать.
Да, забыл добавить: благодаря тому, что этот способ очистки компенсирует «перекоп» от слишком ярких объектов (т.к. анализирует лишь линейный участок, а затем умножает крутизну на время экспозиции), данные надо будет сохранять уже как минимум в формате 32-битных целых, а то и 32-битных числах с плавающей точкой. FITS-файлы с дополнительной информацией позволят упростить предварительную обработку изображений, да и всякие калибровки будут уже значительно точнее.

Date: 2012-03-31 04:42 am (UTC)
From: [identity profile] ivanstor.livejournal.com
Материнка, на которую Вы сослались — чистая разводка, в плане оперативки. Для в ней 8 разъемов для модулей памяти, а максимальный объем 1 модуля памяти общего назначений сейчас 8Гб. Т.е. всего будет 64Гб. 16Гб модули — экзотика, за соответствующую цену. Но даже если их удастся купить, такой объем памяти на плате общего назначения и с обычными модулями — поиск приключений на свою задницу.
Для таких (и больших) объемов памяти применяют серверные платы, серверную память (с буферизацией и коррекцией ошибок) и серверные процессоры. Стоить будет порядка первых сотен тысяч рублей.
Возможно есть смысл приспособить для вычислений видеокарту (CUDA, OpenCL)? Тогда скорость обработки будет ограничена практически скоростью работа диска.
Во всяком случае, билатеральный фильтр для картинки ~4000х4000 на карточке у меня работает быстрее раз в 20-30.
Карточка старая, Geforce GTX 260, процессор Core Quad 3.2Ггц, память 8Гб.

Date: 2012-03-31 09:33 am (UTC)
From: [identity profile] eddy-em.livejournal.com
> Возможно есть смысл приспособить для вычислений видеокарту (CUDA, OpenCL)? Тогда скорость обработки будет ограничена практически скоростью работа диска.

Для такой обработки использовать CUDA бессмысленно: копирование между ОЗУ и оперативкой видеокарты будет происходить дольше, чем обработка на CPU. Для более сложной обработки, естественно, я пользуюсь CUDA. Правда, приходится иногда вместо GPU использовать CPU, т.к. оперативки на видеокарте слишком мало (с 512МБ оперативки на видеокарте я даже Фурье не могу сделать для изображения 3Кх3К).

Date: 2012-04-02 02:33 am (UTC)
From: [identity profile] vlkamov.livejournal.com
Не совсем понял, зачем открывать все файлы одновременно.
Телескоп направлен всю ночь в одну точку ?

Date: 2012-04-02 05:14 am (UTC)
From: [identity profile] eddy-em.livejournal.com
> Не совсем понял, зачем открывать все файлы одновременно.

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

> Телескоп направлен всю ночь в одну точку ?

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

October 2025

S M T W T F S
   1234
567 89 1011
121314 15161718
19202122232425
2627 28293031 

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Feb. 25th, 2026 10:11 am
Powered by Dreamwidth Studios