Подробный материал о программном комплексе Pan-STARRS http://arxiv.org/pdf/1302.7281v1.pdf
На картинке из статьи хорошо понятен их принцип поиска по 2 кадрам, они вычитают кадры между собой, в результате на итоговом кадре остаются только темные и светлые изображения движущихся объектов.
Насколько я помню, Леонид в свое время писал, что при использовании двух кадров у них получалось слишком много ложников и они перешли на использование большего количества кадров.
Испанцы меня на днях также ткнули носом в эту статью. Собственно, сам алгоритм связывания треклетов описан не там, а в статье Кубики 2007 года. Я ее просмотрел и обнаружил, что их алгоритм на 50 процентов совпадает с последним вариантом моего (kd-деревья), используемого для спутников, плюс у меня он уже распараллелен. Из второй половины 25 процентов мне не очень понравилось (это использование пространственных деревьев, со временем как третьим измерением), а оставшиеся 25 (геометрическая интерпретация ограничений по скорости) - классная идея, которая натолкнула меня на то, как ускорить алгоритм еще в разы. Займусь через пару недель, как только закончу с диссером.
Они же, испанцы (конкретно, Хорхе, занимающийся АСЗ), попросили меня попробовать алгоритм на астероидах. В принципе, ничего неожиданного - в серии из трех кадров при ограничении в минимум два детектирования из трех он находит все, что там есть до 3 сигма, и что они нашли ПинПойнтом и донашли потом вручную (поле 4.5, проницающая между 16.5 и 17, на кадрах было по 30-35 тыс. звезд и полтора десятка астероидов), плюс процентов 25 ложняков; в серии из 4 кадров при минимум трех детектированиях - то же самое, но при нуле ложняков. Это обычный скрипт apex_geo_auto последней версии, только перенастроенный под астероидные скорости. Так что, по идее, к нему осталось приделать модуль отсеивания известных объектов - и все.
Также я, в общем, солидарен с авторами MOPS в отношении того, что интерактивный контроль результатов поиска - это не самый правильный путь, в конечном итоге. Сознаю, что тут можно долго спорить, что все любители поголовно уж точно со мной не согласятся, что использование ручного труда при доразметке наших обзоров геостационара позволяет повысить эффективную проницающую по сравнению с тем, на что рассчитана оптика, и что изготовление оптики под ту же проницающую в расчете только на автомат сделало бы ее заметно дороже (правда, это компенсируется более дорогой эксплуатацией из-за того, что надо платить наблюдателям, занимающимся ручной доразметкой - но, в конце концов, одна из целей проекта как раз в том, чтобы поддерживать наблюдателей, а механизм "сделать недорого, а потом просить деньги под уже сделанное" очень даже работает
. Но все-таки, когда количество обнаружений начинает измеряться тысячами, постепенно просто физически становится не до ручного контроля. Поэтому я не планирую пока делать интерактивный интерфейс именно под эту задачу, а предпочитаю повышать надежность детектирования как такового. Тем более, что для точечных изображений это гораздо проще, чем для спутников при том же сигнале к шуму, из-за более простой морфологии объектов.
Также я по-прежнему категорически против использования дифференциальных кадров. О создании своего неба и использовании его для обнаружения транзиентов может долго размахивать руками чистый теоретик Липунов, но на практике это требует высочайшей стабильности размера, формы и амплитуды PSF (во времени и по полю), которая достижима на космических телескопах и, в большой степени, на инструментах класса PanSTARRS высоко в горах, но - не в нашем случае. А в нашем, да еще при нашей обычно низкой дискретизации, любое вычитание кадров, снятых даже подряд, один за другим, порождает кучу артефактов; то же самое - с вычитанием усредненного изображения данного куска неба (я не говорю, что хранить такие собственные каталоги изображений неба на каждом из десятков телескопов пока нереально); и практически то же самое - если вычитать не реальные изображения, а синтезированные. Да что говорить, если на том же испанском TFRM, например, картинки одного и того же поля, снятые даже в хорошую ночь с интервалом в час, могут содержать (на одном и том же пороге детектирования) в полтора раза отличающееся число объектов, и просто приведя их по интенсивности друг к другу, ничего хорошего все равно не получишь из-за хроматизма и того, что звезды разных цветов, собаки, ослабляются и размазываются по-разному - либо надо ставить более узкий фильтр и резать проницающую. Но даже если бы изображения были стабильны в отношении проницающей, дрожания, размазывания и т.д., я не вижу большого смысла в вычитании кадров: допустим, из 35000 объектов на каждом кадре 34950 - это звезды; текущий распараллеленный алгоритм на kd-деревьях в моей версии выявляет их по альфам-дельтам и отбрасывает секунд за 10 на обычной машине. Правда, обработка их всех - это дополнительная тяжкая нагрузка на пиксельный конвейер, но она и так была бы, только ему пришлось бы измерять не звезды, а остатки их вычитания, т.е. артефакты. Которым, ко всему прочему, горадо легче внести вклад в количество ложняков на выходе, чем нормальным звездам.
В отношении целесообразности хранения своего неба в виде каталогов объектов, даже на малых временах, в течение нескольких дней, у меня примерно такие же сомнения, обусловленные реалиями наших наблюдений. А вот связывать одиночные треклеты в треки за несколько ночей для повышения надежности и точности орбиты, как это делается в MOPS, мне кажется крайне правильным. Если не идеологически (панстаровцам, похоже, тесноваты масштабы MPC,
то, по крайней мере, алгоритмически.
