On December 29, 2010 04:50:17 am kfj wrote: > my contribution will only become practical > once my modifications to pano_trafo have been accepted
done (yesterday). > If you look at the purpose of the script in a > different way, you can maybe appreciate it's usefulness better: it's > an insurance that a certain number of control points will be kept for > each image pair when throwing out less well fitted CPs. makes sense and is indeed the weakness of keeping the top X% overall. > At some point the domain of GUIs or > command line parameters isn't sufficient anymore to cater for specific > needs - this is where scripting begins. While I agree with you that your script is useful, I disagree with the above statement. This is not about GUI vs. CLI. It is about workflow. Our GUI represent the workflow at a very superficial level: load > generate cp > align > stitch One level lower there are multiple steps involved, and problems happen inevitably when we try to execute those multiple steps simultaneously. For example, we use the optimizer to: - correct for lens distortion - align images on the panosphere - correct for variations (intentional or unintentional) of the viewpoint What we need are flows, and a script is indeed a very powerful way to express and modify flows; and we need a strategy playing conditionally across flows. In the case of CP generation, Thomas has introduced a simple but very powerful flow based on the assumption that the images are taken in sequence. We need a similar approach to the rest of the process; and probably even going forth and back at the superficial level a few time, simulating what an expert user would do. When designing these flows (or scripts), we need to ask ourselves the questions: what key metrics determines if the step is necessary or not? what key metrics determine if the step succeeded or failed? from the very very start (and completely spontaneous, so there may be errors): 1. are EXIV data available? if no: the "smartsisstant" is screwed. display a message asking the user about their pre-processing workflow (in most cases we can assume digital input nowadays) 2. based on the EXIV lens identification, FOV, F-Stop: do I have lens correction parameters stored? if yes, load them. If not suggest lens calibration (as a separate process) and recommend the user interrupts the stitch process until the lens is calibrated. 3. is there a pattern to the exposure values? if they are all the same, this is a single panorama. if they are regular (e.g. -2/0/+2) this is a user who knows how to shoot HDR. if they are all over the place it can be a panorama shoot in automatic mode (additional info in EXIV too); or it can be that there are one or two straying extra exposures (e.g. for a door or window in the scene). And I have not considered yet the case that multiple panoramas could be in the same set of images. and so on, and so on. > Designing the UI, one walks a > fine line between keeping it simple and comprehensible even for less > experienced users, and nevertheless offering powerful enough features. > A scripting interface is provided for those who want more, if not > total, control. this is not (yet) about designing the UI. It is one level deeper. > My current endeavours of producing a few simple Python scripts to deal > with the issue are just bait, really - and born from my Python > background and my dislike of perl. likes and dislikes aside, I agree with you that Python is the right way to go. Python bindings into the Hugin codebase are long time on my wishlist. > there isn't a scripting interface yet well, theoretically you can shell-script or perl-script or Python-script all of the CLI tools. That's not optimal, but sufficient for a start. The 'old way' of doing things was to script something for the CLI tools and if it would make sense wait for a coder to implement it in the main code and speed it up. With Python binding that second part would not be necessary since your Python script would share the same memory and variables as the code without going through slow and expensive read/write operations. > To facilitate experimentation along these lines, > I'll do the following: In my Python script, I'll provide the set of > control points as a set of objects with more properties than the ones > which can be gleaned from the mere coordinates in the pto. I'll > include the 'distance' and the coordinates in pano space for a start. > Then everyone who's capable of writing a bit of code can interface > with that and flag the points they want deleted. Good. Next in those properties we'd need to identify hand-picked from generated CPs, and here is the limitation of the approach: we need to interface into code and extend that structure there too. And the PTO file, of course. currently a CP line in the PTO file looks like: c n0 N1 x2319.75430140533 y1306.89102657256 X635.409481924115 Y1295.02701452379 t0 what would it take to expand it to: c n0 N1 x2319.75430140533 y1306.89102657256 X635.409481924115 Y1295.02701452379 t0 s0 a0 w100 with s: source (0=unknown, 1=human, 2=cpfind, etc.) a: active (0=yes, 1=no) w: weight (0 to 100) the big question is: would the tools that currently parse the PTO script stumble on this, or is it safe to add? if it is safe to add to the specs, let's do it. Then we can go about adding support for the s/a/w script parameters, all while making the assumption that they may or may not be present. ... > More room for scripting experiments. Let me just finish with a remark > I've made over and over: if your lens is well calibrated, you really > don't need that many CPs. Either you use a set with a great number of > CPs to calibrate your lens, or you have a well-calibrated lens and > only need the CPs to nudge your images in place. It shouldn't be > necessary at all to optimize lens parameters with every pano to 'bend' > the images to fit, and if you don't, what do you need so many CPs for? EXACTLY! Every time I see users coming back with thousands of CPs I wonder if this is another meaningless attempt to assemble the largest quantity of boring pixels or if it is an exercise in global warming by CPU strain. Theory is that three strategically placed CPs per image pair are enough when the lens is already calibrated. I work with five CPs per image pair, and for small projects (e.g. full sphericals with six fisheye shots) repeating the left-click-right-click dance on the CP tab is equally fast and yield better results than any CP generator I've tried before. A CP generator becomes useful only when dealing with a large number of input images. Yuv
signature.asc
Description: This is a digitally signed message part.
