Итак, я продолжаю допиливать свой велосипед для работы с фитсами. Теперь добавлены еще кое-какие полезные штуки. Глядишь, до нового года хотя бы процентов 10 предполагаемого функционала запилю. А там еще немного — и будет автомат для технических ночей (а то и не только). Чтобы перечислить возможности, просто сделаю:
./fitsread -h
Использование: fitsread [аргументы] [префикс выходного файла]
Где аргументы:
-4, --conn4=arg label 4-connected components with giventhreshold
-8, --conn8=arg label 8-connected components with giventhreshold
-B, --binarize=arg binarize image by threshold (in %%from dynamic range)
-D, --del-rec удалить все записи с указанной подстрокой
-a, --add-rec добавить запись в FITS-шапку
-b, --bottom=arg the lowest value, all data less than 'bottom' vould be set to it
-d, --del-key удалить указанный ключ
-h, --help отобразить эту справку
-i, --infile=arg входной файл
-o, --outfile=arg выходной файл
-p, --pipeline установить параметры конвейера, аргументы: type:[help]:...
type - тип преобразования (help для справки)
help - список доступных для данного 'type' опций
-s, --stat отобразить статистические параметры входного и выходного изображения
-t, --top=arg the lowest value, all data more than 'top' vould be set to it
-v, --verbose уровень подробностей вывода (каждый -v увеличивает его)
--inplace записать изменения в тот же файл
--mean вычислить среднее арифметическое всех перечисленных изображений
--median вычислить медиану всех перечисленных изображений
--rewrite перезаписать выходной файл, если он существует (только с опцией -i)
--sum вычислить сумму всех перечисленных изображений
Итак, добавлены: работа с FITS-шапкой (добавление, изменение и удаление записей); обрезка по заданным уровням (нужно иной раз бывает при конвейерной обработке); пакетная обработка изображений (среднее арифметическое, медиана и сумма всех перечисленных в параметрах изображений); бинаризация изображения по заданному (в доле от динамического диапазона) уровню, если уровень указан как отрицательное число, бинаризованное изображение инвертируется; маркировка 4- и 8-связных областей (на выходе получается файл с нумерованными областями вроде картинок ниже).
Конечно, этого мало. Как минимум нужно еще добавить вычисление параметров пятен по найденным маскам с 4- или 8-связностью, а для этого нужно будет еще автоматом вычислять фон и вычитать из изображения. Кроме того, неплохо было бы еще добавить автоматическое "выпрямление" длиннощелевых спектров для большего удобства дальнейшей обработки (это я на будущее для применения со снимками с IRBIS), ну и работу с "пачками" изображений (когда в одном файле находится несколько изображений).
Пронумерованные пятна на гартманнограмме
Нумеруя связанные области инвертированного изображения легко вытащить фон для дальнейшего извлечения
> Как минимум нужно еще добавить вычисление параметров пятен по найденным маскам с 4- или 8-связностью, а для этого нужно будет еще автоматом вычислять фон и вычитать из изображения.
Хз, как там в астрономии, в своих задачах находил связные компоненты заливкой, и относительно компактно их хранил в памяти в виде массива отрезков горизонтальных прямых. Если отрезки упорядочены в лексикографическом порядке, то достаточно на 1 отрезок хранить x координату начала и конца (или длину отрезка) и 1 бит, указывающий на то, стоит ли увеличивать текущее значение у.
Если бинарное изображение - не шахматная доска с пикселами, то такое хранение явно экономичнее по памяти, чем маска меток компонент. Также получается в лаконичной форме писать алгоритмы обхода по маскам, заданные таким образом, ну и не нужно думать о том, хватит ли типа данных (не будет ли целочисельного переполнения) массива меток для подсчёта всех компонент на картинке.
В качестве теста представлений смотрел задачки: 1) jbig2 кодировщик, тоесть нужно найти одинаковые буквы на изображении. Мера схожести букв - определяется как количество пикселей, не совпавших при наложении одной буквы на вторую, ну и процесс повторяется для 9 возможных "подёргиваний" по сторонам.
Заговнокодил со своим представлением, и взял "32-пикселя за такт" версию из лептоники, моя оказалась всего в 3 раза медленнее, хотя кода пришлось написать совсем чуть чуть.
2) генерацию контура связной компоненты - тут раз в 5 по скорости порвал "лептонику"
3) операцию морфологической реконструкции (эт заливка по маркерам, заданных второй бинарной маской) - тут в зависимости от картинок - если много мелких объектов, то лептоника на уровне по скорости, если объектов не много, или они большие и "гладкие" - то "строко-представление" опять обгоняет лептонику.
Такое, может и для астро-задач есть смысел в такое попробовать? Только у меня оно на С++, если что.
Сами по себе связные области не несут никакой полезной информации. Для фона нужно вычислить какой-нибудь сглаживающий полином, чтобы вычесть из изображения; для объектов либо вычислить аппроксимирующую поверхность, либо, аккуратно сглаживая вбросы, вычислить основные параметры по нефильтрованному изображению (только за вычетом фона, в который и BIAS автоматом входит; а на больших экспозициях еще и темновой надо предварительно вычитать).
Со связными областями я еще до конца не закончил. На выходе должен получаться удобоваримый массив масок: координаты левого верхнего угла области интереса, ее размер и сама область в виде "сжатого" бинарного изображения (1 пиксель == 1 бит). Пока вот какой "бенчмарк" получается для велосипеда (i5-3210M CPU @ 2.50GHz x2cores x2hyper):
* 0.25 megapixels
* 4: time/object = 1.7 +- 0.1 us (7.0us per megapixel)
* 8: time/object = 3.9 +- 0.1 us (15.6us per megapixel)
*
* 1 megapixel
* 4: time/object = 5.3 +- 0.0 us (5.3us per megapixel)
* 8: time/object = 13.3 +- 0.1 us (13.3us per megapixel)
*
* 4 megapixels
* 4: time/object = 22.3 +- 2.2 us (5.6us per megapixel)
* 8: time/object = 57.6 +- 1.3 us (14.4us per megapixel)
*
* 16megapixels
* 4: time/object = 146.1 +- 1.6 us (9.1us per megapixel)
* 8: time/object = 229.7 +- 1.0 us (14.4us per megapixel)
Забавно, что с точки зрения времени на один объект на мегапиксель изображения оба метода поиска связных областей дают примерно константную скорость.
> из лептоники Поиск 4- и 8-связных компонент, а также эрозию и дилатацию я завелосипедил сам, т.к. в лептонике крайне медленно это все считается.
> генерацию контура связной компоненты - тут раз в 5 по скорости порвал "лептонику" Я тоже себе для этого пилил свою реализацию "шагающих квадратов".
> Такое, может и для астро-задач есть смысел в такое попробовать? Если исходники под GPL, в любом случае не помешает посмотреть, даже несмотря на > Только у меня оно на С++ Правда, если С++ полноценный, т.е. с кучей объектов, виртуальных функций, наследований и т.д., и т.п., то преобразовать это в сишный код будет сложно, проще с нуля написать, поняв идею алгоритма. // на С++ переходить не собираюсь, т.к. считаю его жутким оверхедом в моих задачах.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
eddy_em
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-12-22 09:55 pm (UTC)Хз, как там в астрономии, в своих задачах находил связные компоненты заливкой, и относительно компактно их хранил в памяти в виде массива отрезков горизонтальных прямых. Если отрезки упорядочены в лексикографическом порядке, то достаточно на 1 отрезок хранить x координату начала и конца (или длину отрезка) и 1 бит, указывающий на то, стоит ли увеличивать текущее значение у.
Если бинарное изображение - не шахматная доска с пикселами, то такое хранение явно экономичнее по памяти, чем маска меток компонент. Также получается в лаконичной форме писать алгоритмы обхода по маскам, заданные таким образом, ну и не нужно думать о том, хватит ли типа данных (не будет ли целочисельного переполнения) массива меток для подсчёта всех компонент на картинке.
В качестве теста представлений смотрел задачки:
1) jbig2 кодировщик, тоесть нужно найти одинаковые буквы на изображении. Мера схожести букв - определяется как количество пикселей, не совпавших при наложении одной буквы на вторую, ну и процесс повторяется для 9 возможных "подёргиваний" по сторонам.
Заговнокодил со своим представлением, и взял "32-пикселя за такт" версию из лептоники, моя оказалась всего в 3 раза медленнее, хотя кода пришлось написать совсем чуть чуть.
2) генерацию контура связной компоненты - тут раз в 5 по скорости порвал "лептонику"
3) операцию морфологической реконструкции (эт заливка по маркерам, заданных второй бинарной маской) - тут в зависимости от картинок - если много мелких объектов, то лептоника на уровне по скорости, если объектов не много, или они большие и "гладкие" - то "строко-представление" опять обгоняет лептонику.
Такое, может и для астро-задач есть смысел в такое попробовать? Только у меня оно на С++, если что.
no subject
Date: 2015-12-23 05:41 am (UTC)Со связными областями я еще до конца не закончил. На выходе должен получаться удобоваримый массив масок: координаты левого верхнего угла области интереса, ее размер и сама область в виде "сжатого" бинарного изображения (1 пиксель == 1 бит). Пока вот какой "бенчмарк" получается для велосипеда (i5-3210M CPU @ 2.50GHz x2cores x2hyper):
Забавно, что с точки зрения времени на один объект на мегапиксель изображения оба метода поиска связных областей дают примерно константную скорость.
> из лептоники
Поиск 4- и 8-связных компонент, а также эрозию и дилатацию я завелосипедил сам, т.к. в лептонике крайне медленно это все считается.
> генерацию контура связной компоненты - тут раз в 5 по скорости порвал "лептонику"
Я тоже себе для этого пилил свою реализацию "шагающих квадратов".
> Такое, может и для астро-задач есть смысел в такое попробовать?
Если исходники под GPL, в любом случае не помешает посмотреть, даже несмотря на
> Только у меня оно на С++
Правда, если С++ полноценный, т.е. с кучей объектов, виртуальных функций, наследований и т.д., и т.п., то преобразовать это в сишный код будет сложно, проще с нуля написать, поняв идею алгоритма.
// на С++ переходить не собираюсь, т.к. считаю его жутким оверхедом в моих задачах.