Nathan Vander Wilt wrote:
I used gdal_merge to combine four tiles into a perfectly square image.
However, the resulting file was double the size on disk than I would expect
based on its dimensions and bit depth. I opened it in a hex editor, and
there is a huge pattern of data that repeats 0x00003075 followed by a ton of
zeroes.
Why is gdal_merge writing all this extra data? Does it have something to do
with the "sparse" blocks discussed in this thread?
http://lists.osgeo.org/pipermail/gdal-dev/2008-October/018750.html
I found how to perhaps compress these blocks with format options
(http://gdal.org/frmt_gtiff.html) and could try that, but that may lead to
compatibility issues. Why are these blocks in the file at all? Again, the
merged image is square and is completely covered by the source data.
NateVW,
There are a variety of reasons the file could be larger than expected.
1) Is the file compressed? If so, gdal_merge's rewriting of blocks
can result in them being moved to the end of the file if the block is
larger on the second write.
2) Is the file tiled? Depending on tile and image size partially used
tiles on the right and bottom of an image can result in files being
significantly larger than expected.
A "tiffdump" report on the output file might help deduce what is going on.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [email protected]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
