GSoC - Batch Processing
Marko Kuder
As it was suggested, I'm starting a new thread which should contain
all discussions regarding my project. At the moment I'm still getting
familiar with Hugin and related applications. This would probably also
be the right time to mention some of your ideas about what would you
like to see in the final version. But go easy on me please.
It has already been discussed while I was applying for GSoC, but I
doesn't hurt to summarize the basic idea. Currently I'm thinking about
something like PTGui's batch stitcher, just a simple additional tab in
Hugin with options for saving projects and executing them later in
sequence. It depends on how much trouble I'll have adapting to
Hugin's existing code, but this shouldn't be a problem to develop soon
enough.
Later I could add some options which are available from the standard
Make program and the ability to define multiple projects with the same
settings but different input/output files. This could be useful for
projects like video stitching, which was discussed recently. Here I
should add an option to calculate control points in each defined
project separately, or keeping all settings except the image files
(useful for fixed camera image sequences).
I would like to make this as user friendly as possible, but still
flexible enough to be used by professionals. Automatic project
creation from directories containing image files with template options
would be great, but we'll see how I'll get through the first bit.
Your comments and suggestions are very welcome.
Best regards,
Marko Kuder
Zoran Mesec
http://code.google.com/soc/2008/pano/appinfo.html?csaid=ED9B86CD65E6238B
http://wiki.panotools.org/SoC_2008_student_proposals#Marko_Kuder.2C_Batch_Processing
http://wiki.panotools.org/SoC2007_project_Batch_Processing
regards,
Zoran
Marko Kuder pravi:
Bruno Postle
>
>As it was suggested, I'm starting a new thread which should contain
>all discussions regarding my project. At the moment I'm still getting
>familiar with Hugin and related applications.
I made a start on documenting the state of the existing
Makefile/batch processing system:
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk/doc/batch-processing/
There are various gaps, both in this documentation and the Makefiles
themselves... The system is very powerful, but only on the
command-line and there are some things that can't be done that
should be easy.
--
Bruno
Yuval Levy
> Your comments and suggestions are very welcome.
batch processing: put a list of elements in a queue and process them
without human intervention.
the elements we have to process in hugin are:
* stitching projects
* images
while the Makefile system and the hugin_stitch_project deal with
stitching projects, we have nothing yet that deals with images. I would
like to see work done on batch processing images.
At the top level, the batch processor should take as input a list of
folders.
it should first expand the folders down to their individual files.
for those files, it should identify whether they are images, stitching
projects, or irrelevant to the process.
if they are images, it should try to group them into stitching projects
using probabilities and based on different criteria.
for example:
if two pictures are taken only a few seconds apart, the probability is
high that they belong to the same panorama.
if they are taken with the same exposure, they are more likely to be
part of the same panorama (but with photometric adjustment and with HDR
they can be part of the same panorama even if the exposure is not the
same, hence probabilities).
if there is a pattern (0/-2EV/+2EV) it may be an HDR panorama.
in a first step, exif/meta data such as time, exposure, focal length,
storage folder should be used to determine a probability that images
belong together, and clusters should be form.
then in a second step the batch processor should run control point
detection on all image pairs in a given cluster, to confirm/refine the
clusters, and also to use as control points for the panorama projects.
the result of this batch process would be a number of panorama projects,
possibly with their Makefiles, ready to be fed into
hugin_stitch_project or to be edited manually in hugin.
since this is dealing with lists and string, I would recommend using
Python or another scripting language, and making bindings for it in
hugin's code or calling the individual functionalities in the command
line binaries.
I would like this to be highly expandable and adaptable. for example,
once such a loop system is in place, I could expand it to recognize XMP
files and RAW files, and as part of the loop trigger my RAW converter to
take the XMP parameters and the RAW files and convert them into TIFs for
further processing by the loop.
Also sensible would be to expand it for template stitching, e.g. if
somebody comes in with video footage, all the same, in which case the
processor would just take the list of files and replace file names in
the template before saving the individual stitch projects.
I am not sure it is a good idea to integrate this in the Makefile
system, because at the beginning there are no Makefiles, just the RAW
files I dump from my memory card to my hard disk.
And there are at least two points at which human interaction is
inevitable because subjective:
* the setting of parameters for the RAW conversion
* the framing of the panorama (in case of full 360°) in hugin
also in this second step, at least for now, is the orientation of the
sphere with vertical or horizontal control points, unless I can
guarantee that all the pictures have been taken with the panohead level
and have a reference image to use in the shots.
I hope this helps
Yuv
Jim Watters
> Currently I'm thinking about something like PTGui's batch
> stitcher, just a simple additional tab in Hugin with options
> for saving projects and executing them later in sequence.
- Queue of projects that have already been either optimized or created
using existing templates.
- The batch stitcher can open a bunch of projects to process.
- The batch stitcher can open a template and a bunch of folders to process.
- In Hugin instead of stitching have button to add to Batch Processing
Queue.
- The Queue of projects can be paused and resumed.
I have been creating some panoramic video from an array of web cameras.
To simplify, I am in the process of incorporating Helmut's Motion
Panorama changes
http://webuser.fh-furtwangen.de/~dersch/mp/MotionPanoramas.html into
panoramatools13.
Look at the pdf documentation for a list of features. Consider what can
be added to expand on these features.
Jim Watters
Marko Kuder
determine.
Yuval Levy wrote:
> then in a second step the batch processor should run control point
> detection on all image pairs in a given cluster, to confirm/refine the
> clusters, and also to use as control points for the panorama projects.
> Also sensible would be to expand it for template stitching, e.g. if
> somebody comes in with video footage, all the same, in which case the
> processor would just take the list of files and replace file names in
> the template before saving the individual stitch projects.
Right, so instead of options to use same settings from one project in the
batch for others, as I originally planned, it would really be better to just
enable template saving and loading in the processor. I didn't realize before
that doing it this way actually solves all problems. Would it be OK to just
keep the existing template system which takes settings from existing
projects or should I define special template files, which wouldn't be
projects by themselves, just setting files?
> the batch processor should run control point detection on all image pairs
in a given cluster...
What if a cluster happens to contain a larger number of images? The user
probably wouldn't like it very much if he would have to wait a very long
time to load the images, which he could regroup manually. We could make it
an option, but I'm not sure if an amateur user would understand it's effect,
except if I add the explanation in the context sensitive description.
> if there is a pattern (0/-2EV/+2EV) it may be an HDR panorama.
I understand the concept of HDR, but I didn't find examples of HDR panoramas
yet to test how Hugin works with them, so I guess it's better to ask. If I
understand correctly, if I load two groups of images with different
exposures into Hugin and enable the "Blended HDR panorama" box in the
stitcher tab, Hugin will automatically join them into a HDR panorama? If it
is so, the only thing to do when finding such a pattern would be to
automatically enable the option, or should the program also do photometric
optimisation for HDR at that time?
> I would like this to be highly expandable and adaptable. for example,
> once such a loop system is in place, I could expand it to recognize XMP
> files and RAW files, and as part of the loop trigger my RAW converter to
> take the XMP parameters and the RAW files and convert them into TIFs for
> further processing by the loop.
Could you explain what form of the planned batch processor would you
consider expandable? As I see it, if it's a part of Hugin's code as a tab in
the GUI, there's no problem to add some code which would recognize
additional formats. If I combine it with Python (which I haven't really
combined with C++ before), it would seem like I'm porting the existing code
to another language and thus additionaly complicating things.
> I am not sure it is a good idea to integrate this in the Makefile
> system, because at the beginning there are no Makefiles, just the RAW
> files I dump from my memory card to my hard disk.
>
> And there are at least two points at which human interaction is
> inevitable because subjective:
> * the setting of parameters for the RAW conversion
> * the framing of the panorama (in case of full 360°) in hugin
As I've planned it, it isn't really integration into the Makefile system, it
merely uses Makefiles as a way to store and run projects, just like Hugin
works at the moment. I wouldn't edit Makefiles directly, except maybe input
and output files. I suppose you prefer the use of Hugin's Makefile system as
oppose to excluding it completely. The human interaction would remain the
same as it is, the user could load the settings of any project in the batch
and change them in the other tabs. When applying the changes, a new Makefile
would be created and replace the old one.
Jim Watters wrote:
> - The Queue of projects can be paused and resumed.
Since I don't really have control over the command line programs, it could
only be paused between projects, but during one could be difficult. The only
additional possibility I see would be to split the Makefiles into parts to
enable pausing between every command line execution, but I don't think
complicating things that far is necessary. If you think such functionality
would be useful, I can add it as a secondary objective.
Best regards,
Marko Kuder
Jim Watters
> Jim Watters wrote:
>
>> - The Queue of projects can be paused and resumed.
>>
> Since I don't really have control over the command line programs, it could
> only be paused between projects, but during one could be difficult. The only
> additional possibility I see would be to split the Makefiles into parts to
> enable pausing between every command line execution, but I don't think
> complicating things that far is necessary. If you think such functionality
> would be useful, I can add it as a secondary objective.
>
CPU I found that with PTGui I would send a project to be added to the
batch stitch. and it would start processing automatically. I was not
able to do much else so I would cancel it. Start the batch process
again put it in pause. Add the new project. When I was done creating
and adding projects I would start the batch stitch and walk away from
the computer and let it work.
Starting the batch stitch in a paused mode or at least having that as
an option should be good enough.
--
Jim Watters
Yahoo ID: j1vvy ymsgr:sendIM?j1vvy
jwatters @ photocreations . ca
http://photocreations.ca
Bruno Postle
>
>As I've planned it, it isn't really integration into the Makefile system, it
>merely uses Makefiles as a way to store and run projects, just like Hugin
>works at the moment.
Marko, you need to decide which ideas your project is going to
follow through. There are various problems being presented, but you
can't do them all:
There is the workflow problem, and this is where I personally need
help - dealing with lots of photos and keeping track of progress
from the basic RAW files, through setting up projects, optimising
and tweaking, stitching and actually doing something with the final
output.
There is batch stitching, i.e. deferred or queued stitching, the
analogy here is with a print spool, the way hugin does it with
hugin_stitch_project is incomplete as there is no concept of
deferment or queuing tasks one after another.
There is the Makefile plugin/extension idea, i.e. there are lots of
things that you do to a panorama after stitching that could be
automated, but which would not be appropriate built into hugin -
hugin is complicated enough as it is.
What I think (but this is your project):
The overall workflow problem is too undefined, you could end up
recreating lightroom or digikam rather than finding ways to extend
these tools to support panoramic stitching workflows.
The batch stitcher is well defined: a standalone GUI spooler that
manages a queue of Makefiles - It doesn't even have to be hugin
specific, all hugin needs to do is pass a message, "here is another
Makefile for you" - This is the nature of good open source tools, do
one thing well and people will find uses that you never thought of.
The Makefile plugin/extension system has potential, but there are
real design problems that need to be solved.
>Jim Watters wrote:
>> - The Queue of projects can be paused and resumed.
>
>Since I don't really have control over the command line programs, it could
>only be paused between projects, but during one could be difficult.
Pausing a 'make' process is easy: just kill the process and it will
stop, start 'make' again with exactly the same parameters and it
continues from where it left off.
--
Bruno
Bruno Postle
>
>I am not sure it is a good idea to integrate this in the Makefile
>system, because at the beginning there are no Makefiles, just the RAW
>files I dump from my memory card to my hard disk.
Actually I have a vague idea of generating a master 'Makefile' for
each directory, this would contain rules for uncompressing RAW
files, decoding, rotating, tca correction, applying colour profiles
and generation of keypoint descriptors.
This would specifically _not_ manage stitching, it would be
pulled-in by hugin .pto.mk Makefiles at the stitching stage. It
would allow keeping just the compressed RAW files on disk and then
generate the TIFF stitching input on demand.
--
Bruno
Bruno Postle
>
>The batch stitcher is well defined: a standalone GUI spooler that
>manages a queue of Makefiles - It doesn't even have to be hugin
>specific, all hugin needs to do is pass a message, "here is another
>Makefile for you"
BTW, this isn't a big job, there are existing libraries that you can
and should use. For instance, if I was building a Linux only tool
to do this then a GUI could be built around this perl module quite
easily:
http://search.cpan.org/dist/Net-Spooler
--
Bruno
Yuval Levy
> Actually I have a vague idea of generating a master 'Makefile' for
> each directory, this would contain rules for uncompressing RAW
> files, decoding, rotating, tca correction, applying colour profiles
> and generation of keypoint descriptors.
it may be just me, and it may be because I am no coder and I have great
fear and respect of make, but I'd rather have something more accessible
to the casual scripter. python?
my current experience with the make system within hugin is mixed. i
suspect it is this make thing that caused my confusion with the same
project stitching in windows and yielding a black surface in linux or
the other way around.
i'd like something simple and easy to read, so that even average users
can get their hands under the hood without too much fear.
Yuv
Yuval Levy
> There is the workflow problem, and this is where I personally need
> help - dealing with lots of photos and keeping track of progress
> from the basic RAW files, through setting up projects, optimising
> and tweaking, stitching and actually doing something with the final
> output.
same here - the workflow problem would have higher priority for me.
> There is batch stitching, i.e. deferred or queued stitching
i might over-simplify, but to me a primitive batch stitcher is done in a
few hours: just loop over a folder and in its sub folders, find the
project files and feed them to the existing hugin_stitch_project.
queuing tasks, a GUI spooler and so on are nice to have, but in term of
raw functionality I'd be happy with just saving the project file once
incepted, repeat for as long as I have projects to set up, and kick the
simple code that loops over the folders and triggers hugin_stitch_project.
> There is the Makefile plugin/extension idea, i.e. there are lots of
> things that you do to a panorama after stitching that could be
> automated, but which would not be appropriate built into hugin -
> hugin is complicated enough as it is.
I understand where you come from, but I am not sure I want to have this
make-driven in Windows. I currently have a glue PHP script that does it
all for me, and I am happy this way. Make would over-complicate my life
and I don't see the benefit of using make. After all, this is not code
building. panorama batch processing is quite linear.
> What I think (but this is your project):
>
> The overall workflow problem is too undefined, you could end up
> recreating lightroom or digikam rather than finding ways to extend
> these tools to support panoramic stitching workflows.
yes, that's the risk. and it is also the opportunity - to define a
solution to the workflow problem. I would not care too much about
digikam or lightroom - they are GUIs to the image pre-processing the
same way that hugin is a GUI to the stitch-process. I would just assume
that the workflow tool starts where LR / dk stops - a folder full of
TIFF files - and take it on from there.
> The batch stitcher is well defined
indeed it is. and much less exciting, if you ask me. but it is your
(Marko) project.
> The Makefile plugin/extension system has potential, but there are
> real design problems that need to be solved.
yes, and i am not sure that make is the right tool for that, but that's
me, and it is your project.
yuv
Yuval Levy
> Now that I have a duel core I don't much care.
I still do. disk access is the bottle neck. and I want the PC to work
overnight on the batch, not when I am at the PC. In PTgui I just start
the batch processor, pause it, and then I go about setting up the stitch
projects for the night, but like you I wish there would be an option to
automatically start it in paused mode.
Yuv
Bruno Postle
>
>it may be just me, and it may be because I am no coder and I have
>great fear and respect of make, but I'd rather have something more
>accessible to the casual scripter. python?
The advantage of 'make' is that it isn't a programming language at
all, these stitching Makefiles are much simpler than the equivalent
programming logic.
A Makefile is really just a list of normal shell commands in no
particular order.
--
Bruno
Yuval Levy
> On Fri 09-May-2008 at 21:20 -0400, Yuval Levy wrote:
>> it may be just me, and it may be because I am no coder and I have
>> great fear and respect of make, but I'd rather have something more
>> accessible to the casual scripter. python?
>
> The advantage of 'make' is that it isn't a programming language at
> all, these stitching Makefiles are much simpler than the equivalent
> programming logic.
to me, the perl code you showcased at
<http://bugbear.postle.net/~bruno/misc/2007-06-23-goodwood-panorama/> is
much simpler than any Makefile I have ever seen; and IMO a great
prototype / proof of concept to expand batch processing in terms of
workflow.
> A Makefile is really just a list of normal shell commands in no
> particular order.
is it cross-platform?
how steep is the learning curve?
how easy is it to modify for somebody who has never seen a Makefile?
to my understanding Makefile was built for *coders*. It solves the
problem that if something changes somewhere in the code tree, all
dependencies are re-compiled and re-linked as necessary, without
re-building the whole solution. That's a tree-like, non-linear process.
Panorama stitching is a mainly linear process. I sometimes may want to
rewind some steps, make changes and re-run it, but I won't have
dependencies between different branches of a tree.
more users understand basic scripting than Makefiles, and much of the
"equivalent programming logic" that is into Makefiles is IMO not needed.
Yuv
Bruno Postle
>
>to me, the perl code you showcased at
><http://bugbear.postle.net/~bruno/misc/2007-06-23-goodwood-panorama/> is
>much simpler than any Makefile I have ever seen; and IMO a great
>prototype / proof of concept to expand batch processing in terms of
>workflow.
Except that script is a doing several things:
Firstly it mimicks the hugin 'align' functionality using the
command-line match-n-shift and autooptimiser tools - This doesn't
make sense driven by make at all.
Then it renders an equirectangular using pto2tiff - this tool is
seriously inadequate in comparison to a hugin .pto.mk Makefile, it
will never do the enfuse thing for example.
Generating QTVR, stereographic views and publishing can just as
cleanly be done using plugin Makefiles - In fact this whole script
will be better as and when - The Makefile system doesn't replace a
script like this.
>is it cross-platform?
It's already working isn't it?
>how steep is the learning curve?
Much easier than any programming language - really.
--
Bruno
Yuval Levy
> Firstly it mimicks the hugin 'align' functionality using the
> command-line match-n-shift and autooptimiser tools - This doesn't
> make sense driven by make at all.
but it does make sense in a batched workflow. So you are saying that the
Makefile does not make sense for batched workflows :-) ?
> Then it renders an equirectangular using pto2tiff - this tool is
> seriously inadequate in comparison to a hugin .pto.mk Makefile, it
> will never do the enfuse thing for example.
So whatever is used to loop through the batch queue should be able to
trigger the Makefile?
>> is it cross-platform?
>
> It's already working isn't it?
I'm afraid not, or in a confusing way. The last time I tested this on a
dual boot machine, projects set in Windows would produce black output in
Linux, and project set in Linux would produce black output in Windows
and it seems to me that this is Makefile related.
>> how steep is the learning curve?
>
> Much easier than any programming language - really.
any short and sweet recommended reading?
Yuv
Bruno Postle
>Bruno Postle wrote:
>> Firstly it mimicks the hugin 'align' functionality using the
>> command-line match-n-shift and autooptimiser tools - This doesn't
>> make sense driven by make at all.
>
>but it does make sense in a batched workflow. So you are saying that the
>Makefile does not make sense for batched workflows :-) ?
It makes sense in a lot of situations where you need to reproducibly
generate output files. The hugin .pto project that match-n-shift
generates isn't really generated data, once you have opened it up
and started editing it, it is your manually created data.
>So whatever is used to loop through the batch queue should be able to
>trigger the Makefile?
Sure:
for file in *.pto.mk; do make -f $file; done
..isn't an awful lot different to:
for file in *.pto; do pto2tiff $file; done
Except with the make command you can re-run it at any time and it
won't do anything unless something has changed, and even then it
will only redo tasks that are absolutely necessary.
>I'm afraid not, or in a confusing way. The last time I tested this on a
>dual boot machine, projects set in Windows would produce black output in
>Linux, and project set in Linux would produce black output in Windows
>and it seems to me that this is Makefile related.
The .pto files should be portable, but the Makefiles are definitely
not, they are recreated whenever you save anyway.
A .pto file saved in Linux, then opened and saved in Windows should
be identical to one created in Windows. Otherwise this is a bug.
>> Much easier than any programming language - really.
>
>any short and sweet recommended reading?
Nope.
--
Bruno
Marko Kuder
couple of days.
Bruno Postle wrote:
> Pausing a 'make' process is easy: just kill the process and it will
> stop, start 'make' again with exactly the same parameters and it
> continues from where it left off.
Hey, you're right! The way Makefiles work already solves the problem, as
they only run commands on files that don't exist / have been modified.
There's just the question whether the host OS would allow killing a process
from inside Hugin.
> Marko, you need to decide which ideas your project is going to
> follow through. There are various problems being presented, but you
> can't do them all
Well, it's good to hear that you agree. I've been wondering whether you
expect me to do all of the suggested ideas, cause it started to seem a bit
hard to handle.
> The overall workflow problem is too undefined, you could end up
> recreating lightroom or digikam rather than finding ways to extend
> these tools to support panoramic stitching workflows.
Of all the ideas presented, this would be the hardest for me, not just
because of the lack of definition, but also because I'm not very familiar
with photography. I know the basics, but I'm no photographer, so even
understanding some of the problems could be difficult. I also think this
domain isn't really in the context of the original problem. It has more to
do with single project management than with batch processing, so if it's up
to me, I would put this aside.
The batch management GUI and Makefile plugin system have been presented as
the primary and secondary objective in the original plan, so they stay.
> The .pto files should be portable, but the Makefiles are definitely
> not, they are recreated whenever you save anyway.
Yuval Levy wrote:
>> Much easier than any programming language - really.
>
> any short and sweet recommended reading?
If you don't understand Makefiles, let me give you a crash course. We had
only one hour about them at school and that was enough. If you look at a
basic Makefile generated by Hugin, you probably have many all-cap names
defined at the top. Those are just constants defined to use later when
running programs. So if you have:
"NONA=I:\huginbase\hugin-build\INSTALL\FILES\bin\nona"
it means you should replace every $(NONA) in the makefile with
"I:\huginbase\hugin-build\INSTALL\FILES\bin\nona". This example also shows
why Makefiles aren't portable. Your paths are different.
The main part of every makefiles are targets, their required files and
target-generating commands. Example:
Target: file1 file2 file3
some_command.exe file1 file2 file3 <other parameters...>
So if you want to make the "Target", which can also be a filename, it will
first check if file1, file2 and file3 exist and if they do run the command
in the next line, which should generate the target file, if Target is a
filename. The command HAS TO BE indented by one tab. If file1 doesn't exist
it will find where it says "file1: ..." and try to make that target first.
Among file1, file2,... in the prerequisites list you can also have other
goals listed, which aren't filenames, but are required to be completed
first.
The smart thing about makefiles is that they check which files have been
updated since a target has been generated the last time and only execute
their command if they don't exist or one of their prerequisites have
changed.
Looking at a Makefile from Hugin I can see nothing else that would be
difficult to understand. So you can see that Makefile's are really quite
simple. As for for loops and such stuff which is more connected with batch
files and less with Make, there I'm far from an expert. You should look into
batch file syntax for your system for that. It can be put into Makefiles
just the same, as far as I know.
Yuval Levy wrote:
> It may be just me, and it may be because I am no coder and I have great
> fear and respect of make, but I'd rather have something more accessible
> to the casual scripter. python?
I know it may be a bit awkward, but you can modify an existing Makefile to
have a target which will run a script in the command line. Modifying Hugin
to recognize scripts and join ther functionality with Make is much more
difficult. How about I add a button to my batch GUI, which would enable you
to add single command line instruction to the batch, which could run your
external script? Quite simple to implement and "support" for any scripting
language. If you want, I could also add the ability to save them as template
commands. This I think would be quite feasible.
> i might over-simplify, but to me a primitive batch stitcher is done in a
> few hours: just loop over a folder and in its sub folders, find the
> project files and feed them to the existing hugin_stitch_project.
Yes, that may be true, but please understand that I have to put this in
Hugin's existing code, so I have quite a lot of adapting to do. At the
moment I'm still trying to understand where to put my code and what will I
have to do so it still works after. Not having worked on such a large
project developed by someone else, this with all the testing afterwards will
probably take most of my time on this project.
Regards,
Marko Kuder
Zoran Mesec
Please add "Exit application when done" and "Shut down computer when
done" checkboxes to batch GUI. I am not sure if Shutting down the
computer is possible on all systems due to user permisions, but I have
seen some apps on Windows do that.
Marko you need to point out the features you will implement in the
Coding Phase 2 before the start of coding. There have been a lot of
ideas stressed out in this post, so you have lot to choose from. :)
Second phase can consist of some form of automatic target
recognition(e.q. image sequence recognition - this part must be
written so that it can be extendable) or panorama video batch
stitching support, ...
And also, please define some details and a timeline for Coding Phase
2.
It is very important to have project well defined at this point,
because there will be no time to think "what to do in phase 2?" when
coding starts...
regards,
Zoran Mesec
On May 11, 8:57 pm, "Marko Kuder" <marko.ku...@gmail.com> wrote:
> Sorry for my short absence, I've been communicationally disabled for a
> couple of days.
>
> Bruno Postle wrote:
> > Pausing a 'make' process is easy: just kill the process and it will
> > stop, start 'make' again with exactly the same parameters and it
> > continues from where it left off.
>
> Hey, you're right! The way Makefiles work already solves the problem, as
> they only run commands on files that don't exist / have been modified.
> There's just the question whether the host OS would allow killing a process
> from inside Hugin.
Bruno Postle
>
>Yes, that may be true, but please understand that I have to put
>this in Hugin's existing code, so I have quite a lot of adapting to
>do. At the moment I'm still trying to understand where to put my
>code and what will I have to do so it still works after. Not having
>worked on such a large project developed by someone else, this with
>all the testing afterwards will probably take most of my time on
>this project.
Actually the stitching spooler can be a separate program altogether,
one of the problems with doing it within hugin is that hugin is a
complex tool that can be made to crash and consume vast amounts of
memory in so many different ways - It's the wrong type of tool to be
handling stitching jobs that can take hours to complete.
All hugin needs to do is write the .pto and .pto.mk files and inform
the batch stitcher that they are ready to go. I'd do this by
running an external tool like this:
send-to-batch --makefile=/path/to/makefile.mk
All this send-to-batch tool needs to do is make sure the stitching
spooler is running and put the job on the end of the queue.
Notice that an interface like this allows other (non-GUI) batch
stitchers to be integrated as options later on.
--
Bruno
Pablo d'Angelo
I have to catch up a lot, so just a quick note.
Bruno Postle schrieb:
I agree 100%. I will not add batch functionality to the main hugin
executable itself, except a button to add a project to the batch stitcher
and possible options for further processing in other external programs or
with custom makefiles.
> Notice that an interface like this allows other (non-GUI) batch
> stitchers to be integrated as options later on.
Actually, it is trivial to add a queue to the hugin_stitch_project program.
Its been designed with that in mind already.
ciao
Pablo
luca vascon
Ptbutcher prepares the projects
I have a template and a bunch of N folders...
In each folder I put the same amount of pics, let's say I work with 8mm on apsc and I shoot a semi-hdr for enfusion, so each project will have 4x3shots.
I say to ptbutcher to run this template on a folder+subfolders.
It builds N projects (make a choice to save them on image folders or in a given folder) each one named as I prefer (choice among: subfolder name, custom progressive, first image name)
Optimizing:
In PTBUTCHER interface I load all the virgin projects and I can see and change, individually or globally:
- CP generation
- kind of optimization
- blending software
- generate preview (just a little 800x400 pano)
Stitching:
In PTBUTCHER interface I load again all the project and I can see and change, individually or globally:
- output folder (user defined, same as project, same as images)
- output name (with simple wildcards for progressive names)
- output type (psp, jpg, layered etc)
- enfuse settings
In the first row I can see the preview stitched image. It is the check to know where to intervein manually.
A duble click on the preview let me open the real projeck and intervein. After the project is updated and saved 0 PTbutcher should know, use it to generate another preview and update it on its interface
I have to stitch a panovideo, so I'll have a template and N folders from N cameras.
PTbutcher makes the N images dummy projekt and runs it in batch stitching changing image name only.
Again the need is to enter a progressive name and folder for resulting images, and to be able to perform a test stitch on the, say, first 10, or from 130th to 140th...
This is what is REALLY needed, I think.
Emulation of autopanoPro functionality is imho a secondary task.
;-PP
Please, hit me if I said bullshit!
Luca.
luca vascon
It would be FANTASTIC to be prepared to add the "feed stitching work to that other machine in the network" button, or the "stitch via the PS3s you find on the gigabit lan"
Bruno Postle
>A duble click on the preview let me open the real projeck and intervein.
>After the project is updated and saved 0 PTbutcher should know, use it to
>generate another preview and update it on its interface
This is a good idea, it should be possible to select a stitching job
in the spooler and choose to view/edit the output image, open the
project file in hugin or open the results folder - As well as
remove/pause/clean/restart/move up/move down.
>It would be FANTASTIC to be prepared to add the "feed stitching work to that
>other machine in the network" button, or the "stitch via the PS3s you find
>on the gigabit lan"
This is already possible using tools such as 'distmake'. Though
a cool thing to do it doesn't really need a GUI - Anyone who is
capable of setting up a stitching cluster isn't going to have any
problem queueing jobs using the command-line.
--
Bruno
Marko Kuder
> Optimizing:
> In PTBUTCHER interface I load all the virgin projects and I can see and
change, individually or globally:
> - CP generation
> - kind of optimization
> - blending software
> - generate preview (just a little 800x400 pano)
> Stitching:
> In PTBUTCHER interface I load again all the project and I can see and
change, individually or globally:
> - output folder (user defined, same as project, same as images)
> - output name (with simple wildcards for progressive names)
> - output type (psp, jpg, layered etc)
> - enfuse settings
Now correct me if I'm wrong, but isn't all this functionality you would like
in this batch processor actually the options available in Hugin? If you
(hugin group) insist that it should be a separate application and not a tab
in Hugin, it should (if you ask me) at least be connected with Hugin so the
individual projects can be loaded and modified there. What you're asking of
me is to make a new a bit simplified Hugin, which would be a bit too much to
do in the given timeframe. A batch tab still seems like a better idea to me
or at least a child window. There's no way I'm going to re-implement most of
Hugin's functionality into a brand new app.
We should get to an agreement so I can define the timeline of this project.
I can't do that not knowing what my app will be based on. After we decide on
the tab/window/separate app dilemma I still have to do some research on the
subject so I know what I'm gonna be dealing with. After that I'll decide on
the additional options this batch processor will include, depending on the
time plan.
regards,
Marko
luca vascon
I'm not able to copy and write back a single line of code. Nor I want to larn how to... :-) I'm a double-click-it guy.
And I think I'm not alone!
A good gui is the 99% of the software.
And the 100 percent of its perception.
luca vascon
The idea, riginally was simply to use the ptbutcher to pass hugin the things to do.
And what I was telling here is the "dream interface" tasks.
Simply generating and iterating batch tasks to projects. Ptbutcher has only to process txt files and to invoke the right Hugin part on it.
I don't know if it is possible.... Am I saying idiocies?
Bruno Postle
>I'm not able to copy and write back a single line of code. Nor I want to
>larn how to... :-) I'm a double-click-it guy.
This is one of those things that needs to proceed incrementally:
First somebody actually has to have a need for network stitching,
then they need to actually try it using the available tools - At
that point it might be possible to design a GUI interface for it (or
decide if one is necessary, or discover that one already exists).
--
Bruno
>2008/5/12 Bruno Postle <br...@postle.net>:
Bruno Postle
>Wait... I'm not a coder, nor the one that can tell you what to do!!
Yes, Marko we are just throwing ideas around. You need to decide
yourself what your project is going to actually be.
Ultimately Pablo is the one who decides what goes into hugin and
what doesn't - You can ignore the rest of us ;-)
--
Bruno
>2008/5/13 Marko Kuder <marko...@gmail.com>:
Yuval Levy
Marko Kuder wrote:
> Now correct me if I'm wrong, but isn't all this functionality you would like
> in this batch processor actually the options available in Hugin? If you
> (hugin group) insist that it should be a separate application and not a tab
> in Hugin, it should (if you ask me) at least be connected with Hugin so the
> individual projects can be loaded and modified there.
yes, we have been bumping a lot of ideas here, and you need to make a
choice. and yes, much of the functionality that Luca, Bruno, others, and
me, mention is already available in Hugin.
We (or at least I) am not asking you to re-invent the wheel. What I
would like is another way to access the wheel.
The process, if you ask me, is the same for the batch processor and for
a human being working with Hugin:
* identify a set of images as being part of a panorama
* identify control points on them
* optimize their position and their photometry
* stitch and blend
In Hugin, the person that does this accesses the functionalities through
a GUI, moving from tab to tab and clicking herself through the steps of
the process.
Now, the same thing could be done on the command line:
* copy the set of images to a folder
* run the command line tool autopano-sift-c on the images in that folder
* run PTOptimizer on the generated control points
* feed the generated project file to nona or PTmender
* feed the remapped images to enblend or enfuse
So we have the same process, once in a GUI and once in a CLI. Obviously
for an interactive process with a human being, the GUI is superior in
this case, but the CLI tools exist, and they are the right interface for
your batch stitcher to tap into hugin's functionality without
reinventing the wheel.
In its most basic form, all you need for this kind of batch processor is
some "glue" that can generate the commands for the CLI and feed them
through system calls.
> We should get to an agreement so I can define the timeline of this project.
> I can't do that not knowing what my app will be based on.
The one thing that can be said for sure: your app will be a standalone
app. And if I could make a recommendation, I'd say: use a scripting
language for it. My choice would be Python. It was built to manipulate
lists, and lists manipulation (the queue of project files) will be core
to your code.
Your app will tap into hugin's functionalities. Which ones depends of
what you decide.
If you want your batch stitcher to be a spooler for existing and
complete stitch projects, you will have an internal list of .pto files
and you will pass them one after the other through system calls to
hugin_stitch_project. you will need to have a few functionalities, such
as adding a .pto file to the queue (from the hugin GUI), removing one
from the queue, pausing and resuming the processing of the queue, some
sort of logging and user notification.
If you want your batch stitcher to be a processor for images, there will
be more binaries that you will call through the system. If you take
Luca's idea, you will start with a given set of folders and a template.
If you take mine, you will start with a bunch of images that you will
want to sort out into folders.
I understand that at this moment we are confusing you. I would suggest
that you make one decision: do you want your processor to process
stitching projects or image files? and I would suggest that we all stick
to whatever you decide and keep spinning only that one idea you have
decided to focus on.
But please, if I can have a piece of advice: do it in Python or in
another scriptable language.
Yuv
Yuval Levy
> First somebody actually has to have a need for network stitching,
> then they need to actually try it using the available tools - At
> that point it might be possible to design a GUI interface for it (or
> decide if one is necessary, or discover that one already exists).
I do network rendering. It is not the complete stitching process, just
the publishing transformation.
My processor (a batch processor) takes as input a folder full of
equirectangular images. It goes through them one by one and transforms
them to different sizes and shapes.
The only GUI I need is Windows Explorer. Connect it to a network drive,
drop the equirectangular TIFF on one end, come back a few hours later
and pick the result from the output folder:
http://www.photopla.net/080415aqua/panohi/080415aqua.jpg
http://www.photopla.net/080415aqua/panomid/080415aqua.jpg
http://www.photopla.net/080415aqua/panonorm/080415aqua.jpg
http://www.photopla.net/080415aqua/panotn/080415aqua.jpg
http://www.photopla.net/080415aqua/spiv1536/080415aqua.jpg
http://www.photopla.net/080415aqua/spiv1024/080415aqua.jpg
http://www.photopla.net/080415aqua/qtvrfs/080415aqua.mov
http://www.photopla.net/080415aqua/planet/080415aqua.png
...
No need for a GUI, the process runs all in the background anyway, I
don't want it to disturb me. For the occasional job of defining a new
format / changing parameters the best GUI known to me is a text editor
(Notepad?) and a well commented script.
Yuv
Yuval Levy
> The .pto files should be portable, but the Makefiles are definitely
> not, they are recreated whenever you save anyway.
that's another reason *not* to go Makefiles. I don't want to save the
project again only to make it compatible with the batch processor.
on the desktop I work in Windows and I set up my projects in Windows, on
a network drive. The batch processor runs in Ubuntu, accessing the same
network drive.
> A .pto file saved in Linux, then opened and saved in Windows should
> be identical to one created in Windows. Otherwise this is a bug.
The .pto files are identical indeed, but to stitch a project right now
it takes both a .pto *and* a Makefile. I had a few weeks ago the problem
on my dual boot workstation. When I was booted in Ubuntu and saved a
project, loading and stitching that project in Windows yielded a black
image. And the other way around too. I am now confident that the one and
sole culprit for that is make.
In another discussion I was cc: on and which probably would have been
better out here, you stated that
> I guess what I'd really like is to only keep my RAW photos and
> whatever information is required to turn them into something useful.
> Unfortunately this 'information' involves: rotation, colour profiles,
> exposure/gamma, noise removal, sharpening, tca, and maybe cropping,
> exposure blending, manipulation in hugin etc... all the intermediate
> image data in this process is just 'cache', I only keep it around
> because 'cache' speeds things up, but it shouldn't survive in the long
> term.
the project file should contain the "information required to turn them
into something useful". it should be portable.
the Makefile is just an obstacle, because it is not portable, and
because when present it influence the process from RAW to end-result.
It's purpose in coding is just 'cache'. But as you state, 'cache'
shouln't survive in the long term, and so shouldn't Makefile.
If the batch processor derives a temporary Makefile based on a .pto
file, that's fine for me. But Makefiles should be temporary IMO, so that
the stitching of both an individual project or a whole batch is seamless
between platforms.
Yuv
Bruno Postle
>
>The .pto files are identical indeed, but to stitch a project right now
>it takes both a .pto *and* a Makefile. I had a few weeks ago the problem
>on my dual boot workstation. When I was booted in Ubuntu and saved a
>project, loading and stitching that project in Windows yielded a black
>image. And the other way around too. I am now confident that the one and
>sole culprit for that is make.
You encountered one bug in the unstable version of hugin, we need to
be able to reproduce it in order to fix it rather than guessing the
cause.
>the project file should contain the "information required to turn them
>into something useful". it should be portable.
The project contains all the information describing how the images
need to relate to each other, the Makefile is just a tedious list of
the commands needed to make the output image file - Uninteresting in
the long term, especially as new tools arrive in the future.
>If the batch processor derives a temporary Makefile based on a .pto
>file, that's fine for me. But Makefiles should be temporary IMO, so that
>the stitching of both an individual project or a whole batch is seamless
>between platforms.
Yes, the Makefiles are transient and are created for each stitch
when they are needed.
We need a command-line tool for generating these Makefiles, in fact
I would like to be able to pass it an option specifying the OS and
generate a Linux Makefile on Windows etc...
This hasn't happened because it really isn't necessary for a 0.7.0
release.
--
Bruno
Yuval Levy
> You encountered one bug in the unstable version of hugin, we need to
> be able to reproduce it in order to fix it rather than guessing the
> cause.
Filed a bug report
<https://sourceforge.net/tracker/index.php?func=detail&aid=1967010&group_id=77506&atid=550441>
> Yes, the Makefiles are transient and are created for each stitch
> when they are needed.
they don't look so transient on my hard disk - I keep finding those .mk
files hanging around. they should go into a temp folder with all the
cached stuff and be deleted at the end of the stitching process, but
this would void some of the functionality why they were introduced in
the first place, wouldn't it?
so at least, is there a make clean target that can be triggered from the
GUI?
> We need a command-line tool for generating these Makefiles, in fact
> I would like to be able to pass it an option specifying the OS and
> generate a Linux Makefile on Windows etc...
the one thing I need is a tool to remove them when I boot from one
system to another.
Yuv
Marko Kuder
my batch processor work with just the project files. The main problem is
that I would need to read the file properly, so I'm leaning towards the
inheritance of Hugin's Panorama and PanoCommand classes, since they appear
to include the necessary data structure and project file parsing.
However, going this way makes C++ and wxWidgets the primary choice as oppose
to Python. I looked at the SWIG library, which enables cross-language
programming, but it looks like it's difficult to use with many header files
and requires a lot of wrapper programming and helper functions. So this week
I'm working on making a simple application (in C++) which would read the
project file, so we can (maybe) avoid the dreaded Makefiles or (which is
more likely) at least make them temporary. After I'm done with this it
should be clear how my summer project can proceed.
Regards,
Marko
Pablo d'Angelo
Marko Kuder wrote:
> Just a quick update. At the moment I'm working on the possibility of making
> my batch processor work with just the project files.
I agree that the batch processor should work with the project files. The
makefiles are only temporary for performing the actual stitching.
Unfortunately I first saved them out next to the .pto file instead of
providing a program to create the makefile from the pto file.
> The main problem is
> that I would need to read the file properly, so I'm leaning towards the
> inheritance of Hugin's Panorama and PanoCommand classes, since they appear
> to include the necessary data structure and project file parsing.
For project parsing, Daniel has written a nice, stand alone parser some time
ago, which would be quite useful for this purpose.
It can be found in the hugin svn repository at:
http://hugin.svn.sourceforge.net/viewvc/hugin/libpanorama/trunk/src/parser/
Otherwise, it is probably easier to write a parser in python than warping
the Hugin Panorama class with swig (although I plan to do this some time in
the future).
ciao
Pablo
Yuval Levy
> Hi Marko,
>
> Marko Kuder wrote:
>> Just a quick update. At the moment I'm working on the possibility of making
>> my batch processor work with just the project files.
>
> I agree that the batch processor should work with the project files. The
> makefiles are only temporary for performing the actual stitching.
The alternative was not much the makefiles as a folder of loose images
that would have to be joined into a project file. Anyway, a batch
processor for project files it is.
>> The main problem is
>> that I would need to read the file properly, so I'm leaning towards the
>> inheritance of Hugin's Panorama and PanoCommand classes, since they appear
>> to include the necessary data structure and project file parsing.
>
> For project parsing, Daniel has written a nice, stand alone parser some time
> ago, which would be quite useful for this purpose.
> It can be found in the hugin svn repository at:
> http://hugin.svn.sourceforge.net/viewvc/hugin/libpanorama/trunk/src/parser/
>
> Otherwise, it is probably easier to write a parser in python than warping
> the Hugin Panorama class with swig (although I plan to do this some time in
> the future).
Python also has <http://wxpython.org/> for a GUI, and probably it is
possible to make hooks in hugin's C++ code to access functionalities
from Python when needed.
Yuv
Bruno Postle
>
>> Yes, the Makefiles are transient and are created for each stitch
>> when they are needed.
>
>they don't look so transient on my hard disk - I keep finding those .mk
>files hanging around. they should go into a temp folder with all the
>cached stuff and be deleted at the end of the stitching process, but
>this would void some of the functionality why they were introduced in
>the first place, wouldn't it?
There are three ways this can work:
1. File -> Save - This writes the .pto and the .pto.mk to disk for
later. You can either reopen the .pto in hugin or batch stitch the
Makefile on the command-line (or delete it).
2. Assistant -> Create panorama - This creates temporary versions of
these files and stitches the panorama, the only file that this
leaves is the output image. This is what you are asking for.
3. Stitcher -> Save project and send to batch - Greyed out as the GUI
batch stitcher doesn't exist yet.
The one current anomaly is the Stitcher -> Save project and stitch
button which actually does (2) above.
>so at least, is there a make clean target that can be triggered from the
>GUI?
As far as I understand, the GUI runs the equivalent of:
make all
make clean
So if you have any intermediate files left over it is because the
process crashed before it could finish.
If you tick 'remapped images' or 'blended exposure layers' in the
GUI then these are not considered intermediate files and you get to
keep them.
--
Bruno
Daniel M German
Pablo> For project parsing, Daniel has written a nice, stand alone parser some time
Pablo> ago, which would be quite useful for this purpose.
Pablo> It can be found in the hugin svn repository at:
Pablo> http://hugin.svn.sourceforge.net/viewvc/hugin/libpanorama/trunk/src/parser/
I would be happy to help with its use. One potential use of this parser
is to create simple stand-alone app that parses the script and generate
"easier" to parse data that can be used by a script. The PTO format is
really legacy, and not the cleanest. One solution would be to generate
simple XML.
--dmg
--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
Marko Kuder
thing I noticed when running the compiled Hugin binary, was that there's a
program in there that's probably perfect as a base for my project -
hugin_stitch_project. I don't know how I haven't spotted that before and I
spent most of the past week trying to mimic parts of code from Hugin itself,
ending up just copy/pasting half the code from different source files,
constantly fighting with unknown references and other compile problems.
Silly old me.
The reason I think hugin_stitch_project is best is that in essence I don't
really need much else from existing code than just something that will read
project files and execute them. Everything else is probably quite doable on
it's own. So today I copied hugin_stitch_project and created my own, at the
moment just an exact copy with the name PTButcher (is that ok? I just took
the name you had planned for it before, although "butcher" seems kind of
destructive and I don't want it to take a cleaver to people's projects :).
I modified all CMake files and stuff so it would work from the svn branch
itself, but I had problems when I wanted to put the project as a
subdirectory of src. Even though I fixed and double checked all paths and
added the include of hugin1, so all project settings are identical to
hugin_stitch_project's with the exception of project names, I still got some
unresolved external symbols of wxWidgets, which I couldn't fix. Since
PTButcher is also a GUI, would it be ok if I just put it in src/hugin1,
where hugin_stitch_project is? If that's a no, I would like some help on why
it doesn't link when all project settings and includes are the same.
Now to the project plan as I imagine it:
May 26 - June 1:
- basic GUI that processes a list of projects
June 2 - June 29 - exam time, work may be a bit irregular, so I joined these
four weeks, plans more or less in sequence as follows:
- command line support, so the batch processor can be included in scripts.
I'll post a suggested parameter syntax next weekend.
- link with Hugin, so projects can be edited. This may take some time to do
properly.
- cross-platform support. Mostly linked with previous goal.
- some additional basic options. Ideas previously mentioned in this thread,
like "shutdown when done", command line instructions between projects and
similar.
June 30 - July 13:
- reserved for open testing and debugging. If it proves to work fine
quickly, start on second code-phase plans or some minor functional additions
- Midterm Evaluation
July 14 - August 3: Not yet fully planned. We'll see how the first part goes
through. Some probable goals:
- directory processing support. Having multiple projects in different
subdirectiories to run them all.
- template support. Probably just an ability to switch input files with
option for control point redetection (as cameras may be fixed).
- complete makefile elimination from the process?
- user help. Those little context sensitive pop-ups that appear when you
hover over a button. Do they have a specific name?
- code clean-up
August 4 - August 10:
- final testing and debugging
August 11 - Suggested 'pencils down date'. An additional week if debugging
seems to be longer.
Phew, that was a long one. I hope someone actually reads it :).
Regards,
Marko
Pablo d'Angelo
Yes, hugin_stitch_project is indeed a good base for a batch stitcher.
Marko Kuder schrieb:
> The reason I think hugin_stitch_project is best is that in essence I don't
> really need much else from existing code than just something that will read
> project files and execute them. Everything else is probably quite doable on
> it's own. So today I copied hugin_stitch_project and created my own, at the
> moment just an exact copy with the name PTButcher (is that ok? I just took
> the name you had planned for it before, although "butcher" seems kind of
> destructive and I don't want it to take a cleaver to people's projects :).
Actually, I think the butcher more referred to the workflow tool, and not
just the sequential stitching of projects, but I see that you might include
stuff like applying template projects to images with automatic control point
detection etc. From there its not a big step to performing the same thing
without templates.
> I modified all CMake files and stuff so it would work from the svn branch
> itself, but I had problems when I wanted to put the project as a
> subdirectory of src. Even though I fixed and double checked all paths and
> added the include of hugin1, so all project settings are identical to
> hugin_stitch_project's with the exception of project names, I still got some
> unresolved external symbols of wxWidgets, which I couldn't fix. Since
> PTButcher is also a GUI, would it be ok if I just put it in src/hugin1,
> where hugin_stitch_project is? If that's a no, I would like some help on why
> it doesn't link when all project settings and includes are the same.
wxWidgets is currently only enabled in the src/hugin1 directory. In order to
get your project to build, you need to place the
add_subdirectory(pt_butcher) after the INCLUDE(${wxWidgets_USE_FILE})
statement in src/CMakeLists.txt
> May 26 - June 1:
> - basic GUI that processes a list of projects
>
> June 2 - June 29 - exam time, work may be a bit irregular, so I joined these
> four weeks, plans more or less in sequence as follows:
> - command line support, so the batch processor can be included in scripts.
> I'll post a suggested parameter syntax next weekend.
> - link with Hugin, so projects can be edited. This may take some time to do
> properly.
I'd just call the external hugin with the project file. No need to embed the
entire editor in the batch stitcher.
ciao
Pablo
Marko Kuder
> Actually, I think the butcher more referred to the workflow tool, and not
> just the sequential stitching of projects, but I see that you might
include
> stuff like applying template projects to images with automatic control
point
> detection etc. From there its not a big step to performing the same thing
> without templates.
Aren't templates just regular projects? If I choose "apply template" and a
project file I saved previously Hugin basically takes all options and you
choose new input files. As we need to take the options from somewhere, we
would probably always have some template, although it would be in the form
of a previous entry in the batch list. I don't see what functionality could
we have here "without templates".
> wxWidgets is currently only enabled in the src/hugin1 directory. In order
to
> get your project to build, you need to place the
> add_subdirectory(pt_butcher) after the INCLUDE(${wxWidgets_USE_FILE})
> statement in src/CMakeLists.txt
Oh, that's it! I'm not that familiar with Cmake and I thought it doesn't
really matter where I put the add_subdirectory command and I put it after
the matchpoint, deghosting,... entries. I thought that's just a redirect so
it processes the subdir and not much else. So, do I move it to the src/
directory now or leave it beside hugin_stitch_project?
> I'd just call the external hugin with the project file. No need to embed
the
> entire editor in the batch stitcher.
Yeah, that's actually what I meant. It's just that the "send project to
batch" button in Hugin needs to be configured and PTButcher should know when
a project file was changed and saved in Hugin, so it reloads it.
Cheers,
Marko
Bruno Postle
>
>Yeah, that's actually what I meant. It's just that the "send project to
>batch" button in Hugin needs to be configured and PTButcher should know when
>a project file was changed and saved in Hugin, so it reloads it.
I suggest you look at the way other 'spooler' tools do this, I would
do something like this:
1. a single spool directory per user, each task is represented by a
file - The files are not .pto projects, but contain pointers to a
project file.
I would have a separate directory per 'state' (processing, paused,
done, failed) and move the files when the state changes. Note that
using files like this is robust and allows for restarting after
power failures, crashes etc...
2. a simple command-line tool that is called by hugin when 'send to
batch' is clicked - All this tool does is check the spool directory
exists and places one of these pointers in it.
3. The batch stitcher itself, this looks at the spool directory and
does whatever is needed - The GUI displays the tasks and their
states and allows killing, pausing, launching projects etc...
--
Bruno
Bruno Postle
>So today I copied hugin_stitch_project and created my own, at the
>moment just an exact copy with the name PTButcher (is that ok? I just took
>the name you had planned for it before, although "butcher" seems kind of
>destructive and I don't want it to take a cleaver to people's projects :).
I think it is inappropriate to call the tool 'butcher', not just
because of the meat connotations, but because in English 'to
butcher' can mean 'to make a big mess'.
Hugin and nona are mythological, we need to find some 'hard working'
name.
--
Bruno
Yuval Levy
> On Mon 19-May-2008 at 07:49 -0400, Yuval Levy wrote:
>>> Yes, the Makefiles are transient and are created for each stitch
>>> when they are needed.
>> they don't look so transient on my hard disk - I keep finding those .mk
>> files hanging around. they should go into a temp folder with all the
>> cached stuff and be deleted at the end of the stitching process, but
>> this would void some of the functionality why they were introduced in
>> the first place, wouldn't it?
>
> There are three ways this can work:
>
> 1. File -> Save - This writes the .pto and the .pto.mk to disk for
> later. You can either reopen the .pto in hugin or batch stitch the
> Makefile on the command-line (or delete it).
why save the .pto.mk file? shouldn't that be transient, and generated
when the .pto is opened for stitching (as opposed to when it is saved)?
> 2. Assistant -> Create panorama - This creates temporary versions of
> these files and stitches the panorama, the only file that this
> leaves is the output image. This is what you are asking for.
not really - the .pto file should be saved permanently, the .mk file
should be deleted after the panorama is created.
> 3. Stitcher -> Save project and send to batch - Greyed out as the GUI
> batch stitcher doesn't exist yet.
save the .pto file. leave the generation of the .mk file to the batch
stitcher.
> The one current anomaly is the Stitcher -> Save project and stitch
> button which actually does (2) above.
the current anomaly is that .mk files are saved before stitching is
triggered. i just saved a project in Windows and closed hugin without
stitching. i have a .pto and a .mk file. i open the project in Linux and
the existing .mk file confuses hugin when i try to stitch.
the .mk file should be generated immediately after the stitching process
is started. if an .mk file exist, it should be overwritten (which might
cause permissioning issues of its own, so better finish the stitch
process with a deletion of the .mk file)
Yuv
Yuval Levy
>
>
> Pablo> For project parsing, Daniel has written a nice, stand alone parser some time
> Pablo> ago, which would be quite useful for this purpose.
> Pablo> It can be found in the hugin svn repository at:
> Pablo> http://hugin.svn.sourceforge.net/viewvc/hugin/libpanorama/trunk/src/parser/
>
> I would be happy to help with its use. One potential use of this parser
> is to create simple stand-alone app that parses the script and generate
> "easier" to parse data that can be used by a script. The PTO format is
> really legacy, and not the cleanest. One solution would be to generate
> simple XML.
how difficult is it to add writing capabilities to this code, i.e. a
function like: Set_Project_Parameter("param","value")?
then it would make sense if over time all applications in the suite
would use this parser to get their values and this added function to
write them, and when they all use them it would be possible to switch
the code from generating the current TEXT file to generate an XML -
completely transparent to the applications that use this interface.
Yuv
luca vascon
Ken Warner
luca vascon
It has some really evil connotations although.
luca vascon
All my computers, phones and things are from greek mithology.
Persephone, Argo, Cerberus, Penelope, Ikaro, Athena, etc.
Only the big, black, stealthy BIG machine is called RedOktober. It is all black Chieftec BIG tower, with a red star sticker on it.
luca vascon
I was sampling steele surfaces and butcher knives as icon and interface background...
with some pretty nice bloody spot here and there...
8-)
no?
8-D
luca vascon
Bruno Postle
>nah... it does not really MAKE the job. And with Hugin and Odin we are far
>north.
I was thinking of 'sisyphus', but it sounds a bit 'sissy'...
--
Bruno
Bruno Postle
>
>why save the .pto.mk file? shouldn't that be transient, and generated
>when the .pto is opened for stitching (as opposed to when it is saved)?
A good reason for doing it like this is that we don't (yet) have a
command-line tool for creating the .mk files and hugin needs a
release.
>not really - the .pto file should be saved permanently, the .mk file
>should be deleted after the panorama is created.
Whichever you want, keeping the .mk file allows you to edit any of
the intermediate files and re-run the job without starting from the
beginning - Which is one of the advantages of using Makefiles in the
first place.
>the current anomaly is that .mk files are saved before stitching is
>triggered. i just saved a project in Windows and closed hugin without
>stitching. i have a .pto and a .mk file. i open the project in Linux and
>the existing .mk file confuses hugin when i try to stitch.
Are you really sure this is happening? My experience is that hugin
always overwrites the .mk file whenever you save. Can you do these
steps that are failing, make a copy of the broken .mk file, delete
it, re-run and diff the newly generated .mk file with the broken
one?
--
Bruno
Bruno Postle
>
>then it would make sense if over time all applications in the suite
>would use this parser to get their values and this added function to
>write them, and when they all use them it would be possible to switch
>the code from generating the current TEXT file to generate an XML -
>completely transparent to the applications that use this interface.
I was an advocate of switching to XML, but I now think that it would
be a diversion to switch from a stable debugged file format (however
ugly) unless there are concrete advantages.
What would you be able to do in XML that you wouldn't be able to do
with this C++ parser and the existing format?
--
Bruno
Pablo d'Angelo
Hugin (or better hugin_stitch_project) always uses a temporary makefile. It
doesn't need the generated pto.mk file at all.
ciao
Pablo
>
Marko Kuder
>Hi,
>
>I need to bring batch processing to my panos too !
>I'll have some free time during this summer to work on it. I think it
>will be more efficient to work in collaboration with you.
>Tell me the state of the union and how I can help to bring hugin batch
>processing to the mass.
>
>Regards
I'm not sure whether the group would allow this, since I'm working as part
of Google Summer of Code, so I get evaluated for what I do and I shouldn't
get payed if I don't do my part. Maybe they can comment on this.
As for the state of my project, I developed the basic GUI with a project
list and three buttons: add, remove project and run batch. I just have some
problems. I cannot commit my code to the repository, as it asks for
authentication, which doesn't work with my sourceforge account. Do I have
commit rights yet?
The other problem is with my batch processor. The base code of
hugin_stitch_project (specifically the includes which take care of makefile
execution in a panel - MyExecPanel and others) is developed in such a way,
that the stitching is run as an asynced process, so in my case every project
in the batch is executed as a separate process and they all start at the
same time. Voila, instant parallel batch processing :). While it is fine at
the moment (multiple projects complete without problems), it would probaly
be better if it would run in sequence. So, do you know of a way that I could
force the GUI to wait the processes to complete? The code that runs them is
deep in includes I never touched, so I can't get any handles. At least don't
know if I can.
The simple, but a bit redundant-code-manifesting way is that I
copy/implement a separate function which will create a separate window to
run the projects in, more or less a copy of the existing one, only that I
make it iterative. Simply changing the ASYNC flag to SYNC doesn't seem to
work though, so I'll take some work.
Regards,
Marko
Pablo d'Angelo
> jupitereyes wrote:
>> Hi,
>>
>> I need to bring batch processing to my panos too !
>> I'll have some free time during this summer to work on it. I think it
>> will be more efficient to work in collaboration with you.
>> Tell me the state of the union and how I can help to bring hugin batch
>> processing to the mass.
>>
>> Regards
>
> I'm not sure whether the group would allow this, since I'm working as part
> of Google Summer of Code, so I get evaluated for what I do and I shouldn't
> get payed if I don't do my part. Maybe they can comment on this.
I don't think we have an all or nothing situation here. I'd have to check
the google summer of code rules (Yuv, do you know what applies here?).
> As for the state of my project, I developed the basic GUI with a project
> list and three buttons: add, remove project and run batch. I just have some
> problems. I cannot commit my code to the repository, as it asks for
> authentication, which doesn't work with my sourceforge account. Do I have
> commit rights yet?
I tried adding you when you send me your account details, but the account
wasn't created at that time. It seems active now, I just added you to the
project.
> The other problem is with my batch processor. The base code of
> hugin_stitch_project (specifically the includes which take care of makefile
> execution in a panel - MyExecPanel and others) is developed in such a way,
> that the stitching is run as an asynced process, so in my case every project
> in the batch is executed as a separate process and they all start at the
> same time. Voila, instant parallel batch processing :).
After a project has been stitched, the RunStitchFrame::OnProcessTerminate
function is called. Simply check there if you have more unstitched projects
in the queue and start the next one by calling
RunStitchFrame::StitchProject with the next unstitched project. No need to
change the other classes. You probably want to add a list view with the
project on top of the stitching output progress display.
The next part is how the communication between the batch stitcher and hugin
(or other tools) should work. I like the spool directory idea Bruno
mentioned earlier, as it does not involve complicated inter process
communication, which is hard to get right for a cross platform application.
ciao
Pablo
Yuval Levy
> Marko Kuder schrieb:
>> jupitereyes wrote:
>>> Hi,
>>>
>>> I need to bring batch processing to my panos too !
>>> I'll have some free time during this summer to work on it. I think it
>>> will be more efficient to work in collaboration with you.
>>> Tell me the state of the union and how I can help to bring hugin batch
>>> processing to the mass.
>>>
>>> Regards
>> I'm not sure whether the group would allow this, since I'm working as part
>> of Google Summer of Code, so I get evaluated for what I do and I shouldn't
>> get payed if I don't do my part. Maybe they can comment on this.
>
> I don't think we have an all or nothing situation here. I'd have to check
> the google summer of code rules (Yuv, do you know what applies here?).
first and foremost: common sense. my advice to Marko:
1. don't make yourself dependent. You have a deadline. If you have to
wait for somebody's code to fulfill it, your project may fail simply
because the promised code arrived too late.
2. keep communicating about such collaboration / contributions to your
code. As long as you clearly take credits only for your bits of code and
not for that of others, you won't risk to be seen as cheating.
3. share freely your plans with jupitereyes or whoever else wants to
participate. if they ask you for what they can work on, think of (1) and
give them some extra bits that are not critical for success. Things that
are planned for "later". Make sure they have information they need to do
it, but use your time wisely on your own project first.
4. they can work on their local copy of your work (available to
everybody from SVN), and keep that independent, so that your work is
delivered to Google, but not theirs.
Yuv
Bruno Postle
>
>1. don't make yourself dependent. You have a deadline. If you have to
>wait for somebody's code to fulfill it, your project may fail simply
>because the promised code arrived too late.
Yes very important, but also remember that lazyness is one of the
Three Virtues - If somebody else has already written the code you
need, then you are under no obligation to recreate it.
--
Bruno
Marko Kuder
>I tried adding you when you send me your account details, but the account
>wasn't created at that time. It seems active now, I just added you to the
>project.
As for the report you all expect... Is what I posted these last few days enough or do you expect something more formal?
Yuval Levy wrote:
>3. share freely your plans with jupitereyes or whoever else wants to
>participate. if they ask you for what they can work on, think of (1) and
>give them some extra bits that are not critical for success. Things that
>are planned for "later". Make sure they have information they need to do
>it, but use your time wisely on your own project first.
--
Marko
Marko Kuder
Today I commited the latest version of the program. I added command
line options, some of which I just kept from hugin_stitch_project,
even though they aren't used yet:
-h : the help message of course
-t : number of threads. Not used yet and if I'm not mistaken, not
even in hugin_stitch_project
-r : run batch list immediately when program is run
-p : enable parallel mode
-d : delete project files. Not used yet.
I fixed the sequential execution at the start of the week and since
parallel could also be useful, I added an option for it and both of
them work. There is also a checkbox for it in the GUI. Removal of
project files isn't implemented yet, cause I'll have to find a way to
make it work with parallel execution (I'll probably just keep a list,
which processes are running and when the last of them is finished,
I'll remove all the files).
The batch list is added as parameters in the format <project1 <output
prefix>> <project2 <output prefix2>> ... Without the "<>" of course.
Basically you just list all the project file names with optional
output prefixes after them. The program distinguishes between project
files and prefixes by extension. If there is no extension or the
extension is that of an image format, it is regarded as a prefix.
Everything else is taken as a project file. If a project file doesn't
have a prefix defined after it, the program opens a file dialog to
define it, with the project selected in the GUI (and the path in the
tile bar of the dialog, so the user knows for which project it is).
I also fixed the GUI a bit. Previously I wanted to use nested sizers,
so all controls (which will be added) could be organized and resized
properly. But it seems nesting doesn't always work as you want it to
(the panel for some of the controls didn't want to expand all the way
no matter what I did, so an unfashionable dark grey space remained in
the lower right corner). Yesterday I threw away the nested sizers and
just kept one, so the list expands properly and the control area is
just a single panel without a sizer. It looks ok now, even when
resizing, but I'll probably have to fix it a bit later, when more
controls are added.
I'm planning on modifing the project listbox by adding it some more
information fields about project properties. But that'll come later.
The next job is linking the program with Hugin, so projects can be
edited, but I'm not sure whether I'll complete that in a week, because
I have a two-part exam next week, and I don't know the date of the
second part. But I'll do some work, so if not sooner it'll be
completed in two weeks' time.
Oh yeah, and I completed one exam this week. Yay! :)
Regards,
Marko
Marko Kuder
I've already started work on the link with Hugin, though I haven't
commited any code yet. As I've planned it, I'll just have a thread in
the batch processor, which will poll the project files, if they
changed. If they do change, I'll probably mark them with a * in the
list or something and automatically reload them. Regarding this I have
to make some changes to the current code (which loads the project
files on project execution), because I plan to add some project
properties in the list view, so they'll have to be parsed when loaded.
I don't think we need a spooler with separate files for every project
as was suggested earlier. To make it crash proof, it's probably enough
to have one temp file, which will contain the project list and batch
settings. Hugin's "send to batch" button can just create a similar
temp file which the polling thread will pick up. If someone thinks
this would be a bad idea, you're welcome to correct me. At the moment
I don't know yet how to pass commands between processes in a different
way (a more direct approach could be complex to do for all platforms)
and this solution seems OK.
Regards,
Marko
Bruno Postle
>
>I don't think we need a spooler with separate files for every project
>as was suggested earlier. To make it crash proof, it's probably enough
>to have one temp file, which will contain the project list and batch
>settings. Hugin's "send to batch" button can just create a similar
>temp file which the polling thread will pick up. If someone thinks
>this would be a bad idea, you're welcome to correct me.
It's ok so long as you don't have two processes trying to write to
the same file at the same time. You can't rely on any file-locking
system working on all platforms.
--
Bruno
Marko Kuder
open a selected project in Hugin. Hugin's "send to batch" button also
works and saves the project before sending it. The batch processor
adds it to the list and asks for the output prefix.
The processor opens the project in Hugin via a simple command
execution and gets the project sent from Hugin in the form of
temporary files (current syntax ~ptb#), which contain the project
path. They are exchanged in the default temp dir. The processor has a
background thread which once per second checks for new files and adds
projects (while locking a mutex). After reading a file, it deletes it.
The next plan:
- periodic checking of project file dates and times, so we detect if
they change.
- extension of project list with their basic attributes. They'll
have to be parsed on load instead on execution, so I'll have to change
some parts of the code
And today I completed another exam. One more to go...
Cheers,
Marko
Marko Kuder
doesn't cause problems on my side (probably some wxWidgets version issue),
so I'll just have to try different options until it builds for everyone.
The button "edit with Hugin" was not that intuitive, as it opened Hugin
without any projects if none were selected. If the user would have only one
project in the list it would seem like it's not working right, so I added a
dialog box that pops up and asks the user if a selection should have been
made.
I've also added a PanoramaOptions object in the project class that
represents a member of the list and added code that parses scripts on load
and reads the project options. That will be used later when I extend the
listbox.
Not much else this week, as we had an exam yesterday and still have a
project at school to complete by Monday. After that there's just a small
exam on Tuesday, and then I'm free to work on Hugin.
--
Marko
Dale Beams
Debs are located here - http://www.tatteredmoons.org/hugin_svn.html
Writing final output...
exiftool -overwrite_original_in_place -TagsFromFile /storage/photos/drbeams/20080619/dscf6196.jpg -ImageDescription -Make -Model -Artist -WhitePoint -Copyright -GPS:all -DateTimeOriginal -CreateDate -UserComment -ColorSpace -OwnerName -SerialNumber zxcv.tif
Can't locate Image/ExifTool/MakerNotes.pm in @INC (@INC contains: /usr/local/bin/lib /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/share/perl/5.8.8/Image/ExifTool/Exif.pm line 38.
BEGIN failed--compilation aborted at /usr/local/share/perl/5.8.8/Image/ExifTool/Exif.pm line 38.
Compilation failed in require at (eval 1) line 3.
Can't find table Image::ExifTool::Exif::Main
Error while attempting to call Image::ExifTool::SetNewValuesFromFile
Can't locate Image/ExifTool/Fixup.pm in @INC (@INC contains: /usr/local/bin/lib /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/share/perl/5.8.8/Image/ExifTool/Writer.pl line 18.
BEGIN failed--compilation aborted at /usr/local/share/perl/5.8.8/Image/ExifTool/Writer.pl line 18.
Compilation failed in require at (eval 2) line 1.
make: *** [zxcv.tif] Error 2
Windows Live Hotmail is giving away Zunes. Enter for your chance to win. Enter Now!
Dale Beams
Don't get caught with egg on your face. Play chicktionary!
Bruno Postle
>
>Can't locate Image/ExifTool/MakerNotes.pm in @INC (@INC contains: /usr/local/bin/lib /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/local/share/perl/5.8.8/Image/ExifTool/Exif.pm line 38.
Your Image::ExifTool installation is broken, possibly you have an
ubuntu exiftool package and a manually installed version
conflicting.
--
Bruno
Dale Beams
===========================
** Exif.pm
35 use vars qw($VERSION $AUTOLOAD @formatSize @formatName %formatNumber
36 %lightSource %compression %photometricInterpretation %orientation);
37 use Image::ExifTool qw(:DataAccess :Utils);
38 use Image::ExifTool::MakerNotes;
$VERSION = '2.61';
===========================
> Date: Tue, 1 Jul 2008 21:53:07 +0100
> From: br...@postle.net
> To: hugi...@googlegroups.com
> Subject: [hugin-ptx] Re: [hugin-ptx]
Dale Beams
I'm using checkinstall to build the *.deb. Upon the first checkinstall build using the options --strip=no --stripso=no --addso=yes, i am getting this as a directory output. You'll notice the missing MakerNotes.pm.
/usr/local/share/perl/5.8.8/Image/ExifTool$ ls -a
. Exif.pm ICC_Profile.pm Minolta.pm Photoshop.pm TagLookup.pm WriteExif.pl WritePDF.pl WriteXMP.pl
.. GeoTiff.pm IPTC.pm PDF.pm PostScript.pm TagNames.pod WriteIPTC.pl Writer.pl XMP.pm
If I run checkinstall the second time with the same options, I get as a directory listing:
/usr/local/share/perl/5.8.8/Image/ExifTool$ ls
AFCP.pm BMP.pm Casio.pm Flash.pm HtmlDump.pm JVC.pm MIEUnits.pod NikonCapture.pm PICT.pm Real.pm Sigma.pm WritePhotoshop.pl
AIFF.pm BuildTagLookup.pm DICOM.pm FotoStation.pm HTML.pm Kodak.pm MIFF.pm Nikon.pm PNG.pm Ricoh.pm SigmaRaw.pm WritePNG.pl
APE.pm CanonCustom.pm DNG.pm FujiFilm.pm ID3.pm KyoceraRaw.pm MinoltaRaw.pm Olympus.pm PPM.pm RIFF.pm Sony.pm WritePostScript.pl
APP12.pm Canon.pm Fixup.pm GIF.pm ITC.pm Leaf.pm MNG.pm Panasonic.pm PrintIM.pm Sanyo.pm Unknown.pm
ASF.pm CanonRaw.pm FLAC.pm GPS.pm Jpeg2000.pm MakerNotes.pm MPC.pm Pentax.pm QuickTime.pm Shift.pl Vorbis.pm
BigTIFF.pm CanonVRD.pm FlashPix.pm HP.pm JPEG.pm MIE.pm MPEG.pm PhotoMechanic.pm README Shortcuts.pm WriteCanonRaw.pl
When I try to run it, I get
~/Image-ExifTool-7.34$ exiftool
bash: /usr/local/bin/exiftool: No such file or directory
I noticed that when I ran got the following output
~/Image-ExifTool-7.34$ perl Makefile.PL
WARNING: LICENSE is not a known parameter.
Checking if your kit is complete...
Looks good
'LICENSE' is not a known MakeMaker parameter name.
Writing Makefile for Image::ExifTool
For the time being, I'm going to copy each checkinstall output into a tar or zip file and then unzip on my local machine. This will let me move foward.
From: drb...@hotmail.com
Bruno Postle
>
>** When I look in /usr/local/share/perl/5.8.8, I don't find
>MakerNotes.pm at line 38 in Exif.pm. If
>I check adept manager for exif, you'll notice I only have image-exif
>installed. http://www.tatteredmoons.org/snapshots/snapshot1.png What am I doing wrong?
It looks like the image-exiftool package you built with checkinstall
is messed up, try removing it and installing the
libimage-exiftool-perl ubuntu package listed a bit further down.
--
Bruno
Dale Beams
Copying the contents of both checkinstall runs into a tar.gz file and then copying that to the proper directory /usr/local/share/perl/5.8.8/Image/ExifTool worked. Hugin is now running agian with the latest Image ExifTool 7.3.4
Marko Kuder
This week I've completed the switch to the multi-column project list,
as I promised. Currently, the additional columns are:
- output prefix
- last date and time of modification (which is important if we edited
the project while in the list)
- output extension
- output format (maybe I should join this with the previous column by
adding it in parentheses)
- projection type
- output image size
I can add more and I plan to (whatever is in the PanoramaOptions
class), and you can suggest anything you would like to see here. Maybe
I'll put the choices in program options, so the user can customize to
his preference.
I also added modification time checking in the polling thread (modDate
is now part of the Project class) and the items in the project list
box are automatically refreshed with new options as they change.
If the project file goes missing for some reason the program blanks
the line and writes out "Project missing", but that's not really
robust enough yet, so I'll have to fix that in the near future. I'll
also add move-up and move-down buttons for batch list editing.
Mid-term evaluations are coming and I would like to get rid of the
current problems and bugs by then, so my main concern now is for the
program to work on all platforms. Has anyone tried it on Linux and the
Mac? Regarding this I would like it if you could supply me with any
information on problems and necessary adjustments between platforms. I
saw some ifdefs for the Mac in Hugin's code, but I don't know all of
the specifics, so any help would be appreciated.
--
Marko
Zoran Mesec
I've compiled it on Ubuntu - it works like on windows. Next to other
things this two bugs are most noticable:
- File -> Add project does nothing
- Edit with hugin button opens blank hugin on windows and does nothing
on linux
cheers,
Zoran
Marko Kuder
instructions to the list between projects, so you can run scripts and
such. I've also changed the prefix system, so now they are
automatically set to the default value of the project name (the user
can still change them with the push of a button).
With some bugs fixed besides that, it is sadly all I've done this
week, because my hard drive got corrupted by a faulty PSU and I tried
to save the data that wasn't lost. It takes some time when you haven't
got an OS anymore :s. I'm still in the testing phase whether the disk
is still OK, but after two days in a different computer it seems to be
fine. I'll move it to the previous computer (but with a new PSU) today
to see if the motherboard also survived. Fingers crossed...
On Jul 16, 2:12 am, Zoran Mesec <zoran.me...@gmail.com> wrote:
> I've compiled it on Ubuntu - it works like on windows. Next to other
> things this two bugs are most noticable:
> - File -> Add project does nothing
> - Edit with hugin button opens blank hugin on windows and does nothing
> on linux
Zoran Mesec
Thanks Marko for the update.
Batch processor GUI needs new icons. I would like to ask people on
this list if it is ok to use tango project icons. Where do hugin icons
originate from?
We need icons for:
Play|Stop|Pause batch process
Add project
Clear finished projects
...
Is anyone still reading this loooooong thread?
cheers,
Zoran Mesec
Bruno Postle
>
>Batch processor GUI needs new icons. I would like to ask people on
>this list if it is ok to use tango project icons. Where do hugin icons
>originate from?
Pablo drew them.
Yes you should use tango icons, it would be nice to have the rest of
hugin 'tangoified'.
>Is anyone still reading this loooooong thread?
Yep.
--
Bruno
luca vascon
prokoudine
> Hi all!
>
> Thanks Marko for the update.
>
> Batch processor GUI needs new icons. I would like to ask people on
> this list if it is ok to use tango project icons.
Besides, they are changing the license of the core set of icons now
http://lists.freedesktop.org/archives/tango-artists/2008-July/001822.html
Alexandre
Marko Kuder
Reporting, just so you know I'm still on the job :). Do you know
anything about the fact that hugin_stitch_project outputs exclusively
tiff files? I thought I saw a discussion about this once, but I can't
seem to find it. If you have any info on the subject it would be
appreciated, otherwise I'll dig into Hugin's code to see how it's made
in the main application, where it doesn't have this problem.
Otherwise, I've added an icon toolbar (with the air of Tango) and done
quite a lot of work on the area of project execution. At the moment
I'm working on the pause function. It's given me some problems,
because you can't kill a process gently on windows and if you
forcefully kill Make, it doesn't always resume as you would want. But
I'll work it out, I'll try to implement it by actually suspending all
child threads/processes, although that'll mean some cross-platform
programming.
Oh, and I should mention that I haven't commited any code lately. I'll
do it as soon as I solve the pause problem.
Cheers,
Marko
luca vascon
Marko Kuder
Did you thought about possibility of saving the full batcher's project???So if the machine crashes you do not have to rebuild the batcher settings...
Yeah, that's planned too. At least background autosaving into temp. Saving to file by choice should be easy when that's done.
luca vascon
Will allow FAR less swearing around...
:-)))
Marko Kuder
- pause function finished, works on windows and linux
- added some buttons (reset project, reset all, clear batch) and
icons (add/remove project)
- output extension column fixed
- put the button panel in a sizer, so it should look better
- added "overwrite always" and "shutdown when done" checkboxes
- added send to batch and open batch processor to menu in Hugin
- removing/reseting was buggy while project were running, i'm making
that nice and robust now, it will be commited tommorow
After tommorow's commit I'll start working on the autosave/save to
file part. We should have quite a nice and working program by next
weekend.
--
Marko
Marko Kuder
It's been a while since my last update. Last week my mentor Zoran and
I have come to an agreement that it would be good for our batch
processor (now renamed to a less bloody PTBatcher :) to have a
separate command-line tool and GUI, like some other tools. So I've
taken my time to translate the previous code to two programs,
PTBatcher and PTBatcherGUI, which use a common class Batch for
manipulating the batch list.
The code is better organized now, although some testing is still in
order to fix any uncaught bugs. The code I commited today includes the
new pair of applications and both seem to work fine on Windows, as
much as I tested them, but Linux is still untested. I think Zoran will
take on that mission, as I lost my Linux installation to a hard drive
crash a couple of weeks ago and not used it much anyway. The GUI
version should work identically, only the console part may prove to
need some tuning.
In the last few days of official coding I intend to fix some minor
problems in the application, organize and comment the code and maybe,
depending on time left, add some additional features we had planned,
like an output preview, drag&drop, "silent" mode without output window
for nona&enblend, column customization & others. Whatever doesn't get
done now, I'll do later outside of GSOC. After the 18th I'll take a
bit of a break (I haven't had a real holiday this year yet), so I
don't really plan on coding in late August (except if we'll do the
transfer to the main branch or if some nasty bugs show up, I'll be
checking the mails), but you can count on me returning later. Even
though GSOC hasn't finished yet, I'll say it's been a great
experience.
Cheers,
Marko
Bruno Postle
>
>The code is better organized now, although some testing is still in
>order to fix any uncaught bugs. The code I commited today includes the
>new pair of applications and both seem to work fine on Windows, as
>much as I tested them, but Linux is still untested. I think Zoran will
>take on that mission, as I lost my Linux installation to a hard drive
>crash a couple of weeks ago and not used it much anyway.
I compiled it on Linux a few days ago, but probably won't get a
chance to do any testing until next week or more likely the week
after.
In general, the Summer of Code 2008 branches all compile and install
exactly the same as normal hugin SVN (except sky identification
which is a separate command-line tool called celeste) - In fact they
are all ready right now for use with real panorama projects.
It would be nice to have some more user feedback since the projects
all come to an end this weekend, screenshots (video for the opengl
preview) would be great too.
--
Bruno
luca vascon
Yuval Levy
> In general, the Summer of Code 2008 branches all compile and install
> exactly the same as normal hugin SVN (except sky identification
> which is a separate command-line tool called celeste)
in Linux. I still experience some difficulties in Windows with celeste
and with the changes to wxWidgets necessary for the new opengl preview.
> - In fact they
> are all ready right now for use with real panorama projects.
the preview window is way cool! kudos to James.
Celeste works well with some images, but I have issues with fisheye
images. I suspect we'll need to train it for different kind of lenses.
But with the kind of images it was trained for, it works very well.
I have not had time to try the other projects yet.
> It would be nice to have some more user feedback since the projects
> all come to an end this weekend, screenshots (video for the opengl
> preview) would be great too.
No, the projects don't come to an end. Google's Summer of Code does. The
requirements for the students to be awarded Nodal Ninjas are slightly
more stringent than those for Google Summer of Code - namely:
integration of their code in hugin's trunk and in the Cmake build system.
Beyond that, students are encouraged to stay around and to continue
their positive contribution to the community. They have shown amazing
passion and immense talent. And they are now acquainted with the code
base and with the community. Things won't be as fast as they've been
through the summer when they were working full time, but I really hope
to see further progress as the projects still have a lot of potential to
be developed further.
Kudos, students!
Yuv