[gdal-dev] ECW writing (was GTiff optimisation)

[Even Rouault]

Le mercredi 31 août 2011 17:18:35, Yves Jacolin a écrit :
> Le mercredi 31 août 2011 14:38:53, Even Rouault a écrit :
> > It contains a possible workaround
> > (altough you will find it quite ironic if you keep in memory what has
> > been said previously in this thread about gdalwarp being slower than
> > gdal_translate ;-)).
> 
> ouaaah, indeed it is really fast, the first file is not finished yet that
> the second one is already done.
> 
> Ok that's fine but my file is 50 % lighter than the input file :) It could
> be ok if the output file looks the same than the input file, but it does
> not. I suspect a compress option different. The documentation doesn't give
> any information about this. Can the user act on some creation option for
> ECW format with gdal_translate?

http://gdal.org/frmt_ecw.html mentions that the default target size reduction 
is 95% (TARGET creation option). You might want to lower it. If you want your 
output file to have the same size as your input ECW file, you should try
TARGET = 100 - input_ecw_file_size_in_bytes / (width * height * 
number_of_bands)

But the ecwhdr utility that Jean-Claude mentionned is really what you would 
want to use, if you indeed just want to alter the projection info and/or 
georeferenced bounds. I thought that there was only a Erdas utility to achieve
that, cool to see that it can be done with the SDK API. This gives me the idea 
that the ECW driver could be enhanced to implement the SetGeoTransform() and 
SetProjection() API, as well as some special metadata (likely PROJ and DATUM 
to be consistant with the creation options) through SetMetadataItem() to 
explicitely set the datum and projection codes. Then a simple python script 
could use those new capabilities to offer a service equivalent to the one of 
the ecwhdr utility. This would have the advantage of being available through 
GDAL as soon as the ECW driver has been compiled. I think I'm going to give it 
a try.

> 
> Thanks,
> 
> Y.