寫大tiff圖片

Question

我正在用bigtif庫寫大tiff文件。我使用「TIFFWriteScanline」的簡單調用來編寫tiff，它會正確寫入數據，直到文件大小超過3,4 GB，寫入過程變得非常緩慢，但正確寫入tiff。我想要一種方法來解決它，因爲它會導致我的應用程序速度瓶頸。我可以在libtiff中解決這個問題，或者我必須切換到另一個庫，如gdal，..？

gdal能夠以良好的速度寫入巨大的tiff文件（大於4GB）嗎？

在此先感謝。

Answer 1

GDAL可以編寫非常大的BigTIFF。您需要使用BigTIFF支持構建GDAL。

如果您從GDAL外部構建libTIFF，則需要使用libTIFF版本4或更新版本。

您將需要通過一組選項，以GDAL寫BigTIFFs，請參閱：

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

• BIGTIFF = YES/NO/IF_NEEDED/IF_SAFER：控制是否創建的文件是一個BigTIFF或經典的TIFF。

可以使用下列選項加快處理：

• NUM_THREADS = number_of_threads/ALL_CPUS：（來自GDAL 2.1）通過指定的工作線程的數量啓用多線程壓縮。值得慢速壓縮，如DEFLATE或LZMA。 JPEG會被忽略。主線程默認爲壓縮。

如果是自己，然後寫BigTIFFs當您打開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. 
*/ 

確保你寫出來的TIFF作爲要麼帶或瓷磚。我喜歡瓷磚。使用GDAL時也是如此。對於BigTIFF圖像，您必須將圖像作爲瓷磚或條帶進行處理。

編輯18:19 24/7/2017

我回答這個問題的原因是因爲我不得不爲客戶（11個加水平可能覆蓋整個世界）創造巨大的金字塔GeoTIFFs。

我迄今爲止創建的最大圖片略低於4GB。我只是將最高分辨率圖像的大小增加了四倍（至1638400x1638400像素RGBA，LZW壓縮）。到目前爲止，一小時過去了，我只產生了這層的5％（在'MSI GP727RD Leopard'上，發佈版本）。

時間問題很複雜，因爲我正在將矢量數據繪製到正在生成的每個圖塊中。

我部分使用GDAL從Coordinate System WKT創建GeoTIFF標籤（不得不將它從驅動程序中解析出來）。

我正在使用libTIFF寫出TIFF my-self。一旦這是所有工作，我將推動處理成儘可能多的線程。然而，我將爲每個線程創建單獨的GeoTIFF，因爲沒有簡單的方法將這個批次合併到一個大的TIFF中，我不確定這在任何情況下都是明智的。

32位進程中的內存使用率很低。我的過程使用〜60Mb的內存。