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 <[email protected]> > Date: Thursday, September 28, 2017 at 3:36 PM > To: "Agram, Piyush S (334D)" <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 > >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
