В текстовых уничтожена вся структура, пишу это наверное в 10-й раз. TXT, ASC и прочее - это уже не сканы. Какие другие форматы? Зачем же вы смешиваете всё в кучу? Не находите ли, что задачки сохранять разные направления движения точек в строке и попытка оструктурить пересортированный текстовик от Тримбла - несколько разные. В любом случае, это легко можно разделять по вертикальным угловым величинам или как-то ещё,- было бы желание производителя. И правильно делали. (Добавление) Хоть название появилось. По моему опыту, многие форматы не имеют открыто-опубликованных описаний. Приходилось изучать самостоятельно "по-русски". Однако, с PTX-ом работают многие известные софты, они-то точно без спецификаций ничего не сделают... (Добавление) Александр, ваши намёки неуместны. PTX я пользую с 2006 года, когда ещё Faro занимался. (Добавление) А ещё субсканы делают: Trimble, Faro, Optech, Surphaser... Возможно и другие (Добавление) Было у меня уже подобное, писал такую приблуду. Но чаще происходит не разовый скачёк (оператор задел треногу), а ножка штатива проседает иль винт штатива не держит, один раз треггер дурил... Соответственно, весь скан кривой получается. Анализ точек в подобной ситуации результата не даёт. Ну или очень сильно морочиться надо... Реализовал так: раскидывал вертикальное смещение (круговые сканы) пропорционально по всем строкам, а затем как пирог делил на 8 горизонтальных частей и сшивал по-отдельности. Естественно, это был PTX
Да, разбиение на столбцы уничтожено. Но я отвечал на это: "А мне и нужно лишь чтобы скан читался в софте вне зависимости от его производителя. Точность измерения точки на объекте съёмки - обеспечив это, сканер с прогой сканирования отходят на второй план. " Про структуру здесь не было ни слова (и меня это очень удивило). Точность точки есть, скан читается... а то, что "без структуры это уже не скан" - это вопрос терминологии. Я как раз пытаюсь разделить задачи сохранения порядка следования импульсов в скане и сохранения двумерной геометрической структуры. Потому что я знаю, что это разные задачи, требуют разных усилий и дают разные результаты. Пользователю чаще нужна вторая задача. Исследователю (для которого объектом исследования является сам сканер, а не окружающая сцена) вполне может потребоваться первая. Производитель разделит. И даже переставит столбцы так, чтобы они шли слева направо. Но порядок следования точек при этом будет нарушен. Ха-ха три раза. Их тоже пишут небольшие команды. Состоящие из таких же людей, как мы. И тоже, не найдя описания, скажут, что "все и так очевидно".
Намек был вот это;) [/off][/quote]Намёк на что? Поясните что вы имели ввиду. (Добавление) По аналогии с тахеометрией ВОТ ТУТ я всю логику расписал с т.з. данных. От производителя инструмента требуется выполнение 2-х задач: обеспечить выполнение (с определённой в ТХ точностью) каждое единичное измерение и предоставить пользователю результаты измерений для дальнейшей работы. Данные необходимо предоставлять в структурированном виде для их дальнейшего свободного использования. Скан - это структурированные данные измерений, данные без структуры (unsorted) становятся просто облаком точек, финальный результат. Вы полагаете, надо каждый раз писать очевидные вещи?
Samara Ну, ясно. Из всей возможной "структуры" в пределах одного субскана Вам надо, чтобы точки были отсортированы по некоторой сетке в некоторой (одной из многих) системе коородинат, а именно, в псевдосферической. Ни порядок, ни происхождение точек, по-видимому, не важны (хотя интерполированные точки Вам не годятся - вероятно, пустое место в массиве устроит больше, да и усредненные точки, наверное, тоже не понравятся - хотя все точки во всех сканерах, в конечном итоге, являются результатом некоторого усреднения). Что же, это один из многих возможных способов структуризации - Range Image. В случае сферической развертки более-менее можно сопоставить линию сканирования отдельной строке или столбцу растра. Для других типов развертки (например, спиральных - отлично подходящих для какой-нибудь камеры слежения, но совсем не популярных в наше время) это может быть совсем не так. Для других задач PTX с его способом сортировки - не самый удачный вариант. Для построения замкнутых тел больше подойдет растр, созданный в истинных сферических координатах, со скомпенсированными искажениями. Но в нем точки будут интерполированы. Для глобальной регистрации и для визуализации больших облаков удобнее структура с пространственной сортировкой (Octree). Так что универсального удобного формата найти не удастся. А максимально сохраненная структура скана была бы в формате, где точки следовали бы строго в порядке сканирования (для случая сканирующей точки, а не линии и не площадки со структурным светом) - и для каждой точки записано 7 (или больше) координат - 3D, яркость, измеренная дальность и показания всех (2 или больше) датчиков развертки. От обрабатывающей программы при этом не будет требоваться знать конкретные параметры модели сканера - внутренние координаты будут использоваться только для контроля непрерывности и взаимного расположения точек. Тогда бы каждый мог строить из этого потока PTX или другие представления скана так, как ему удобно, и единственной претензией было бы то, что с этим форматом невозможно работать (а ответом - "вы сами этого хотели" ).
Mrrl, столько много умных слов, усложнений и теорий, а в итоге - на выходе тривиальный TXT , потому, что иные форматы несовершенны с вашей т.з. ??? А я говорю обратное: несовершенны приборы, программы, системы в целом, которые не способны на выходе представить свои сканы в общеупотребимом виде. По крайней мере, такие приборы не должны входить в общую линейку вида приборов. Потому, что это уже не сканер, а "облакоточкер" (утрирую тут конечно ж). Вот с Риглем-то что получается? сама железяка хорошая, красивая и надёжная, всем нравится, но она не способна выдать данные в структурном виде. Т.е. либо разработчики лоханулись (скорее всего это не так), либо это жлобская политика бренда. Не выдачей сканов пытаются привязать юзера к своим продуктам. Уверен, что по заявляемому функционалу, РиСкан делает всё то же, что и другие софты по обработке. Получается: "Купите у меня молоток, а вот и специальные гвозди к нему, поскольку только они подходят для работы с нашим шикарным молотком". Что вы называете псевдосферической СК? Порядок, происхождение, температура, данные компенсатора и прочее - важны лишь сканирующей проге для коррекции единичных измерений от своего прибора. Копаться в этом пользователь не должен по определению. Как максимум, выполнять определённые действия на уровне чёткой инструкции. Равно как сканер не должен выдавать интерполированных (придуманных) точек. Пустое место в сетке свидетельствует об отсутствии отклика на входящуу апертуру прибора с конкретной дискреты (н-р, небо). Или сигнал сравним с шумами. Усреднение из нескольких измерений - это нормально и полезно для точности. От буржуйских коллег приходили PTX-сканы с постоянным приращением горизонтального угла (модель сканера не уточнял), подшивались без проблем. Да, координатная проекция спиральной развёртки будет выглядеть кривоватой, но это проблема восприятия. Число измерений в строке и число самих строк - постоянные величины с нормальной структурой, без проблем укладывающейся в PTX. Не аргумент. Идеального в мире нет ничего. Однако, человек создаёт регламенты, спецификации и всё развивается. Максимально сохраненная структура скана - это формат производителя. Если кто не доверяет производителю и хочет юзать свой алгоритм поправок, пожалуйста, вот сырые данные. Опять же, исследователям разным... Подавляющему числу пользователей этого не надо. Его интересуют готовые единичные измерения от прибора в любом структурированном виде, пригодном для дальнейшей работы в привычном для него софте. Для простоты понимания аналогия следующая: Ваш партнёр просит вас прислать проект договора. 99% людей скинет ему DOC-файл, потому, что этот формат де-факто стал стандартом в документообороте и читается хоть на маках. Но всегда найдутся умники, которые сделают экранные скриншоты и пришлют JPG-файлы, текст-то ведь читается А на недоумение начинают пояснять о сложностях и перепетиях их крутейших технологий для изготовления DOC-файла. Исход такой ситуации очевиден: будут посланы подальше со всеми ихними пупер-технологиями. Договор же будет согласован и исполнен с другими партнёрами. Всё. Надоело уже объяснять, почему в НЛС я не пользуюсь шикарными сканерами Riegl.
Систему коородинат, в которой точки отсортированы не по истинным азимуту и углу относительно горизонта, а по тем углам, которые выдали датчики сканера. Без коррекции отклонений параметров реальной развертки от идеальной. Система, конечно, хорошая. Строится быстро, каждая точка - в своей клетке (если движение было достаточно равномерным), но вот неопытные пользователи приходят в недоумение, переходящее в панику, когда обнаруживают нестыковки на линии, соединяющей левую и правую половины картинки (в 3D, конечно, никаких нестыковок нет). И программы, которых хочется узнать, лежит ли какая-нибудь точка перед сканированной поверхностью, или за ней, не могут это сделать сразу (по направлению на точку) - им приходится примерно угадывать положение на картинке и перебирать соседние точки. Если бы столбцы и строки в PTX соответствовали истинным сферическим координатам, им было бы легче. Но кому-то - сложнее. А как нам быть с участком, плотность измерений на котором гораздо меньше углового разрешения ptx? Программам может не понравиться, что каждая вторая (например) точка пустая. Придется выделять отдельный субскан? Ага. Если эти измерения не на краю объекта. Но хоть на этом спасибо. Спиральная развертка - это у сканеров, предназначенных для сканирования небольшого сектора пространства. Например, не дальше 30 градусов от некоторой оси. Луч там движется не по строкам/столбцам, а по архимедовой спирали, раскручивающейся вокруг центральной оси. Это позволяет гораздо быстрее отсканировать выбранную область с нужной плотностью (луч не уходит в ненужных напрвлениях), но возникают проблемы с лазерной безопасностью (луч слишком много времени проводит в центре сцены). Наверное, поэтому такие сканеры и не делают. Уложить такую картинку в PTX можно, но она будет совершенно неузнаваемой (примерно как изображение потолка в обычном PTX - если его половинки склеить макушками). Подозреваю, что 25% пришлют PDF. Он гораздо красивее выглядит, и они давно привыкли отправлять и получать готовые документы в этом формате. Чем же проект хуже? ;) А с тем, что PTX - стандарт, удобный для многих программ, я не спорю. Я не согласен только с тем, что он "сохраняет структуру скана". Сканы-то по-разному получаются, а формат один на всех. Для одних сканеров он, может быть, действительно повторяет структуру, а другим приходится выкручиваться, чтобы ему угодить. Кстати, при сканировании на сильном ветру столбцы PTX могут начать переплетаться. И это нравится не всем программам обработки - некоторые падают, даже наткнувшись на невыпуклый 4-угольник, не говоря уже о самопересекающихся и вывернутых наизнанку. Приходится переставлять точки между соседними столбцами. Струтура потока снова нарушается, зато все довольны.
Не а, не получается! Дело в том, что если вы покупаете "молоток", то в придачу вам дают и "гвозди". Так что они получаются условно бесплатными, как в свое время TGO к GPS приемикам Trimble. Такова политика так нелюбимого Samara бренда RIEGL. Кстати, если не нравится, то можете пользоваться и "гвоздями" иных производителей, привычных вам, что некоторые пользователи и делают. (Добавление) Вопрос только КАКОГО бренда?! Политика бренда RIEGL раньше была такой: "Ребята, мы делаем сканеры и стараемся делать их хорошо, дальше с полученными данными можете делать всё что хотите, вот вам софтина для этого." Я могу только предполагать почему с форматом PTX как-то у них не сложилось, но думаю тут не только в политике RIEGL дело, а и в том, что возможно какие-то ограничения есть на, например, использование данного формата (чисто юридические) - не допускаете такой момент? Просто ваш "любимый бренд" не хочет открывать вашему "не любимому бренду" все подробности данного формата, как Вы думаете? Как я понял видимо вы будете полностью счастливы, если из RiSCAN PRO можно будет получить данные в PTX. - Так?
Я навскидку не помню, но если мне не изменяет память, ptx - это ascii формат. Ну и по опыту работы я его старался никогда не использовать, да и не использовал в принципе, так как данный формат имеет ряд существенных недостатков, например: 1. это ascii формат, а не, например, бинарный без сжатия как rxp, или бинарный со сжатием, как zfs, что ведет к тому, что данные занимают существенно больше места на диске по сравнению с двоичным файлом. Кроме того, пользователь при желании может открыть файл простым блокнотом и подредактировать данные вручную, что может привести к нарушению структуры скана; 2. сохранение структуры в том виде, в котором это описал Samara - весьма сомнительная затея по сравнению с уменьшением производительности чтения и обработки такого файла в несколько раз вследствие того, опять же, что это символьный файл; 3. кроме того, как писал Mrrl, бывают случаи неоднозначной трактовки данных из этого файла Ну а ваши, Samara, нападки на Ригль не имеют никакой почвы. Вы заикнулись про открытость. Z+F и Riegl дают библиотеки и подробные описания к ним, первые за небольшие деньги, вторые, кстати, бесплатно. Кроме того, в описании к программе РиСканПро можно найти полезную информацию о структуре различных файлов, входящих в базу данных РиСканПро, с помощью которой человек, мало-мальски знакомый с азами программирования, может читать эти файлы самостоятельно. У Leica такого не было и нет, насколько я знаю. Так что я не пойму, какой реальный выигрыш получает пользователь от использования формата ptx в вашем понимании "сохранения структуры". Например, сохранение структуры zfs файла в смысле порядка сканирования точек позволяет работать с этими файлами с очень высокой скоростью. Кроме того, этот файл скачивается непосредственно с прибора и работа происходит непосредственно с ним; в нем сохраняется вся информация о данном скане (марки, регистрация, цвета, маски и т.д.). Вот приведите конкретный производственный пример?! Допустим, я использую для хранения и работы тот же формат las, а вы - ptx. Я могу загружать точки в этом формате в большинство ПО с высокой скоростью, которая объясняется грамотно продуманной структурой файла этого формата, могу эти точки классифицировать, раскрашивать в реальные цвета, он занимает меньше места, чем ascii форматы, т.к. хранит числа, а не символы. С другой стороны, файл этот является обменным форматом, т.е. теряется порядок записи импульсов приемником сканера и всякая другая структура. Вы используете ptx, в чем ваше преимущество? Только не надо такого "если я сделал что-то до этого не так, я смогу вернуться и подправить", хорошо? Я предполагаю, что и я, и вы достаточно грамотные специалисты и делаем все сразу хорошо. Ну и без высеров, что единственный грамотный специалист - это вы.
Mamont, вы как всегда, что-то недопоняли, что-то исказили. По прочтении хотел ответить по пунктикам, но после "высеров" таковое желание пропало.
Нечего ответить? Оффтоп (Move your mouse to the spoiler area to reveal the content) Про Leica и 20 см это было по мотивам: http://www.navgeocom.ru/projects/671/4565/ Какая точность была при детальности 20 см?
А чего там отвечать? Все и так понятно. (Мне все равно, что защищать - аргументов достаточно для любой стороны. Поэтому я никогда не могу выбрать единственное правильное решение) PTX регулярно выигрывает у бинарных форматов без сжатия (особенно, если они сохраняют двумерную структуру облака) по двум причинам: - во-первых, за счет нулевых точек. В монохромном PTX такие точки занимают 8-9 байт ("0 0 0 0" + перевод строки). В неупакованном бинарном формате - по меньшей мере, 14-16, а то и 32 (в зависимости от того, на какую точность рассчитывают авторы формата). Конечно, можно такие точки выкинуть, добавив в бинарный формат битовую маску хороших-плохих точек, но тогда начнутся сложности с навигацией, которая могла бы быть преимуществом неупакованного бинарного (придется помнить, как минимум, карту расположения столбцов и аккуратно с ней работать). Формат усложнится. - ASCII-формат позволяет легко управлять разрядностью сохраненных в нем данных вообще без изменения формата: хотите 11 значащих цифр (1 микрон на 100 км) - пожалуйста (и отдельные пользователи/программы подобных вещей действительно хотят). А не хотите - можете обойтись 5 знаками (1 мм на 100 м), тогда точка займет 24 байта текста. Переменная точность в бинарном формате - редкость: дали вам 4 или 8 байт на координату - и не вздумайте требовать больше или меньше. Опять же, может быть и по-другому - но опять за счет усложнения формата (к чему оно ведет - см. пункт 4). Так что то, что "бинарный формат экономнее, чем ASCII" - далеко не аксиома. Как ни странно. Открыть файл простым блокнотом - хорошая идея. Но, к сожалению, неосуществимая. Даже для небольшого скана в 50 миллионов точек (плотность 1/4 по шкале FARO, 8x по шкале Leica, если не ошибаюсь; время сканирования - 3-5 минут) размер PTX будет порядка 1 ГБ. "Простой блокнот" надолго задумается, прежде чем открыть такой файл. Бинарные редакторы справятся гораздо лучше. Это верно. Но только при условии, что бинарные форматы сохранения чисел являются "родными" для компьютера, на котором файл читается. Если вдруг окажется, что порядок байтов в записи целого числа другой (от старшего к младшему), или вещественные числа имеют не такой формат, то распаковывать двоичный формат будет не легче, чем преобразовывать строку цифр в число. А если формат как-нибудь упакован, то вообще со временем распаковки может быть что угодно. Насчет "трактовки" я не говорил. Просто авторам спецификации было бы неплохо указать требования на расположение точек. Вроде ограничения на угловые смещения точек в соседних столбцах, или на топологию полученной сетки, или какие-нибудь ограничения на направление нормали... Формат создавался в те времена, когда старт-стопный режим медленной и даже быстрой разверток был вполне осуществим. Какая скорость была у Cyra? 1000 точек в секунду? Вот они и предполагали, что направление луча для каждого измерения устанавливается с хорошей точностью, и все точки попадают на регулярную прямоугольную решетку. Сейчас сканеры стали на 3 порядка быстрее (в соответствии с законом Мура, как ни удивительно), так что даже тормозить мотор панорамы им вредно, лучше пытаться обеспечить стабильность его вращения и устойчивость. А программам, читающим PTX, надо быть осторожнее с предположениями. Только и всего. От библиотек (возможно, не этих фирм, но многих других) у меня только негативные впечатления. Во-первых, документация никогда не бывает полной. Всегда есть предположения о взаимосвязях данных и о способе использования, которые авторам кода и документации кажутся очевидными, а пользователям - не только неочевидными, но и неподходящими. Во-вторых, могут быть ошибки, про которые никак нельзя узнать - вызваны они неправильным использованием, имеются в самой библиотеке, или причина - в неправильных данных (т.е. ошибка где-то в выхывающем коде). Особенно грустно, когда дают библиотеку только для сохранения файла, а возможности прочитать формат (для проверки) нет. И в-третьих, платформы развиваются (даже в рамках Windows появились и 64-битные системы, и .NET) - и библиотеки не всегда поспевают за этим развитием. Ну, и вызов чужого кода может негативно сказаться на общей архитектуре и эффективности проекта - подключать целый модуль, чтобы работать с одной-единственной чужой dll - не очень приятно. Описание формата в этом смысле лучше. Хотя и там есть проблемы с интерпретацией и допущениями на структуру данных. Даже в одной страничке описания ptx есть двучмысленности - что такое z-координата в матрица ориентации сканера, и в какой системе координат ориентация дается (в той, в которой записаны точки, или после применения второй матрицы). Посмотрим, как у меня получится реализовать (по описаниям) LAS и PTG :) Какая была - не знаю, но теоретически может быть любой, хоть полмикрона. Главное, чтобы каждая приведенная в выходных данных точка находилась не дальше, чем... от какой-нибудь точки поверхности объекта. Тогда можно будет построить и плоскость по 3 точкам, и цилиндр по 6, и линию пересечения двух плостостей найти. Насколько они будут соответствовать реальности, неизвестно (зависит от того, насколько реальная форма соответствует идеальной), но к пуговицам претензий не будет - они все пришиты к поверхности костюма. А вот почему проект 2011 года назван "хвастливым", мне очень интересно.
au78, вам действительно надо учиться, прежде, чем делать какие-либо выводы на форум... Детальность - это параметр моделирования. Для данной работы моделировались все элементы, крупнее 20 см. Максимальный "пирог" в той работе составил 7мм, да и то из-за вибрации (в ТЗ было 20мм). Сканировать и сшивать можете хоть с милиметровой точностью, а моделировать, например, только крупные объекты: балки, колонны, стены... И обратно: проблемы начинаются, когда моделировать надо металлоконструкции с точностью, например, 5мм, а неуч-оператор отработал и сшил сканы с сантиметровыми пирогами. Обычно в таких случаях камеральщица убивает сканеровщика ::war.gif::
Вы геодезии то хоть учились?;) Али фотограмметрии? Самородок Вы наш. Будем знаниями мериться? Читайте вопрос внимательно. Точность с детальностью я не смешивал. А если Вы на счет этого, то просто забыл смайлик любимый поставить, а Вы приняли за чистую монету;) http://geodesist.ru/forum/topic.php?forum=50&topic=85&postid=1329764814#1329764814
Про нулевые точки согласен. Про разрядность: пусть вы и записали в ascii формат 11 значащих цифр, но если программа представляет координаты в виде float, то больше 6-7 знаков после запятой вы не сохраните в ячейку памяти для дальнейшей работы:) Ну и про бинарные редакторы тоже не новости)) Кроме того, не забывайте простые вещи: если вы используете бинарный формат, то туда записываются непосредственно числа, а если ascii, то перед записью каждое число переводится в набор символов, а при считывании - из набора символов составляется число. Так что если даже бинарный файл будет занимать больше места, скорость работы с ним все равно выше:) Возьмите, например, ту же РиСканПро. Для хранения угловых величин полярных координат используется число Мортона, при этом его разложение не оказывает серьезного влияния на производительность. Тот же zfs формат использует алгоритм сжатия (самый простой), при этом производительность ПО для работы с этим форматом (Z+F Laser Control) много выше и РиСканПро, и, тем более, Cyclone (создателям которого мне очень охота посмотреть в глаза;)). Про библиотеки. Это ваше впечатление. Но документация у меня серьезных вопросов не вызывала, все ясно. Про то, что библиотеки не поспевают за развитием - смотря, какие библиотеки. Сужу опять же по SDK от Ригля - это заголовочные файлы на С/С++ и lib-овские библиотеки, поэтому с производительностью никаких проблем нет. Конечно, если использовать управляемый код (например, dll библиотеки на NET), то производительность будет низкой (относительно). Для обработки больших массивов данных ничего быстрее неуправляемого кода (C/C++) еще не придумали. Ну а то, что ошибка может быть в вызывающем коде: ПО для обработки сканирования и SDK пишут не дилетанты, оно тестируется; да, ошибки могут быть, но скорее всего, что ошибку сделаете вы, когда начнете писать свои алгоритмы чтения файла по спецификации формата, которой еще и нигде официально нет, как для того же PTX формата. Про то, что лучше давать структуру файла, а не библиотеку. Опять тот же Ригль сначала давал описание файла rdd, но потом стал давать именно статические библиотеки с заголовками, т.к. у пользователей возникала куча ошибок из-за собственной невнимательности:)
Во-первых, это трудности программы. Исходные данные важнее, а программу можно взять и другую (или пересобрать с использованием более точной арифметики). А вот если вы в формате используете тип float - то нарисовать гайку на опоре моста в геоцентрических координатах (а почему бы и нет?) не получится никак. Во-вторых, программе никто не мешает разбить облако на небольшие (по диаметру) фрагменты, и хранить в формате float смещения относительно центра (а центр - хоть со 128-битной точностью, если надо). Правда, я для координат предпочитаю int :) Попробую как-нибудь сравнить скорость. Будет интересно. Ну, не знаю, просто ли будет вызвать 32-битную static C++ библиотеку из-под C#-кода в 64-битном режиме. И не проще ли будет написать по спецификации чтение/запись формата. Ага, тестируется. Производитель обрабатывающей программы говорит производителю сканера: вот вам dll для генерации нашего формата, сделайте, чтоб ваша программа его экспортировала. А свой вьюер я вам не дам, потому что он денег стоит. И как в таких условиях тестировать? Только уговорить их проверять файлы самим. А они в ответ: а что это у вас в сканах ступеньки по 1.6 мм? Где обещанные 100 микрон? А оказалось, что они пытаются 100 метров уместить в 16-битное целое число :) Хорошо, что файл был неупакованный - удалось понять это двоичным редактором :) А лучше бы и то, и другое...
То, что вы описали - это реализовано в формате las. Попробуйте. У меня получилось, что преобразование символов в числа требует большего времени, чем преобразования непосредственно чисел. Нет, в С# вызывать lib нельзя. Только писать оболочку, компилировать dll и уже над ним устраивать танцы с бубном. Я в своей программе сделал внешний exe-шник на С++ для чтения файлов, а в C# - уже работу с этими данными. Ну а по-честному все равно C# работает медленнее в плане обработки больших массивов данных, т.к. C++ обращается непосредственно к памяти, а C# - через платформу NET. Просто я решил немного пощадить свои силы и не заморачиваться с C++. Можно написать unsafe-код, но в этом случае теряется всякий смысл использования C#. Для сравнения можете написать небольшую программку на том же С# для прохождения по всем пикселям изображения в виде обычного и unsafe-кода и протестируйте, разницу сразу прочувствуете.
В PTX тоже. Если перевод в геоцентрическую систему конкретного субскана задать матрицей. Попробовал. Язык C++, собрал в 32-битной версии. Программа должна была распаковать 10^9 точек, координаты которых - целые числа от 0 до 2^21-1. В одном случае они были записаны в строке как ASCII (разделенные пробелами или \n), в другом - упакованы в 63-битные числа Мортона (если я правильно понял, что это такое). Распаковку я в обоих случаях пытался сделать максимально эффективной (но не очень упирался). Итог: на распаковку одной ASCII-точки ушло 19.968 нс, на одно число Мортона - 22.027 нс :) Я бы сказал, разницы никакой :) Код (для VS2008) прилагается. Да, про LockBits я знаю. И unsafe-кода не боюсь - выигрыш от остальной части библиотеки .NET перевешивает возможные опасности unsafe :) Кстати, в большинстве случаев unsafe почти не дает выигрыша (я его пытаюсь использовать, чтобы не проверять индексы в массиве, но C# их проверяет достаточно эффективно). (Добавление) Update: в 64-битном режиме распаковка ASCII замедлилась в 1.4 раза, а распаковка числа Мортона - ускорилась более, чем вдвое. Половину времени в 32-битном режиме занимал сдвиг 64-битного числа на 20 бит.
Согласен, разницы заметной для конечного пользователя нет. Но по своей натуре я тяготею больше к двоичным форматам, нежели ascii, чтобы никто не лазал там особо. Ну и плюс есть разные удобные вещи, легко реализуемые с помощью бинарников, например, не читая облака определить, сколько в нем записано точек и т.д. Но это дело вкуса:) Про тот же формат PTX - опять же, не могу понять конечную цель использования данного формата. Данные да, структурированы в некотором виде, а вот в чем преимущество по сравнению с другими форматами, кроме "если что-то пойдет не так" - не вижу. Свои доводы про las я уже привел.
