<html>

  <head>

    <meta content="text/html; charset=ISO-8859-1"

      http-equiv="Content-Type">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <font face="Times New Roman, Times, serif">Hi Peter,<br>

      <br>

      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<br>

      <br>

      Jan<br>

      <br>

    </font>

    <div class="moz-cite-prefix">On 06/17/2013 10:48 AM, Even Rouault

      wrote:<br>

    </div>

    <blockquote cite="mid:1371458893.51becd4de04e7@imp.free.fr"

      type="cite">

      <pre wrap="">Selon Peter Freimuth <a class="moz-txt-link-rfc2396E" href="mailto:freimuth69@gmail.com"><freimuth69@gmail.com></a>:

</pre>

      <blockquote type="cite">

        <pre wrap="">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?

</pre>

      </blockquote>

      <pre wrap="">

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.

</pre>

      <blockquote type="cite">

        <pre wrap="">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.

</pre>

      </blockquote>

      <pre wrap="">

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

<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>

<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a>

</pre>

    </blockquote>

    <br>

  </body>

</html>