Ticket #1174 (closed enhancement: fixed)

Opened 7 years ago

Last modified 5 years ago

[PATCH] Enhancement request : specify Tiff Deflate compression level

Reported by: quickstuff@… Owned by: rouault
Priority: normal Milestone: 1.5.0
Component: GDAL_Raster Version: unspecified
Severity: minor Keywords: gtiff deflate
Cc: warmerdam

Description (last modified by warmerdam) (diff)

Creation of Deflate-compressed TIFF datasets lack a creation-option allowing to
specify the desired compression level.
(so-called zlevel 0-9 in zlib / pseudo-tag TIFFTAG_ZIPQUALITY in libtiff)

Attachments

Change History

Changed 6 years ago by rouault

  • keywords gtiff deflate added
  • owner changed from warmerdam to rouault
  • summary changed from Enhancement request : specify Tiff Deflate compression level to [PATCH] Enhancement request : specify Tiff Deflate compression level
  • milestone set to 1.5.0

Patch provided adding this feature. The only point I'm unsure is the name of the creation-option. I've chosen 'ZLEVEL'. I find ZIPQUALITY a bit confusing (it's a lossless compression).

Changed 6 years ago by rouault

Changed 6 years ago by rouault

  • cc warmerdam added

Changed 6 years ago by warmerdam

  • description modified (diff)

Even,

This patch looks great, go ahead and apply it in trunk.

Changed 6 years ago by rouault

  • status changed from new to closed
  • resolution set to fixed

Commited in trunk in r12575

Changed 5 years ago by quickstuff

  • status changed from closed to reopened
  • resolution fixed deleted

Though the enhancement worked under FWTools 1.4.x, the option ZLEVEL appears to do nothing with subsequent versions (FWTools 2.0.x) based on GDAL 1.5 betas.

Tested with FWTools 2.0.3 Win32:

gdal_translate -of GTiff -co COMPRESS=DEFLATE -co ZLEVEL=9 source.tif dest.tif

Whatever the number used (1...9) the destination file always has exactly the same size/compression ratio.

Changed 5 years ago by warmerdam

Even,

In our discussion in IRC was I was mixed up about tiffcp. The argument for zip compression is predictor. In fact, I think your earlier analysis is correct and that this isn't a libtiff problem. The difference (I think) was the gutting of GTiffCreateCopy() and change to close, reopen and then use GDALDatasetCopyWholeRaster(). So the change in behavior wasn't (I think) in libtiff, but in geotiff.cpp. Setting the zipquality after the reopen would appear to be the right solution.

I've leave it in your hands.

Changed 5 years ago by rouault

  • status changed from reopened to closed
  • resolution set to fixed

Fix commited in r13326. I've also fixed JPEG_QUALITY that has the same behaviour.

Note: See TracTickets for help on using tickets.