In Pano13 the tilt parameters TiX, TiY, TiZ and TiS?

21 views
Skip to first unread message

johnfi...@gmail.com

unread,
Aug 10, 2022, 2:26:21 PMAug 10
to hugin and other free panoramic software
Do the Pano13 tilt parameters TiX, TiY, TiZ and TiS exist in some form in Hugin or only in libpano13?

What are they tilting?

Looking at the code, I can't backtrack from implementation to intent.

They are effectively lens parameters, right?

I am thinking in terms of a division between lens parameters and "camera?" parameters:

The former is all part of the mapping between an x,y pixel position in the image and a correct yaw,pitch relative angle (direction of the obect that pixel imaged relative to the direction the camera is pointing).

The latter is involved in mapping from that correct relative yaw,pitch to the true location (in some coordinate system) of that object.  Computing the actual direction by combining the camera's yaw, pitch, roll with that relative yaw,pitch.  Combining that with the camera's X,Y,Z location (TrX, TrY, TrZ) to compute the line of sight.  Intersecting that line of sight with something to determine the object seen.

I'm investigating rewriting parts of libpano13 for various possible benefits for hugin++.  My first impulse is to leave out TiX, TiY, TiZ and TiS.  But if that would be a bad idea, I hope someone will tell me why.  If I don't leave them out, I'd really like to understand them better before including them.  That "Intersecting" step is something I want to provide an alternate version of.  The rest, I'd like to match behavior but with new code.

Florian Königstein

unread,
Aug 10, 2022, 3:24:57 PMAug 10
to hugin and other free panoramic software
I searched all source code files of Hugin++ for the string "tilt" (e.g. there could be variables tilt_x, tilt_y, tilt_z like in libpano13). But there wasn't found anything.
So Hugin probably does not use tilt.

I don't know the meaning of it.

But I wouldn't delete the tilt from libpano13. Hugin and libpano are widely used software, and surely some people have made other tools that can be used with libpano13 and Hugin.
If there are no ** very good ** reasons against it, you should keep backward compatibility when developing Hugin++ and libpano13 / fastPTOptimizer further.

johnfi...@gmail.com

unread,
Aug 10, 2022, 4:07:47 PMAug 10
to hugin and other free panoramic software
On Wednesday, August 10, 2022 at 3:24:57 PM UTC-4 Florian Königstein wrote:
I searched all source code files of Hugin++ for the string "tilt" (e.g. there could be variables tilt_x, tilt_y, tilt_z like in libpano13). But there wasn't found anything.
So Hugin probably does not use tilt.

I don't know the meaning of it.

But I wouldn't delete the tilt from libpano13. Hugin and libpano are widely used software, and surely some people have made other tools that can be used with libpano13 and Hugin.
If there are no ** very good ** reasons against it, you should keep backward compatibility when developing Hugin++ and libpano13 / fastPTOptimizer further.

One possibility is adding alternate code under a different internal name, such that it can be selected by the caller, but isn't used by default.
So, there would be two optimizers there, one with the original performance and features, the other with better performance, removing some features I don't understand and don't think hugin++ uses, and adding the features that I want to add.  The features I want to add would also change stitching.  I'm not yet even looking at what backward compatibility for that would look like (but don't expect it to be difficult).  For optimization, I will need to have new and old versions coexist in one build anyway during development.  Once I think the new optimization is across the board better than the old one for hugin++, that doesn't necessarily give a good reason to remove the old one from the build.  I'm not sure yet, but I think a parameter based internal (to the dll) run-time selection of which is being invoked (through the same call) would be better than simply giving the new one a new name.  But either is practical.

I'm a big believer in extern "C" interface across exe to dll boundaries wherever practical, even if both sides are coded in C++.  That solves some problems in Linux, and a far larger number of uglier problems in Windows.

If I make any big change to fastPTOptimize, the new code will be all C++.  I doubt that will present any problems for those building it from source (as it might have presented problems back when libpano13 was first invented).  But I certainly don't want to do anything that stops a caller of all the features of the DLL from being coded entirely in C.  Having a C interface to the DLL (because it is currently coded in C) is a good starting point for having a C interface because I prefer a C interface on that boundary.

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.


Bruno Postle

unread,
Aug 10, 2022, 5:15:33 PMAug 10
to hugin and other free panoramic software
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.

In principle you can have multiple planes in a single scene.

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.

-- 
Bruno

johnfi...@gmail.com

unread,
Aug 10, 2022, 5:58:03 PMAug 10
to hugin and other free panoramic software
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.

Bruno Postle

unread,
Aug 10, 2022, 7:00:49 PMAug 10
to hugin and other free panoramic software
On Wed, 10 Aug 2022, 23:58 johnfi...@gmail.com, <johnfi...@gmail.com> wrote:


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:

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).

Ah my mistake, I was describing the Tpy and Tpp parameters.

I think these other parameters are from an earlier attempt at the mosaic functionality. I vaguely remember that there was a system with four parameters, that was replaced by a three parameter system. If this is what it is then it is junk code.

-- 
Bruno
Reply all
Reply to author
Forward
0 new messages