Le jeudi 02 octobre 2014 09:55:17, Jukka Rahkonen a écrit :
> Rahkonen Jukka (Tike mmmtike.fi> writes:
> > > True, a way to improve things might be to specify -co PREDICTOR=2.
> > > Should apply to both LZW and DEFLATE.
> > > This is one of the filter that might be used by PNG, except that PNG
> >
Andrea Aime geo-solutions.it> writes:
> Interesting... wondering how much the predictor affects decoding speed
though (it is
> a common case to have to compress once, and read many times out of the
> compressed file)
A very quick test by decompressing deflate -> uncompressed from disk to disk
s
On Thu, Oct 2, 2014 at 9:55 AM, Jukka Rahkonen
wrote:
> Rahkonen Jukka (Tike mmmtike.fi> writes:
>
>
> > > True, a way to improve things might be to specify -co PREDICTOR=2.
> Should
> > > apply to both LZW and DEFLATE.
> > > This is one of the filter that might be used by PNG, except that PNG
>
Rahkonen Jukka (Tike mmmtike.fi> writes:
> > True, a way to improve things might be to specify -co PREDICTOR=2. Should
> > apply to both LZW and DEFLATE.
> > This is one of the filter that might be used by PNG, except that PNG has
different
> > filters, so it will eventually beat TIFF deflate.
>
On Thu, Oct 2, 2014 at 12:46 PM, Armin Burger wrote:
> The only time that I discovered where LZW does not work well was when
> using gdalwarp and directly writing the output as (untiled) LZW TIFF. This
> could create LZW files up to 2-3 times bigger than the uncompressed input
> TIFF. When using
Even Rouault wrote:
>
> Le jeudi 02 octobre 2014 01:06:57, David Strip a écrit :
> > On 10/1/2014 12:02 PM, Jukka Rahkonen wrote:
> >
> > For comparison:
> > Tiff as zipped347 MB
> > Tiff into png 263 MB
> > If I have understood right both zip and png are using deflate
> > algorithm so the
I would also always recommend to use -co PREDICTOR=2 when compressing
with LZW (or DEFLATE). So far I made quite good experiences with LZW and
PREDICTOR=2, with typical compression rates close to gzip compression
(meaning when putting the tif file into a tgz archive file).
The only time that I
Le jeudi 02 octobre 2014 01:06:57, David Strip a écrit :
> On 10/1/2014 12:02 PM, Jukka Rahkonen wrote:
>
> For comparison:
> Tiff as zipped347 MB
> Tiff into png 263 MB
> If I have understood right both zip and png are using deflate algorithm so
> there might be some place for improving d
On 10/1/2014 12:02 PM, Jukka Rahkonen
wrote:
For comparison:
Tiff as zipped347 MB
Tiff into png 263 MB
If I have understood right both zip and png are using deflate algorithm so
there might be some place for improving deflate compression in GDAL.
I
Even Rouault spatialys.com> writes:
>
> If that's an option for you, you could try lossless JPEG2000 compression. See
> http://www.gdal.org/frmt_jp2openjpeg.html and the "Lossless compression"
> paragraph.
My numbers for the most simple compressions without tiling:
Original RGB 424 MB
Le mercredi 01 octobre 2014 19:21:39, Stephen Roecker a écrit :
> I've also been toying with the compression settings lately and thought
> I would mention my experience. I'm not sure if this is known behavior,
> but when subsequently using the compressed rasters with 'gdaldem' I
> got some strange
I've also been toying with the compression settings lately and thought
I would mention my experience. I'm not sure if this is known behavior,
but when subsequently using the compressed rasters with 'gdaldem' I
got some strange results when the raster was greater than 4GB (i.e.
BIGTIFF). The resulti
Thanks! I have been also working with JPEG2000 compression with both he
jasper and openjpeg libraries. For some reason, the openjpeg library
didn't seem to work with 4 band imagery ( Error 6: Unable to export files
with 4 bands) , but the jasper library did.
Doug
On Wed, Oct 1, 2014 at 10:32 AM
I was sufficiently intrigued by this result that I tried on some 3-band
aerial data I had handy. My data is from over Phila, PA. Here are the
results for various compression/tiling combinations. It's quite
different from yours
93,784,427 out_none.tif
73,241,943 out_deflate.tif
59,786,628 out_
Le mercredi 01 octobre 2014 16:26:15, Newcomb, Doug a écrit :
> Well,
> I went back and compiled with 1.11.1 with the external geotiff library and
> got the same result for LZW, tiling made no difference in size .
>
> As an interesting sideline, I noticed that I had not been compiling with
> LZMA
Well,
I went back and compiled with 1.11.1 with the external geotiff library and
got the same result for LZW, tiling made no difference in size .
As an interesting sideline, I noticed that I had not been compiling with
LZMA compression previously and compiled gdal 1.11.1 with LZMA. I ran:
gdal
Le mercredi 01 octobre 2014 15:41:06, Newcomb, Doug a écrit :
> Hi,
> I have a 4 band uncompressed geotiff ( NAIP data for North Carolina, USA)
> that is 193 MB
> I've been going over the compression options for gdal_translate geotiffs
> and I note the following:
> gdal_translate -of “GTIFF” -co “
Hi,
I have a 4 band uncompressed geotiff ( NAIP data for North Carolina, USA)
that is 193 MB
I've been going over the compression options for gdal_translate geotiffs
and I note the following:
gdal_translate -of “GTIFF” -co “COMPRESS=PACKBITS” gives me a file that is
194MB in size
gdal_translate -o
18 matches
Mail list logo
