Все довольно любопытно. В заголовке прописана скорость ведения по часовому 881.231"/с (!); по дельте 7.05984. При такой скорости, если она была бы реальной, за 10 секунд экспозиции звезды должны были бы быть длиной (881 - 15)*10 = 8660", или 2.4 градуса - в два с лишним раза больше размера поля. Да и по дельте при такой скорости они должны были быть заметно наклонены. Фильтр trail_cluster пытается создать ядро такого огромного размера для детектирования таких длиннющих треков и пройтись им по кадру. На это ему не хватает памяти, и он вылетает, не обнаружив ничего. Прописывание в заголовках (например, с помощью CameraControl, File -> Image info или Ctrl-I или кнопка с синей i на тулбаре, вкладка с допольнительными FITS-полями) нулевых значений в полях HA_RATE, DEC_RATE нормализует ситуацию, кадр прекрасно обрабатывается.
Другой вопрос - как такие значения там появились? С биннингом это никак не связано. Скорее, это связано с режимом съемки. Все выглядит так, как будто ХАОС думает, что труба едет, а на самом деле она стоит на месте. Более нигде такого я не встречал, и мне не говорили. Единственное, что мне может прийти в голову: объект предполагалось снимать с ведением именно с такой скоростью, она была включена, но контроллер не смог ее отработать и перешел в manual mode, остановив трубу. ХАОС про это ничего не узнает и будет думать, что труба едет. Надо заглянуть в tcs.log - там могут быть (а могут и не быть) записи про manual mode вблизи этого момента. Единственное, что говорит не в пользу такого предположения - это что, судя по кадру (если искомый объект - внизу), скорость у него, все же, не такая фатальная. Поэтому хочется узнать поподробнее, как проходила съемка.
