Запись больших фотографий tiff

Question

Я пишу большие файлы tiff с библиотекой bigtif. Я использую простой вызов «TIFFWriteScanline» для записи tiff, и он корректно записывает данные, пока размер файла не станет больше 3, 4 ГБ, и там процесс записи становится очень медленным, но правильно пишет tiff). Я хочу, чтобы решить его, потому что это является узким местом для моей скорости приложения. могу ли я решить эту проблему в libtiff или я должен переключиться на другую библиотеку, такую ​​как gdal, ..?

Может ли gdal написать огромные файлы TIFF (более 4 ГБ) с хорошей скоростью?

благодарит заранее.

Answer 1

GDAL может писать очень большие BigTIFF. Вам нужно построить GDAL с поддержкой BigTIFF.

Вы должны использовать версию libTIFF версии 4 или новее, если вы создаете libTIFF извне из GDAL.

Вам нужно будет пройти множество опций для GDAL писать BigTIFFs см:

http://www.gdal.org/frmt_gtiff.html

• BIGTIFF = ДА/НЕТ/IF_NEEDED/IF_SAFER: Управление ли не созданный файл BigTIFF или классический TIFF.

Вы можете ускорить обработку, используя следующий вариант:

• NUM_THREADS = количество_потоков/ALL_CPUS: (Из GDAL 2.1) Включение многопоточного сжатия, указав количество рабочих потоков. Стоит использовать медленные сжатия, такие как DEFLATE или LZMA. Будет проигнорирован для JPEG. По умолчанию используется сжатие в основном потоке.

Если вы пишете BigTIFF самостоятельно, то при открытии файла TIFF для записи вам необходимо передать «8» (как ASCII) в вызов TIFFOpen как часть символьной строки режима.

Документационный в tif_open.c указывает допустимые варианты:

/* 
* Process library-specific flags in the open mode string. 
* The following flags may be used to control intrinsic library 
* behaviour that may or may not be desirable (usually for 
* compatibility with some application that claims to support 
* TIFF but only supports some brain dead idea of what the 
* vendor thinks TIFF is): 
* 
* 'l' use little-endian byte order for creating a file 
* 'b' use big-endian byte order for creating a file 
* 'L' read/write information using LSB2MSB bit order 
* 'B' read/write information using MSB2LSB bit order 
* 'H' read/write information using host bit order 
* 'M' enable use of memory-mapped files when supported 
* 'm' disable use of memory-mapped files 
* 'C' enable strip chopping support when reading 
* 'c' disable strip chopping support 
* 'h' read TIFF header only, do not load the first IFD 
* '4' ClassicTIFF for creating a file (default) 
* '8' BigTIFF for creating a file 
* 
* The use of the 'l' and 'b' flags is strongly discouraged. 
* These flags are provided solely because numerous vendors, 
* typically on the PC, do not correctly support TIFF; they 
* only support the Intel little-endian byte order. This 
* support is not configured by default because it supports 
* the violation of the TIFF spec that says that readers *MUST* 
* support both byte orders. It is strongly recommended that 
* you not use this feature except to deal with busted apps 
* that write invalid TIFF. And even in those cases you should 
* bang on the vendors to fix their software. 
* 
* The 'L', 'B', and 'H' flags are intended for applications 
* that can optimize operations on data by using a particular 
* bit order. By default the library returns data in MSB2LSB 
* bit order for compatibility with older versions of this 
* library. Returning data in the bit order of the native CPU 
* makes the most sense but also requires applications to check 
* the value of the FillOrder tag; something they probably do 
* not do right now. 
* 
* The 'M' and 'm' flags are provided because some virtual memory 
* systems exhibit poor behaviour when large images are mapped. 
* These options permit clients to control the use of memory-mapped 
* files on a per-file basis. 
* 
* The 'C' and 'c' flags are provided because the library support 
* for chopping up large strips into multiple smaller strips is not 
* application-transparent and as such can cause problems. The 'c' 
* option permits applications that only want to look at the tags, 
* for example, to get the unadulterated TIFF tag information. 
*/ 

Убедитесь, что вы пишете размолвку, как либо полос или плиток. Я предпочитаю плитки. Это также верно при использовании GDAL. Для изображений BigTIFF вы должны обрабатывать изображения как плитки или полоски.

Редактировать 18:19 24/7/2017

Поэтому я ответил на этот вопрос, потому что я имею создавать огромные пирамиды GeoTiffs для клиента (11 плюс уровни потенциально охватывающих весь мир).

Самое большое изображение, которое я создал до сих пор, немного меньше 4 ГБ. Я только увеличил в четыре раза размер изображения с высоким разрешением (до 1638400x1638400 пикселей RGBA, сжатие LZW). До сих пор прошел час, и я создал только 5% этого слоя (на «MSI GP727RD Leopard», выпуск).

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

Я частично использую GDAL для создания тегов GeoTIFF из системы координат WKT (пришлось взломать его из драйвера).

Я пишу сам TIFF, используя libTIFF. Как только все это будет работать, я буду настаивать на обработке как можно большего количества потоков. Однако я буду создавать отдельные GeoTIFF для каждого потока, так как нет простого способа объединения партии в один большой TIFF, и я не уверен, что это было бы разумно в любом случае.

Использование памяти в 32-битном процессе довольно низкое. Мой процесс использует ~ 60 Мб памяти.