writing big tiff pictures

writing big tiff pictures

本文关键字：pictures tiff big writing      更新时间：2023-10-16

我正在使用bigtif库编写大tiff文件。我使用简单的调用"TIFFWriteScanline"来写入tiff，它正确地写入数据，直到文件大小超过3,4 GB，并且写入过程变得非常慢，但正确写入tiff）。我想要一种方法来解决它，因为它会导致我的应用程序速度瓶颈。我可以在 libtiff 中解决此问题，或者我必须切换到另一个像 gdal 这样的库吗,..?

gdal 可以以良好的速度写入巨大的 tiff 文件（超过 4GB）吗？

提前谢谢。

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）通过指定工作线程数来启用多线程压缩。值得缓慢按压，如放气或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 写成条带或瓷砖。我更喜欢瓷砖。使用 GDAL 时也是如此。对于 BigTIFF 图像，您必须将图像处理为平铺或条带。

编辑 18：19 24/7/2017

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

到目前为止，我创建的最大图像仅略低于4GB。我刚刚将最高分辨率图像的大小翻了两番（达到 1638400x1638400 像素 RGBA，LZW 压缩）。到目前为止，一个小时过去了，我只生成了该层的 5%（在"MSI GP727RD Leopard"上，发布版本）。

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

我部分使用 GDAL 从坐标系 WKT 创建 GeoTIFF 标签（必须将其从驱动程序中破解）。

我

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

32位进程中的内存使用量非常低。我的进程正在使用 ~60Mb 的内存。

下面是一个使用 LibTIFF 库编写 bigTIFF 的好例子：

TIFF *tif = TIFFOpen(fileName, "w8");

来源和背景：https://gist.github.com/jcupitt/ba60e4e1100607d7a5cc9c19e2ec11e8

相关文章：