[gdal-dev] update to overview resampling methods?

[Ivan Lucena]

On 10/4/12 11:10 PM, Etienne Tourigny wrote:
> Hi list,
>
> I would like to know if the overview resampling methods listed on help
> pages are really up-to-date, because I found some discrepancies in the
> docs and code:
>
>
> - gdaladdo utility page / http://www.gdal.org/gdaladdo.html
>
> nearest,average,gauss,cubic,average_mp,average_magphase,mode
>
>
> - GDALDataset::BuildOverviews /
> http://www.gdal.org/classGDALDataset.html#a2aa6f88b3bbc840a5696236af11dde15
>
> "NEAREST", "GAUSS", "CUBIC", "AVERAGE", "MODE", "AVERAGE_MAGPHASE" or "NONE"
>
>
> - searching the code I found the following undocumented resampling
> methods (there may be others)
>
> AVERAGE_BIT2GRAYSCALE, AVERAGE_BIT2GRAYSCALE_MINISWHITE, AVERAGE_BIT2,
> AVERAGE_BIT2GR, NO_REGEN
>
>
> - gtiff overviews (in frmts/gtiff/gt_overviews.cpp)
>
> only mentions the following, does it also support all others?
> AVERAGE_BIT2, NEAR, AVERAGE, GAUSS
>
>
> So I have a few questions:
>
> 1) why are some methods not listed in GDALDataset::BuildOverviews and
> gdaladdo docs
> average_mp, AVERAGE_BIT2*, NO_REGEN  (there may be others)
>
> 2) are there some methods which are not supported in specific drivers,
> such as e.g. CUBIC in the gtiff driver?
Yes, some drivers support a different set of methods, so the "solution" 
is to find a common set of methods.

In a driver level, if we allow GDAL core to produce and write data 
buffer using a method that is strange to the format, that data could 
potentially look very different from other images produced by other 
software. In fact, how can we put in the metadata that the resampling 
method used was something that the format does not support. That would 
be inconsistent.

>
> 3) why is AVERAGE_MP considered unfit for use in the gdaladdo docs?
> and why is it still available?
>
> 4) AVERAGE_MAGPHASE has been reported as buggy by some QGIS users,
> could someone comment?
> see http://hub.qgis.org/issues/284
>
> 5) should the docs be updated and harmonized, including any
> driver-specific options, or are they too obscure to worry about?
>
>
> regards,
> Etienne
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>