[gdal-dev] GTiff optimisation
Even Rouault
even.rouault at mines-paris.org
Wed Aug 31 08:38:53 EDT 2011
Selon Yves Jacolin <yjacolin at free.fr>:
> List,
>
> I successfully assigned my projection information but still have some
> difference in the file size. This is not so important but I wanted to
> understand
> the reason. Idea welcome :)
Yves,
You have a difference between the input file and the output file produced with
gdal_translate (not gdalwarp) with identical compression method and NBITS value,
right ? If the difference is in the order of a few hundred bytes, it might be
due to the way the TIFF directory is written (and perhaps rewritten), nothing
really to bother (from my developer point of view, the cost for "fixing" this
would scare me of, because of the complexity of dealing with this issue in the
GTiff driver while still being compatible with most active libtiff versions in
the wild). But it is a significant difference, then it is unexpected and it
would be indeed good to find the reason. You could provide a sample for further
examination if you cannot figure out the reason by yourself.
>
> Another question: I have 2 000 ECW files (40 Mo each), 49 ECW files (1 Go
> each)
> and 2 ECW files (2 Go each). I worked first on 2 Go ECW file, it takes around
> 1
> day to assign the projection information in the files.
>
> Do you think this is normal? How can I improve this?
It sounds particularly slow indeed, even if it isn't totally unexexpected,
gdal_translate being a format agnostic tool, and when doing ECW -> ECW
transformation, it will decompress and recompress the data, which is not ideal
from a speed point of view and, in the case of lossy compression methods, from
the data integrity point of view. But a day for 2 ECW files is admitedly slow.
You might hit that ticket about ECW -> ECW slowness :
http://trac.osgeo.org/gdal/ticket/3454 . 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 ;-)).
Another solution if you only want to correct the projection information is to
use the "ECW Header Editor". I have never used that tool myself, but a search in
your favorite engine should bring some results. However it might not be
appropriate for batch processing.
Even
>
> Thanks.
>
> Y.
>
> Le mardi 30 août 2011 18:46:53, Matt Wilkie a écrit :
> > Yves, it's best to use gdalwarp without any compression options and
> > then use gdal_translate as a last step to apply the compression. See
> > http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp#GeoTIFFoutput-coCOMPRESSi
> > sbroken for more.
> >
> > cheers,
> >
> > matt wilkie
> > --------------------------------------------
> > Geomatics Analyst
> > Information Management and Technology
> > Yukon Department of Environment
> > 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9
> > 867-667-8133 Tel * 867-393-7003 Fax
> > http://environmentyukon.gov.yk.ca/geomatics/
> > --------------------------------------------
> >
> > On 30/08/2011 4:22 AM, Yves Jacolin wrote:
> > > Hello,
> > >
> > > I am converting GTiff to GTiff in order to add projection and
> > > georeferencing information in the header. I am using gdalwarp with some
> > > flags, mailny -co flags. I have some question about this.
> > >
> > > Here is my command line:
> > >
> > > gdalwarp -co "COMPRESS=PACKBITS" -co "PHOTOMETRIC=MINISWHITE" -co
> > > "NBITS=1" - s_srs "EPSG:2154" -t_srs "EPSG:2154" input.tif output.tif
> > >
> > > 1. File size: input.tif and output.tif have different file size, output
> > > file is 50 % bigger than the input file. Is it normal?
> > >
> > > 2. If I use gdalinfo on my output file, I have no information about
> > > MINISWHITE parameter while I have it in the input file. Am I using this
> > > creation option correctly? This issue could be related to the first
> > > item?
> > >
> > > 3. I also have a "AREA_OR_POINT=Area" item in my output from gdalinfo,
> > > what does it means?
> > >
> > > gdal version: GDAL 1.7.3, released 2010/11/10
> > >
> > > thanks,
> > >
> > > Y.
> >
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> Yves Jacolin
>
> http://yjacolin.gloobe.org
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
More information about the gdal-dev
mailing list