On August 16, 2010 12:27:27 pm Dale Beams wrote: > I was under the impression that celeste was for cloud based areas.
Indeed it is. > Could celeste be used elsewhere? It would need to be trained against these other visual features you want to identify. The code is in the repository but so far there was no particular interest to pursue this. > previously was able to produce a wonderful set of > cloud type of photos Your problem has nothing to do with Celeste. If you disable Celeste in the Preferences Hugin should be able to produce exactly the same things it was able to produce previously. > > Because of the symmetry/similarity autopano-sift-c finds wrong > > control points, you just have to help it. ... > I didn't have to help AutoPano Pro. that's one of many differences between APSC and APP. They have evolved differently. APP does not need help in this kind of situations. APSC does. > Yes. Roll angle has been an issue for a while. Hugin turns photos > every which way. the optimization process will turn photos in every which way that the user allows it to. If you are sure about the roll (i.e. if you held the camera more or less constantly oriented) uncheck the optimization of the roll for the first iterations and optimize it only during the last tuning. > Why did the same control point detector (unless AutopanoPro has made > their own enhancements) make inappropriate matches in Hugin and not the > other program? There is more than just a CP detector to the process. First, features are identified in each pictures. Then they are matched / detected in pictures pairs. APSC is "dumb": it simply tries all the possible pair combinations blindly. The new APSC multi-row setting is slightly smarter. Some logic controls which pairs to feed to APSC. You can also simulate such a logic manually by selecting two images in the Images tab and running the CP detector of your choice. The consequences are significant. Say for example you have a sequence of 1-2-3-4 photos. I suspect APP runs the detector first on 1-2, then on 2-3, then on 3-4. Then it checks what results it got and decides based on expected overlap whether it is worth to detect 1-3 1-4 2-4. In contrast, APSC blindly detects 1-3 1-4 2-4 even if it would not make any sense. Of course also this can go wrong: if the photographer didn't shoot in a regular pattern, there is nothing but manual intervention (in the definition of adjacent pairs) that helps. > it's only during/after > alignment/optimization that matches are messy. because APP seems to have limits in place which prevent implausible input, while with APSC this is still mostly user responsibility. Have you tried the new mode in the Images tab? > In regards to symmetrical, isn't the point of a ACPD to find those > differences? not really. the detector only finds similarities. other logic (currently incomplete) should make sense of those similarities; or even drive the detection process as in Thomas' new detection mode. > Wouldn't program A and program B using the same ACPD have > the same issues? Assuming it is the same detector, it can be used in different ways. The way you have used it is like Hugin telling APSC "here are 21 pictures, find control points" which results in 230 detection runs on all possible pairings from those 21 images, no matter how realistic the pairing is. Or heuristic can be brought in and the program can first do 20 detection runs (one per each pair of time-contiguous images, i.e. 1-2 2-3 3-4 and so on). Then based on the findings estimate the shooting pattern (e.g. 3 rows of 7 because there is no point identified in 7-8 and in 14-15) and identify further points with 1-8 and 8-15 to test the 3x7 hypothesis before doing another 18 detections and having enough good and valid input for the optimization process. There are other strategies for this, such as starting with a template (if you know you often shoot 3x7, make a template for it). > Sometimes though I feel like I'm wrestling a tiger. This might be because you're approaching Hugin with the expectation that you can simply drop a bunch of pictures at it and it will do the job, rather than take the time to understand how it works (and how it is different from APP). > Many times Hugin simply can't put the thing together. like I said in my previous post to this thread, it's garbage-in garbage-out. The other tools may have a better garbage-filter. Hugin has finer grained control for the expert users. Sometimes there are trade-offs between the two approaches. Sometimes it is just that those working on Hugin have not taken the time to analyze and solve the issue because it is a non-issue for them. While writing the first reply to this thread I have assembled a 60 pictures project with little effort, and I have now another 35 pictures project going on. > Only then, if I like what I > see in the preview of another program, do i make an attempt to use > Hugin. I would prefer to just use Hugin as it's open source and GPL. to be honest, I think you are wasting your time running first the other program and then expecting Hugin to work like the other program. Either stick with the other program; or spend that time to understanding how Hugin works. > For what it's worth, I did also try Pablo's Patent Free ACPD. The > results were the same, which makes me think the problem is within the > optimization algorithm. No? No. It is with the input that goes into the algorithm that drives it to a point that is mathematically correct but visually wrong. The software can't see. You are the eyes and if you look at other software, you won't be able to give Hugin the input it needs to work properly. Hugin's strength (and weakness, depending on the perspective you take on it) is that the optimization process will run from any starting state (the typical one being a bunch of pictures at y/p/r of 0/0/0) and on any set of variables to optimize. APSC weakness is that it runs the detection process on any possible combination of two images out of those fed to it. This is at least partially solved with the new detection mode in the Images tab. It still depends on the user's shooting pattern, though. Yuv
signature.asc
Description: This is a digitally signed message part.
