Работа с большими(1гигабайт) и гигантскими(10Гб) растрами

[Aleh]

Сейчас ошибки правлю

Везёт человеку, всего-то 10 кб

Мне за кб не платят, а по мне, чем их меньше, тем лучше

[pupsik]

Осмелюсь спросить: 10кб - чего? Т.е. исходник, бинарник, фотка (ну понятно что 1,5 гб открывает)... Кстати: upx не считается...

п.с.
Есть ещё Nativejpg. Он, если не ошибаюсь, может с большими jpg работать. Хоть и для дельфина но и в лазаре работает (не без бубна).

[MylnikovDm]

Если не секрет, откуда у вас данные по 10Гб и как вы собираетесь их дальше использовать в ГИС?
Исходя из того, что я уже прочитал, у вас явно какая-то неправильная логика работы приложения. Если вы даже получаете откуда-то подобные растры как RAW данные с сенсоров, то их необходимо сразу же порезать в набор тайлов меньшего размера, для которых потом построить пирамиду индексных уменьшеных изображений. При этом, если у вас исходный размер растра в 10 Гб, то и уменьшенные индексные изображения как минимум первого, а то и второго уровня у вас также должны быть разделены на фрагменты.

В противном случае никакая реальная работа с подобными изображениями будет невозможна. Держать в памяти всё изображение такого размера слишком дорогое удовольствие. При каждой манипуляции с ним всё время перечитывать всё изображение, или даже значительную его часть, будет слишком долго. Да и я не знаю таких ГИС, которые бы работали с подобными растрами. Преобразовать большое изображение в индексированный набор тайлов, это да, такая функция есть и в ArcINFO, и в некоторых других ГИС, но "на лету" они с такими растрами не работают.

Что касается конкретной реализации, то написать простенькую программку, которая будет резать стандартный BMP большого рамзера на куски, это работа на два-три часа. Формат очень простой. С Tiff уже сложнее, если раньше с ним не работали. С JPG'ом ещё посложнее, так как там сжатое изображение, которое разворачивается построчно, поэтому если памяти не хватает, то придётся делать несколько проходов. Кстати, внутри ТIFF тоже может быть JPG, если он со сжатием. При этом вряд ли получится использовать готовые библиотеки, поскольку они прнимают на входе сжатый файл, а на выходе выдают матрицу точек растра целиком. То есть, придётся писать свой код для дешифровки JPG'а, либо переделывать что-то из готовых под свою задачу.

>>Удивил встроенный недоделанный TBitmap - 382М bmp прочитал (изображение rgb 24bit), съев в 2 раза больше памяти.<<
В Delphi ровно такая же ситуация, поскольку TBitmap в обоих случаях сначала полностью грузит файл в память, а потом из него создаёт в системе растровое изображение с разделением на структурные элементы, которое занимает ещё столько же места. Скорее всего это анахронизм, который остался с тех времён, когда некоторые варианты BMP хранились в файле и памяти вверх ногами. Это очень старый прикол от Microsoft со времён самой первой Windows.

[скалогрыз]

Исходя из того, что я уже прочитал, у вас явно какая-то неправильная логика работы приложения. Если вы даже получаете откуда-то подобные растры как RAW данные с сенсоров, то их необходимо сразу же порезать в набор тайлов меньшего размера, для которых потом построить пирамиду индексных уменьшеных изображений. При этом, если у вас исходный размер растра в 10 Гб, то и уменьшенные индексные изображения как минимум первого, а то и второго уровня у вас также должны быть разделены на фрагменты.

я думаю, он как раз "резчик" и пишет

[Aleh]

Если не секрет, откуда у вас данные по 10Гб и как вы собираетесь их дальше использовать в ГИС?
Исходя из того, что я уже прочитал, у вас явно какая-то неправильная логика работы приложения. Если вы даже получаете откуда-то подобные растры как RAW данные с сенсоров, то их необходимо сразу же порезать в набор тайлов меньшего размера, для которых потом построить пирамиду индексных уменьшеных изображений. При этом, если у вас исходный размер растра в 10 Гб, то и уменьшенные индексные изображения как минимум первого, а то и второго уровня у вас также должны быть разделены на фрагменты.

Данные из нашего БелКА, аналог вашего Конопуса.
по логике: Вопрос 1 - КТО будет резать и строить пирамиды, перепривязку... это не сложно(если не бесплатно). Убийственный вопрос 2: кто будет платить!
Отсюда следует, что если программа "сама" переварит это, то вопрос 1 и 2 не возникают.

Добавлено спустя 10 минут 12 секунд:
Re: Работа с большими(1гигабайт) и гигантскими(10Гб) растрами

я думаю, он как раз "резчик" и пишет

написал, только не резчик, а разметчик. Читает только заголовок, а загрузка частей идёт только при необходимости отрисовать на "приемлемом масштабе". MylnikovDm прав работы на полдня, и ещё полдня на рисовашку CanvasCopyRect(Dest: TRect; Canvas: TCanvas; Source: TRect)//область Dest Canvas в которую нужно скопировать область Source размеченного изображения. Проверено только на 24-битных(доделанных) битмапах.

Добавлено спустя 9 минут 57 секунд:
Re: Работа с большими(1гигабайт) и гигантскими(10Гб) растрами

В Delphi ровно такая же ситуация,

В дельфи (4-5 помнится) ситуация обратная. Там проблемы начинались с 50М, но на меньших размерах работало ВСЁ!!! а выше ничего.
ВСЁ - это битмапы 1,2,4,8,16,24 бита, чтение, запись, отрисовка, канвас.пиксельс, сканлайн ВСЁ! В лазаре нормально поддерживаются 24 битмапы, немножко 1битные, с остальными лучше не работать(как я понял беда где есть политры).

[vitaly_l]

не резчик, а разметчик. Читает только заголовок, а загрузка частей идёт только при необходимости отрисовать на "приемлемом масштабе"

Ну вот, теперь всё надёжно. А интересно, снимки с БКА(БелКА) можно ли смотреть в открытом доступе?

Проверено только на 24-битных(доделанных) битмапах.

В 32-битах всё тоже самое, только добавлен 4-й альфа канал прозрачности. Скорее всего он Вам ненужен, т.к. снимки с БКА скорее всего без прозрачности.

[Aleh]

А интересно, снимки с БКА(БелКА) можно ли смотреть в открытом доступе?

Чесно-не знаю. У них панхром 2,5м цвет 5, нам в общем не айс, нам 0,5-1м. формат несжатый тиф в зип архиве.
рулят им там: http://nasb.gov.by/rus/index.php

Добавлено спустя 40 минут 50 секунд:
Re: Работа с большими(1гигабайт) и гигантскими(10Гб) растрами

Осмелюсь спросить: 10кб - чего? Т.е. исходник, бинарник, фотка

Ну конечно исходник, бинарники такие были в Турбопаскале 5.5, а лазарю и UPX не поможет, фотка такая называется аватарка . Спасибо за пост. Не поленился, посмотрел - работает, но в работе не использовал(масштабирование требуется).

[MylnikovDm]

по логике: Вопрос 1 - КТО будет резать и строить пирамиды, перепривязку... это не сложно(если не бесплатно). Убийственный вопрос 2: кто будет платить!
Отсюда следует, что если программа "сама" переварит это, то вопрос 1 и 2 не возникают.

Работали когда нибудь в QGIS или через GDAL http://www.gdal.org/ с большими растрами?
При работе с большими растрами в них можно построить пирамиду масштабных растров, которые записываются в отдельный файл. Этот файл записывается рядом с основным с тем же именем и другим расширением. Эта процедура запускается и выполняется один раз, чтобы каждый раз не ждать. При просмотре уменьшенной карты данные считываются не с основного файла, а из вспомогательного. Если растр слишком большой, то его лучше вначале разделить на несколько фрагментов, а потом для каждого из них построить подобную пирамиду масштабных растров. Причём в QGIS/GDAL можно сначала нарезать большой растр в тайлы, потом объендинить их в единый растровый слой, а потом уже на этот растровый слой целиком сформировать общую пирамиду масштабных растров.
Естетственно, что это всё делается уже там, где данные используются.

Кстати, а зачем делать перепривязку? Если у вас есть данные о привязки основного большого растра, то это значит, что вы можете получить координаты в привязанной системе координат для любой точки растра. Что вам мешает перед разбиением вычислить координаты углов для каждого фрагмента и сформировать новые данные привязки для каждого файла? Если это GeoTIFF или GeoJPG, то привязку можно сразу записать внутрь файла. А для форматов, которые не поддерживают запись пространственных метаданных о привязке, обычно формируется дополнительный файл, типа файла .tab в MapInfo достаточно простой структуры.

Итого, на вашем месте, если бы мне необходимо было работать со всерхбольшими растрами в своей ГИС, то логика работы была бы следующей.
Если это файл типа BMP, который допускает прямое обращение к любому фрагменту растра, то его можно и не делить на тайлы, а считывать только нужный фрагмент. Но делать это имеет смысл только когда мы смотрим изображение в масштабе близком к 1:1 (масштаб в смысле точка растра - точка экрана). Для просмотра этого растра в уменьшеном масштабе формируется набор вспомогательных растров, зарание просчитанных, которые лежат в виде отдельных файлов рядом с основным. И пока мы работаем с уменьшеным изображением, то мы данные считываем из вспомогательных файлов. А когда приближаемся к масштабу 1:1, то уже небольшие фрагменты считываем непосредственно из основного файла.
Если это файл типа JPG, в котором по понятным причинам прямой доступ к нужному фрагменту растра в файле недоступен, то тут уже выбора особого нет. Его по любому придётся разрезать на фрагменты. При этом данные фрагменты, в принципе, тоже можно потом сохранить в формате JPG.

Что касается масштабных фрагментов, то из своей личной практики могу сказать, что делать растры для каждой ступени с кратностью 2, то есть уменьшенные в 2, 4, 8, 16 и т.д. раз не обязательно. На практике вполне удовлетворительно работает кратность 4, то есть использование фрагментов уменьшенных в 4, 16, 64 и т.д. раз.
Уменьшать фрагменты меньше чем 100х100 точек смысла уже не имеет. Но и останавливаться на слишком крупных фрагментах тоже плохо, так как они будут загружаться достаточно долго. У меня алгоритм работал, пока размер по одной из сторон не становился меньше 100 точек.

>>В дельфи (4-5 помнится) ситуация обратная. Там проблемы начинались с 50М, но на меньших размерах работало ВСЁ!!!<<
Я говорил не про качество работы с разными форматами, а про то, как и почему расходуетя память при загрузке растров. В Дельфи работа с растрами, с точки зрения поддержки разных форматов, была сделана достаточно хорошо, так как это коммерческий продукт. В Lazarus с этим намного хуже. Весьма часто качество кода оставляет желать лучшего.
Возвращаясь к работе с растрами, то логика работы класса TBitmap в Delphi была примерно такой же, как сейчас в Lasarus. Вначале все данные из файла BMP грузились в память, а уже потом разбиралась структура файла. Отсюда при работе с большими файлами начинались проблемы.

Удачи вам в ваших разработках!

[Aleh]

Работали когда нибудь в QGIS

У нас Аргис, ещё та зараза, хоть и коммерческая. Знаю я эту кухню, и не хочу с ней связываться (в данном случае это лишнее). По кратностям пирамид согласен, и по фрагментам. Чтоб решить эту задачу, мне нужно добавить поддержку несжатого тифа. Как должно работать: посмотрит оператор на поле/лес в м2000-10000, включит снимок, посмотрел рубки/зарастания, если нужно оцифровал, выключил. А пирамид других у нас уже выше крыши. Но если оператор не посмотрит ни разу этот снимок, то работа, кратко описанная в предыдущем посте вообще сделана впустую. Тут впору вопросу 3 возникнуть...