[gdal-dev] Availability of Lanczos and cubicspline in gdaladdo

[Benoit Andrieu]

Thanks for the answer,

> > Hi list !
> > 
> > I was wondering why the Lanczos and cubicspline are available in 
> > gdal_warp and not gdaladdo ?
> 
> Benoît,
> 
> The overview builder and warper use quite different mechanisms so there
> is no close relationship between the resampling options available in each
> case.
> 

Ok, I think the best thing to do for me is to look at the source code...

> > The quality after downsizing images with gdalwarp is so perfect that I 
> > am now willing to include this in my overviews.
> > Is there any chances to have this include in future releases or is there 
> > any difficulties I am not aware of ?
> 
> It is my intention to add a cubic resampling option to the overview
> building for 1.7.  I am not planning to add the other options.

Are you not planning because there is nobody asking for (poor me) ?
The image quality on our datasets is really amazing between merging with bilinear / cubicspline / Lanczos !
I am surprised to be the first one to notice such a difference.
I will try to see if gdaladdo and gdalwarp give the same results. I have a doubt right now.

> In theory it should be possible to programatically connect warpers to
> overview levels in cases where overview band objects have "proper"
> dataset parents - which is the case with GeoTIFF hosted overviews.
> 
> For instance, this C entry point could likely be used with hSrcDS being
> the base datset, and hDstDS being the dataset for the overviews.  One
> problem with this plan is that it is likely that overview datasets do
> not have proper geotransforms or coordinate systems.  So you might need
> to push a geotransform onto the overview dataset (with GDALSetGeoTransform())
> before calling GDALReprojectImage().
> 
> CPLErr CPL_DLL CPL_STDCALL
> GDALReprojectImage( GDALDatasetH hSrcDS, const char *pszSrcWKT,
>                      GDALDatasetH hDstDS, const char *pszDstWKT,
>                      GDALResampleAlg eResampleAlg, double dfWarpMemoryLimit,
>                      double dfMaxError,
>                      GDALProgressFunc pfnProgress, void *pProgressArg,
>                      GDALWarpOptions *psOptions );
> 
> Generally the warp api resamplers are not suitable for with a destination
> dataset with a radically lower resolution than the source.  So I'd suggest
> doing it such that each overview is generated from the next higher resolution
> overview rather than always building from the base level.

Ok.
Do you mean that producing a 1m x 1m image with 20cm x 20cm images could give bad results ?

There is something I am not sure to understand.
You are saying to use the warp library directly from the overviewing mechanism.
Why can't I take the lanczos/cubicspline codes, separate it from the warping code to make a "library" callable from the overviewing and warping codes ?
I think that the answer is a long one so if it is too much to ask, just say to me to look at the code ! ;)

> Note that the overview levels still need to be pre-created using normal
> mechanisms.

Ok. Have to look.

I'll take a look in the next days and will come back for help !! :)

Regards,

Benoît Andrieu
bea at ixsea.com
benoit.andrieu at gmail.com