Opened 12 years ago

Closed 11 years ago

#163 closed defect (fixed)

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

Reported by: cmbarton Owned by: grass-dev@…
Priority: major Milestone: 6.4.0
Component: Default Version: svn-develbranch6
Keywords: g.transform georectify Cc: glynn@…
CPU: Unspecified Platform: All

Description

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.

Attachments (1)

roads_streams.zip (1.7 KB) - added by cmbarton 12 years ago.
a group to georectify (from xy location) to test this with

Download all attachments as: .zip

Change History (12)

Changed 12 years ago by cmbarton

Attachment: roads_streams.zip added

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

comment:1 in reply to:  description Changed 11 years ago by 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

comment:2 Changed 11 years ago by cmbarton

Cc: glynn@… added
CPU: Unspecified
Milestone: 6.3.16.4.0
Platform: All
Resolution: fixed
Status: newclosed

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.

comment:3 Changed 11 years ago by hamish

Resolution: fixed
Status: closedreopened

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

comment:4 Changed 11 years ago by 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

comment:5 in reply to:  4 ; Changed 11 years ago by 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

comment:6 in reply to:  5 Changed 11 years ago by 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

comment:7 Changed 11 years ago by martinl

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

comment:8 Changed 11 years ago by 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

comment:9 in reply to:  8 Changed 11 years ago by 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

comment:10 Changed 11 years ago by martinl

Any reason why this ticket is still open?

comment:11 in reply to:  10 Changed 11 years ago by hamish

Resolution: fixed
Status: reopenedclosed

Replying to martinl:

Any reason why this ticket is still open?

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

Hamish

Note: See TracTickets for help on using tickets.