[gdal-dev] Reducing the size of a GeoTIFF file with significant blackfill

[Jan Hartmann]

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 <freimuth69 at gmail.com>:
>
>> 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130617/f4c70487/attachment.html>