Ищу формат высокой компресии

Ariki
Гуру
Сообщения: 731
Зарегистрирован: 12 янв 2011, 22:40
Репутация: 304
Ваше звание:

Re: Ищу формат высокой компресии

Сообщение Ariki » 19 мар 2016, 04:23

Boris писал(а):б) отображается на экране - сдвиг экрана вправо-влево - перерыв на кофе.
Обычно помогает конвертация в GeoTIFF с -co TILED=YES . Чтобы не висло при зуме, нужны пирамиды, но они увеличивают размер файла.
boris писал(а):Где вообще почитать про растры с масками в ГИС? Есть какой стандартный всеми признаваемый подход к ним в ГИС, или RGBA - это и есть наше все?
https://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask
http://www.gdal.org/frmt_gtiff.html#internal_mask
Вкратце, либо значение NODATA, либо альфа-канал, либо специальный слой маски (который может быть внутренним или храниться в отдельном файле .msk).

Другое дело, что не всякое ПО поддерживает эти опции. Но то, что основано на GDAL, — должно.

gamm
Гуру
Сообщения: 4048
Зарегистрирован: 15 окт 2010, 08:33
Репутация: 1050
Ваше звание: программист
Откуда: Казань

Re: Ищу формат высокой компресии

Сообщение gamm » 19 мар 2016, 05:00

Boris писал(а):Проблема с масками в том, что раздолбаи, которые орто творили, использовали в каждом канале все 256 оттенков, а не 255 + NODATA, и эти маски имеют "разводы" из NODATA в значимой части растра.
а что мешает уменьшить на 1 эти значения внутри маски, тем же калькулятором - min(254,val)? визуально ничего незаметно будет ...

Аватара пользователя
Игорь Белов
Гуру
Сообщения: 2229
Зарегистрирован: 04 янв 2011, 22:00
Репутация: 1501
Откуда: Казань

Re: Ищу формат высокой компресии

Сообщение Игорь Белов » 19 мар 2016, 09:32

Все говорят правильные слова, и
gamm писал(а):визуально ничего незаметно будет ...
Только это верно ровно до того момента, как изображение будет сжато алгоритмом высокой компрессии с потерей качества.
The purpose of computing is insight, not numbers

Ariki
Гуру
Сообщения: 731
Зарегистрирован: 12 янв 2011, 22:40
Репутация: 304
Ваше звание:

Re: Ищу формат высокой компресии

Сообщение Ariki » 19 мар 2016, 12:49

Слой маски в GDAL сжимается без потерь, даже если сам растр в JPEG. Вот только я не знаю способа сформировать маску из хранящихся в слое другого растра данных средствами утилит GDAL, без программирования.

ericsson
Гуру
Сообщения: 3321
Зарегистрирован: 27 июл 2009, 19:26
Репутация: 748
Ваше звание: Вредитель полей

Re: Ищу формат высокой компресии

Сообщение ericsson » 19 мар 2016, 20:37

"Сформировать маску" - это добавить ее к другому набору?
gdalbuildvrt -addalpha

Ariki
Гуру
Сообщения: 731
Зарегистрирован: 12 янв 2011, 22:40
Репутация: 304
Ваше звание:

Re: Ищу формат высокой компресии

Сообщение Ariki » 20 мар 2016, 00:38

Эта опция создаёт альфа-канал из границ растров, включаемых в VRT. А я имел в виду NoData mask:
CPLErr GDALDataset::CreateMaskBand (int nFlagsIn).

Такая бинарная маска сжимается без потерь и весит меньше, чем альфа-канал. Фича эта пока слабо поддерживается в прикладном ПО, но через промежуточный слой VRT маску при просмотре снимков можно отображать на альфа-канал на лету.

Аватара пользователя
Игорь Лебедь
Завсегдатай
Сообщения: 452
Зарегистрирован: 24 апр 2010, 19:47
Репутация: 101
Откуда: Город в клёнах и акациях
Контактная информация:

Re: Ищу формат высокой компресии

Сообщение Игорь Лебедь » 22 мар 2016, 16:37

Boris писал(а):2. Я пытался делать маску через GDALCALC, но не говорят про регулярное падение python'а, что делает технологию малопригодной для потоковой обработки, в маске, построенной таким образом остаются артефакты от ярких объектов, со значение 255 во всех 3-х каналах. Да, я знаю, что за это надо убивать, но мне изготовители ортофото не доступны, работа получена по "каналам обмена" - "вот вам от бюджетных затрат". Может есть еще какой метод построения масок?
3. Векторный слой маски то у меня как раз есть изначально - это же планшеты М1:10000, а как мне его учесть при обработке или просмотре. Я читал-читал описания форматов в GDAL, но ни в одном не увидел как "прикрутить" векторную маску.
4. Я пока не сталкивался с экранными ГИС, которые умеют учитывать растровую или векторную маску. Есть такие? ArcGIS?
2.Делал такую задачу как раз для таких, как указано, ортофото так (255 указывается для каждого канала, выходное значение нодата зависит от ваших задач, точно не помню, но надо играть с вариантами 0 / 255 / 256):

Код: Выделить всё

gdal_merge.bat -n 255,255,255 -a_nodata 256 -co BIGTIFF=YES -co TFW=YES -co COMPRESS=LZW -of GTiff -o D:/folder/output.tiff C:/work/orto01.tif C:/work/orto02.tif C:/work/orto03.tif
Всё работало. Минус был в кирилистических названиях, винда это не понимала, выдавала ошибку питона, на убунте всё получилось.
3. В аркгисе делал Raster - Clip в тулбоксе, но вот про пакетную реализацию надо подумать...
4. В "панораме" строится любая разграфка, в т. ч. для стандартных масштабов ортофото (1:500, 1:1000, 1:2000, 1:10000) точно, только параметры стоит знать.

P.S. Делал скрипт с параметрами, как указано, но сейчас висят другие:
-srcnodata
-dstnodata

По-моему, не надо никаких масок, перегдалить (перегдалварпить) нодату в правильную/нужную, и смёрджить воедино. Если кинете примерчик (затертый, естесно), попробую вспомнить былые костыли.

Boris
Гуру
Сообщения: 4205
Зарегистрирован: 10 апр 2006, 22:34
Репутация: 433
Откуда: Париж

Re: Ищу формат высокой компресии

Сообщение Boris » 23 мар 2016, 01:01

Я что то запутался в ответах. Я в сомнениях о том, на какие вопросы мне теперь отвечают. Еще раз:
1. Как расположены планшеты я ЗНАЮ. И векторный слой разграфки планшетов у меня есть. Я не видел реализации в настольной ГИС векторной маски к растру. Я и растровой не видел, но это у меня такие ГИС ;(
2. Я в начале обсуждения хотел растровый формат, который не портит растр, там где его не просили. Ответ, как я понял, состоит в том, что алгоритм сжатия "себя не контролирует" и будет улучшать растр не зависимо от NODATA - везде.
3. То, что TIF сохраняет прозрачность, если только он не JPEG в душе, я то же не сомневаюсь, поскольку исходные данные у меня в TIF'ах. И к ним в части рамок NODATA - претензий нет. Претензии есть к тому, что NODATA появляется в значимой части растра.
3. Затем, я хотел ответа на вопрос "как создать растровую маску для имеющегося растра из вектора или с учетом вектора?". Ответа не понял или не увидел.
4. Я не понимаю чем мне поможет наличие маски, если общих правил для масок в 4-х канальном растре не существует. Тем более для отдельно лежащих масок. Или это поможет при сжатии растра - при наличии маски поля NODATA точно не будут затронуты? Или маски я делаю для GDAL? Но в исходном формате, GDAL, как и настольные ГИС, NODATA и так распознает.
5. Я не понял какие задачи решает "gdal_merge.bat". Точно в выходном растре удалось установить значение 256? Но даже если это так, то создано то оно из исходного 255, которое есть NODATA по краям растра, и максимум белого в остальной части растра. Я же не могу каждую полученную маску затирать "стеркой" в фотошопе или аналогах по центру растра, оставляя по краям.
6. Я конечно теоретически могу создать "BIGTIFF=YES" в 2ТБ, но что я с ним дальше буду делать? У меня от растра 1ГБ экранные ГИС начинают "терять голову", даже при наличии пирамиды растров. Я первый испробованный формат сжатия выбрал во многом из-за того, что в нем в стандарте были пирамиды. Не могу сказать, что за исключением скорости копирования, это как то повлияло на поведение ГИС. Есть у меня подозрение, что они оперируют не частью растра на диске, а частью растра распакованного в оперативную память. А тут будет 2ТБ растра...
7. Может потому, что я ArcGIS, не владею, что именно делает этот самый Raster - Clip? Он умеет физически обрезать растр векторной маской? Но ведь трапеции то никуда не денутся? А раз так, то вернемся опять к началу задачи...
8. "gdal_merge.bat", по личному опыту, для самого GDAL прекрасно заменяется на "gdalbuildvrt.exe". И не надо хранить дубль исходных растров, и все операции выполняются в 10-100 раз быстрее. Я читал, что и QGIS его понимает.
---
Я для себя готов подвести итог:
1. Растры на моих условиях не сожмешь, а маски подойдут или нет - это еще зависит от настольной ГИС.
2. Не изобретая "велосипед", надо взять и создать для каждого растра виртуальный или реальный слитый растр - сам растр и его 8 соседей. В этом случае края NODATA центрального растра затрутся значимыми пикселями растров соседей, после чего вырезать новый растр в размер старого из этого обобщенного растра. Полей NODATA в нем уже не будет - там будут обычные значения, и соответственно, после сжатия любым алгоритмом эти значения там и останутся. Проблема непрозрачных почти белых полос будет решена тем, что самих белых полос уже не будет.

Аватара пользователя
Игорь Лебедь
Завсегдатай
Сообщения: 452
Зарегистрирован: 24 апр 2010, 19:47
Репутация: 101
Откуда: Город в клёнах и акациях
Контактная информация:

Re: Ищу формат высокой компресии

Сообщение Игорь Лебедь » 23 мар 2016, 11:10


Boris
Гуру
Сообщения: 4205
Зарегистрирован: 10 апр 2006, 22:34
Репутация: 433
Откуда: Париж

Re: Ищу формат высокой компресии

Сообщение Boris » 23 мар 2016, 11:45

К какой части задачи это может быть приложено? И что даст на выходе?
Вот например, ложные NODATA - что-то с зеркальной крышей в центре снимка, площадь - много пикселей. Все каналы = 255. Как исправить?

Аватара пользователя
Игорь Лебедь
Завсегдатай
Сообщения: 452
Зарегистрирован: 24 апр 2010, 19:47
Репутация: 101
Откуда: Город в клёнах и акациях
Контактная информация:

Re: Ищу формат высокой компресии

Сообщение Игорь Лебедь » 23 мар 2016, 13:37

Boris писал(а):К какой части задачи это может быть приложено? И что даст на выходе?
Вот например, ложные NODATA - что-то с зеркальной крышей в центре снимка, площадь - много пикселей. Все каналы = 255. Как исправить?
От такого г, конечно, вряд ли что поможет. Но честно говоря, не очень ясна ваша конечная цель.
Мне вот тогда надо было слепить большой растр без белых полосок из исходных растров с белыми полосками. В каждом канале соответственно было 255. В gdal_merge.py задавал нодата 255,255,255 и на выходе оно преобразовывалось в реальную нодату, то есть он объединял нормально в один растр.
Если не надо объединять в один растр, тогда ещё проще - просто gdal_warp.py или gdal_edit.py - заменяете 255,255,255 на NODATA,NODATA,NODATA и всё.
Что должно получиться на выходе? Также отдельно каждый растр или объединённый большой?

Ariki
Гуру
Сообщения: 731
Зарегистрирован: 12 янв 2011, 22:40
Репутация: 304
Ваше звание:

Re: Ищу формат высокой компресии

Сообщение Ariki » 23 мар 2016, 13:43

Boris писал(а):2. Я в начале обсуждения хотел растровый формат, который не портит растр, там где его не просили. Ответ, как я понял, состоит в том, что алгоритм сжатия "себя не контролирует" и будет улучшать растр не зависимо от NODATA - везде.
Для алгоритма JPEG это так, насчёт более хитрых форматов, наподобие MrSID, не уверен. Если есть чем сконвертировать в MrSID, стоит поэкспериментировать, потому что мозаики ортофотопланов в этом формате ужимаются раз в 20 без видимой потери качества и быстро грузятся, в том числе в MapInfo. Но формат проприетарный, это большой минус.
Boris писал(а):Растры на моих условиях не сожмешь, а маски подойдут или нет - это еще зависит от настольной ГИС.
Из того, что я сейчас могу попробовать, ArcGIS маски поддерживает, QGIS - нет. Про MapInfo не знаю. Тестовый растр можно взять здесь: https://svn.osgeo.org/gdal/trunk/autote ... h_mask.tif. Можно заставить маску выглядеть как обычный канал в VRT:

Код: Выделить всё

gdal_translate -b 1 -b 2 -b 3 -b mask -of VRT ycbcr_with_mask.tif ycbcr_with_mask.vrt
и затем использовать его в качестве альфа-канала в QGIS, но у меня работает как-то глючно. Правда, у меня и исходный растр в QGIS тупит.
Boris писал(а):Проблема непрозрачных почти белых полос будет решена тем, что самих белых полос уже не будет
Не знаю, какова ваша конечная цель, но, может быть, вам лучше сначала добавить альфа-канал, обрезав растры с помощью gdalwarp -cutline, а потом собранный VRT порезать на тайлы и поднять веб-сервер? При таком подходе у пользователя точно ничего тормозить не будет.

Boris
Гуру
Сообщения: 4205
Зарегистрирован: 10 апр 2006, 22:34
Репутация: 433
Откуда: Париж

Re: Ищу формат высокой компресии

Сообщение Boris » 23 мар 2016, 15:47

Игорь Лебедь писал(а): Если не надо объединять в один растр, тогда ещё проще - просто gdal_warp.py или gdal_edit.py - заменяете 255,255,255 на NODATA,NODATA,NODATA и всё.
Что должно получиться на выходе? Также отдельно каждый растр или объединённый большой?
На выходе хотелось получить копию исходного растра, только сжатую с высокой компрессией (10-20 раз), для ускорения копирования по сети, пригодную для просмотра в MapInfo и Geomedia Pro 6. Как бонус в разных Автокадах, если получится, но это не цель. ECW, полученный через Global Mapper, по моему 14, исказил NODATA на диапазон 250-255 в каждом из каналов. JPEG и JP2OpenJPEG --- JPEG2000 driver based on OpenJPEG library, входящие в GDAL от OSGeo4W, - так же попортили NODATA, после чего упомянутые выше ГИС, которые понимают только 1 цвет как NODATA, стали отображать растры с белыми полосами в местах перекрытий.
На сколько я могу судить, NODATA нельзя присвоить, его можно только назначить в некоторых метаданных, внутренних или внешних. Для всех программ, не понимающих конкретный вид метаданных, эти пиксели так и останутся с установленным для NODATA цветом.

Ответить

Вернуться в «GDAL/OGR»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя