On Tuesday, February 1, 2022 at 6:56:17 AM UTC-5 bruno...@gmail.com wrote:
> > The remapping and stitching is performed as usual by the Hugin toolchain, > ptomorph just manipulates the input images a bit to make them stitch better. > By "input" do you mean original? I can't imagine how that data flow would work. Maybe I'm also confused by the terminology, but I think I understand what the "remapping" and "stitching" steps are. In that context, I saw "fine tuning" as an adjustment* logically* after remapping and before stitching. I would not want that *actually* after remapping, because I think the interpolation of moving pixels non-integer distance is best done all at once. So I would want the morphing to occur during the remapping (digging into that code is the biggest obstacle to my actually doing this whole thing). > > The question was always: should this morphing be added as an overall > polynomial distortion in the panotools lens model so that it became another > part of the optimisation step, > That is another thing for which I can't even imagine the workflow (or the point) so I must be misunderstanding what you mean. I am assuming a morphing that goes all the way to perfect alignment of every control point, so it would overwhelm the point of optimization if it were in optimization. So I would think it must be after optimization. I am only guessing at the data flow inside remapping, but based on that guess my idea is: First do optimization additionally computing something that I think isn't currently output but easily could be: the "correct" yaw and pitch of each control point. A control point exists in two images (could be more than two if other ideas I have were mixed in). The "correct" yaw and pitch of a control point would be necessarily the same across all images that contain that control point. For each image the control point is in, you would also compute the "incorrect" yaw/pitch of that control point by applying the optimization results for that image to that control point. In remapping, I assume you work on an integer row/column position of the output and need to compute the corresponding (non integer) row/column position in the input. I assume you have the parameters to convert the output row/column to yaw/pitch, then you would identify the triangle of control points (in correct yaw/pitch coordinates of control points). Then you need to adjust the point you are working on by a small amount based on where it is in the triangle and the difference between the "correct" and "incorrect" positions of each corner of the triangle. Finally, you apply the optimization results of the input image to convert that yaw/pitch back to row/column. When the triangles are very large in yaw/pitch, because either masking or other factors left no details needing to be fixed by extra control points, it is important that the adjustment by the error of the triangle is tiny compared to the adjustment by image's optimization results. So shape within that triangle is preserved as well as possible by the chosen projection method. or is it just a stitch-time fix (as in the ptomorph examples). The problem > for me is that doing it in the lens model is more elegant, and the problem > of three or more images doesn't exist because you wouldn't be forcing an > exact alignment; but on the other hand I was getting *really good* results > using the ptomorph approach with the 'Shepards' stretch to fit distortion > between two images. > -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/a04e49a6-7b7c-4a40-8387-9da5690c9a04n%40googlegroups.com.
