Первое преимущество, которое я вижу - можно сразу показать "амплитудную" двумерную картинку, предложить пользователю выбрать области интереса и прочие объекты, а программе - что-нибудь поискать. Второе - сразу доступны соседние точки не только вдоль линии сканирования, но и на соседних линиях, что позволяет посчитать нормали к поверхности. Безо всяких предварительных сортировок и прочей глобальной обработки (кроме собственно загрузки/чтения файла). Так что можно сразу запускать последовательную геометрическую обработку скана. Линейные форматы такой возможности быстро не дают, а у трехмерных (octree) вообще своя специфика. Но, конечно, любой бинарный упакованный (или неупакованный) формат с сохранением 2D-структуры может дать такие же возможности, а иногда и еще больше. Например, не читать файл целиком, а идти сразу к нужному месту.
Кстати, у той же Лейки есть формат PTG - обладающий как раз нужными свойствами: двумерный, бинарный, с картой субскана и маской пустых точек. И с выбором точности float/double. Вопрос только в том, кто его умеет читать. И говорят, что перед ним был формат PTZ - тоже бинарная версия PTX - но его описания у меня нет.
Уж с троллем буями мериться точно незачем. Не вы ли недавно спрашали: К вопросу о смайликах прочитайте ещё раз своё сообщение: После двух запросов на пояснение вы выдали: Тем не менее, заявляете: Или вам уже всё-равно какую тему троллить? (Добавление) Mrrl, спасибо. Классно вы тут тему развили! Новое есть, и есть над чем поразмыслить.
Как это я не заметил сразу противоречия... Рассмотрим такую ситуацию. У нас есть линия сканирования, состоящая из точек P1, P2, P3,... Первому пользователю не понравилось, что точек слишком много, и он попросил их усреднить попарно. В его ptx-файле получился столбец, состоящий из точек (P1+P2)/2, (P3+P4)/2, ... - усредненные точки (что, по Вашим словам, нормально). Второй пользователь заметил, что в разных столбцах PTX точки находятся на разных углах относительно горизонта (не образуют решетки с горизонтальными линиями), и попросил, чтобы соседние пары точек проитерполировали, и выбрали на отрезках точки, попадающие на нужные углы. В частности, столбец P1, P2, P3,... пришлось сдвинуть на полточки, и программа обработки выдала (P1+P2)/2, (P2+P3)/2, (P3+P4)/2... - столбец, целиком состоящий из придуманных точек, что, по Вашим же словам, недопустимо. Но нетрудно заметить, что во втором столбце присутствуют все точки из первого (а в первом, в свою очередь, нет ни одной "настоящей" точки). Как же так?
Какое же тут противоречие? Измерений может быть сделано несколько, а вот итоговая точка будет записана лишь одна, как среднее из всех. По крайней мере так делает импульсный Trimble GX , а вы сразу в формулы...
Противоречие в том, что при интерполяции тоже будет записана одна точка, как среднее из нескольких измерений: первая - среднее из первого и второго измерений, вторая - среднее из второго и третьего... Ну и что, что одно измерение участвует в нескольких точках. Так чем же интерполяция хуже усреднения?
Можно так рассуждать, в приводимом вами частном случае, теоретически вы будете правы. Но, если отталкиваться от реалий, то ваша "линейная интерполяция" в последние годы совсем не актуальна. "Среднее арифметическое" ведь ещё ни-кто не отменял, а оно и является частным и забытым случаем интерполяции. Сам же термин "интерполяция" на практике применяем к нелинейным алгоритмам. Сплайнам или МНК, всё болше распространение получают новомодные алгоритмы вейвлетов. Это же особенно справедливо и для алгоритмов экстраполяции, что сложнее. К тому же, в лазерном сканировании при миллионах реально измеренных точек просто глупо ограничиваться на линейке. По боковым точкам вы легко вычисляете нелинейное поведение функции, по которой и с-интерполируете значение на нужном гриде. Но, надеюсь, вы понимаете, что это будет лажой с т.з. самих измерений. Реализация алгоритмов переменного ребра, на котором выполняется интерполяция, и вовсе до сих пор не реализована из-за немощи современной вычислительной техники. В нашем случае и не зачем. Я же исхожу из того, что лазерный сканер - самодостаточный измерительный прибор. Конечно же, в определённых случаях интерполяция может помогать в обработке его данных, но ни в коем случае не подменять сами измерения. Максимум, что дозволительно - это генерировать поправки к измерениям, от сканирующей проги производителя в зависимости от условий работы прибора.
Я с подозрением отношусь к алгоритмам интерполяции, которые затрагивают больше, чем 3-4 соседних точки . "Миллионы измеренных точек" - это очень мало: чтобы шаг между точками хотя бы приблизился к размеру лазерного пятна (1 угловая минута для красного лазера), нужен скан минимум на 200 миллионов точек (т.е. 20000 линий/360 гр). И даже в этом скане, если при обработке вы будете использовать что-нибудь нелинейное (шумодав, повышение четкости...), то разрешение скана (в смысле размера разрешимой детали, а не плотности точек) неизбежно ухудшится. Оно портится даже при линейной интерполяции (к размеру пятна прибавляется расстояние между соседними точками). А вы говорите, вейвлеты... Да, при обработке они могут быть полезны, но скан тут ни причем. Вопрос, который меня здесь беспокоит (и который относится к приведенному случаю - с моей точки зрения, он совсем не частный, а принципиальный) - что делать, если формат (или программа, его читающая) требует точек, выровненных по гриду, а алгоритм работы сканера позволяет получить точки, которые более-менее случайно смещены относительно его узлов/линий. Воспользуетесь ли лично Вы таким сканером? Или скажете, что выровненные точки - это результат интерполяции и лажа, и пойдете искать сканер с идеальным алгоритмом управления? Предполагается, конечно, что в программе управления есть флажок, регулирующий применение такой интерполяции, а где-нибудь на 34-й странице мануала написано, что этот флажок делает. Кстати, что, по вашим наблюдениям, сейчас больше в реальных сканах - шум дальности или поперечное расстояние между точками? Если они хотя бы похожи, то вычислить поведение функции в окрестности точки совсем нелегко...
