[gdal-dev] Geolocation arrays - location interpretation

[Even Rouault]

On vendredi 29 septembre 2017 03:35:55 CEST Agram, Piyush S (334D) wrote:
> Hi Even,
>      Here is my first cut at fixing the half pixel shifts:
> https://github.com/piyushrpt/gdal/commit/ead79550e7120767187a0b9c836b5d86122
> 3d997
 
> With these changes, the shifts are down to sub 0.2 pixels. Still not sure if
> I got the math right. Feel like the errors should be smaller for the ideal
> simulated datasets that I’m using.

Yes I think with a synthetic geolocation array that would encode the equivalent of a 
geotransform matrix (padfX[y][x] = X0 + x_res * x + 0.5 and padfY[y][x] = Y0 + y_res * y - 0.5), 
you should ideally get a ~0 pixel error.
One potential candidate for error would be the "loop over the backmap trying to fill in holes 
with nearby values." step. Given the backmap is created at a higher resolution than the 
source, the interpolation done in it can contribute errors.
On the above synthetic geolocation array, I would probably try with a backmap size equal to 
the geolocation dataset size (which should eliminate any hole filling step), and then tune 
things until I get a 0 error.
Perhaps the hole filling step would need a smarter/smoother interpolation logic

 
> Piyush
> 
> From: Even Rouault <even.rouault at spatialys.com>
> Date: Thursday, September 28, 2017 at 3:36 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 22:18:31 CEST Agram, Piyush S (334D) wrote:
> 
> 
> > 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/b199cbae9ea15e31c787c1480c342bb84
> > de
> 
> 
> > bf774
> 
> 
> 
> > 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?
> 
> 
> 
> 
> Yes I agree there must be a 0.5 pixel shift issue when looking at the
> forward path in GDALGeoLocTransform(), ie the one taken by if( !bDstToSrc
> )
 
> 
> 
> So we have currently
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170929/36ad1acf/attachment-0001.html>