On Wednesday, August 10, 2022 at 5:15:33 PM UTC-4 bruno...@gmail.com wrote:
> On Wed, 10 Aug 2022, 22:07 johnfi...@gmail.com, <> wrote: > >> >> I still hope this question gets a reply from someone who does know what >> those parameters are intended for and what other tools might be using them. >> > > 'Mosaic' XYZ control points are mapped onto a vertical plane that is > directly in front of the 'camera'. > > These other parameters allow different planes. The basic use is for > stitching a spherical panorama where the ground surface is a horizontal > plane, but there is parallax movement that needs to be corrected using the > usual mosaic functionality. > An example would really help, especially a runable example. I can't relate what I see in the source code to what you are saying. I also can't distinguish what you are saying from the Tpy and Tpp parameters (though it does seem like a third component should be needed to use them that way). > > In principle you can have multiple planes in a single scene. > With these parameters? Or do you mean with some feature added to the optimizer? These seem to apply to at least a whole image at a time. Part of what I was asking was whether these are logically associated with the lens as I would guess from the source code (which would mean they typically would apply across more than one image). > I have in the past wondered if (with a modified GUI) this functionality > could be used to build a hybrid photogrammetry application, where you match > control points, but also indicate which points are coplanar - this would be > very useful for architectural surveying where you are only really > interested in placing planes and the intersections between them. > >> Again, I really can't see how that is *this *(TiX etc.) functionality could be used that way. But I'm glad you mentioned that idea. I think there are more common use cases than the one you mentioned. A big part of my intent here is due to dissatisfaction (as a user) with the two basic models hugin effectively has for the parallax problem: 1) Assume there is no parallax problem (such as with no translation) or 2) Assume all CPs of an image are coplanar and if that assumption is mostly correct, that eliminates the optimization errors due to paralax, leaving only the fundamentally intractable part of the parallax problem. I really dislike that coplanar assumption for all CPs of an image and want to offer an alternative that is much more general (but has its own limitations, so it can only be an alternative, not a complete replacement method). But I do like the idea of letting the user identify a set of CPs (across multiple images for it to really be useful) that are coplanar. I don't immediately have an idea what the UI should look like. I do immediately think I know what the optimization math would look like (and I can't see any similarity to TiX etc.) It is compatible as a sub alternative to my main idea and shares the same issues (and I think solution) for changes needed in stitching (though not needed in the use case you described). There really is a fundamentally intractable part of the parallax problem. But in most cases you don't need to let that drive optimization to an incorrect result; Then after optimization is correct, you can't really stitch correctly, but I think you can stitch in a way that looks correct. Feel free to tell me I'm wrong about any of this (I often am at a stage like this). But hopefully you can do so in an informative way. -- 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/5f44a5fb-f8df-45ca-97cc-27d68bcc0b8cn%40googlegroups.com.
