2 kg_vista - как на счёт mrsid???

[Bushman]

Разберем ту же задачу на примере того, как работыет GlobalMapper. Во-первых, что mrsid, что ecw могут быть в какой угодно проекции (как, в общем, и любой графический образ карты, к которому приложен ESRI world-file и projection file). Например, mrsid с сервера ESAD - в wgs84/utm.

Во-вторых, вышеописанный метод конвертирования при загрузке поносится всякими нехорошими словами что на сайте lizardtech, что на ermapper. "Пирамиды" из копий изображений с разным разрешением - прошлый век, в общем-то. И именно возможность "выкусывать" определенные данные из целого файла и есть главная фишка этих форматов, позволяющая, как минимум, на два порядка сократить требования к объему памяти и "размазать" выполнение трансформаций на все время работы с исходным изображением, а не выполнять их один раз в начале.

В-третьих, тот же GlobalMapper выполняет преобразование проекции только в случае, если его об этом попросить. Как он делает: после загрузки он сам есть 8 Мб. Скармливаем ему mrsid с сервера ESAD (41Мб сжатый, 1Гб - расжатый целиком). Он показывает его целиком, проекция вида автоматически становится wgs84/utm с соотв. параметрами, отъедает он при этом еще 6 Мб (показывать что-то в другой проекции он будет только в случае, если ему задать другую проекцию вида). Далее, при каждом приближении или сдвиге изображения он отъедает по 4-5 Мб, тут же возвращая их обратно (сдвиг на экран или приближение в два раза занимают около 2 секунд времени, за которое и происходит декомпрессия недостающих частей, трансформация и интерполяция для приведения картинки к нужному разрешению/проекции вида, время замерено мной на p4-1200/512). Очевидно, что трансформации и интерполяции подвергается только участок изображения, который чуть больше размеров окна программы. Сухой остаток: НИЧЕГО "ЧУДОВИЩНО" НЕ ТОРМОЗИТ. Да и нафига иметь возможность сдвига изображения совершенно в реальном времени? Для реальных задач небольшая задержка вовсе не страшна. Советую ради эксперимента повозиться с MrSID GeoViewer и Global Mapper (на все интересующие вопросы отвечу по возможности).

В-четвертых, хотелось бы прояснить - в latitude\longitude картинка конвертится для того, чтобы удобнее было работать с данными в текстовике?

[SaNFiSkO]

>Я так понял, народу MrSID намного нужнее ECW просто потому, что в нем есть готовые карты.

[kg_vista]

>В-четвертых, хотелось бы прояснить - в latitude\longitude картинка конвертится для того, чтобы удобнее было работать с данными в текстовике?

1. В этой с позволения сказать "проекции" самый быстрым образом вычисляются координаты в пикселах на экране из координат в градусах: простое умножение на коэффициент и округление. Поэтому для визуализации векторных данных Lat\Lon предпочтительно.

2. Если надо одновременно показывать растр и вектор, то, очевидно, все данные должны быть приведены к одной проекции-датуму-единицам. Тут конечно можно вектор привести к проекции растра. Правда, несколько сложнее становится рисовать координатную сетку . И много чего еще переписывать основательно...

3. Есть кстати и такой частный случай, когда нужно показывать более одной растровой картинки, приаттаченой к вектору. Что делать, если эти картинки в разных проекциях?

Вот поэтому я решил не заморачиваться и мысленно провозгласил, что Lat\Lon - самая "правильная" проекция, к которой должны предварительно приводится ВСЕ данные, тем более что визуализация растра для моей программы есть более второстепенная функция, чем визуализация и редактирование вектора. Такая вот у меня "изначальная идеологическая ошибка".

> В-третьих, тот же GlobalMapper выполняет преобразование проекции только в случае, если его об этом попросить.

Надеюсь, ты теперь понимаешь, что у меня несколько иной случай? Я ведь не просто вьюер картинок пишу...

>время замерено мной на p4-1200/512

То есть, скажем, на P3-550 это будет секунд 5. По моим меркам, это и есть чудовищно .

> Да и нафига иметь возможность сдвига изображения совершенно в реальном времени?

... даже и не знаю, что сказать ... Но лично меня такие программы, которые долго думают над сдвигом, мягко говоря... нервируют .

>Очевидно, что трансформации и интерполяции подвергается только участок изображения, который чуть больше размеров окна программы.

Интересно, а какого размера окно? Оно ведь само может быть немаленьким. У меня только трансформация картинки размером 1000 x 1000 занимает порядка секунды-двух, то есть даже и не на этапе загрузки будет кушать столько же. Это между прочим 3 мега надо выкачать по шине из ОЗУ в проц, и столько же обратно; да и скумекать над трансформацией (каюсь, связался я напрасно с плавающей точкой). Да нынче и копирование нужного куска из готового буфера на экран в максимизированное окно, (которое делается чуть ли не на аппаратном уровне - через StretchBlt) отнюдь не блещет мгновенностью...

[Bushman]

По поводу "изначальной идеологии" мне и так было ясно. Просто я надеюсь, что данное обсуждение может сподвигнуть к каким-либо изменениям в будущем. Я же не с ножом к горлу лезу требовать этих изменений, а просто привожу аргументы, которые нахожу логичными, что подтверждается успешным функционированием уже существующих программ.

По поводу же одновременного показа нескольких слоев в разных проекциях - тут опять же логика может быть достаточно проста. Если нет никаких дополнительных моментов, то "основной" выбирается проекция первоначально открытого растра (ну, на худой конец, задается вопрос "перепроецировать все?" если проекция нового растра не совпадает с предыдущими). Существует и другой вариант, когда, например, открытые данные не могут быть корректно отображены в какой-либо проекции, кроме географической (lat/lon) из-за искажений (строго говоря, например, в той же UTM больше одной зоны показывать нельзя).

По поводу "торможения на 5 секунд" - так мы же тут не в кваку играем. Процесс редактирования карт - дело, можно сказать, медитативное. 8) Соответственно, "лучше день потерять, потом за пять минут долететь". 8)) А если серьезно, то практическая работа с данными такого уровня в настоящем реальном времени пока что удел граждан, работающих не на x86, а на более правильных RISC-платформах. Ограничение чисто физическое. Хотя конечно, можно занизить планку необходимого количества операций, и получить "настоящий" realtime. Поминая все тот же GlobalMapper - его "торможение", как я уже сказал, находится на допустимом уровне, а размеры изображения в окне (по крайней мере, у меня) - порядка 1000х800 (разрешение - 1152х864).

[kg_vista]

- точность вычисления проекции. Мои нынешние халявные алгоритмы имеют точность порядка 0.05%, что годится для изображений размером 2000-3000. Если же этими формулами персчитывать картинки в десятки тысяч пикселов, то искажения будут уже в десятки пикселов, то есть неприемлимыми... А бОльшая точность - это опять дополнительное время, необходимое для учета высших порядков.

> так мы же тут не в кваку играем.
Вопрос, собственно, упирается исключительно в удобство (то бишь юзабилити). Неподдержка MrSID/ECW = пользователь должен делать дополнительные телодвижения с помощью других программ для приведения данных к поддерживаемым форматам, что не удобно. А соответственно поддержка = большие тормоза при перерисовке, что тоже неудобно (народ перешел на мою программу с GPSmapper'а, я так понимаю, главным образом из-за тормознутости последнего). Итак, получается немного "меняем шило на мыло"...

Вобщем, полноценная поддержка MrSID пока требует долгих дум .

[Bushman]

Я, конечно, не знаю, что там за алгоритмы и т.п., но преобразование-то выполняется каждый раз локально, для отдельных кусков. А используется, случайно, не вот это - http://www.nima.mil/GandG/geotrans/geotrans.html ? По поводу же юзабилити: кому не нужен mrsid/ecw, тот и так ничего не заметит - у него векторные данные так и будут дальше отображаться... Между прочим, у меня есть смутное подозрение, что одна из mrsid'овских DLL'ок содержит функции для трансформации.

[kg_vista]

> преобразование-то выполняется каждый раз локально, для отдельных кусков Если бы точки привязки были тоже всегда "локально", ошибка была бы пренебрежимой. А там наверняка задается привязка где-нибудь на границах карты. То есть в "промежуточных" точках надо самостоятельно "интерполировать". А чем больше интервал, тем точнее нужна интерполяция. Я-то использую лишь квадратичное приближение. А для точности в 0.01% нужно уже учитывать третий порядок. А вот если библиотечные функции LizardTech действительно сами умеют делать преобразования - это было бы просто идеально! > А используется, случайно, не вот это - http://www.nima.mil/GandG/geotrans/geotrans.html ? Нет. Я поначалу самопально ваял формУлы и алгоритмы; а эти исходники нашел значительно позже, но пока даже не "вникал". Зато вот позавчера "Математическую картографию" Бугаевского добыл - теперь буду более подкован в теории .

[Bushman]

Чтоб были локальные точки, их можно "сочинить". 8)) Хотя это тоже, в общем, извращение... По поводу же умения библиотек lizardtech преобразовывать самим - пока не могу поспособствовать, но в списках экспортируемых/импортируемых функций есть подозрительные названия.

Использование же geotrans есть штука полезная, насколько я понимаю.

[kg_vista]

>Чтоб были локальные точки, их можно "сочинить".

Да, это идея, но только сочинять надо с адекватной точностью (с учетом третьего порядка). А промежуточные точки можно уже быстро обсчитать 2-м порядком. Так что действительно можно считать с не худшей скоростью, чем сейчас (надо только не промахнуться в 3-м порядке для "сочиненных" точек .

[Bushman]

Скажу больше: применительно к файлам с ESAD, в .met-файлах содержатся еще и некие дополнительные точки, описывающие (насколько я понял) исходные изображения мозаики. А поставить, грубо говоря, одну "фальшивую" точку между двумя "настоящими" и так далее - не должно быть большой проблемой...