On 2 Feb., 09:22, D M German <[email protected]> wrote: > Hi everybody, > > I undusted the code I started few years ago and finally completed a > working prototype:
what took you so long ;-) > THe idea of this parser is old: if we have a single parser (as a > library) we can then have multiple tools reading (and perhaps > generating) these files. Precisely. I wish I'd known of your work when I wrote my Python parser for pto files some months ago. I might even have made a Python module from it rather than writing it from scratch... > One of the goals is to replace (or at least create an alternative > execution path) the parser in libpano, so we can more easily upgrade it > when we need new options/variables. This will probably help in the > creation of more portable lens parameters. This is very laudable. All the time I was messing with the pto format, I thought to maybe eventually write a proper grammar for it myself. I'm glad, though, I don't have to do it because the format is so 'ugly' (forgive me) - and I was hoping to maybe find support for creating a new format altogether - but I achnowledge it would be painful to make the move... I had a brief look at the code and the data structures it generates. I have some comments: - I could not find code handling masks. These are in lines like # masks k i0 t1 p"74 4350 2619 4365 2611 232 82 240" So the line type is 'k', i0 means image 0, the t-field is, I think, the type of mask (include/exclude) and the string after the p contains x/y coordinates of the points making up the mask polygon. If I've overlooked mask handling in your code, please disregard my comment - it seems to me as if you were reading the data into data types specified in the header file. This would imply that a next step would be needed to move all the values from the parse tree into hugin's data structures. Is this deliberate, to make the parser independent of hugins data structures? Or do the hugin data structures inherit from the parse structures? - I didn't see a reflection of the bottom end of hugin scripts with the hugin options, like #hugin_optimizeReferenceImage 0 #hugin_blender enblend #hugin_remapper nona #hugin_enblendOptions #hugin_enfuseOptions #hugin_hdrmergeOptions -m avg -c etc. which would fit nicely into the pt_script_pano structure - unless, since they are 'technically' comments, you treat them as such, and hugin gets hold of them in some other way. - Do you also parse what I've termed the 'ugly ducklings' - deviations from 'orthodox' pto which some of hugin's relatives use and which also come in the guise of comments? Like, there is a dialect which (I quote myself:) "# now some CPGs produce files with yet another complication. # They put image data in o-lines and precede these o-lines with # more data in a line starting with '#-imgfile'. this line contains, as far as # I can tell, the image's width, height, and name, untagged. Having thusly output # these data, they are promptly omitted from the o-line. # I found Panomatic and A. Jenny's autopano to do this." If you're interested in my work, have a look at my pto parser at http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/parse_pto.py It's written in Python, and it's merely syntactic, so it doesn't assign the scanned data to meaningful variables like 'float fHorFOV' but merely to something named like the tag letter (I think it's v, in this case) - at the time this was sufficient, and the structure is the same, just the fancy names are missing. But apart from that, it's, I reckon, fairly complete and well commented, so you might find it a good read (giggle). 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
