On 29 Dez., 00:29, Rogier Wolff <[email protected]> wrote:
> Allow me to add that I really don't think that removing all the "far" > points is the best way to do this. Overall you are probably right. I contributed my script for the specific purpose of Kevin's initial request - he noticed that when doing an overall delete-by-distance, some images would be left without control points altogether, since they couldn't compete with other image pairs where the situation was better. It's is a real problem, I've been there, I've sympathized and I felt it worth my while to do something about it, though my contribution will only become practical once my modifications to pano_trafo have been accepted, which I hope they will. Until then, Bruno's solution ought to solve Kevin's specific problem. 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. > Often hugin will find control points in the grass near my > feet. Sometimes one or two near the horizon where it actualy matters. > > Now the 5 or 10 control points in the grass will "twist" the images so > that the one or two good ones are some of the furthest from their > proper mapping. But in fact they are the ones that matter most. as far as twisting is concerned, see my final remark > Throwing them away (well ok, commenting them out) isn't going to help > the pano. I totally agree that a simple approach like the one currently taken - i.e. just looking at the 'fit' or 'distance' won't help or even be detrimental in certain situations. But it may work for quite some and be better than what there is now. 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. 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. 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. It seems to me, though, that Python is ideal as a scripting language - it's free, it's easily included, the path is trodden, the syntax is easy... just to name a few advantages. Me peeking and poking in the pto files isn't really what I have in mind in the longer term, it's because I haven't found an easy way into hugin's body of code, since that isn't very well documented and, well, organically grown - to be nice about it - and there isn't a scripting interface yet, just a bunch of historically grown interfaces: - the CPG interface, which isn't much to write home about by anyone's standards, so I've written glue code for that - pto files, which work but are ugly and dialect-ridden - but I have written a pto parser to help - lens.ini files, which are inflexible and a bit obscure - the interfaces to other tools which aren' even fully transparent (at least not to me) so when I want to control these interfaces, I usually have to write glue code as well (as I have done to interface with panomatic, which obstinately refuses to work with cropped images) and there may be more than I can think of at short notice. > You know what I'd like to do? I'd like to assign weights to the > control points. For example, all control points would start with > weight 10. But then I can set the weight of those in the distance to > 100 to increase their weight. Or I can set the weight of those closeby > to 1 to reduce it. (for an identical effect). I'm with you there. 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. > One step further we'd find different ways to set the weights > automatically. For example the similarity index might come into > play. Or I might be able, as a user, to indicate: the further up an > image the higher the weight. As I have remarked previously, UI design is walking a thin line. If we had a scripting interface, we could leave such more ambitios levels of control to the domain of optional functionality: plugins. Most large software packages introduce them at some point, that's one of the advantages of a scripting interface. And many of them choose Python (even if they've started out with follies like lisp dialects initially, if you know who I mean) > When I shoot panos, I take portrait pictures. These overlap in a > narrow region with the next image. So I think I'd like about > > --sieve2width 2 --sieve2height 5 --sieve1size 3 > > To have points near both edges let and right, and a uniform > distribution along the height of the image. If in all ten areas 3 > control points are found, 30 is a bit much. On the other hand, it > doesn't always find control points. Hmm. cpfind can't know the > overlapping area, right? So I would need say a 5x5 grid to guarantee > some points in the overlapping area. Oh well. Then we might have > even more control points if things match up well.... 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? > Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. > Does it sit on the couch all day? Is it unemployed? Please be specific! > Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ That actually made me laugh Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
