[gdal-dev] Geolocation arrays - location interpretation

[Agram, Piyush S (334D)]

Hi Even,
    I implemented the bilinear weighting like we discussed and that took out the systematic pixel shift from 1 to 0.5 (sign depending on orientation).
You can see the changes here:
https://github.com/piyushrpt/gdal/commit/b199cbae9ea15e31c787c1480c342bb84debf774

I also tried playing with the upsampling factor (1.3 to 4.0) and the discrepancy numbers were consistent after 1.5. Probably, the minimum needs to be sqrt(2) for square pixels.
Using the weighting fixed the truncation / rounding error and the results seem consistent when I move the output extent around.

The systematic 0.5 pixel shift suggests that there is still an issue. Is my interpretation that the GeoLocTransformer is supposed to operate on pixel center coordinates correct?
i.e – if my geoloc arrays were regular grid and I feed in the coordinates to the transformer, they return pixel centers – 0.5,0.5 etc.
I’m going to try implementing some round trip checks to see if that shows something?

Piyush

From: Even Rouault <even.rouault at spatialys.com>
Date: Thursday, September 28, 2017 at 12:25 PM
To: "Agram, Piyush S (334D)" <Piyush.Agram at jpl.nasa.gov>
Cc: "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] Geolocation arrays - location interpretation


On jeudi 28 septembre 2017 17:26:52 CEST Agram, Piyush S (334D) wrote:

> Hi Even,

> I think I have figured out how the GeoLocTransformer works. Dumped out

> the backmap and might have some changes.

>

> 1) Rounding up to the nearest integer is definitely the issue here.

>

> 2) I’m going to try this first – maybe a weighted approach will be

> better. For now, if a pixel falls in the middle of square – I’m going to

> add it to all of the 4 vertices. Then average all the data that went into a

> pixel of the backmap.



Perhaps bilinear resampling so that the weights are proportionnal ?



> 3) For the regular grid tests, if this shows improvement (hopefully) –

> I can share the implementation and we can possibly discuss about adding a

> weighting scheme. I don’t want to increase the runtime too much by adding

> complexity.



I think (sub-pixel) accuracy is more important than speed. Speed improvements can be investigated later if needed.



--

Spatialys - Geospatial professional services

http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170928/f95f06e4/attachment-0001.html>