[gdal-dev] Downsampling with gdal_translate and overviews

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gdal-dev] Downsampling with gdal_translate and overviews

Julien Michel-2
Hi all,

Yesterday I experienced a strange issue while downsampling image with
gdal_translate -tr option (-filter is average). I was downsampling data
before feeding them into a stereo reconstruction processing chain, and
the output DSM had a clear and straight cutline in the middle of the
image, as if the whole south part of the image was several meters lower
than the north part. I compared the downsampled images with an in-house
downsampling tool, and found indeed that whole rectangular portions of
the gdal_translate output were a bit shifted (maybe less than a pixel,
but that counts when doing stereo reconstruction). At one point I
started suspecting my .ovr files, and indeed removing them made the
problem disappear (I was subsampling by 10, whereas overviews have been
generated with the classical 2 4 8 16 32 ... progression). So here are
my questions :

- Is gdal_translate using the nearest overview level as a start for
resampling ?

- Is there a way to prevent that (other than removing the ovr file) ?

- Is it expected than the resampling yields artifacts when ovr files are
present ?

Thanks a lot for your help,

Regards,

Julien

--
Julien MICHEL
CNES - DSO/SI/2A

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gdal-dev] Downsampling with gdal_translate and overviews

jratike80
Julien Michel-2 wrote
Hi all,

...
So here are
my questions :

- Is gdal_translate using the nearest overview level as a start for
resampling ?

- Is there a way to prevent that (other than removing the ovr file) ?

- Is it expected than the resampling yields artifacts when ovr files are
present ?

Thanks a lot for your help,

Regards,

Julien

--
Julien MICHEL
CNES - DSO/SI/2A

Hi,

There are some answers to your question in the gdalwarp documentation http://www.gdal.org/gdalwarp.html.

-ovr level|AUTO|AUTO-n|NONE>:
    (GDAL >= 2.0) To specify which overview level of source files must be used. The default choice, AUTO, will select the overview level whose resolution is the closest to the target resolution. Specify an integer value (0-based, i.e. 0=1st overview level) to select a particular level. Specify AUTO-n where n is an integer greater or equal to 1, to select an overview level below the AUTO one. Or specify NONE to force the base resolution to be used (can be useful if overviews have been generated with a low quality resampling method, and the warping is done using a higher quality resampling method).

It is also possible that a solution/workaround for your problem could be to use gdalwarp instead of gdal_translate.

-Jukka Rahkonen-
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Downsampling with gdal_translate and overviews

Even Rouault-2
In reply to this post by Julien Michel-2

Hi Julien,

 

>

> Yesterday I experienced a strange issue while downsampling image with

> gdal_translate -tr option (-filter is average). I was downsampling data

> before feeding them into a stereo reconstruction processing chain, and

> the output DSM had a clear and straight cutline in the middle of the

> image, as if the whole south part of the image was several meters lower

> than the north part. I compared the downsampled images with an in-house

> downsampling tool, and found indeed that whole rectangular portions of

> the gdal_translate output were a bit shifted (maybe less than a pixel,

> but that counts when doing stereo reconstruction). At one point I

> started suspecting my .ovr files, and indeed removing them made the

> problem disappear (I was subsampling by 10, whereas overviews have been

> generated with the classical 2 4 8 16 32 ... progression). So here are

> my questions :

>

> - Is gdal_translate using the nearest overview level as a start for

> resampling ?

 

Yes. Well, "yes essentially" I should say if I'm pedantic: there's some subtely in the GDALBandGetBestOverviewLevel2() function in gcore/rasterio.cpp, line 3044 (a candiate overview level is accepted even if its resolution is lower up to 20% of the desired resolution, but I'm pretty sure that's subtelty is unrelated to your issue)

 

>

> - Is there a way to prevent that (other than removing the ovr file) ?

 

I second Jukka's suggestion to try with gdalwarp. Will be somewhat slower, but you'll likely not get those artifacts, given that gdalwarp and gdal_translate works completely differently regarding how they process chunks of pixels.

 

If your whole image fits into RAM, you might also go on using gdal_translate, and set the GDAL_SWATH_SIZE environment variable to at least the uncompressed size of the image (value in bytes). This impacts the size of the rectangles used in GDALDatasetCopyWholeRaster(), which might relate with the artifacts you observe. No guarantee though.

 

>

> - Is it expected than the resampling yields artifacts when ovr files are

> present ?

 

No, this is definitely not the expected behaviour. Definitely worth a ticket with ideally an easy way to reproduce

 

I somehow suspect that at some place (likely in rasterio.cpp or in vrtsources.cpp / vrtsourcedrasterband.cpp), although I couldn't find an obvious candidate by skimming quickly through them, the GDALRasterIOExtraArg argument of IRasterIO() and similar methods lacks a proper source window expressed as floating point coordinates, and use instead the base integer coordinates. Or something more subtle.

 

I can't really make sense why this is specific to overviews though. Are you sure the overviews don't already have those artifacts ? (you can extract them without any resampling with gdal_translate -oo OVERVIEW_LEVEL=x for example) In which case the culprit would be GDALRegenerateOverviews() / GDALRegenerateOverviewsMultiBand()

 

Even

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Loading...