>> 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.
kfj> Precisely. I wish I'd known of your work when I wrote my Python parser kfj> for pto files some months ago. I might even have made a Python module kfj> from it rather than writing it from scratch... ;) maybe we can use each others as cleanroom for quality testing. >> 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. kfj> This is very laudable. All the time I was messing with the pto format, kfj> I thought to maybe eventually write a proper grammar for it myself. kfj> I'm glad, though, I don't have to do it because the format is so kfj> 'ugly' (forgive me) - and I was hoping to maybe find support for kfj> creating a new format altogether - but I achnowledge it would be kfj> painful to make the move... I know it is ugly. That is why I needed to write a parser that was independent from the libpano code. kfj> I had a brief look at the code and the data structures it generates. I kfj> have some comments: kfj> - I could not find code handling masks. These are in lines like kfj> # masks kfj> k i0 t1 p"74 4350 2619 4365 2611 232 82 240" these are "new". I'll implement them. Ugly, it means that the p parameter has to be parsed once more... kfj> So the line type is 'k', i0 means image 0, the t-field is, I think, kfj> the type of mask (include/exclude) and the string after the p contains kfj> x/y coordinates of the points making up the mask polygon. If I've kfj> overlooked mask handling in your code, please disregard my comment kfj> - it seems to me as if you were reading the data into data types kfj> specified in the header file. This would imply that a next step would kfj> be needed to move all the values from the parse tree into hugin's data kfj> structures. Is this deliberate, to make the parser independent of kfj> hugins data structures? Or do the hugin data structures inherit from kfj> the parse structures? yes. I didn't want to mess with hugin. Hugin is already too big, and it depends on C++, while libpano is plain C. So I decided to take a simple approach and create new data structures that facilitate parsing. Then one can write a simple function that maps one to the other (and can be done by the people who know the hugin data structures). kfj> - I didn't see a reflection of the bottom end of hugin scripts with kfj> the hugin options, like kfj> #hugin_optimizeReferenceImage 0 kfj> #hugin_blender enblend kfj> #hugin_remapper nona kfj> #hugin_enblendOptions kfj> #hugin_enfuseOptions kfj> #hugin_hdrmergeOptions -m avg -c No. These ones surprised me. There are already 3 types of "hugin" variables. if libpano was a mess, hugin is helping: #-hugin #hugin and # hugin Can anybody shed some light on why 3 variants, and what does each mean? kfj> which would fit nicely into the pt_script_pano structure - unless, kfj> since they are 'technically' comments, you treat them as such, and kfj> hugin gets hold of them in some other way. doable. I just need a spec with their meaning. kfj> - Do you also parse what I've termed the 'ugly ducklings' - deviations kfj> from 'orthodox' pto which some of hugin's relatives use and which also kfj> come in the guise of comments? Like, there is a dialect which (I quote kfj> myself:) No. :) we need to document them. At this point my goal has been to create a mapping from PTO to txt formats (txt is the libpano format). kfj> "# now some CPGs produce files with yet another complication. kfj> # They put image data in o-lines and precede these o-lines with kfj> # more data in a line starting with '#-imgfile'. this line contains, kfj> as far as kfj> # I can tell, the image's width, height, and name, untagged. Having kfj> thusly output kfj> # these data, they are promptly omitted from the o-line. kfj> # I found Panomatic and A. Jenny's autopano to do this." kfj> If you're interested in my work, have a look at my pto parser at kfj> http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/parse_pto.py I am not a python programmer :) but I see what you mean by syntactic parser. -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . -- 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
