c++ - 写大口角图片

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 以编写 BigTIFF，请参阅:

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 将被忽略。默认是在主线程中压缩。

如果您自己编写 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.
 */

确保您将 tiff 写成 strip 或平铺。我偏爱瓷砖。使用 GDAL 时也是如此。对于 BigTIFF 图像，您必须将图像处理为图 block 或 strip 。

编辑 18:19 24/7/2017

我回答这个问题的原因是因为我必须为客户创建巨大的金字塔 GeoTIFF(11 多个级别可能覆盖整个世界)。

目前为止我创建的最大图像略小于 4GB。我刚刚将最高分辨率图像的大小增加了四倍(达到 1638400x1638400 像素 RGBA，LZW 压缩)。到目前为止，一个小时过去了，我只生成了这一层的 5%(在“MSI GP727RD Leopard”上，发布版本)。

时间问题很复杂，因为我要将 vector 数据绘制到正在生成的每个图 block 中。

我部分使用 GDAL 从坐标系统 WKT 创建 GeoTIFF 标签(不得不从驱动程序中破解)。

我正在使用 libTIFF 自己写出 TIFF。一旦一切正常，我将把处理推送到尽可能多的线程中。但是，我将为每个线程创建单独的 GeoTIFF，因为没有简单的方法可以将大量的 TIFF 组合成一个大的 TIFF，而且我不确定这在任何情况下都是明智的。

32 位进程的内存使用量非常低。我的进程使用了​​大约 60Mb 的内存。