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

[SaNFiSkO]

Не поддерживает? Может от озика Dllку присобачить?

[kg_vista]

Увы, с MRSID я еще не разбирался... То есть я пока без понятия, насколько это просто .

[kg_vista]

Посмотрел я на MrSID ActiveX - из него кашу вряд ли сваришь .
А длл-ка к Ози несколько того... недокументированная. То есть, чтобы угадать, как ей аргументы передать, ее ломать надо.

Вобщем, я пока пас...

[SBN]

Попробуй MrSID из OZI экспортировать в .bmp, потом привязать, а уж потом смотреть в MAPedit. Правда бмпешка будет под гигабайт :(

[Bushman]

DLL от OZI не подойдет. У самой фирмы Lizardtech есть партнерская программа для девелоперов, насколько я знаю, они предоставляют по ней SDK бесплатно (с соответствующими условиями), зарегистрироваться можно вот тут: http://www.lizardtech.com/partners/join/ А какой-либо формат (MrSID или ER Mapper ECW) подобного рода действительно нужен, так как работать с большими покрытиями в растре иначе совершенно невозможно. В плане этого, могу отметить - ECW несколько проще реализовать (и осмысленней), т.к. для него все более открыто и бесплатно - и SDK, и утилиты компрессии и декомпрессии (OZI его также понимает). Если надо, каждый желающий может переконвертить mrsid в ecw через geotiff (экспорт из GeoViewer, компрессия в ECW Compressor, если надо - исправления в ECW Header Editor).

[kg_vista]

>У самой фирмы Lizardtech есть партнерская программа для девелоперов,

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

[Bushman]

Ну это, девелопер же должен что-нибудь продавать. 8))
А вообще, в SDK у них входят библиотеки
lt_common.dll
lt_messagetext.dll
lt_trans.dll
lt_utils.dll
MrSIDD.dll
- они есть и в поставке их собственных гляделок, и в GlobalMapper.
Но советую все же начать с ECW - там все прозрачнее. Для начала будет проще выяснить подводные камни работы с wavelet, например...
Я тут вчера провел эксперимент:
1) MrSID GeoViewer'ом экспортил регион в GeoTIFF с сохранением привязки.
2) посредством listgeo из поставки libgeotiff_win32 вывел всю информацию из заголовка получившегося файлика
3) посредством Free ECW Compressor 2.6 пожал файлик в ECW с компрессией 1:20.
4) посредством ECW Header editor ввел в заголовок получившегося файлика информацию о привязке, которую мне вывел listgeo (там все понятно, кроме проекции - там всего одно поле, и, например, для UTM 37й зоны северного полушария надо писать код NUTM37).
5) Открыл исходный geotiff в GlobalMapper, а следующим слоем открыл получившийся ECW, которому затем указал "blending mode"="difference".
В результате изображения совпали с 100% точностью позиционирования (а с чего бы оно отличалась?), визуальные искажения (на глаз) были менее полпроцента (изменения яркости некоторых отдельных резко выделяющихся на исх. изображении деталей).
Так что можно начинать с ECW.

[kg_vista]

>они есть и в поставке их собственных гляделок, и в GlobalMapper.
Этого мало, нужны еще хедера к тем DLL-кам.

>Для начала будет проще выяснить подводные камни работы с wavelet
Если есть готовый код "от производителя", то алгоритм сжатия меня уже не особо волнует. Мне нужно лишь нечто, превращающее имя файл в распакованный битмап в памяти. То есть если какое-то API умеет рендерить только на экран, а не в произвольный HDC - то нафиг такое API...

> Но советую все же начать с ECW
Да, это поможет, но это если я сам буду учиться писать декомпрессор (причем для обоих форматов). А пока я не встречал нигде описания формата.

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

[Bushman]

>>они есть и в поставке их собственных гляделок, и в GlobalMapper. >Этого мало, нужны еще хедера к тем DLL-кам. Это я понимаю, написал просто к тому, что dll от озика уж точно не то, что надо. >Если есть готовый код "от производителя", то алгоритм сжатия меня уже не особо >волнует. Мне нужно лишь нечто, превращающее имя файл в распакованный битмап в >памяти. То есть если какое-то API умеет рендерить только на экран, а не в >произвольный HDC - то нафиг такое API... Оно все что надо умеет... просто там некоторые хитрости могут быть с тем, как у него этот самый требуемый битмап требовать. С такими файлами по определению нельзя (и не целесообразно, главное) делать "имя файла -> битмап", на это ни памяти, ни времени не хватит никакого (декомпрессованый mrsid с сервера ESAD, о которых тут шла речь, целиком занимает 1'008'165'494 байт) - доступ осуществляется совсем иначе. Что в mrsid, что в ecw каждый участок изображения декомпрессуется отдельно в зависимости от того, с каким разрешением он будет выводиться - чтоб не жрать память, не издеваться над локальным накопителем или сервером, откуда в реальном времени берется изображение. Приведу пример (только я не знаю, что именно из этой работы делает фирменный декомпрессор, а что должен писать сам разработчик): мы хотим показать кусок изображения, входящий в некий прямоугольник, с уменьшением 2,3 раза в отношении к "реальным пикселям". Мы получаем координаты (в пикселях) угла нужного участка и инкремент координат по осям, чтоб получить нужную область. Из этих данных однозначно получается смещение, откуда начинается чтение фрагмента. Далее мы определяем ближайшее значение уменьшения, кратное двойке (тут тонкость - я не знаю, как оно округляется - до большего или меньшего). В данном случае, это, например, 2. Исходя из этого чтение происходит определенным образом (фактически - не читается информация, описывающая в данном случае каждый второй пиксель, как именно - это уже тонкости формата). В результате мы получаем в памяти декомпрессованный с заданной точностью фрагмент, который интерполяцией приводится точно к необходимому разрешению. При сдвиге также декомпрессуются только нужные части с нужной точностью. >Да, это поможет, но это если я сам буду учиться писать декомпрессор (причем >для обоих форматов). А пока я не встречал нигде описания формата. Не надо писать декомпрессоры - они уже у фирм-производителей готовы. Про плюсы ECW я говорю именно в том плане, что кто угодно сможет пожать им растровую карту бесплатно, если размер входного файла меньше 500Мб. Советую глянуть на <a href="http://www.ermapper.com/download_new/do ... раничку</a>, где все ясно и понятно (ближе к ее концу). У Lizardtech такой странички в явном виде нет. А по поводу того, что народу нужно - так народ сам толком это не всегда знает. 8) Я в своем предыдущем сообщении привел метод корректного преобразования mrsid в ecw, и сложностей там нет никаких, так что кому надо - справится...

[kg_vista]

> декомпрессованый mrsid с сервера ESAD, о которых тут шла речь, целиком занимает 1'008'165'494 байт

Это-то я ужо усек... Вот только GPSMap Edit на это совсем не расчитан. Нынче он именно распаковывает ВСЕ в битмап. А потом создает ЕЩЕ один битмап тех же размеров (и еще просто память захватывает 2 раза по столько). И делает преобразование проекции из исходной в latitude\longitude, копируя пикселы из первого битмапа во второй (с квадратичными преобразованиями координат). После чего первый битмап убивает и далее довольствуется вторым. Правда, заводит еще уменьшенную в 2 раза копию второго - для ускорения рендеринга. Это все ради того, что бы в любой момент иметь под рукой растровые данные, максимально быстро отображаемые на экране (просто через BitBlt, поскольку картинка теперь уже в нужной проекции).

Стоит ли говорить, что все это не годится на размерах не только в 1 ГБ, но и на гораздо меньших... Иными словами, проблема полноценной поддержки MrSID/ECW состоит не только в их декомпресии, но и в основательной переделке много чего. Хуже того, не понятно, как, например, быть с проекциями - на лету брать нужный кусочек растра и преобразовывать? Но это же будет чудовищно тормозить и пользоваться будет просто невозможно! Так закрадываются сомнения, а стоит ли овчинка выделки...

Впрочем, я упустил один важный момент: а какие бывают проекции для MrSID? Может там допустИм только тривиальный Latitude\Longitude? (Я пока с этим вопросом не разбирался).