Hi,

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

+ an update to all previously written infos:
http://code.google.com/soc/2008/pano/appinfo.html?csaid=ED9B86CD65E6238B
http://wiki.panotools.org/SoC_2008_student_proposals#Marko_Kuder.2C_B...
http://wiki.panotools.org/SoC2007_project_Batch_Processing

regards,
Zoran

Marko Kuder pravi:

On Mon 05-May-2008 at 08:33 -0700, Marko Kuder wrote:

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...

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

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

That is basically what I envisioned too.
 - 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

Thanks for the feedback, I see we have quite a few things still to
determine.

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?

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.

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?

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.

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.

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

Now that I have a duel core I don't much care.  But when I had just one
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

On Fri 09-May-2008 at 01:50 +0200, Marko Kuder wrote:

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.

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

On Thu 08-May-2008 at 11:40 -0400, Yuval Levy wrote:

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

On Sat 10-May-2008 at 00:19 +0100, Bruno Postle wrote:

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

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