Panomatic

[Nicolas Pelletier]

Hi,

Many questions about panomatic (btw, still targetting to setup and help on windows, but this itched a little more)

First, is there a reason that the panomatic project on SF has files but no source?

Second, if I don't want to get into trouble with patent... where is the limit?

- Publishing the source?

- Contributing a new version?

- Uploading\encouraging people to use it?

I'm asking because I was limited on the 32 bit version because of the memory limit (only 1 or 2 thread running) so I recompiled a 64 bit version. I'm all for sharing, but don't want any trouble.

As I'm testing the result, I'm hitting one problem. My benchmarks are running, but here is the preliminary:

DL version (binary for windows) runs a test in 350 seconds

Compiled 32 version (in release, fully optimized) runs the same test in 895 seconds.

This is baffling me. Anybody has any clue? Does the source actually match what was used to build it? (I may have done a dumb mistake, worked on this instead of sleeping... but I typically know what I'm doing with code...)

These results are king of killing the purpose of building a faster version... If the original is still 2-3 times faster, tough to beat!

Also, this is more technical, but here we go.

Panomatic seems to have 2 phases in the same way that Sift does; 1st find control points. 2nd, match points between images and purge everything else.

In Panomatic, the 2nd phase is awfully long, taking over 90% of the processing time. It seems that one major difference between sift and surf in their classic impementation is that in sift, it is done single thread and in one global run, while for surf, it is done per pair of images, multi thread. The pair thing is killing me since I typically shoot 51 images per pano.

Now, the question for the experts. Is that second phase the same\similar\completely different between autopanoSIFT-c and Panomatic? Could the second one be improved with the way the first one was coded?

There you go. Hope this mail is not too long.

nick

[Harry van der Wolf]

Naouel's homepage is at http://aorlinsk2.free.fr/panomatic/

He also has windows binaries there and you can also find the source there. Maybe if you get in direct contact with him you might get your answers.

Harry

2009/11/21 Nicolas Pelletier <nicolas....@gmail.com>

--
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[Nicolas Pelletier]

I'll contact him, but this is where I got the source and the win32 binary for comparison.

nick

[Harry van der Wolf]

2009/11/21 Nicolas Pelletier <nicolas....@gmail.com>

I'll contact him, but this is where I got the source and the win32 binary for comparison.

nick

OK, but you mentioned sourceforge. This is his "private"  address.

Harry

[Nicolas Pelletier]

I mentioned sourceforge because if I get the 64 bit running properly, there is no place to upload the changes if the source code is not going to be kept there.

But I'll contact him directly for the important questions.

nick

--

[Nicolas Pelletier]

For anyone interested, found the problem with the version. Mail me if you want the source.

nick

[Tom Sharpless]

Hi Nicolas

On Nov 20, 10:18 pm, Nicolas Pelletier <nicolas.pellet...@gmail.com>
wrote:

I last looked at Panomatic about a year ago, so my opinion may be
stale or faulty, but I seem to recall that the interest point matching
phase tried every pair of images as a separate operation. That would
lead to a big slowdown as the number of images increases, because the
number of pairs grows as the square of the number of images. Autopano-
sift-c, on the other hand, matches each image once against a pool of
all interest points. So the slowdown factor is much smaller, but the
memory requirement is much bigger.

Neither approach is optimal. The right way to handle big image sets
would be to use prior knowledge of how they are layed out -- the
photographer almost always knows that -- to limit pairwise matching
just to the pairs that have some chance of overlapping.

It would not be hard to change Panomatic to do pooled matching. That
would make it faster than autopano-sift-c, since it finds interest
points considerably faster. I almost did that back when I was working
on APSCpp, but was not sure about Anael's feelings about foreign
branches, so I didn't.

Also, being a perfectionist, I really wanted to wait until we were in
a position to do layout-based matching, that is, until Hugin (or any
other front end, for that matter) was able to routinely capture
nominal image positions and pass those to the CP finder. I am not
sure if that day has arrived yet, but if it has, it would be good if
someone would add layout-based matching to Panomatic and APSCpp both.

Regards, Tom
>
> nick

[Nicolas Pelletier]

Thanks Tom, I appreciate your input.

Pair matching with prior knowledge would be something nice I agree, as the global pooling method.

I typically send 51 images to the CP finder, so this phase is pretty long. At least now I can run 4 threads at full speed.

Again, thanks,

nick

[Oskar Sander]

I agree it would be good to limit the search between relevan groups of images, When I tested the layoutbranch when that was requested from the community at the beginning of October. I had some CP issues in my projects then, and I was thinking along you lines too.

I used APSCpp and I manually selected relevant groups of adjacent images to search between in a project of in total 50 images.  the images were very difficult with low contrast and near monochrome features.

Interestingly enough the groups of images I selected did seem to matter for the resulting CP found. Different (more) CPs were found if I selected a subset rather than the whole project.

Unfortunately I could not understand the pattern enough to file a bug report (And I don't know where to file it for APSCpp and to whom)

My thinking is that, either it is a bug in the pairing that throws the search off if the search space gets too big. OR there may be an adaptive threshold of required match in order to deem a valid pair and the threshold gets different depending on the image and feature points set.

So with these images that are difficult, I think it would be possible to make a less discriminate feature search based on the layout of the pictures. In the end I have not managed to complete this project as automatic CP detection only worked for say 20% of all overlaps.

Cheers

2009/11/27 Tom Sharpless <tksha...@gmail.com>

Neither approach is optimal.  The right way to handle big image sets
would be to use prior knowledge of how they are layed out -- the
photographer almost always knows that -- to limit pairwise matching
just to the pairs that have some chance of overlapping.

It would not be hard to change Panomatic to do pooled matching.  That
would make it faster than autopano-sift-c, since it finds interest
points considerably faster.  I almost did that back when I was working
on APSCpp, but was not sure about Anael's feelings about foreign
branches, so I didn't.

Also, being a perfectionist, I really wanted to wait until we were in
a position to do layout-based matching, that is, until Hugin (or any
other front end, for that matter) was able to routinely capture
nominal image positions and pass those to the CP finder.  I am not
sure if that day has arrived yet, but if it has, it would be good if
someone would add layout-based matching to Panomatic and APSCpp both.

--
/O

[Battle]

Hi all,
I've been lurking for a while, and this is my first post.

I frequently do large panoramas with 50 to 150 or more images - see
www.manassasconsulting.com for sample images most of which were
completed with hugin.

The idea of CP pair matching with prior knowledge of the image order
and overlap would be of tremendous value to me. There is of course
more than one way to skin a cat. There are at least two ways I can
think or about approaching the problem or reducing pair matching
search and processing time. In addition to loading the photos in a
sort of viewable checkerboard grid where the number of rows and
columns are specified such as seen in the gigapan.org stitcher (I can
post a screen dump if needed) we can also generate prior knowledge by
using sub projects where we choose what photos are loaded in each sub
project. So, there is the possibility of running multiple sub
projects and merging them. For example, the idea of loading each
column of photos as a subproject, processing sub projects and then
merging would also reduce processing time. As I understand it there
are command line tools for merging multiple projects so this might be
an option to pursue as well.

I haven't done much progamming since I was working basic in binary
with dip switches on a Digital PDP8 except for a bit of java and ajax
here and there. However I would be happy and willing to engage in
assisting others who want to work on this issue by helping to define
needs, features, testing, etc... I am comfortable with terminal and
command line language.

Battle

[Bruno Postle]

On Sat 28-Nov-2009 at 08:21 -0800, Battle wrote:
>I've been lurking for a while, and this is my first post.
>
>I frequently do large panoramas with 50 to 150 or more images - see
>www.manassasconsulting.com for sample images most of which were
>completed with hugin.
>
>The idea of CP pair matching with prior knowledge of the image order
>and overlap would be of tremendous value to me.

I think the way to do this is clear-ish, we currently have two ways
of calling a control point generator from Hugin:

1. Passing a list of photos to the tool, then reading control points
from an outputed .pto project.

2. Creating a temporary .pto project specifying all the image file
names, projections and lens distortion, then using that as input for
the control point generator (only autopano-sift-c supports this
interface at the moment).

This second method is much richer and clearly will allow
specification of approximate relative image positions as well as
stacks (which require a different control point strategy).

It isn't clear what the Hugin GUI for specifying the approximate
positions would look like, James wanted to tackle this with his
layout summer of code project but other things were done instead.

One of the issues we had is that the only real application where
users would want to shoot with regular numbers of rows and columns
is a 'gigapixel' or very high resolution panorama - If you are
shooting a spherical panorama like this then you are doing it wrong.
Everyone else is shooting in a way that doesn't guarantee regular
intervals, either handheld or on a tripod without 'click-stops'.

So it seems that these users who are shooting high resolution 'grid'
panoramas would be well served by a template system - A template
system would be useful for spherical panoramas too.

Photos can be dragged around in the fast preview window, so maybe
the question is how can this manual 'arranging' be improved so that
it scales to hundreds of photos, and how can the existing templating
system be improved?

--
Bruno

[Ryan]

On Nov 30, 1:17 am, Bruno Postle <br...@postle.net> wrote:
> Photos can be dragged around in the fast preview window, so maybe
> the question is how can this manual 'arranging' be improved so that
> it scales to hundreds of photos, and how can the existing templating
> system be improved?

I have to admit I've never tried to stitch much more than a dozen
photos, but even that size exposes the current scalability problems.
Some things I can think of are:

1. Have [an option to make] the preview pane scatter the images in a
grid rather than all on top of each other. I usually have to move each
image twice: once to get them all out where I can see them, and then
actually put them in place. In 1D stitch this would do most of the
work (how often does anyone shoot out of order?) and for a 2D stitch
see the next point...

2. Ability to select groups of photos and move them around. Even
better would be groups of photos which act like a single entity for
move/show/hide purposes, but which can be "entered" to allow
individual movement ala ppt 2007. Right now you can "group" photos by
joining them with control points, but that's backwards (you want to
position them in order to find those control points...) and inflexible
(you can't move them separately any more after they are joined).

Ryan

[dex Otaku]

I second the interest if not the programming skills.

I'm approximating a fairly uniform spherical shot-pattern manually
[usually ~48 shots] with a panosaurus head, and have been trying out
different P&S cameras.

The majority of my time making these is spent manually CP tuning to
compensate for a lack of lens calibration profiles. Having even an
approximately template to start from might cut some of the time
accurate CP matching takes.

But alas, I am merely a user.

[Dale Beams]

Having a layout would help immensely weather it was uniform or not.  I always shoot from left to right, bottom to top.  I to have a panosaurus head (recently purchased) and it does wonderfully when i can get Hugin to work.  My biggest headaches in Hugin is turning photos because (i've been told, mismatched cp).  It's such a headache i've abandoned auto CP finding almost entirely and went to manual location.  However with layout and turning restrictions while the pano might still have bad CP at least you could assume to be in the ballpark.

On a side note, watching the list and seeing all the ideas, I've wondered if Hugin's original goal has been discarded in favor of new features.  While I think stacking, etc. and a large assortment of photo manipulations is great, shouldn't Hugin do "great" what it originally was intentioned on doing?

This brings me to my conclusion.  If Hugin were to again focus on it's original intention, a very good pano stitcher and layout program, wouldn't we need a new algorithm for a completely free and oss CP finder program?  I'd like to see Hugin ditch sift and surf for something oss and gpl, and something that worked well.

Dale


> Date: Mon, 30 Nov 2009 03:09:20 -0800
> Subject: [hugin-ptx] Re: CP Pair Matching with Prior Knowledge, was Re: Panomatic
> From: dexo...@gmail.com
> To: hugi...@googlegroups.com

> --
> You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx

---

Bing brings you maps, menus, and reviews organized in one place. Try it now.

[Bruno Postle]

On Mon 30-Nov-2009 at 03:09 -0800, dex Otaku wrote:
>
>I'm approximating a fairly uniform spherical shot-pattern manually
>[usually ~48 shots] with a panosaurus head, and have been trying out
>different P&S cameras.
>
>The majority of my time making these is spent manually CP tuning to
>compensate for a lack of lens calibration profiles. Having even an
>approximately template to start from might cut some of the time
>accurate CP matching takes.

Hugin has a lot of this already, i.e. you can save a lens profile
and reuse it in another project, so next time around you only have
to optimise positions. You can also reuse any project as a
template, so if you often shot panoramas with shots in the same
relative positions these positions don't need to be recreated each
time.

There are lots of things that could be improved: The lens profile
saving/loading needs to switch to using the lensfun library and
database, and maybe there should be a default location to save and
load templates that is separate from the current project directory.

--
Bruno

[Bruno Postle]

On Mon 30-Nov-2009 at 10:30 -0600, Dale Beams wrote:
>
> Having a layout would help immensely weather it was uniform or
> not. I always shoot from left to right, bottom to top. I to have
> a panosaurus head (recently purchased) and it does wonderfully
> when i can get Hugin to work. My biggest headaches in Hugin is
> turning photos because (i've been told, mismatched cp).

The symptom is turned photos, but the cause is a messed-up project.
This sort of thing should be much improved by apclean, if not we
need to discover how to make it better.

> On a side note, watching the list and seeing all the ideas, I've
> wondered if Hugin's original goal has been discarded in favor of
> new features.

Yes there are some features that have been added in a way that
complicated the GUI, but on the whole I think Hugin is as good as
has ever been for the situation where you throw a bunch of handheld
photos at it and click 1, 2, 3.

> While I think stacking, etc. and a large assortment
> of photo manipulations is great, shouldn't Hugin do "great" what
> it originally was intentioned on doing?

I would say yes if the stacking could be done outside of Hugin, but
enfuse is so useful for creating panoramas and in practice you need
a panorama stitcher to align the stacks.

> This brings me to my conclusion. If Hugin were to again focus on
> it's original intention, a very good pano stitcher and layout
> program, wouldn't we need a new algorithm for a completely free
> and oss CP finder program? I'd like to see Hugin ditch sift and
> surf for something oss and gpl, and something that worked well.

Yes, the number one Hugin 'bug' is that it doesn't ship with a
patent-free control point generator.

--
Bruno

[Dale Beams]

Bruno,

What causes a messed up project?  I purchased a pano head to get better panographs, however, i can recall doing panographs by hand prior and with 0.7.x and having better luck in getting a usable pano than i do with precision taken photos with a pano head.  I suppose this is why I recently been so confused.

>
> The symptom is turned photos, but the cause is a messed-up project.
> This sort of thing should be much improved by apclean, if not we
> need to discover how to make it better.
>

[Bruno Postle]

On Mon 30-Nov-2009 at 15:12 -0600, Dale Beams wrote:
>
> What causes a messed up project? I purchased a pano head to get
> better panographs, however, i can recall doing panographs by hand
> prior and with 0.7.x and having better luck in getting a usable
> pano than i do with precision taken photos with a pano head. I
> suppose this is why I recently been so confused.

A panohead doesn't really help the control point generator, the
matching process is the same regardless. Though if you have a
really good panohead, then you can use a previous project as a
template and don't need to bother with control points at all.

The control point generators haven't really changed since 0.7.0 was
released a year ago (except for bug fixes), so I'm suprised that
things are so different - Do you know what control point generator
you were using with 0.7.0?

--
Bruno