> Yes, with interpolation methods that take into account more than a
> single pixel of the source image, this effect will not be that obvious.
> But that doesn't resolve the problem if one is interested in more than
> just visualization, but e.g. in deriving positions from the image
> content, as
Dear Even,
On 06.07.2016 13:45, Even Rouault wrote:
> Le mercredi 06 juillet 2016 12:52:15, Wilfried Karel a écrit :
>> 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.
>
Le mercredi 06 juillet 2016 12:52:15, Wilfried Karel a écrit :
> 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.
I guess the effect is the most distracting with nearest neigh
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
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 hint
Dear list,
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
