On Oct 7, 2009, at 8:04 AM, Lukáš Jirkovský <l.jirkov...@gmail.com>
wrote:
>
> Hello,
> I've got a quite sound idea. Just "to put a bug in your head" (czech
> saying) – to make you think about it. There are numerous bug reports
> which are caused by using some "forbidden" characters inside makefile
> (and some strange bugs too). Sometimes they can be escaped but
> sometimes it doesn't help or it breaks something.
>
> I can imagine using something different instead of makefile. My first
> thoughts were about using some dynamic language like python or perl
> but I rejected these thoughts immediately. They would brink need to
> distribute python/perl/whatever with hugin. So this is no way. They're
> too big.
>
> What I think may be quite nice way to store necessary data is the XML.
> Although I'm not a huge XML fan (in fact I think it's overused) it
> could bring some improvements to the current workflow. I've two ideas
> how it could help. First it wouldn't break just because someone used =
> (or so) in file name. Second it would allow to create better
> structured files which would be more readable especially when working
> with stacks. However it has it's culprits eg someone would have to
> write some parser which would process this kind of files. The other
> problem is backward-compatibility.
>
> Let the discussion begin.
>
> regards,
> Lukáš
>
Hello Lukas,
I have long since considered something similar to this. I had a draft
email that I never sent to this list that outlined my thoughts but I
never fully developed it.
I would like to see the pto files be replaces by some other persitent
file format. I had considered XML at the time as I find it easy to
read and extend as more data is needed to be stored. (people always
seem to be able to come up with different things for hugin to do.)
Hugin would load up the project from this new file and then
export .pto files along with some sort of platform specific script
file (bat on windows, shell scripts on Linux/mac os x). The script
file generation would be handled by a generic interface calling the
platform specifc script generators as necessary. In the end, only one
file would be necessary to be retained along with the images: the
original file.
I am a fan of python but it is probably overkill for the sequence of
commands that would need to be executed.
I hadn't considered reusing the same code to generate a cli tool
that would parse the XML and execute the commands directly. That
would be cool....
I'll try to post more later.
Gerry
--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
