[gdal-dev] Overview scales

[Wilfried Karel]

Dear Even,

I'm not referring to a specific interpolation method. However, for
checking GDAL's behaviour, nearest-neighbor interpolation is surely the
easiest way. And yes, it may seem arbitrary whether to select only even
rows/columns or only odd rows/columns of the base image when
downsampling by a factor of 2 (although I'd prefer to select even rows,
as that means that the image coordinate systems of overviews only differ
by scales, and not also by shifts - if indices are 0-based and if the
image coordinate systems' origins are at the center of the upper/left
pixel).

However, what seems not arbitrary to me, but is quite an obstacle for me
(and possibly others who would like to use GDAL for doing
photogrammetry), is GDAL's behavior to not use strictly constant
sampling distances, as can be seen in the following example of 1 line of
a base image with 11 columns:

246   7   2 212  93  80 231 174 134  69  24

downsampling by a decimation factor of 2, using nearest-neighbor
interpolation (via GDALDataset::BuildOverviews) results in:

246       2      93     231 174      69

2 neighboring pixels in the base image are both mapped to the overview,
while all other source pixels are separated by a non-mapped source
pixel. That means that there is no linear transformation between image
coordinates in those 2 images. What I would strongly welcome, at least
for the very common decimation factors of 2, would be the following line
in the overview:

246       2      93     231     134      24

In that case, when transforming image coordinates from the overview to
the base image or vice versa, simply the scale factor of 2 would need to
be considered.

Looking into GDAL, it seems to me that (relative) image scales are
always derived from the base image / overview resolutions. While this
may be a good way to handle overviews with arbitrary scales (probably
created with other tools), I find this very distracting when the goal is
to simply have scale factors of exactly 2.
While decimation factors for GDALDataset::BuildOverviews can be
specified as integers only, the actual scale ratios may result as e.g.
1.8999 or so. This ratio is applied and then casted to
integer-coordinates of the source image grid. Hence the 2 neighboring
rows/columns close to the horizontal and vertical center lines of the
source image that are both mapped to the overview image.

I think that scale factors of 2 are the by far most common case. Thus,
I'd vote for rounding scale factors that are "close" to 2 to exactly 2.
However, as I can see it, the derivation of scales by dividing the
resolutions of 2 images is done in multiple places. Hence, this change
would need to be done in all those places, I believe.

Cheers,
Willi.


On 06.07.2016 10:08, Even Rouault wrote:
> Wilfried,
> 
>>
>> I'd like to use overviews for building image pyramids with a scale
>> reduction of 2 for photogrammetric applications. While
>> GDALDataset::BuildOverviews allows for the specification of "overview
>> decimation factors" as integers only, GDAL seems to interpret these
>> factors as hints only, and it generates overviews of slightly different
>> scales if the base image resolution is not divisible by the decimation
>> factor without remainder. The way that GDAL tries to even out the
>> varying offsets between the regular image grids not only results in
>> possibly anisotropic scales in the 2 coordinate directions of overview
>> images, but it also means that the transformation of image coordinates
>> from 1 overview to the other is not linear, but a step function (image
>> content is shifted between -0.5px and +0.5px), and that the sampling
>> distance is non-constant: there will be 2 neighboring rows and columns
>> close to the horizontal/vertical center lines of the base image that are
>> both mapped to neighboring rows and columns of the overview.
> 
> You are talking about nearest resampling right ? I'm not sure the current 
> behaviour was really intended. It is more likely just a detail of 
> implementation. We could potentially have a "NEAR_CONSTANT_STEP" alternate 
> variant that would implement what you mention. But anyway nearest resampling 
> is always more or less arbitrary. Even if you have an original image of size 
> 2N and you compute its overview of factor 2. Which lines do you take : the 2i 
> ones or the 2i+1 ones ? For high quality overviews, people use usually other 
> resampling methods, and starting with GDAL 2.0, with 
> bilinear/cubic/cubicspline/lanczos, you should get "good" results.
> 
>> What is the reason for this behavior, especially as by GDAL-means, only
>> integer decimation factors may be specified, anyway? 
> 
> Because 99% of people use powers of 2 ?
> 
> That said, if the overview is initialized (empty) with other means than this 
> interface, the overview building should be able to take into account non 
> integer decimation factor.
> 
>> Also, all other
>> image processing tools that I know of (and that are not based on GDAL)
>> seem to support a constant sampling distance of exactly 2.
>>
> 
> Even
> 

-- 
                        _____ _____ _____  Technische Universität Wien
   DI Wilfried Karel   /____// ___//    / Dept. of Geodesy & Geoinform.
  wilfried.karel@     // __ / /__ / // / Research Groups Photogrammetry
 geo.tuwien.ac.at    //__/// /__ / // /   & Remote Sensing
+43 1 58801 12244   /____//____//____/ Gusshausstr. 27-29, A-1040 Wien