Almost! ![]()
I would turn around Projections and Tie Points. I think the Features are projected into space according to the image geometry. Where they intersect, there lies the Tie Point. I might be wrong but there doesn’t seem a reason to project an already known 3D point. In the end, the image has only 2D info and only by different orientation of several image planes and a vector projecting from those planes will, by intersection, lead to 3D info.
Yeah, I would like to know that obscure reason as well - probably just some remnant of an ancient way to visualize those values…
The colours (of the lines, I guess you mean) in the inspector tool (there are also colours of the images, which represent exif groups I think) represent the number of Tie Points that 2 images have in common. That can say something about the reliability of the alignment and therefore the geometry used to calculate the (internal/external?) orientation of the images, and by extension the projections.
Which leads us to the last one - the error is called REprojection error, which is the clue - the Tie point is being REprojected to the image and the difference between this point and the real feature gives the value. I guess that since it is quite rare that several vectors (aka projections) will intersect at exactly one point, the Tie Point is at a position with the smallest error. I could imagine that the reprojection uses the original vector but from the idealized position of the Tie Point and then counts the pixels to the real Feature. If that were true, then what you said isn’t far off, only that there are no pixels to measure at the Tie Point but only “at home” on the image plane.
Phew - you always make me think about things that I usually just file under “oh, I’ve read that before somewhere”… ![]()