On Monday, August 8, 2022 at 11:32:07 AM UTC-4 Florian Königstein wrote:
> Hi John, > > Optimization ran fast for me, > What is "fast" and which hugin did you use? It runs "fast" (17 to 36 seconds) using any build of pano13 with sparse lev-mar. But I still want it to be faster and I want much bigger examples (even though I don't currently have any) to also be fast. With one exception, it runs "slow" (85 to 212 seconds) in any build without sparse lev-mar. That is exactly as I'd expect and I'm not much interested in those. The exception I asked about was: 2021.0.0.52df0f76c700 built by Thomas I'm pretty sure that does not have sparse lev-mar. It optimizes in 21 seconds producing garbage results (large average, 158 worst case). The worst CP is not a poorly chosen CP. All the other versions have worst CP 30 to 38. My question was why that build is so fast and bad. The fact that the average can be below 3 and the worst 30 means I want to be able to do that well regularly. So I have the second issue of why fastPTO does slightly worse. It should simply be faster, not a tradeoff of much faster for slightly worse. But that is too complicated and detailed for me to want to ask here. I'll need to figure it out myself. But why the official hugin build is so much faster and worse than it should be seemed like somethings others might weigh in on. First I assume: > ** You took the images in a "standard way", i.e. by rotating the camera > around a tripod or panoramic head. > No. I did not set up my tripod for that one. I hand held as carefully as I could and came pretty close. So I certainly needed to optimize the six basic parameters of camera position as well as one lens parameter. > ** You just want so see how the optimizer works when you select nearly all > variables to be optimized. > I avoided opening the FOV can of worms. The correct FOV is known and using incorrect FOV as a coverup for other issues is one of my frequent tools, but not a valid tool either for this panorama or for this performance test. Some other parameters are in there mainly for "maybe they help" in addition to performance testing purposes. The problem is that you select both rotation and translation to be > optimized. Normally, you should only optimize for yaw, pitch and roll, but > not for trannslations - if you rotated the cammera but didn't perform > bigger translations. > Instead if you kept the orientation of the camera the same and translated > it for the different photos, then you should optimize for translations, but > not for yaw, pitch and roll. > I certainly needed all six of those. Otherwise, the panorama is garbage. I did my best to hand hold the camera varying only Yaw and Pitch, not Roll, TrX, TrY, and TrZ. But I didn't do that well enough. Tr value are tiny compared to the physical distance to nearest CP but they still matter. I haven't yet taken any mural shots, so varying translation without also Yaw is not in any of my examples. > > The reason is the following: > Suppose you have a FOV that is not big (like you have). Imagine first you > rotate the camera a bit horizontally. Then you rotate it back to the > original position and trannslate it a bit horizontally. If the amout of > rotation and translation have an appropriate ratio, then the control points > will move in a similar way (not much difference) in the image both by > rotation and by translation. So the optimizer cannot decide whether you > rotated or translated the camera. > There is enough difference. If the real world location of the CPs in an image are relatively co planar (with each other) then optimization should be able to distinguish rotation from translation. I have refined my ideas (but not yet written code) for handling the case that the real world CPs are not actually co planar. I think I will then do vastly better than 3 average and 30 worst case in this example. But before coding that, I want a somewhat better understanding, and maybe do a cleaner re-coding, of what is already there. In some cases you can determine both rotation and translation of the > camera, but these cases are usually not relevant for panorama photography: > Assume for simplicity you have an ideal (pinhole) camera (no lens > distortion). Assume you have 5 (or better 8) points in 3D space that will > get control points in the photos. You take two photos of these points by > both rotating and translating the camera between these photos. Then there > are mathematical algorithms with that you can determine both the relative > rotation and the relative translation of the camera. But there are at least > two cases in that the algorithms fail or yield bad results (big errors): > 1. There is no or little translation in the camera position between the > two photos > That is the area in which my current ideas are least solid: Hugin is already good for where all the cameras have little of no translation. The tricky case (but I won't know untill I code an test this) is a CP that is only seen by cameras that have little translation relative to each other, but significant translation relative to the chosen origin for the panorama. 2. All the points in 3D space are on a plane (e.g. on the wall of a house > or on the flat ground plane) > I'm not understanding your point. First, that case doesn't need to be fixed. Hugin does it well enough already. I'm trying to create only an alternative for when that isn't true. But, unlike the case of all cameras being in the same place, the new method would also work fine for planar CPs. I can't see any reason that ought to be a problem. Maybe you are thinking about the case that the chosen origin for the panorama is not among the camera locations (neither matches a single camera as one normally would) nor has cameras generally "around" it. That is a very hard (and pointless) panorama anyway, and maybe the planar CPs make it harder. But since you are commenting, I'll ask your opinion on a related part of where I'm going with all this (since you seem to understand the case of very many images): I think I can get a big performance boost by using the tendency to have multiple images per lens. So my question is whether, in the useful cases of very many images, there are several images per lens. I mean a "lens" in the sense of a set of parameters, so at the optimization level, a group of images within which every lens parameter is either linked to be equal or constant and happens to be equal. My code idea would speed things up significantly when one set of lens parameters (whether fixed or subject to optimization) applies to multiple images. It would only very slightly slow down optimization if every image has its own lens parameters. Since I bought by 105mm non-zoom lens. It has been used for almost all my panoramas. If I were an actually competent hugin user, I would separately determine its parameters and use them for all such panoramas. So far I just let each panorama solve whatever lens parameter(s) seem to help, but subject to one lens for all 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/a20cdf76-0859-4fa9-9669-3d15f4bf9155n%40googlegroups.com.
