On Tue, 1 Feb 2022 at 12:53, johnfine2017 wrote: > On Tuesday, February 1, 2022 at 6:56:17 AM UTC-5 [email protected] 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). >
ptomorph was a proof of concept, so it mapped the coordinates of both sides of each control-point to the output panorama, mapped the half-way point back to each source photo, and used this as the distortion destination. The source photos were distorted into temporary files and a new PTO project created that used the temporary images as input. As I remember, the conclusions were that: 1. Squashing triangles as implemented in panotools looks terrible, it doesn't work, the 'Shepards' stretching/morphing as implemented in ImageMagick is much better. They both force an exact alignment, the pixel ends up exactly where you tell it to go, but Shepards does it right. 2. High-order polynomials work ok for correcting parallax. Though with a polynomial you get a smooth transition, so the pixels don't end up exactly where you tell them to go. The problem with a high-order polynomial distortion is you need a huge number of control points over the whole image or optimisation goes a bit mad. 3. Low-order polynomials are more stable, but less useful for correcting parallax errors which are often only visible in small-scale features. 4. The Shepards distortion is not an easy fit with the panotools lens model, so it would need to be implemented as a pre-processor (like ptomorph) or as a post-processor, either way it could be rolled-into nona. 5. Shepards distortion (and squashing triangles) won't work so well when three or more images overlap. Either: you accept that there is no perfect solution, you implement multiple-image control points (ew), or you only allow control points that are very close to the seam boundary (forcing a two image solution everywhere). -- Bruno -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAJV99ZhW7e25To6i5gyYfaexu%2BSAFOmcfwB%3DF2eZ5601J86X0Q%40mail.gmail.com.
