Jan, Its in the docs (http://gdal.org/frmt_gtiff.html)
About JPEG compression of RGB images When translating a RGB image to JPEG-In-TIFF, using PHOTOMETRIC=YCBCR can make the size of the image typically 2 to 3 times smaller than the default photometric value (RGB). When using PHOTOMETRIC=YCBCR, the INTERLEAVE option must be kept to its default value (PIXEL), otherwise libtiff will fail to compress the data. Note also that the dimensions of the tiles or strips must be a multiple of 8 for PHOTOMETRIC=RGB or 16 for PHOTOMETRIC=YCBCR From: Jan Hartmann <j.l.h.hartm...@uva.nl<mailto:j.l.h.hartm...@uva.nl>> Date: Tuesday, December 18, 2012 6:12 AM To: Michael Smith <michael.sm...@erdc.dren.mil<mailto:michael.sm...@erdc.dren.mil>> Cc: Jukka Rahkonen <jukka.rahko...@mmmtike.fi<mailto:jukka.rahko...@mmmtike.fi>>, "gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>" <gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>> Subject: Re: [gdal-dev] Q: on gdalwarp of ecw file Any ideas why this should be so, Mike? Is this the case for all images? I found a few pointers with Google, like the one below, but I am still unsure about the reasons. http://boatfloater.wordpress.com/2012/02/13/photometric-rgb-ycbcr/ On 12/18/2012 12:59 PM, Smith, Michael ERDC-RDE-CRREL-NH wrote: I've found setting PHOTOMETRIC=YCBCR to allow much higher compression when using jpeg compression in gtifs. Mike -- Michael Smith US Army Corps Remote Sensing GIS/Center From: Jan Hartmann <j.l.h.hartm...@uva.nl<mailto:j.l.h.hartm...@uva.nl>> Date: Tuesday, December 18, 2012 5:47 AM To: Jukka Rahkonen <jukka.rahko...@mmmtike.fi<mailto:jukka.rahko...@mmmtike.fi>> Cc: "gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>" <gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>> Subject: Re: [gdal-dev] Q: on gdalwarp of ecw file Resent-From: Michael Smith <michael.sm...@usace.army.mil<mailto:michael.sm...@usace.army.mil>> Thanks Jukka, very informative. I'll start with jpeg compressed tiffs and will do additional tests next year. I'm on a Cloud environment nowadays, so it's easy to set up clean VMs for testing. Any suggestions for experiments with different raster formats would be very welcome. Jan On 12/18/2012 12:33 PM, Jukka Rahkonen wrote: Jan Hartmann <j.l.h.hartmann <at> uva.nl> writes: Hi Even, are there any benchmarks to compare (uncompressed) gtif with the three formats above? My production maps are always tiled to 2000*2000 pixels, all zoomlevels precomputed. Very efficient with uncompresssed gtif, but they take lots of space. How much slower are these formats? Jan Hi, Here are some 6 years old numbers from some Mapserver tests: http://permalink.gmane.org/gmane.comp.gis.mapserver.user/23540 The speed feels now rather slow compared with the feeling I have from our recent services but differences may be alike. Or then they are not because drivers are not the same anymore and new hardware can suit better for one than for another. We are using aerial images mostly as JPEG compressed tiffs now but I have not bothered to do any timings lately. They save 90-95% of disk space, they are not much slower and users have not noticed the difference in quality so for us the choice was pretty easy. It is usually too simplified to say that some file format is slower that some other because there are so many other factors also in play. JPEG200O is an infamous example. It is a complicated file format and many software are very slow with big geospatial JPEG2000 images, but there are applications which can handle them very fast. Sluggish software does not necessarily mean that the format itself is slow. Six year old numbers 270/120/24 images per minute for tiff, ECW, and JPG2000 with Kakadu prove mainly that there must have been something wrong in how Kakadu and GDAL were working together at that time. You can get the best information about the real speed in your environment by making your own tests. Others will praise you later if you make controlled tests and publish the arrangement and results somewhere for future references. Unfortunately I do not remember myself how I did my own tests but I believe I was using FWTools 2.0.4 binaries. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
