On January 3, 2011 09:49:21 am Bruno Postle wrote: > On Sun 02-Jan-2011 at 21:47 -0500, Yuval Levy wrote: > >If there are no objections I will updated the specs both in Hugin and in > >Libpano to make developers aware of things to come. > > There is no need to update the docs until the feature exists, the > implementation often determines the details anyway.
this is the wrong way of doing things. first write the specs, then implemented them. as an extra bonus, well written specs are the documentation that often lacks^H^H^H^H^Hfollows implementation. > Note that an existing hack to simulate weighting is to simply > duplicate control points, it works ok. Hack. Hugin also has a function to remove duplicate CPs. I already see the unpredictable results from improperly mixing the two. > Panotools::Script is ok, it will just ignore any unknown parameters > so long as they are implemented using the existing syntax. good to know. > I don't think there is a problem here, if extra data needs to be > added to the Hugin .pto format then it can be added, the other tools > can catch up. See the addition of photometric parameters and masks > to see how it can be done painlessly. thanks. I went by the book [0], posted [1] to panotools-devel and if there is no objection I will unify the specs. Once the specs are unified there will be work to do to bring the parser(s) up to date; and to actually implement the new parameters. I know I will move forward at a snail pace, so if somebody is faster than me, be my guest and take me over. Otherwise, I will appreciate the mentorship of more experienced devs as I am making my mistakes while trying to implement this. Yuv [0] http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/libpano/doc/developmentPolicy.txt?revision=1060&view=markup [1] http://article.gmane.org/gmane.comp.graphics.panotools.devel/1761
signature.asc
Description: This is a digitally signed message part.
