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

[Seth Price]

One reason that warping is different than overviews is that warping has
much more versatile resampling. For the current overview code, an integer
number of pixels are combined into one pixel, and there is no overlap
between resampling areas. For warping code, each destination pixel draws
from source pixels which may overlap with the neighboring destination
pixel. This is also complicated because the weights need to be
recalculated for each destination pixel. I believe that there are
complications due to various image bounds and NODATA masks in warping.

Due to these problems, the warping code is much slower and complicated
than the overview code. Feel free to take a look, though. Be sure to post
anything you notice, and copy me in case I'm not paying attention to the
mailing list on that day.
~Seth

On Mon, March 30, 2009 3:45 pm, Benoit Andrieu wrote:
> 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
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>