From: Zoran M. <zor...@gm...> - 2007-03-23 00:02:37
|
Hello, I am considering applying to Google Summer of Code for hugin/panotools project. I am undergraduate student from Ljubljana, Slovenia, studying computer and information science at the University of Ljubljana. Before in apply I would like to make sure whether I am suitable candidate. I find the project & ideas interesting from both the programmers and the photographers point of view. I am already a developer of a open-source application(http://jimmyim.berlios.de) and quite well accustomed to c++ and Qt(although I have more skills in Java), in addition to that I am also a photographer, therefore I would like to contribute as much as I can. Since some project are already appointed, I have considered applying for PTButcher or Pteditor2. In case of PTButcher I have the following questions: - what if no mentor is appointed - is the project then still active? - this seems to be a very large project for one student to handle - how much help from the community is expected here? Thanks in advance, Zoran Mesec |
From: yuval l. <yuv...@ya...> - 2007-03-23 00:58:41
|
Hi Zoran, welcome to the community! --- Zoran Mesec <zor...@gm...> wrote: > I have considered applying for PTButcher or > Pteditor2. > In case of PTButcher I have the following questions: > - what if no mentor is appointed - is the project > then still active? YES. We will find mentors for any project worth pursuing. No mentor is currently listed because the idea was entered a few hours ago by Luca. > - this seems to be a very large project for one > student to handle - > how much help from the community is expected here? To my understanding, most of it can be solved with simple string manipulation and some glue invoking the existing tools. have you seen a hugin / PTgui project file before? Yuv ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html |
From: Daniel M. G. <dm...@uv...> - 2007-03-23 02:02:37
|
yuval> Hi Zoran, yuval> welcome to the community! yuval> --- Zoran Mesec <zor...@gm...> wrote: >> I have considered applying for PTButcher or >> Pteditor2. >> In case of PTButcher I have the following yuval> questions: >> - what if no mentor is appointed - is the project >> then still active? yuval> YES. We will find mentors for any project worth yuval> pursuing. No mentor is currently listed because the yuval> idea was entered a few hours ago by Luca. I can mentor part of it (at least the part that relates to the input format in panotools and hugin), and the workflow around panotools. I like the name :) dmg >> - this seems to be a very large project for one >> student to handle - >> how much help from the community is expected here? yuval> To my understanding, most of it can be solved with yuval> simple string manipulation and some glue invoking the yuval> existing tools. yuval> have you seen a hugin / PTgui project file before? yuval> Yuv yuval> ____________________________________________________________________________________ yuval> Expecting? Get great news right away with email Auto-Check. yuval> Try the Yahoo! Mail Beta. yuval> http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html yuval> ------------------------------------------------------------------------- yuval> Take Surveys. Earn Cash. Influence the Future of IT yuval> Join SourceForge.net's Techsay panel and you'll get the chance to share your yuval> opinions on IT & business topics through brief surveys-and earn cash yuval> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV yuval> _______________________________________________ yuval> PanoTools-devel mailing list yuval> Pan...@li... yuval> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "Don't try to be like Jackie. There is only one Jackie... Jackie Chan -> Study computers instead" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Zoran M. <zor...@gm...> - 2007-03-23 14:26:34
|
Hello, I appreciate your feedback, thanks. I have seen the project file of PTgui/hugin before - it is very simple. I understand now the purpose of this project - e.q. to search for pto files, read them and then use the existing tools, according to the data in the project files. Ok, that should not be a problem. You should also think of having the project file written in XML, because this files can quickly grow large, especially if you are constantly adding new features. Regards, Zoran Mesec -----Original Message----- From: yuval levy [mailto:yuv...@ya...] Sent: Friday, March 23, 2007 1:59 AM To: Zoran Mesec; pan...@li... Subject: Re: [PanoTools-devel] [SoC] PTButcher Hi Zoran, welcome to the community! --- Zoran Mesec <zor...@gm...> wrote: > I have considered applying for PTButcher or > Pteditor2. > In case of PTButcher I have the following questions: > - what if no mentor is appointed - is the project > then still active? YES. We will find mentors for any project worth pursuing. No mentor is currently listed because the idea was entered a few hours ago by Luca. > - this seems to be a very large project for one > student to handle - > how much help from the community is expected here? To my understanding, most of it can be solved with simple string manipulation and some glue invoking the existing tools. have you seen a hugin / PTgui project file before? Yuv ____________________________________________________________________________ ________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html |
From: yuval l. <yuv...@ya...> - 2007-03-23 14:40:23
|
--- Zoran Mesec <zor...@gm...> wrote: > I understand now the purpose of this > project - e.q. to search for pto files, read them > and then use the existing tools, according to the > data in the project files. > Ok, that should not be a problem. excellent! do you want to take this project and run with it? as Pablo stated, it will probably be better done in a scripting language. Something like Ruby or Python? > You should also think of having the project file > written in XML good idea. you could make it part of your project. And if you do, don't remember the daunting thing called "legacy support". there are plenty of older project files out there, in the original format. A converter will be highly appreciated. Yuv ____________________________________________________________________________________ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html |
From: Daniel M. G. <dm...@uv...> - 2007-03-23 17:07:07
|
yuval levy twisted the bytes to say: yuval> --- Zoran Mesec <zor...@gm...> wrote: >> I understand now the purpose of this >> project - e.q. to search for pto files, read them >> and then use the existing tools, according to the >> data in the project files. >> Ok, that should not be a problem. yuval> excellent! do you want to take this project and run yuval> with it? as Pablo stated, it will probably be better yuval> done in a scripting language. Something like Ruby or yuval> Python? >> You should also think of having the project file >> written in XML yuval> good idea. you could make it part of your project. And yuval> if you do, don't remember the daunting thing called yuval> "legacy support". there are plenty of older project yuval> files out there, in the original format. A converter yuval> will be highly appreciated. I think designing an XML format, and implementing an API to access it from C/C++ would be great. This would be in line replacing the parser in panotools. -- Daniel M. German "One thing I have learned in a long life: that all our science, measured against reality, is primivite and childlike --and yet it is the most precious thing Albert Einstein -> we have. " http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Zoran M. <zor...@gm...> - 2007-03-23 18:40:15
|
I agree with Pablo, some parts of PTButcher should be written in a scripting language. I have not digged into the code yet, so, I can not say much more, however I believe python is better because we can use swig to call some existing c functions(I am not sure whether there a similar bridge between Ruby and c++). Yes, I would like to take part in this project. I intend to use and develop hugin/panotools also after we finish SoC. Regards, Zoran Mesec On 23/03/07, Daniel M. German <dm...@uv...> wrote: > > yuval levy twisted the bytes to say: > > yuval> --- Zoran Mesec <zor...@gm...> wrote: > >> I understand now the purpose of this > >> project - e.q. to search for pto files, read them > >> and then use the existing tools, according to the > >> data in the project files. > >> Ok, that should not be a problem. > > > yuval> excellent! do you want to take this project and run > yuval> with it? as Pablo stated, it will probably be better > yuval> done in a scripting language. Something like Ruby or > yuval> Python? > > > >> You should also think of having the project file > >> written in XML > > yuval> good idea. you could make it part of your project. And > yuval> if you do, don't remember the daunting thing called > yuval> "legacy support". there are plenty of older project > yuval> files out there, in the original format. A converter > yuval> will be highly appreciated. > > I think designing an XML format, and implementing an API to access it > from C/C++ would be great. This would be in line replacing the parser > in panotools. > > > -- > Daniel M. German "One thing I have learned in a long life: > that all our science, measured against > reality, is primivite and childlike > --and yet it is the most precious thing > Albert Einstein -> we have. " > http://turingmachine.org/ > http://silvernegative.com/ > dmg (at) uvic (dot) ca > replace (at) with @ and (dot) with . > > > |
From: Daniel M. G. <dm...@uv...> - 2007-03-23 22:18:57
|
Zoran, Keep in mind. We need tools that we can maintain. I don't know how many of us know Ruby or Python. Bruno has been maintaining perl for some time, so there is already precedent in the use of that languae. A proposal to use a different language will have to be approved first. I believe (and others can add their opinions) we do not want a system that we can't maintain in the future, now matter how great it might be. BTW, Perl can interface with C and C++. dmg Zoran> I agree with Pablo, some parts of PTButcher should be written in a Zoran> scripting language. I have not digged into the code yet, so, I can not Zoran> say much more, however I believe python is better because we can use Zoran> swig to call some existing c functions(I am not sure whether there a Zoran> similar bridge between Ruby and c++). Zoran> Yes, I would like to take part in this project. I intend to use and Zoran> develop hugin/panotools also after we finish SoC. Zoran> Regards, Zoran> Zoran Mesec Zoran> On 23/03/07, Daniel M. German <dm...@uv...> wrote: >> >> yuval levy twisted the bytes to say: >> yuval> --- Zoran Mesec <zor...@gm...> wrote: >> >> I understand now the purpose of this >> >> project - e.q. to search for pto files, read them >> >> and then use the existing tools, according to the >> >> data in the project files. >> >> Ok, that should not be a problem. >> >> yuval> excellent! do you want to take this project and run yuval> with it? as Pablo stated, it will probably be better yuval> done in a scripting language. Something like Ruby or yuval> Python? >> >> >> >> You should also think of having the project file >> >> written in XML >> yuval> good idea. you could make it part of your project. And yuval> if you do, don't remember the daunting thing called yuval> "legacy support". there are plenty of older project yuval> files out there, in the original format. A converter yuval> will be highly appreciated. >> >> I think designing an XML format, and implementing an API to access it >> from C/C++ would be great. This would be in line replacing the parser >> in panotools. >> >> >> -- >> Daniel M. German "One thing I have learned in a long life: >> that all our science, measured against >> reality, is primivite and childlike >> --and yet it is the most precious thing >> Albert Einstein -> we have. " >> http://turingmachine.org/ >> http://silvernegative.com/ >> dmg (at) uvic (dot) ca >> replace (at) with @ and (dot) with . >> >> >> Zoran> ------------------------------------------------------------------------- Zoran> Take Surveys. Earn Cash. Influence the Future of IT Zoran> Join SourceForge.net's Techsay panel and you'll get the chance to share your Zoran> opinions on IT & business topics through brief surveys-and earn cash Zoran> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV Zoran> _______________________________________________ Zoran> PanoTools-devel mailing list Zoran> Pan...@li... Zoran> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "All the fun of sitting still, being quiet, Principal Skinner (Simpsons) -> writing down numbers, yes science has it all."" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: yuval l. <yuv...@ya...> - 2007-03-23 22:50:07
|
--- "Daniel M. German" <dm...@uv...> wrote: > A proposal to use a different language will have > to be approved first. Daniel, please allow me to express a different opinion. I understand your concerns about maintenability and I also kindly ask Zoran to consider this factor when making his choice. However, for the vast majority of users C++, perl, python, or assembler is all the same, because they are no programmers. I'd rather have a working system with limited maintenance status than no system at all. Zoran has expressed interest to continue after GSoC and I am ready to build mutual trust with him and to work together on *his* project proposal. I firmly believe that the choice of tools (and the programming language is just a tool) is the prerogative of the student, and as long as the language chosen is a fairly popular one the choice is secondary to me. His project will have to be approved, of course, like any other project, but IMO the choice of language, especially for such a self-contained tool, should not be the primary factor on which approval depends. To me, what counts most is the student's enthusiasm, his skill, his will to take up a challenge and live up to it. Yuv ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 |
From: Daniel M. G. <dm...@uv...> - 2007-03-23 23:38:21
|
yuval levy twisted the bytes to say: yuval> --- "Daniel M. German" <dm...@uv...> wrote: >> A proposal to use a different language will have >> to be approved first. yuval> Daniel, yuval> please allow me to express a different opinion. yuval> I understand your concerns about maintenability and I yuval> also kindly ask Zoran to consider this factor when yuval> making his choice. That is why I mentioned that it should be discussed first. Programs need to evolve, so the question in this case is, who is going to evolve them? If they don't need maintenance, great. But usually this is not the case. dmg -- Daniel M. German "Eat food. Not too much. Mostly Plants" M. Polland from NY Times http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2007-03-23 23:41:48
|
On Fri 23-Mar-2007 at 15:18 -0700, Daniel M. German wrote: > > Keep in mind. We need tools that we can maintain. I don't know how > many of us know Ruby or Python. Bruno has been maintaining perl for > some time, so there is already precedent in the use of that languae. A > proposal to use a different language will have to be approved first. Panotools::Script isn't the most elegant bit of code, but it does have a lot of accumulated fixes for various quirks in the script format. I do think it would be a waste of time to build yet another panotools script parser, especially if there is going to be a move to an XML format. An idea would be to prototype the XML stuff with Panotools:Script. For example, it would be quite easy to create wrappers around nona and PTOptimizer that would talk XML externally, but would use the old interface internally. This way, 'PTbutcher' could be built in whatever language is most suitable and wouldn't be dependent on the 'Architectural Overhaul of Panotools' or require a new panotools parser in that language. -- Bruno |
From: Zoran M. <zor...@gm...> - 2007-03-24 11:01:57
|
Ok, I will keep this in mind. I would like to point out this(part of the project description): "See Panotools::Script for a perl approach to this. Note that the PanoTools script format is is a bit hard to understand, there is a proposal in the SoC2007 project Panotools Architecture to replace it with a more workable XML file format, so work should concentrate on the workflow aspects instead of another panotools script parser." ...according to this, arguing whether to use perl or python is unnneccessary at this moment. I was thinking designing PTButcher in such way that it can be easily extendable with any scripting language, because The PTButcher core should be, however, based on c++ and as a part of hugin(or even loaded as a module or extensions). The scripting language support should only provide functionalities needed to implement some features. -Z -----Original Message----- From: dm...@uv... [mailto:dm...@uv...] Sent: Friday, March 23, 2007 11:18 PM To: Zoran Mesec Cc: pan...@li... Subject: Re: [PanoTools-devel] [SoC] PTButcher Zoran, Keep in mind. We need tools that we can maintain. I don't know how many of us know Ruby or Python. Bruno has been maintaining perl for some time, so there is already precedent in the use of that languae. A proposal to use a different language will have to be approved first. I believe (and others can add their opinions) we do not want a system that we can't maintain in the future, now matter how great it might be. BTW, Perl can interface with C and C++. dmg Zoran> I agree with Pablo, some parts of PTButcher should be written in a Zoran> scripting language. I have not digged into the code yet, so, I can not Zoran> say much more, however I believe python is better because we can use Zoran> swig to call some existing c functions(I am not sure whether there a Zoran> similar bridge between Ruby and c++). Zoran> Yes, I would like to take part in this project. I intend to use and Zoran> develop hugin/panotools also after we finish SoC. Zoran> Regards, Zoran> Zoran Mesec Zoran> On 23/03/07, Daniel M. German <dm...@uv...> wrote: >> >> yuval levy twisted the bytes to say: >> yuval> --- Zoran Mesec <zor...@gm...> wrote: >> >> I understand now the purpose of this >> >> project - e.q. to search for pto files, read them >> >> and then use the existing tools, according to the >> >> data in the project files. >> >> Ok, that should not be a problem. >> >> yuval> excellent! do you want to take this project and run yuval> with it? as Pablo stated, it will probably be better yuval> done in a scripting language. Something like Ruby or yuval> Python? >> >> >> >> You should also think of having the project file >> >> written in XML >> yuval> good idea. you could make it part of your project. And yuval> if you do, don't remember the daunting thing called yuval> "legacy support". there are plenty of older project yuval> files out there, in the original format. A converter yuval> will be highly appreciated. >> >> I think designing an XML format, and implementing an API to access it >> from C/C++ would be great. This would be in line replacing the parser >> in panotools. >> >> >> -- >> Daniel M. German "One thing I have learned in a long life: >> that all our science, measured against >> reality, is primivite and childlike >> --and yet it is the most precious thing >> Albert Einstein -> we have. " >> http://turingmachine.org/ >> http://silvernegative.com/ >> dmg (at) uvic (dot) ca >> replace (at) with @ and (dot) with . >> >> >> Zoran> ------------------------------------------------------------------------- Zoran> Take Surveys. Earn Cash. Influence the Future of IT Zoran> Join SourceForge.net's Techsay panel and you'll get the chance to share your Zoran> opinions on IT & business topics through brief surveys-and earn cash Zoran> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV Zoran> _______________________________________________ Zoran> PanoTools-devel mailing list Zoran> Pan...@li... Zoran> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "All the fun of sitting still, being quiet, Principal Skinner (Simpsons) -> writing down numbers, yes science has it all."" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2007-03-24 15:54:17
|
On Sat 24-Mar-2007 at 12:01 +0100, Zoran Mesec wrote: > I was thinking designing PTButcher in such way that it can be > easily extendable with any scripting language, because The > PTButcher core should be, however, based on c++ and as a part of > hugin(or even loaded as a module or extensions). Yes, if PTbutcher was part of hugin then it should use the internal hugin code for handling the script files. -- Bruno |
From: JD S. <jd...@as...> - 2007-03-23 22:30:45
|
On Fri, 23 Mar 2007 10:06:50 -0700, Daniel M. German wrote: > > yuval levy twisted the bytes to say: > > yuval> --- Zoran Mesec <zor...@gm...> wrote: > >> I understand now the purpose of this > >> project - e.q. to search for pto files, read them > >> and then use the existing tools, according to the > >> data in the project files. > >> Ok, that should not be a problem. > > > yuval> excellent! do you want to take this project and run > yuval> with it? as Pablo stated, it will probably be better > yuval> done in a scripting language. Something like Ruby or > yuval> Python? > > > >> You should also think of having the project file > >> written in XML > > yuval> good idea. you could make it part of your project. And > yuval> if you do, don't remember the daunting thing called > yuval> "legacy support". there are plenty of older project > yuval> files out there, in the original format. A converter > yuval> will be highly appreciated. > > I think designing an XML format, and implementing an API to access it > from C/C++ would be great. This would be in line replacing the parser > in panotools. Not sure of the relevance, but there has been effort put into an XML format for Panoramas: http://www.openpanorama.org/ This seems to have had a large IQTVRA involvement, and is more aimed at replacing container formats like QuickTime (or so I infer from a casual reading). In any case, we might at the least inherit some of their terminology and namespace for constructing a replacement for the venerable but overwrough panotools script file. It's also possible they might have interesting insights, having put a lot of thought into an open format for panorama specification. JD |
From: Bruno P. <br...@po...> - 2007-03-23 11:04:50
|
On Thu 22-Mar-2007 at 19:02 -0700, Daniel M. German wrote: > > yuval> YES. We will find mentors for any project worth > yuval> pursuing. No mentor is currently listed because the > yuval> idea was entered a few hours ago by Luca. > > I can mentor part of it (at least the part that relates to the input > format in panotools and hugin), and the workflow around panotools. I can help too, though I probably won't be able to set aside a specific timetable for mentoring. As a project this needs a good specification, Luca's idea reads a lot like my general plan for Panotools::Script - ie. a list of cool things that I'd like to be able to do one day rather than a specific design. -- Bruno |
From: Pablo d'A. <pab...@we...> - 2007-03-23 13:40:33
|
Bruno Postle schrieb: >On Thu 22-Mar-2007 at 19:02 -0700, Daniel M. German wrote: > > >>yuval> YES. We will find mentors for any project worth >>yuval> pursuing. No mentor is currently listed because the >>yuval> idea was entered a few hours ago by Luca. >> >>I can mentor part of it (at least the part that relates to the input >>format in panotools and hugin), and the workflow around panotools. >> >> > >I can help too, though I probably won't be able to set aside a >specific timetable for mentoring. > >As a project this needs a good specification, Luca's idea reads a >lot like my general plan for Panotools::Script - ie. a list of cool >things that I'd like to be able to do one day rather than a specific >design. > > Yes, this is true. I guess the main thigk Luca wants is a GUI to do all this, since many of the tasks can already be done by Panotools::Script and other command line tools. So this could be either build on top of Panotools::Script, or with a separate application, which would preferably be written in a scripting language for easy modification and extension, IMHO. Actually I hope that with the new QT interface we will also gain a scriptable version of hugin, since QT 4.3 will include a JavaScript like scripting language. ciao Pablo |
From: yuval l. <yuv...@ya...> - 2007-03-23 14:37:09
|
--- Bruno Postle <br...@po...> wrote: > I can help too, though I probably won't be able to > set aside a specific timetable for mentoring. knowing how busy you are, I did not dare to ask when setting up the GSoC organization. The same applies to many other contributors here which are highly appreciated. officially the Google web based application accepts only one mentor per student project. i talked with them about having more than one mentor per project and this is now in the requested features for 2008. from the start I insisted on setting up redundant mentorship, a primary mentor and a backup mentor, so that students always have a reference when need guidance. besides the primary and backup mentor, community input is welcome. I've asked Google about it. We have to respect that the actual writing of the code is the student's task, since his evaluation will depend on him completing that task. Interaction with and support from the community is welcome within this simple rule. I encourage everybody who has a relevant contribution to make to any of our GSoC project proposals to contact the lead mentor and the student, so that we can find a way to leverage your contribution. Just keep in mind that the primary goal here is the student's GSoC. We want our students to deliver successfully on their projects. Make sure their delivery is not dependent on community input, and if it is, make sure you deliver. These projects will hopefully continue beyond GSoC completition. It is important to set a solid analysis now, identify what can be done by the student within the GSoC time constrains and what can be done beyond, by community members. Yuv ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 |
From: Bruno P. <br...@po...> - 2007-04-03 22:44:00
|
This is some extra info relating to the PTButcher proposal: http://wiki.panotools.org/PTButcher_proposal Something that Pablo started but didn't finish adding to hugin was an idea to use Makefiles to manage the stitching workflow, PTButcher could be a tool to manage and drive these Makefiles. The great thing about 'make' is that any changes to files anywhere in the process can be handled without regenerating everything from scratch. Particularly, adding an external mask file to any of the intermediate images would trigger only the minimum amount of processing necessary to integrate the mask. At the end you just run `make clean` and everything is deleted but the original photos, hugin project file, external masks and final output. In the future all you have to do to recreate the entire process is to run `make` again. Here is how it might apply to my current spherical panorama workflow, each of these would be a Makefile target: 1. Converting RAW files to TIFF - I currently do this with dcraw, but ufraw-batch is probably as good or better - dcraw does nice wavelet noise removal at this stage. 2. Correcting vignetting and TCA with fulla - At some point this will be integrated into nona and this step will be redundant (this requires a lookup in a lens database to be fully automatic). 3. Identifying control points with an autopano-* tool and generating a hugin project file. This could be pre-optimised and levelled using existing 'hugin assistant' code and some lens database lookup. 4. Remapping input images to separate TIFF files with nona/Tmender, this step would detect external masks and apply them without modifying the originals (similar to 'enblend-mask'). 5. Blending TIFF files into a single output with enblend, 'enblend-mask' handles external mask files for this step. 6. Sharpening with a (yet to be created) equirectangular sharpening tool. 7. Generating a QTVR with something like erect2qtvr or pano2qtvr. That is my workflow, but different workflows such as HDR, pre-press, web-publishing etc... would use different Makefiles. -- Bruno |
From: Daniel M. G. <dm...@uv...> - 2007-04-04 18:39:12
|
hi Bruno, I fully agree. Using make will make much more sense, but it needs to be configurable. Some of us will start the process with TIFFs, not RAWs (I use photoshop instead of dcraw), and for some of us the flat file might be the end product (no need for QTVR). dmg Bruno> This is some extra info relating to the PTButcher proposal: Bruno> http://wiki.panotools.org/PTButcher_proposal Bruno> Something that Pablo started but didn't finish adding to hugin was Bruno> an idea to use Makefiles to manage the stitching workflow, PTButcher Bruno> could be a tool to manage and drive these Makefiles. Bruno> The great thing about 'make' is that any changes to files anywhere Bruno> in the process can be handled without regenerating everything from Bruno> scratch. Particularly, adding an external mask file to any of the Bruno> intermediate images would trigger only the minimum amount of Bruno> processing necessary to integrate the mask. Bruno> At the end you just run `make clean` and everything is deleted but Bruno> the original photos, hugin project file, external masks and final Bruno> output. In the future all you have to do to recreate the entire Bruno> process is to run `make` again. Bruno> Here is how it might apply to my current spherical panorama Bruno> workflow, each of these would be a Makefile target: Bruno> 1. Converting RAW files to TIFF - I currently do this with dcraw, Bruno> but ufraw-batch is probably as good or better - dcraw does nice Bruno> wavelet noise removal at this stage. Bruno> 2. Correcting vignetting and TCA with fulla - At some point this will Bruno> be integrated into nona and this step will be redundant (this Bruno> requires a lookup in a lens database to be fully automatic). Bruno> 3. Identifying control points with an autopano-* tool and generating Bruno> a hugin project file. This could be pre-optimised and levelled Bruno> using existing 'hugin assistant' code and some lens database lookup. Bruno> 4. Remapping input images to separate TIFF files with nona/Tmender, Bruno> this step would detect external masks and apply them without Bruno> modifying the originals (similar to 'enblend-mask'). Bruno> 5. Blending TIFF files into a single output with enblend, Bruno> 'enblend-mask' handles external mask files for this step. Bruno> 6. Sharpening with a (yet to be created) equirectangular sharpening Bruno> tool. Bruno> 7. Generating a QTVR with something like erect2qtvr or pano2qtvr. Bruno> That is my workflow, but different workflows such as HDR, pre-press, Bruno> web-publishing etc... would use different Makefiles. Bruno> -- Bruno> Bruno Bruno> ------------------------------------------------------------------------- Bruno> Take Surveys. Earn Cash. Influence the Future of IT Bruno> Join SourceForge.net's Techsay panel and you'll get the chance to share your Bruno> opinions on IT & business topics through brief surveys-and earn cash Bruno> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV Bruno> _______________________________________________ Bruno> PanoTools-devel mailing list Bruno> Pan...@li... Bruno> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- dmg |