为什么多个栅格合并的结果这么大?[关闭]


10

我尝试像这样合并14个geotiff:

在此处输入图片说明

每个geotiff约为50Mb。我在输出端需要一个Geotiff

我的工作流程:

gdalbuildvrt -input_file_list list.txt test.vrt 

(我的列表中包含tif的名称)

然后 :

gdal_translate -of Gtiff test.vrt test.tif
Input file size is 79841, 59955

它可以工作,但是结果是13,3 Gb的geotiff!对于14个文件(每个50 Mb),我尝试了700 Mb(而不是13 Gb)的geotiff。

我知道gdal默认不会压缩,所以我尝试了以下命令:

gdal_translate -of Gtiff -co COMPRESS=JPEG test.vrt test_compressed.tif

但是文件的“合并”对于JPEG压缩来说太大了:

Input file size is 79841, 59955
0ERROR 1: JPEGPreEncode:Strip/tile too large for JPEG
ERROR 1: WriteEncodedTile/Strip() failed.
ERROR 1: JPEGPreEncode:Strip/tile too large for JPEG
ERROR 1: WriteEncodedTile/Strip() failed.
ERROR 1: An error occured while writing a dirty block
...

因此,我尝试了另一种工作流程,并将所有tif转换为jpeg(每个14 Mb),构建了一个vrt文件,并使用LZW压缩对其进行了翻译。但是输出geotiff约为5 Gb。

你能告诉我什么是做这项工作的最佳实践,以及是否有可能获得一个14 * 50Mb的Geotiff?

我没有尝试过,但是我考虑过在Photoshop中合并这些tif,然后使用左上/右下坐标重新地理定位。通过此工作流程,我想我将拥有14 * 50 Mb,但不确定。我想学习gdal最佳做法,所以我暂时没有尝试


咬人:如果输入默认是8位的tif,默认情况下是32位的输出,则会遇到严重的麻烦。因此,请确保保持字节定义不变。请记住:完整的tif可能会出现。有20x 50mb,因为tiff总是矩形

如果我理解的话,我在此屏幕截图中以绿色指向的数字必须在左侧和右侧相同。

位

您的输出图像将比输入图像的总和具有更多的像素,但这不能解释较大的差异。我建议您基于gdalinfo查看图像的特征,以查看使用了哪种压缩并检查范围是否正确。

50 Mb的14个Tif最初是我用-co COMPRESS = JPEG用gdal_translate处理的700 Mb的14个Tif。我压缩了栅格以减少Mb的数量,但这也许不是一个好主意吗?

此屏幕快照表示同一geotiff(01.tif)的2 gdal信息,屏幕截图的左侧是700 Mb的未压缩Gtiff的gdalinfo,在右侧以COMPRESS = JPEG结束同一Gtiff,因此50 Mb,差异为绿色:

不压缩和压缩01.tif文件的gdalinfo

据我说,范围是正确的,因为在qgis中它与其他数据源和卫星图像相匹配。

*假设输入图像的大小相同,则每个输入图像的大小为20000 * 12000像素,对于50 Mb的图像来说这是很大的,也许在创建镶嵌时您正在越过坐标系的范围。*

我不确定要“跨越范围”是什么意思。但是我尝试在QGIS中打开我的5 Gb LZW,范围很好,因为它与其他数据源匹配。

您的回答使我意识到Gtiff的大小不一样,您认为合并时可能会导致大小增加吗?因为gdal更喜欢相同大小的文件。我在每个Gtiff上制作了一个gdalinfo以获取其大小,Gtiffs的大小之间有很小的差异:

02.tif Size is 19956, 11981
03.tif Size is 19959, 11993
04.tif Size is 19961, 11992
05.tif Size is 19958, 11993
06.tif Size is 19958, 11990
07.tif Size is 19956, 11984
08.tif Size is 19956, 11993
09.tif Size is 19958, 11993
10.tif Size is 19958, 11989
11.tif Size is 19958, 11985
12.tif Size is 19958, 11993
13.tif Size is 19959, 11993
14.tif Size is 19960, 11994

然后,您应该查看图像的像素深度:如果您输入的数据以字节为单位,则应保留字节。gdal_translate -of Gtiff -ot字节-co COMPRESS = LZW test.vrt test.tif

我尝试了此命令,但gdal告诉我,tiff的大小已超出。

Input file size is 79841, 59955
0...10...20...30...40...50..ERROR 1: TIFFAppendToStrip:Maximum TIFF file size exceeded. Use BIGTIFF=YES creation option.
ERROR 1: WriteEncodedTile/Strip() failed.

但是,如果我必须创建一个较大的tiff,它不能解决我的问题,因为它大于4 Gb。对我而言,像素深度重要吗?(地图的高清照片,然后经过地理定位,而不是DEM)

备注1:在构建vrt之前将图像转换为jpeg并没有帮助,并且可能会丢失数据。

如果我松散一点信息并不严重。我当然不希望松开它,但是如果需要的话,这不是问题。我坚信如果我使用jpeg,输出将更轻,但是结论是,当输出为Gtiff时,情况并非如此。因此,这不是一个好的解决方案。我放弃这个解决方案。

>备注2:使用vrt会有所帮助:确定要使用GTiff吗?

是的,我需要一个Gtiff,因为我必须将其导入需要Geotiff输入才能工作的移动应用程序中(我认为该应用程序也可以接受地理空间pdf输入,但是我从不使用它,并且我想了解我的问题gdal,因为这不是我第一次拥有它)。


我尝试了-co tiled =是-co bigtiff =是-co compress = jpeg -co photometric = ycbcr并尝试了-co TILED =是-co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512

这2个命令运行良好,我的大小约为700 Mb。正是我所期望的。

现在我有另一个问题:QGIS无法快速打开它。我必须等待15分钟(但是在QGIS成功打开tif之前我退出了)。我不知道为什么 并且在我的android应用中,它不起作用(可能是“ tiled = yes”的原因)。我必须自己阅读一些文档。


使用-co tiled = yes -co bigtiff = yes -co compress = jpeg -co photometric = ycbcr
user30184 2014年

Answers:


2

您的输出图像将比输入图像的总和具有更多的像素,但这不能解释较大的差异。我建议您基于gdalinfo查看图像的特征,以查看使用了哪种压缩并检查范围是否正确。(假设输入图像的大小相同,则每个输入图像的大小为20000 * 12000像素,对于50 Mb的图像来说这是很大的,也许您在创建镶嵌时越过了坐标系的范围。)然后应该查看图像的像素深度:如果您输入的内容以字节为单位,则应保留字节。

gdal_translate -of Gtiff -ot Byte -co COMPRESS=LZW test.vrt test.tif 

备注1:在构建vrt之前将图像转换为jpeg没有帮助(它将在下一步之前解压缩),并且您可能会丢失数据。

备注2:使用vrt会有所帮助:确定要使用GTiff吗?

编辑:图像大小没有奇迹,但是您应该使用切片tif作为输出,以便可以对大数据使用jpeg压缩(-co TILED =是-co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512 )。如果太大,那么唯一的解决方案是使用gdalwarp以较低的分辨率重新采样。


咬人:如果输入默认是8位的tif,默认情况下是32位的输出,则会遇到严重的麻烦。因此,请确保保持字节定义不变。请记住:完整的tif可能会出现。有20x 50mb,因为tiff总是矩形。
Riccardo 2014年

您从哪里获得20000 x 12000?在问题建议在输入图像中示出的输出是79841 X 59955.
邪恶天才

79841、59955是输入vrt的大小。但是有5行和4列,因此我将〜80000除以4,并将〜60000除以5。正如我所说,这是假定图像的大小相同并且位置如图所示。
radouxju 2014年

我是通过编辑原始问题来回答的,我希望这是我必须继续的工作。
grimdaemon
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.