On Mar 5, 11:40 pm, tcorbet <[email protected]> wrote: > John is very knowledgeable and he suggested yaw, pitch, and roll AND > the tutorial says that we ought also be able to 'skin the cat' by > letting the software optimize the r, v, d and e parameters. Is there > a nice article, in lay terms with minimal jargon, to explain either > why the results would be identical, or if the results would not be > identical, what the shades of difference would be between those three > seemingly very different approaches?
I'm extremely pleased that my efforts contributed to a successful solution, but "very knowledgeable" I am not ! When I wrote I didn't realise that we were dealing with a "parallel projection" (http://en.wikipedia.org/wiki/Parallel_projection) rather than a perspective projection, so ( X Y Z ) translations does make more sense than ( y p r ) rotations - I apologize for that misdirection ! Bruno's flat-scan tutorial suggests that optimising ( r X Y Z ) may be practically equivalent to ( r d e v ). ( r ) is just rotation about the Z-axis, in case the side of the image is not quite parallel to the Y-axis. I can see how a ( d e ) offset could produce the same effect as an ( X Y ) offset, but is not recommended because it will mess up if ( a b c ) are not disabled. The implied equivalence of ( v ) and ( Z ) is intriguing. I suspect that ( v ) is angular size and ( Z ) is (linear) viewing distance. As such both should - theoretically - be irrelevant to a parallel projection "mosaic", so my guess may be simplistic. One way of describing a parallel ( or orthographic ) projection is "as if the viewpoint is at an infinite distance from the object", which is what an object-space telecentric lens does (http://en.wikipedia.org/ wiki/Telecentric_lens). By definition, a telecentric lens has an angle of view ( v ) of zero degrees, but of course its linear field of view is not zero; its linear FOV simply doesn't vary with distance ( Z ). This telecentric approach to parallel projection problem seems to run aground because Hugin will not accept ( v = 0 ) and seems to have no input for linear field of view, except for the pixel dimensions of the input image itself. Optimising ( r X Y ) should work if none of the images need to be "resized" to fit, eg. flatbed-scanned at the same resolution. It seems conceivable that optimising ( v ) or ( Z ) might somehow fudge the resizing ... ? :-J -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
