Hi Peter,

You can get a compress-ratio to about 10% of the original size with the GDAL option -co COMPRESS=JKEG -co PHOTOMETRIC=YCBCR. Perhaps even more for you sort of data. Of course that compression is lossy, so for archival purposes it is useless. For viewers, you won't note the difference and it is quite fast, especially if you use gdaladdo with the option --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR

Jan

On 06/17/2013 10:48 AM, Even Rouault wrote:
Selon Peter Freimuth <[email protected]>:

Hi,

I have a 5 band, 16-bit orthorectified GeoTIFF from a satellite image that
contains a significant amount of blackfill and has a file size of over 21GB.
I would like to decrease the file size by eliminating or negating the
blackfill. I have attempted to use the SPARSE_OK option in GDAL as such:

gdal_translate -of GTiff -co "BIGTIFF=YES" -co "SPARSE_OK=TRUE" -co
"TILED=YES" input.tif output.tif

This has had no effect on the file size. Is my understanding of how SPARSE_OK
works incorrect or is there a potential problem with the SPARSE_OK option?
Peter,

Yes, SPARSE_OK works but as not you intend it to. SPARSE_OK is usefull only when
you create a file with the Create() API. With SPARSE_OK, at dataset closing, it
will not try to instanciate tiles that have not been written. But with
gdal_translate, the CreateCopy() API is used and it will write each block of the
target datasets, so SPARSE_OK is useless.


Is
there a better way of reducing the file size? I have tried
"COMPRESS=DEFLATE", which works, but then the product is veryyyy slow
loading into the viewing software.
I've not really a ready-made solution for you, but I'm thinking of a possible
evolution where the GTiff driver would detect the tiles at 0 (or nodata value)
and would not write them physically (like SPARSE_OK does on a newly Create()'d
dataset), or would point them all on the same physical tile (but the later would
cause interesting issues in case of update).

Best regards,

Even
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to