Bruno Postle | 1 Nov 2010 01:02
X-Face

Re: Where to place feature requests?

On Sun 31-Oct-2010 at 14:20 -0700, Eric O'Brien wrote:

> Well, this is an interesting point.  I also shoot the horizon row 
> first, then the zenith, then the nadirs.  That is, I don't proceed 
> top to bottom or bottom to top but shoot the middle row, the top 
> "row" and then the bottom "row."
> 
> For me, the assumption that "pictures that are next to each other 
> in the shooting sequence are also next to each other in the 
> panorama." will be incorrect.

The multi-row option is more sophisticated than this, matching 
consecutive images is only the first step in the process.  It is 
able to deal with rows or columns in any order.

> On the other hand, if I (we) are shooting a sequence that is 
> standard for us, it seems that using a Template would work.  Apply 
> the template would distribute the images in close to the correct 
> locations on the sphere.  Then the trick would be to get the 
> control point generators to generate points only between adjacent 
> images.

Yes you can do this in Hugin currently, use an existing project as a 
template with the File -> Apply Template function, then use a 
'prealigned panorama' control point detector preset.

This is definitely the most efficient way to align multiple 
panoramas taken with the same setup.

Sorry, we are really suffering from a lack of documentation 
(Continue reading)

Bernd Hohmann | 1 Nov 2010 01:08
Picon

Re: Where to place feature requests?

On 01.11.2010 01:02, Bruno Postle wrote:

> The multi-row option is more sophisticated than this, matching
> consecutive images is only the first step in the process.  It is
> able to deal with rows or columns in any order.

Sure? I'd seen a process like 1,2 2,3 1,3 but nothing beyond this.

Bernd

--

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

Eric O'Brien | 1 Nov 2010 06:20

Re: Where to place feature requests?

Hey Yuval...

I appreciate you technical contributions to the project but I've grown  
quite weary of your impatience and short temper with people who, even  
slightly, might disagree with you or perhaps write something that  
turns out not to be completely precise.

You often seem to work hard at MIS-understanding people's intentions  
and quickly take offense at perceived slights.  Why so sensitive?

Maybe some of your time would be better spent studying mediation or  
taking an anger management class.  I mean, you bother to work up some  
outrage about top or bottom posting??  How tiresome.  Go outside for  
some fresh air.  Practice your breathing exercises.

eo

On Oct 31, 2010, at 3:23 PM, Yuval Levy wrote:

> On October 31, 2010 06:11:13 pm Eric O'Brien wrote:
>> I will say that I think a slightly more tolerant original response on
>> Yuval's part could have avoided an escalation.  :(
>
> here [0] is my original response.  Would you please be so kind and  
> point me to
> which part of it is not tolerant enough to your taste?
>
> Yuv (being way to tolerant of your bad habit of top posting [1])
>
> [0] http://groups.google.com/group/hugin-ptx/msg/8a23f6f8a238c5e2
(Continue reading)

Eric O'Brien | 1 Nov 2010 06:34

Re: Where to place feature requests?

On Oct 31, 2010, at 5:02 PM, Bruno Postle wrote:

> On Sun 31-Oct-2010 at 14:20 -0700, Eric O'Brien wrote:
>
>> Well, this is an interesting point.  I also shoot the horizon row  
>> first, then the zenith, then the nadirs.  That is, I don't proceed  
>> top to bottom or bottom to top but shoot the middle row, the top  
>> "row" and then the bottom "row."
>> For me, the assumption that "pictures that are next to each other  
>> in the shooting sequence are also next to each other in the  
>> panorama." will be incorrect.
>
> The multi-row option is more sophisticated than this, matching  
> consecutive images is only the first step in the process.  It is  
> able to deal with rows or columns in any order.

Does this require using a pre-aligned panorama (as below), or is it  
expected to succeed with images in the project in any order and all  
beginning placed at 0, 0, 0?

>
>> On the other hand, if I (we) are shooting a sequence that is  
>> standard for us, it seems that using a Template would work.  Apply  
>> the template would distribute the images in close to the correct  
>> locations on the sphere.  Then the trick would be to get the  
>> control point generators to generate points only between adjacent  
>> images.
>
> Yes you can do this in Hugin currently, use an existing project as a  
> template with the File -> Apply Template function, then use a  
(Continue reading)

Tom Sharpless | 1 Nov 2010 14:32
Picon

Re: View this page "Affine SIFT algorith"

Hi Bernd

On Oct 31, 7:02 am, Bernd Hohmann <hohm... <at> harddiskcafe.de> wrote:
> On 31.10.2010 03:14, Tom Sharpless wrote:
>
> Tom,
>
> > It is a fact that SIFT does not find as many matches as we would like
> > in wide angle and especially fisheye images.  But that problem will
> > not be solved by better matching of affine transformations, as it is
> > due to image deformations, characteristic of those lenses, that are
> > not affine transformations.
>
> As far as I can see, ASIFT is doing its job very well even with fisheye
> images and without calibration data.
>
That is surprising to me.  As I understand the description of ASIFT
(which is not very well) it assumes that the source images are in
rectilinear projection.  I do agree with Morel and Yu's idea that
simulating rotations of the direction of view should improve local
similarity measured at true match points.  However the results of that
rotation do depend on the lens projection function, so I would not
expect such a good result when the wrong lens function is used.
However, the results should speak for themselves.

In panoramic image sets, the images are in fact related by pure
rotations of the view direction (leaving aside parallax errors).
Therefore, if lens distortion is corrected, the Morel/Yu procedure
should generate locally almost identical images, when the chosen
rotations happen to equal the true ones.  By using the approximate
(Continue reading)

john doe | 1 Nov 2010 14:36
Picon

Re: Re: View this page "Affine SIFT algorith"

so, it would be an interesting thing to create  a template.pto before, and include it in the ASIFT source code, and see what happens??

On Mon, Nov 1, 2010 at 9:02 AM, Tom Sharpless <tksharpless <at> gmail.com> wrote:
Hi Bernd

On Oct 31, 7:02 am, Bernd Hohmann <hohm... <at> harddiskcafe.de> wrote:
> On 31.10.2010 03:14, Tom Sharpless wrote:
>
> Tom,
>
> > It is a fact that SIFT does not find as many matches as we would like
> > in wide angle and especially fisheye images.  But that problem will
> > not be solved by better matching of affine transformations, as it is
> > due to image deformations, characteristic of those lenses, that are
> > not affine transformations.
>
> As far as I can see, ASIFT is doing its job very well even with fisheye
> images and without calibration data.
>
That is surprising to me.  As I understand the description of ASIFT
(which is not very well) it assumes that the source images are in
rectilinear projection.  I do agree with Morel and Yu's idea that
simulating rotations of the direction of view should improve local
similarity measured at true match points.  However the results of that
rotation do depend on the lens projection function, so I would not
expect such a good result when the wrong lens function is used.
However, the results should speak for themselves.

In panoramic image sets, the images are in fact related by pure
rotations of the view direction (leaving aside parallax errors).
Therefore, if lens distortion is corrected, the Morel/Yu procedure
should generate locally almost identical images, when the chosen
rotations happen to equal the true ones.  By using the approximate
alignment angles from a "shooting template", it should be possible to
limit the range of angles that needs to be searched; and of course
also to limit the image areas that need to be searched.   This could
lead to a rather fast alignment algorithm.

Regards, Tom

> Bernd
>
> --
> Bernd Hohmann
> Dipl. Organisationsprogrammierer
> DV Sachverständiger & Gutachter
> Höhenstrasse 2 * 61130 Nidderau
> Telefon: 06187/900495 * Telefax: 06187/900493
> Blog:http://blog.harddiskcafe.de

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

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

Re: Re: View this page "Affine SIFT algorith"

On 01.11.2010 14:32, Tom Sharpless wrote:

Tom,

>>  As far as I can see, ASIFT is doing its job very well even with fisheye
>>  images and without calibration data.
>>
> That is surprising to me.  As I understand the description of ASIFT
> (which is not very well) it assumes that the source images are in
> rectilinear projection.

I don't think that the projection of the original images does matter 
because the algorithm bend and distort them in all directions.

> However, the results should speak for themselves.

Indeed.

I created a testcase: 8 fisheye shots, all of them "shots from the hip".

All the cp finders included in hugin went wrong, ASIFT created enouth 
good points so that all images were almost in the right position.

On images with high detail (for example my shots of an ancient lime rock 
mine), the algorithm gets painful slow. About 90 seconds for generating 
the keypoints and about 20-25 minutes for matching.

Bernd

--

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

john doe | 1 Nov 2010 16:49
Picon

Re: Re: View this page "Affine SIFT algorith"

maybe its because the algorith isnt written for high detail pics, so it might work with 640*480 resolution images or 800*600...

On Mon, Nov 1, 2010 at 10:48 AM, Bernd Hohmann <hohmann <at> harddiskcafe.de> wrote:
On 01.11.2010 14:32, Tom Sharpless wrote:

Tom,


 As far as I can see, ASIFT is doing its job very well even with fisheye
 images and without calibration data.

That is surprising to me.  As I understand the description of ASIFT
(which is not very well) it assumes that the source images are in
rectilinear projection.

I don't think that the projection of the original images does matter because the algorithm bend and distort them in all directions.


However, the results should speak for themselves.

Indeed.

I created a testcase: 8 fisheye shots, all of them "shots from the hip".

All the cp finders included in hugin went wrong, ASIFT created enouth good points so that all images were almost in the right position.

On images with high detail (for example my shots of an ancient lime rock mine), the algorithm gets painful slow. About 90 seconds for generating the keypoints and about 20-25 minutes for matching.

Bernd


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

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

Re: Re: View this page "Affine SIFT algorith"

On 01.11.2010 16:49, john doe wrote:

> maybe its because the algorith isnt written for high detail pics, so it
> might work with 640*480 resolution images or 800*600...

It works perfectly with high resolution images, its a matter of the 
number of contrast changes (or so). I guess a fine checkerboard pattern 
will drive it crazy :-)

demo_ASIFT rescales to 800*600 internally.

Bernd

--

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

john doe | 1 Nov 2010 18:06
Picon

Re: Re: View this page "Affine SIFT algorith"

ok im out for now, im going to check out some avidemux code...i think hugin can use some part of it and FFMPEG to read videos to convert them to diffrent projections and do video stitching...i opened a thread on this, havent seen any replies..

On Mon, Nov 1, 2010 at 11:43 AM, Bernd Hohmann <hohmann <at> harddiskcafe.de> wrote:
On 01.11.2010 16:49, john doe wrote:

maybe its because the algorith isnt written for high detail pics, so it
might work with 640*480 resolution images or 800*600...

It works perfectly with high resolution images, its a matter of the number of contrast changes (or so). I guess a fine checkerboard pattern will drive it crazy :-)

demo_ASIFT rescales to 800*600 internally.


Bernd

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

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

Gmane