g.transform no longer calculating error for 2nd order transformation

[cmbarton]

Sometime recently, g.transform stopped calculating forward and backward error for 2nd order transformations. It simply returns 0's. 1st order transformations still work fine AFAICT.

[cmbarton]

a group to georectify (from xy location) to test this with

[martinl]

Replying to cmbarton:

Sometime recently, g.transform stopped calculating forward and backward error for 2nd order transformations. It simply returns 0's. 1st order transformations still work fine AFAICT.

The 2nd order transformations requires at least 6 GCPs. Your input POINTS file contains 6 points. Then forward/reverse error is 0.0's.

Martin

[cmbarton]

It turns out that 2nd order transformation need MORE than 6 points, not 6 points or more--at least in g.transform. There needs to be a change to the help file about this (for g.transform if different from i.rectify, or for i.rectify if in both). I've changed the information in the interactive georectify modules for TclTk and wxPython. I'm closing this because it is not really a bug (or at least I don't think so), but some misinformation in the docs.

[hamish]

It turns out that 2nd order transformation need MORE than 6 points, not 6 points or more

Not according to the i.rectify man page,

"The number of control points required for a selected order of transformation (represented by n) is ((n + 1) * (n + 2) / 2) or 3, 6, and 10 respectively."

And imagery/i.vpoints/analyze.c's compute_transformation() which leads to imagery/i.vpoints/crs.c's calccoef() function agrees. n >= 6.

The same code is reused by g.transform, I assume they are identical after re-indent. no idea about what the needs of backtransforming are. I assume they are symetric with a forward transform.

No idea if any of this matters to the status this bug. Reopening as the reason for closing it is invalid and the interactive georectify modules now need to be reverted.

Hamish

[cmbarton]

Well, when I use exactly 6 GCP's the RMS values returned by g.transform are 0, and i.rectify fails. If I use 7 GCP's, I get real values from g.transform and i.rectify works.

So at present, in terms of how this functions, the i.rectify man page is incorrect. I don't know if there is an error in the code or an error in the description.

Michael

[hamish]

Replying to cmbarton:

Well, when I use exactly 6 GCP's the RMS values returned by g.transform are 0,

IIUC that is RMS *error* value is 0, not results. By specifying the minumum number of points have you just fit a perfect surface to the points, and so no error? or is the actual fit bad?

you can interactively play with this with i.vpoints's analyse tool if you like.

ISTR in photogrametry the standard fiducial marks needed are like:

+          +

    +  +  

+          +

which compensates for rotation, scale, skew, and lens fisheye. (if that translates to this task geometrically..?)

and i.rectify fails.

what is the error i.rectify gives?

If I use 7 GCP's, I get real values from g.transform and i.rectify works.

... but what if 0 rms error is real?

So at present, in terms of how this functions, the i.rectify man page is incorrect. I don't know if there is an error in the code or an error in the description.

Or consider the case that the error is not with i.rectify at all. (sorry, I haven't tried the test data yet)

Hamish

[msieczka]

Replying to hamish:

Replying to cmbarton:

Well, when I use exactly 6 GCP's the RMS values returned by g.transform are 0,

IIUC that is RMS *error* value is 0, not results. By specifying the minumum number of points have you just fit a perfect surface to the points, and so no error? or is the actual fit bad?

On GDAL API reference pages [1] it reads that "Note that 2nd order requires at least 6 GCPs, and 3rd order requires at least 10 gcps". GDAL uses the same algorithm as GRASS and this info is coherent with GRASS manual.

AFAIK, for any transformation supported by i.rectify, adding an extra point above the minimum lets the algorithm calculate residuals. If only the very required number of points is provided, the transformation result is still valid, but you don't know the RMS. Given that, g.transform should return 0 with 6 values, but i.rectify should work. If it doesn't it's strange.

[1]​http://www.gdal.org/gdal__alg_8h.html

[martinl]

Maybe I don't understand the problem fully, is there any reason why this ticket is still open?

[hamish]

"I've changed the information in the interactive georectify modules for TclTk? and wxPython."

has that been changed back to 3,6,10?

Hamish

[martinl]

Replying to hamish:

"I've changed the information in the interactive georectify modules for TclTk? and wxPython."

has that been changed back to 3,6,10?

these values are checked in wxGUI

source:grass/trunk/gui/wxpython/gui_modules/georect.py@35312#L972​

[martinl]

Any reason why this ticket is still open?

[hamish]

Replying to martinl:

Any reason why this ticket is still open?

last bits should be done now. (r35450 thru r35454)

Hamish