2007.07.05 16:56 "Re: [Tiff] 16-Bit-Per-Channel Lossless Compression", by Andy Cave

Hi Andrey,

Sorry for wasting your time and others - my mistake. I had two different checkouts of s/w I was experimenting with. One was set to work with full RGB, the other was set to work just with R (and stripped out the GB), which I didn't realise. That's where I got 20M from.

Andy.

----- Original Message -----

On Thu, Jul 05, 2007 at 04:08:47PM +0100, Andy Cave wrote:

Actually, I used quite small tiles - not something I normally do. For 1 bit data, larger tiles are better (but then there's more repeatability). In this case I used tiles approx 40x128 and lzw'd it as a stream. Unless I made a mistake, it compresses to around 20M or thereabouts. That was RGB interleaved 16 bit data - no messing about splitting it or anything.

I found that each tile compressed by around 50%+. I presume that was because the LZW code uses 9 or 10 bits for more data and also finds more repeated strings.

Can you repeat your below test with BLOCKXSIZE=40 and BLOCKYSIZE=128?

Hmm, I tried

 $ gdal_translate -co "COMPRESS=ZIP" -co "PREDICTOR=2" -co "TILED=YES" -co "BLOCKXSIZE=48" -co "BLOCKYSIZE=128" -co "INTERLEAVE=PIXEL" IMG_2948.Flowers1.tif IMG_2948.Flowers1-zip2-tiled.tif

...and results are

        Original                                60483984
        ZIP, predictor 2, tiled                 48269416
        ZIP, predictor 2, tiled, separated      49714874
        LZW, predictor 2, tiled                 63307750

It seems you have encoder which is significally different from the

libtiff one. Or you just made a mistake somewhere.