Существуют ли конвертеры связи для состыковки данных с разных программных обеспечениях!! например с одного сканера и другого объединить информацию чтобы получилась картинка,есть ли такие программные обеспечения!!!!
Я так понимаю, что суть вопроса в том, как конвертировать облака точек из одного формата в другой, правильно я вас понял? Как правило, все программы "понимают" формат *.las, через него и можно произвести конвертацию.
Мне кажется, в данном случае просто нужно все облака точек, имеющиеся в наличии, привести к единому формату (хоть бы и txt, например), а потом работать со всей этой информацией в любом софте. Ну, или в том, который есть :) Главное, что бы тот формат понимал. Как вариант, использовать кадовский dwg. Главное, не открывать его в автокаде ::asleep::
Классный вопрос! ::respect:: Конверторы существуют: каждый бренд пишет их под своего софт-монстра, обрабатывающего его же сканы. Но единые стандарты пока отсутствуют. Как правило, текстовые форматы (TXT, ASC, XYZ) всасывают все. Через текст вы получите единую картинку от своих разных сканеров. Но проблема в том, что текст - это уже финальные данные, т.к. в этих форматах структурные данные от исходного скана уже утрачены. Трансформации этих облаков сильно ограничены объёмом оперативки и быстродействием компа. Проекты в несколько десятков текстовых сканов от фазового сканера и вовсе становятся трудноперевариваемым объёмом. Проще говоря, это происходит потому, что для системы обработки объектом уже становится не скан, а каждая отдельная точка. А их в современном облаке миллионы-миллиарды. Представьте себе, что все файлы вашего компа со всех папок и дисков оказались в одной куче. Лекго ли вам будет работать с подобной организацией информации? Жлобские бренды как специально экспортируют из себя только текстовые форматы. Вот тут-то и начинаются проблемы по обработке облаков от разных приборов или просто в ином софте. Три года назад мне пришлось самому написать конвертор, что бы перебивать тримбловский формат в нормальную структуру. В итоге, сканы от GX легко шьются в Поливорксе совместно с Лейковскими иль Фарошными сканами. Таким образом, действительность такова, что каждый камеральщик индивидуально настраивает технологическую цепочку под решение своих конкретных задач. На мой взгляд, самый удобный формат, это не LAS, а PTX. Сканы в PTX-формате сохраняют всю структуру измерений, выполненных сканирующей системой. В нём понятны трансформации, произведённые над каждым конкретным сканом проекта. Можно легко работать с субсканами, строками, цветом... Можно корректировать данные, например, перетрансформировать при уточнении геопривязки от геодезистов. В общем, самостоятельно делать всё, что захочешь и без использования дорогих монстрообразных софтин.
В RealWorks можно подгрузить родные форматы ригля *.3dd, ASCII, *.xyz (просто изменив расширение у ASCII)
Отсюда: http://geodesist.ru/forum/topic.php?for ... 1330330263 Конечно придется ... особенно после вот этого: В той самой "закрытой" системе это всё легко делается изменением (коррекцией) самого фотоснимка, который сохраняется в том числе и как отдельный файл. Не уж-то в Cyclone этого сделать нельзя? У вас вместо этого куча действий: И еще о "закрытой системе". Она настолько закрыта, что в ней есть иморт в том числе и в *.PTS (Cyclone), а вот есть ли экспорт из Cyclone в тот же *.3DD (RiSCAN PRO)? - Сообщите пожалуйста!
отсюда: http://geodesist.ru/forum/topic.php?forum=50&topic=85&postid=1330496872#1330496872 Samara, Не подскажете, для чего может потребоваться порядок следования точек в скане? И как Вы его извлекаете из PTX-файлов? Ведь нужна информация о направлении сканирования (по или против часовой стрелки), о направлении движения точки сканирования (вверх или вниз), да и вообще - шло сканирование по столбцам или по строкам. А если в ptx присутствуют данные с передней и задней сторон сканера, причем для экспорта выбраны разные диапазоны углов "спереди" и "сзади", то определить взаимный порядок следования точек можно разве что по косвенным признакам. Кстати, есть ли хоть где-нибудь документация по формату PTX? Поиск по сети дает в лучшем случае ссылку на сообщение с английского форума по лазерному сканированию. А для чего может меняться порядок следования точек - в общем, понятно. Для повышения скорости обработки: на многоядерных процессорах скан может параллельно обрабатываться с разных точек (и сохраняться по мере вычисления координат). Для экономии размера файла - самое эффективное представление без потери информации о координатах это разновидности octree, а в них точки отсортированы не по времени, а в пространстве. И еще кстати: а разве PTX - не текстовый формат?
Не нужно ничего самому писать, изобретать, настраивать сложные технологические цепочки... LAS > PTG, 3PF, PTS 3PF > PTG, LAS, PTS 3DD > PTG, LAS, 3PF, PTS PTG > LAS, 3PF, PTS PTS > PTG, LAS, 3PF PTX > PTG, LAS, 3PF, PTS Этот конвертер поможет Вам решить многие проблемы. http://3dlasermapping.com/index.php?opt ... Itemid=147
Какой-то дилетантский вывод. А вот указанный конвертор действительно полезен, хотя и содержит далеко не все варианты.
Так Вам нужны "отсортированные понятным образом" данные, или данные, отсортированные в порядке сканирования? Это очень разные вещи. Многие хотят, чтобы данные были отсортированы по углам (и структурированы в виде двумерной картинки), как в PTX, но порядок сканирования им не важен. Соответственно, когда я открываю PTX, я вижу один или несколько прямоугольников. Как эти прямоугольники возникли - столбец за столбцом слева направо, или справа налево; возникали строчки столбцов сверху вниз, снизу вверх или одновременно (а может быть, весь PTX возник одновременно - каким-нибудь структурным светом), или сканирование шло по строкам - этой информации нет. Субсканы - это отдельные прямоугольники со своими размером, диапазоном углов и разрешением? К сожалению, не все программы их понимают (примера привести не могу, но жалобы пару лет назад были - не то от пользователей PoinTools, не то от RapidForm). Сканирующей программе порядок следования был известен - пока она не экспортировала облако точек. Но чтобы определить, между какими столбцами передней половины скана находится (по времени сканирования) тот или иной столбец задней половины, надо не только считать азимуты точек, но и учитывать геометрические особенности развертки. А их Вам никто не скажет. Обрабатывать проще структурированные. Но разным алгоритмам удобнее разные структуры. А создавать бывает проще точки в том порядке, в каком они стали известны создающей скан программе - и на пересортировку она может потратить драгоценные десятки секунд (а потом окажется, что конкретному пользователю порядок был не нужен, и он все равно все пересортирует). А про "структуру" сканов - что-нибудь кроме разделения на "субсканы" и на столбцы в эту структуру входит? Экспортировать ее несложно, если формат экспорта ее поддерживает и читающие программы понимают. Тот же PTX вряд ли поддержит скан, в котором вертикальная и горизонтальная плотность сканирования плавно меняется (а смысл в таких сканах есть - за один проход получаем и общую картинку и области интереса - экономится время в поле). А если такой скан будет "разобран" на виртуальные субсканы с разным разрешением - Вы же первый будете говорить про скрытие структуры и "интерполированные точки" (хотя в реальности там будет только прореживание). А насчет формата PTX - может быть, Вы все-таки знаете, где его можно найти? Иначе весь разговор про структуру сканов и сохранение/сокрытие информации оказывается обсуждением слухов и борьбой частных точек зрения :(
Углубляться можно до бесконечности. Давайте вернёмся к сути. Необходим некий обменный формат содержания данных сканирования, который поддерживается известными брендами и софтами. Хоть PTX, хоть XXX . Просто PTX поддерживают очень многие, по-этому он де-факто становится межплатформенным. А мне и нужно лишь чтобы скан читался в софте вне зависимости от его производителя. Точность измерения точки на объекте съёмки - обеспечив это, сканер с прогой сканирования отходят на второй план. И весь остальной софт этого бренда - лишь один из вариантов по обработке данных. Именно об этом писал вот тут. Порядок сканирования не важен. Чесно говоря, я даже не могу представить для чего он может понадобится, в практике не было таких задач. Для PTX-а по-моему важно лишь что бы в пределах одного субскана соблюдалось единообразие направлений во всех строках и порядок самих строк. Даже если вы получите данные одновременно "структурным светом" , вы легко обеспечите порядок сохранения в соответствии с заданным форматом. Экспорт-то делается на компе, Сканеры не пишут сразу в PTX Можно сказать и так. Именно по-этому корректно экспортировать, например в PTX, должна сама сканирующая программа. По порядочку, с каждого режима - в отдельный субскан. А копаться потом в несортированном мусоре точек - никому не интересно. В строке обычно до нескольких тысяч точек. Сортировка тут заключается лишь в порядке записи этой строки в файл: прямой или инверсный. Делается это не сканером, а компьютерной прогой в соответствии с требуемым форматом, поэтому "драгоценные десятки секунд" - не аргумент. Входит. Четкие границы строк и столбцов, афинная матрица преобразований, включая и масштабы по осям. Разрешение в субсканах может быть разным (проверено). Про плавное - не знаю. В любом случае, сканер-то эту плавность всё равно делал дискретно, просто на каких-то дискретах отсутствовало измерение. А это так же легко укладывается в идеологию того-же PTX-а. Вы видели там нулёвые точки? Не знаю, не я его вводил, даже не знаю кто его автор... А зачем описание? Там и так всё очень понятно.
Ну, этому критерию удовлетворяют многие форматы, вне зависимости от того, как в них расположены точки. В том числе, нелюимые Вами текстовые форматы. Не Вы ли писали, что "От Тримблов встречались такие текстовики, в которых не сохранена даже последовательность единичных измерений...", выдавая это за недостаток? Я так понял, что последовательность важна. И представить, зачем это может понадобиться, могу легко. Например, если кто-нибудь напишет программу регистрации, компенсирующую возможные движения треноги во время сканирования, или температурные дрейфы за время скана, которые не смог компенсировать производитель. Правда, пока я о таких программах не слышал, но мало ли, что в мире делается. "По порядочку" и "в отдельные субскан" - несовместимые свойства. Ведь сферический сканер за каждый оборот сканирует и переднюю и заднюю стороны сцены, поэтому данные должны попасть либо в разные участки одного субскана, либо в разные субсканы. Иначе Вы увидите в PTX-файле (в 2D-картинке) заднюю сторону сцены, висящую над передней в зеркально отраженном виде. Большинству пользователей это может не понравиться. Как угодно. Я думаю, что когда сканов много, то и для программы лишняя минута на обработку может быть важной. А я имею в виду ситуацию, когда программа обрабатывает скан на многоядерном процессоре (читая его с нескольких точек одновременно) и скидывает результаты со всех ядер в один текстовый файл. Но это действительно не очень важно, узкие места у обработки будут совсем другими. В первую очередь, описание - чтобы его корректно создавать. Например, я недавно с удивлением узнал, что некоторые программы требуют, чтобы все координаты были только в метрах. А другие (судя по недавнему комментарию на английском форуме) пытаются читать их в футах. И насчет "понятно" я тоже не уверен. Правда, я ориентируюсь по примерам PTX 6-летней давности, с тех пор формат мог развиться. В том, что я видел - размер прямоугольника (число строк и столбцов), какие-то две матрицы и дальше точки. Понять, зачем нужны две матрицы, для чего каждая из них - без описания не получается. Допускает ли формат точку с нулевыми x,y,z и ненулевой интенсивностью (для случая, когда сканер смог увидеть яркость, но не смог измерить дальность) - непонятно. Куда и в каком виде вставлять диапазоны углов и угловые разрешения - непонятно. И как правильно оформлять субсканы, чтобы их все понимали? Я писал их подряд один за другим, но клиентам это не понравилось :(
Ответ от Лейки про формат PTX мало что прояснил. Про метры там написано, для диапазонов углов и углового разрешения места нет, но про матрицы все весьма запутано. Строчки с 3 числами - "scanner registered position and axes" - но в какой системе координат -не очень ясно (вероятно, в той, в которую идет пересчет с помощью второй матрицы). Не указана конвенция на направление осей сканера (вертикальная - Z? или может быть, Y, как было принято в Open Inventor в начале века?). И что самое интересное, документ с описанием формата, де-факто являющегося стандартом в этой индустрии, не удается найти в сети, даже зная его название: "HDS PTX Point Cloud Interchange Format".
Формат, насколько я понимаю, cyclone-овский, а Cyclone теперь лейковский, несмотря на свое название :)
Субсканы, насколько я знаю, делает только Leica, поэтому и PTX реально может пригодиться для обработки сканов, сделанными сканерами данной фирмы. Остальные сканеры, насколько я знаю, просто последовательно пишут измерения в порядке поступления на приемник сигналов. Такую программу я писал для формата *.rxp риглевого, но в таком подходе есть свои подводные камни, поэтому эту идею я отложил. Например, частота фиксации колебаний штатива должна быть высокой, да и колебания эти должны быть плавными, тогда эти колебания можно реально учитывать, а иначе получается ерунда.
Для повышения точности сканирования? И какой выигрыш даст учет этих эффектов? Некоторые 20 см точность сканирования получают сканерами Leica.
Нет, для повышения точности итоговой сшитой сцены. Выигрыш может быть значительным: если программа догадалась, что в такой-то момент на таком-то скане тренога повернулась/наклонилась на пару угловых минут (и определила, куда именно), она может применить компенсирующее преобразование ко всему участку скана после этого момента. Или просто разделить скан на половинки "до" и "после", и учитывать их при регистрации независимо. (Добавление) PTX может пригодиться для экспорта данных из любого сканера (если программа обработки согласна выдать такой формат) в любую программу для дальнейших обработок (если она согласна прочитать PTX и они имеют общее понимание о формате). А субсканы... наверное, у разных сканеров для этого есть разные названия (и разное понимание, какими эти "субсканы" могут быть).
