[gdal-dev] Q: on gdalwarp of ecw file

[Jan Hartmann]

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.hartmann at uva.nl <mailto:j.l.h.hartmann at uva.nl>>
> Date: Tuesday, December 18, 2012 5:47 AM
> To: Jukka Rahkonen <jukka.rahkonen at mmmtike.fi 
> <mailto:jukka.rahkonen at mmmtike.fi>>
> Cc: "gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>" 
> <gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>>
> Subject: Re: [gdal-dev] Q: on gdalwarp of ecw file
> Resent-From: Michael Smith <michael.smith at usace.army.mil 
> <mailto:michael.smith at 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 at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20121218/fa24beb1/attachment-0001.html>