[hugin-ptx] Re: replacing make?
Lukáš Jirkovský wrote: > Hi Bruno, > > 2009/10/9 Bruno Postle : >> >> Currently Hugin doesn't need to worry about ordering of commands, it >> just writes rules and then specifies the end target(s) it wants, you >> will need to write a dependency solver. > > May be fun. I never did that :-D if you want to do something fun in an area parallel to make (not sure it will replace it though), think of a Composer, similar to what can be done with the latest MathMap. Align a series of filters on a GUI. You can start by representing graphically the Makefile (which input file is required to which output file, with arrows). Then enable the user to double-click on each node and edit them (the parameters of each operation, e.g. output resolution; FOV; masks; etc.). Then enable the user to move the arrows around and add boxes. > I didn't think about that. AFAIK it only looks at the timestamps. The > question how difficult is to do it really multiplatform. timestamps is what make does. if you give the user a drawing board to connect nodes/operations, you may want to add also plausibility checks. > I've just got an idea that I may reuse it in some school subject. This > term they allowed me to try to implement simple denoising algorithm > which I invented when I was drunk instead of the boring "standard" > task. I kind of figured / hoped that you were trying to use Hugin as a "playground" for some school work. Please do that. If the byproduct of your school work is useful to the project, good. If not, it does not really matter, as long as it has served you well in your school projects. I wish we had more students doing that; and professors giving them Hugin as a playground / exercise. I know of at least three professors doing this on the basis of the GIMP. So: talk to your professors. Tell them of the advantage of Hugin as a playground for students (real world experience; a supportive community; very liberal access to SVN - in short: the professor can outsource most of the infrastructure and some of the handholding). Yuv Yuv --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
On 7 окт, 17:04, Lukáš Jirkovský wrote: > 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. If you ever reconsider or need it for a different project, have a look at waf. It's Python based, portable, *tiny* and very straightforward. Alexandre --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
Hi Bruno, 2009/10/9 Bruno Postle : > > On Thu 08-Oct-2009 at 10:04 +0200, Lukáš Jirkovský wrote: >> >>> I know I'm not great at this stuff, but in the panostart tool there >>> is a perl module that abstacts all the business of writing and >>> escaping Makefile rules, i.e. you declare your intent with a list of >>> input files, a list of output files, and the command(s) needed to >>> generate those output files: > >>Yep, it's much cleaner. But I think this would be much more easy to >>implement with XML or other markup language (eg YAML). > > Hugin needs to programatically define all the files it knows how to > create and the commands for creating them somewhere. > > If you abandon 'make' then you need to find some way of recreating > its functionality: > > Currently Hugin doesn't need to worry about ordering of commands, it > just writes rules and then specifies the end target(s) it wants, you > will need to write a dependency solver. May be fun. I never did that :-D > > You would need to find some way to run commands in parallel as we > can now with -j. > > Currently intermediate files are shared between targets, e.g. if you > specify both kinds of Exposure Fused output, 'make' only remaps the > images once with nona and reuses the files with the two different > enblend/enfuse strategies. I didn't think about that. AFAIK it only looks at the timestamps. The question how difficult is to do it really multiplatform. > > Currently I can stop and restart stitching simply by killing the > process, you will need to find some way of doing the same thing. I > can edit the alpha channel of one of the intermediate files then > restart 'make' and it will pick up at the right point and only > create the files that are effected by my changes. > >>I'd keep .pto format at least for storing image positions etc. But >>with XML it would be much easier to store more informations to store. >>I can think of storing informations about positions, stacks, it would >>be possible to store informations about exposure > > We already store all this stuff in the .pto. I admit that it wasn't a good example. Especially the one about exposure. What I meant about positions was not "absolute" positions like the ones in stored pto but instead something like "pictures a,b and c are in stack" or "this picture is nadir". > > -- > Bruno > > > > It is said that every programmer tried to write his OS in his life. I'm not that experienced (yet ;-) ) so this may be nice start. I've just got an idea that I may reuse it in some school subject. This term they allowed me to try to implement simple denoising algorithm which I invented when I was drunk instead of the boring "standard" task. Lukas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
On Thu 08-Oct-2009 at 10:04 +0200, Lukáš Jirkovský wrote: > >> I know I'm not great at this stuff, but in the panostart tool there >> is a perl module that abstacts all the business of writing and >> escaping Makefile rules, i.e. you declare your intent with a list of >> input files, a list of output files, and the command(s) needed to >> generate those output files: >Yep, it's much cleaner. But I think this would be much more easy to >implement with XML or other markup language (eg YAML). Hugin needs to programatically define all the files it knows how to create and the commands for creating them somewhere. If you abandon 'make' then you need to find some way of recreating its functionality: Currently Hugin doesn't need to worry about ordering of commands, it just writes rules and then specifies the end target(s) it wants, you will need to write a dependency solver. You would need to find some way to run commands in parallel as we can now with -j. Currently intermediate files are shared between targets, e.g. if you specify both kinds of Exposure Fused output, 'make' only remaps the images once with nona and reuses the files with the two different enblend/enfuse strategies. Currently I can stop and restart stitching simply by killing the process, you will need to find some way of doing the same thing. I can edit the alpha channel of one of the intermediate files then restart 'make' and it will pick up at the right point and only create the files that are effected by my changes. >I'd keep .pto format at least for storing image positions etc. But >with XML it would be much easier to store more informations to store. >I can think of storing informations about positions, stacks, it would >be possible to store informations about exposure We already store all this stuff in the .pto. -- Bruno --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
Harry van der Wolf wrote: > And for windows? Better or worse? nightmare. Yuv --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
Hi Lukáš Lukáš Jirkovský wrote: > I don't want to replace .pto files. would you mind elaborating a little bit more about what exactly you want to do? given the previous discussions on this list (that you could not know about) I (and maybe some others too) have some preconceived notions in the area, which obviously don't necessarily apply to your ideas. I would like to know what your ideas are. What problem(s) have you identified with the current way things are, and what is your suggested solution? >> Maybe you want to wait for Layout integration before branching out. > > That's not a bad idea. this will give you time to articulate your idea. I must admit that I am lost. At the moment I can not imagine what you want to do. Sorry Yuv --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
2009/10/8 Lukáš Jirkovský > > > > > I am a fan of python but it is probably overkill for the sequence of > > commands that would need to be executed. > > I think so. > > Please don't introduce an extra "external" dependency. Python works well on Linux and fine on MacOSX as long as you don't starrt fiddling with Macports or Fink. For creating a "your system only" cmake build, you do need Fink or MacPorts. This is really a terrible conflicting situation. Believe me: I've been there several times. For Perl it's exactly the same. That's why it created an OSX package for Bruno's tools, otherwise you can forget it. Only tcl works relatively uncomplicated on OSX with macports or Fink. Next to that: Bringing either perl or python into a bundle is another terrible task. Please stay away from it. And for windows? Better or worse? Harry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
Hi Garry, 2009/10/8 Gerry Patterson : > > > On Wed, Oct 7, 2009 at 6:21 PM, Bruno Postle wrote: >> >> On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: >> >Lukáš Jirkovský wrote: >> >> What I think may be quite nice way to store necessary data is the XML. >> > >> >this has been discussed before. The result was that some people favor >> >the Makefile, others would favor the XML (me included). >> >> This all sounds like 'version 2 syndrome'. Isn't there enough stuff >> that really needs fixing in Hugin? Sure the .pto format would be >> more elegant rewritten in YAML (or maybe XML), but without any >> positive benefits it is just an opportunity to introduce new bugs. >> >> What can you do with XML that we can't already do with the current >> .pto format? >> >> Abandoning 'make' is a mistake, the Makefile stitching system is >> very powerful: we get ordering of commands, parallel processing, >> restarting, and supervision of the whole process by a mature tool. >> I can't accept "Makefiles are hard" as a valid reason for recreating >> 'make' in XML. >> > > Hello, > > OK. I understand there are many benefits of using makefiles such as the > ones you have mentioned. I was considering things such as platform specific > script files since they seemed more likely to be able to support filenames > with alternate character sets. If it is possible to have make targets such > as 'this is a directory/this is date: "quoted string"' then make is fine. I > wasn't aware that all of the problematic strings can be expressed properly > in a makefile. If the perl scripts can do this already, then we can > certainly look at a refactor of the Makefile exporting. The problem would be code duplication. Now if you want to change something in makefile you do it in only one place. This would force you to change several "script generators". > > I propose XML or different format than the pto format (hugin project > persistent storage only, pto's would still be generated and passed to things > such as the optimizer, fulla, nona) as it would more easliy handle extra > info and structure of a project that hugin can do now. I haven't seen how > the layout mode is storing the state of pano yet so perhaps it is not an > issue. Makes me thing that we violate PTO for different use than it was originally planned. > > Best Regards, > > - Gerry > > > > > Lukáš --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
Hi Yuv, 2009/10/7 Yuval Levy : > > Hi Lukáš, > > Lukáš Jirkovský wrote: >> What I think may be quite nice way to store necessary data is the XML. > > this has been discussed before. The result was that some people favor > the Makefile, others would favor the XML (me included). I didn't know that. > > The next logical step, rather than discussing this to death once again, > would be to branch out a development codeline and start playing with > your ideas (which I support). Add an XML library. Output some mockup XML > from it. Show what you mean. Discuss on that basis. Yep, I can try it. There are some libraries which are fairly easy to use like expatpp. I've never tried that one but I've worked with expat several years ago. It's not very C++ friendly but it's not that hard to use. > > I think your analysis is right and that XML has advantages; and if done > properly an XML to Makefile is also possible. Another possibility would > be YAML. Have you considered it? > > Regarding parser, aren't there libraries around that we can re-use? There's expat which is quite common. Probably every linux distro out there has it installed (it's dependency of eg. freetype2 or exiv2) so it would bring some obscure dependencies. Unfortunately it's not C++ library so it's not that comfortable. For C++ there are Xerces-C++, expatpp SAX-C++ and probably many others. > > Backward-compatibility is a non-issue IMO. The Makefile is always > reproducible from the PTO file. Unless I am misunderstanding you > completely and your plan is to replace the PTO file with an XML file? if > you plan to replace the PTO with XML, we'll need a PTO2XML utility to > convert older project to the new format, and maybe keep support for PTO > loading during a transitional time. I don't want to replace .pto files. > > Maybe you want to wait for Layout integration before branching out. That's not a bad idea. > Am I assuming correctly that the integration of Deghosting has worked well? Fortunately it does. Or at least there's no one complaining about it. > > Yuv > > > > 2009/10/8 Yuval Levy : > > Bruno Postle wrote: >> Isn't there enough stuff that really needs fixing in Hugin? > > yes there is. but the topic seems to itch Lukáš. Other topics may not be > of interest to him. Take it as an exercise in text processing and XML. I've never wrote something like that (except from simple processor of OBEX output). > > >> What can you do with XML that we can't already do with the current >> .pto format? > > it's extensible without conflicts, and already that is a bonus. I'd like > to add plenty of information to the project file, such as GPS > coordinates, comments, RAW conversion settings, other workflow > consideration, region of interest coordinates, tags, etc. It has potential. > > But I have not seen Lukáš mentioning any change to the PTO file format > or the project file. Or am I misunderstanding? Nope. XML could be used to store additional data but tit still should be possible to create XML from pto. > > >> Abandoning 'make' is a mistake > > Has anybody mentioned *abandoning*? XML usually comes in as an > *additional* layer, not as a replacement. And it is a *descriptive* > language, not a procedural one. It just makes some things more explicit, > trading off readability for a little bit of disk space and processing time. In fact I did. Let me explain it why. The limitation of make is IMO it's "power". Make reserves too many constructs and characters for it's internal use so it's matter of time when someone hits some of them. I've spent several hours to force make accept = in target name (see bug 2813663). It seems that there's none. My only idea is to name the target some "normal" name like final_stitch and do mv as last step. > > To my understanding XML2Make would still generate Makefiles. It could > catch many of the hard edges that are currently causing errors and that > give make a worse reputation (in the context of Hugin) than it deserve. If it would work this way we couldn't get rid of problems like the one mentioned above. > > Yuv > > --~--~-~--~~~---~--~~ > 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 > -~--~~~~--~~--~--~--- > > Lukas --~--~-~--~~~---~--~~ 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@goog
[hugin-ptx] Re: replacing make?
Hi Bruno,
2009/10/7 Bruno Postle :
>
> On Wed 07-Oct-2009 at 15:04 +0200, Lukáš Jirkovský wrote:
>>
>>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.
>
> That would be recreating 'make' with XML and this would be a massive
> task. I think the Makefiles themselves are fine and `make`
> processes them efficiently, what is problematic is the way they are
> assembled in PanoramaMakefileExport, basically we just print
> low-level strings to the Makefile like this:
>
> o << "$(HDR_STACK_" << i << ") : $(HDR_STACK_" << i << "_INPUT)" << endl
>
> I think this could be much cleaner, and as a result the code would
> more closely resemble the intent rather than being a huge list of
> low level string handling.
It could. Currently it's huge mess with some never-used options (like
switches foe different blend apps).
>
> I know I'm not great at this stuff, but in the panostart tool there
> is a perl module that abstacts all the business of writing and
> escaping Makefile rules, i.e. you declare your intent with a list of
> input files, a list of output files, and the command(s) needed to
> generate those output files:
>
> my $rule = new File::Makefile::Rule;
> $rule->Prerequisites ('file-A');
> $rule->Targets ('file-B');
> $rule->Command ('cp', 'file-A', 'file-B');
>
> To turn this into valid, properly escaped and tabbed make-speak you
> just do this:
>
> $rule->Assemble;
Yep, it's much cleaner. But I think this would be much more easy to
implement with XML or other markup language (eg YAML).
>
> Aside from removing the low level stuff, the best thing about
> abstracting it like this is that the module is testable, just feed
> it a bunch of problematic filenames and see if the Makefile succeeds.
>
> --
> Bruno
>
It's not that difficult to test it with Makefile itself, but it's hand work.
2009/10/8 Bruno Postle :
>
> On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote:
>>Lukáš Jirkovský wrote:
>>> What I think may be quite nice way to store necessary data is the XML.
>>
>>this has been discussed before. The result was that some people favor
>>the Makefile, others would favor the XML (me included).
>
> This all sounds like 'version 2 syndrome'. Isn't there enough stuff
> that really needs fixing in Hugin? Sure the .pto format would be
> more elegant rewritten in YAML (or maybe XML), but without any
> positive benefits it is just an opportunity to introduce new bugs.
>
> What can you do with XML that we can't already do with the current
> .pto format?
I'd keep .pto format at least for storing image positions etc. But
with XML it would be much easier to store more informations to store.
I can think of storing informations about positions, stacks, it would
be possible to store informations about exposure and I'm sure that
others could think of may different informations to store.
>
> Abandoning 'make' is a mistake, the Makefile stitching system is
> very powerful: we get ordering of commands, parallel processing,
> restarting, and supervision of the whole process by a mature tool.
> I can't accept "Makefiles are hard" as a valid reason for recreating
> 'make' in XML.
It is powerful but it's not suited for use with GUI application. When
you use it for building some application you can easily avoid
dangerous files names and options. We can't do this here without
limiting users.
>
> --
> Bruno
>
> >
>
Lukas
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
Hi Gerry, 2009/10/7 Gerry Patterson : > > > > > > On Oct 7, 2009, at 8:04 AM, Lukáš Jirkovský > 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. It's nice to see that I'm not the only one who thinks that it would improve things. > > 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 don't think it's a good idea to replace .pto completely. I think only about replacing makefile. Since the markup languages are powerful enough it would be possible to store also hugin specific data in it, but I'd like to keep .pto files. The problem of doing these platform specific scripts is that every change would have to be reflected on several places. I think if we (i guess that it would be me ;-) ) create some tool (maybe library) it would be good abstraction and all the platform specific things would be in one place (the tool). > > I am a fan of python but it is probably overkill for the sequence of > commands that would need to be executed. I think so. > > 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
Bruno Postle wrote: > Isn't there enough stuff that really needs fixing in Hugin? yes there is. but the topic seems to itch Lukáš. Other topics may not be of interest to him. > What can you do with XML that we can't already do with the current > .pto format? it's extensible without conflicts, and already that is a bonus. I'd like to add plenty of information to the project file, such as GPS coordinates, comments, RAW conversion settings, other workflow consideration, region of interest coordinates, tags, etc. But I have not seen Lukáš mentioning any change to the PTO file format or the project file. Or am I misunderstanding? > Abandoning 'make' is a mistake Has anybody mentioned *abandoning*? XML usually comes in as an *additional* layer, not as a replacement. And it is a *descriptive* language, not a procedural one. It just makes some things more explicit, trading off readability for a little bit of disk space and processing time. To my understanding XML2Make would still generate Makefiles. It could catch many of the hard edges that are currently causing errors and that give make a worse reputation (in the context of Hugin) than it deserve. Yuv --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
On Wed, Oct 7, 2009 at 6:21 PM, Bruno Postle wrote: > > On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: > >Lukáš Jirkovský wrote: > >> What I think may be quite nice way to store necessary data is the XML. > > > >this has been discussed before. The result was that some people favor > >the Makefile, others would favor the XML (me included). > > This all sounds like 'version 2 syndrome'. Isn't there enough stuff > that really needs fixing in Hugin? Sure the .pto format would be > more elegant rewritten in YAML (or maybe XML), but without any > positive benefits it is just an opportunity to introduce new bugs. > > What can you do with XML that we can't already do with the current > .pto format? > > Abandoning 'make' is a mistake, the Makefile stitching system is > very powerful: we get ordering of commands, parallel processing, > restarting, and supervision of the whole process by a mature tool. > I can't accept "Makefiles are hard" as a valid reason for recreating > 'make' in XML. > > Hello, OK. I understand there are many benefits of using makefiles such as the ones you have mentioned. I was considering things such as platform specific script files since they seemed more likely to be able to support filenames with alternate character sets. If it is possible to have make targets such as 'this is a directory/this is date: "quoted string"' then make is fine. I wasn't aware that all of the problematic strings can be expressed properly in a makefile. If the perl scripts can do this already, then we can certainly look at a refactor of the Makefile exporting. I propose XML or different format than the pto format (hugin project persistent storage only, pto's would still be generated and passed to things such as the optimizer, fulla, nona) as it would more easliy handle extra info and structure of a project that hugin can do now. I haven't seen how the layout mode is storing the state of pano yet so perhaps it is not an issue. Best Regards, - 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
On Wed 07-Oct-2009 at 17:26 -0400, Yuval Levy wrote: >Lukáš Jirkovský wrote: >> What I think may be quite nice way to store necessary data is the XML. > >this has been discussed before. The result was that some people favor >the Makefile, others would favor the XML (me included). This all sounds like 'version 2 syndrome'. Isn't there enough stuff that really needs fixing in Hugin? Sure the .pto format would be more elegant rewritten in YAML (or maybe XML), but without any positive benefits it is just an opportunity to introduce new bugs. What can you do with XML that we can't already do with the current .pto format? Abandoning 'make' is a mistake, the Makefile stitching system is very powerful: we get ordering of commands, parallel processing, restarting, and supervision of the whole process by a mature tool. I can't accept "Makefiles are hard" as a valid reason for recreating 'make' in XML. -- Bruno --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
Hi Lukáš, Lukáš Jirkovský wrote: > What I think may be quite nice way to store necessary data is the XML. this has been discussed before. The result was that some people favor the Makefile, others would favor the XML (me included). The next logical step, rather than discussing this to death once again, would be to branch out a development codeline and start playing with your ideas (which I support). Add an XML library. Output some mockup XML from it. Show what you mean. Discuss on that basis. I think your analysis is right and that XML has advantages; and if done properly an XML to Makefile is also possible. Another possibility would be YAML. Have you considered it? Regarding parser, aren't there libraries around that we can re-use? Backward-compatibility is a non-issue IMO. The Makefile is always reproducible from the PTO file. Unless I am misunderstanding you completely and your plan is to replace the PTO file with an XML file? if you plan to replace the PTO with XML, we'll need a PTO2XML utility to convert older project to the new format, and maybe keep support for PTO loading during a transitional time. Maybe you want to wait for Layout integration before branching out. Am I assuming correctly that the integration of Deghosting has worked well? Yuv --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
On Wed 07-Oct-2009 at 15:04 +0200, Lukáš Jirkovský wrote:
>
>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.
That would be recreating 'make' with XML and this would be a massive
task. I think the Makefiles themselves are fine and `make`
processes them efficiently, what is problematic is the way they are
assembled in PanoramaMakefileExport, basically we just print
low-level strings to the Makefile like this:
o << "$(HDR_STACK_" << i << ") : $(HDR_STACK_" << i << "_INPUT)" << endl
I think this could be much cleaner, and as a result the code would
more closely resemble the intent rather than being a huge list of
low level string handling.
I know I'm not great at this stuff, but in the panostart tool there
is a perl module that abstacts all the business of writing and
escaping Makefile rules, i.e. you declare your intent with a list of
input files, a list of output files, and the command(s) needed to
generate those output files:
my $rule = new File::Makefile::Rule;
$rule->Prerequisites ('file-A');
$rule->Targets ('file-B');
$rule->Command ('cp', 'file-A', 'file-B');
To turn this into valid, properly escaped and tabbed make-speak you
just do this:
$rule->Assemble;
Aside from removing the low level stuff, the best thing about
abstracting it like this is that the module is testable, just feed
it a bunch of problematic filenames and see if the Makefile succeeds.
--
Bruno
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[hugin-ptx] Re: replacing make?
On Oct 7, 2009, at 8:04 AM, Lukáš Jirkovský 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 -~--~~~~--~~--~--~---
