360 shot from rectilinear images - hugin doesn't understand?

[aleks...@gmail.com]

I'm using a cybershot dsc-p32 (cheapy point-and-shoot, no fancy
lenses...) to do a full 360 shot of a room. I've got plenty of control
points set up in hugin with a good vertical and horizontal range, and
defined at least 2 vertical lines in each image. However, hugin
doesn't seem to "get" that I want a 360 shot, it kludges the pictures
into a circle as best it can. Am I missing a setting somewhere? none
of the optimizer options seem to work, or the assistant aligner.

here's what I'm getting :

http://flickr.com/photos/sweeperpix/2697615953/

[Ken Warner]

I get that kind of problem sometimes too. Sometimes
the code that generated control points get wacky.

I don't know how to fix it. Recently, with a well
exposed sequence that lacked a definite horizon, some
of the images got rotated. One was inverted 180 degrees.

Baffling...

[Klaus]

On 24 Jul, 11:36, "aleks.cl...@gmail.com" <aleks.cl...@gmail.com>
wrote:

> I'm using a cybershot dsc-p32 (cheapy point-and-shoot, no fancy
> lenses...) to do a full 360 shot of a room.

Have you included the v parameter among those that are optimised?

I presume that h/v CPs are labelled correctly. And you say you got
enough CPs. I find that one needs only few h/v CPs to orient tha pano
in space, maybe a handful, but dozens of standard CPs. But I think
that is not the problem here.

If that fails, try optimising stepwise:
1) Take one of the images out of the optimisation, select (start from
anchor)
2) re-include that image again, optimise with one of the options that
include v.

Good luck

Klaus

P.S. please report back and tell, how you made it work ;-)

[Klaus]

P.P.S. to the experts: could it be, that with lots of vertical lines
and relatively few control points an image can get stuck in the
180degrees orientation, as the vertical lines create a (false) local
minimum and the optimiser only looks locally (i.e. uses a gradient
technique)?

[Pablo d'Angelo]

Hi Klaus,

Klaus schrieb:

Yes.

ciao
Pablo

> >
>

[aleks...@gmail.com]

No go, it does the same thing...without a "join" image, it creates the
long view. With the join image, it tried to arrange the images in a
circle. I could swear it's a setting somewhere, it seems a basic
assumption of hugin about wrapping the images is the problem....or
maybe my fov settings are wrong? I used a tape measure to determine
the fov of a horizontal pic to be about 30 degrees, and ratio is 3:4,
so vertical fov should be about 22.5...is this causing my problem?

[Seb Perez-D]

On Thu, Jul 24, 2008 at 12:36, aleks...@gmail.com
<aleks...@gmail.com> wrote:
>
> http://flickr.com/photos/sweeperpix/2697615953/

Have you optimized the horizontal field of view? my guess is that some
control points show a very large error. You say that you have plenty
of control points, but some pairs of images have a very bad match. can
you check that the control points are properly spaced over the regions
of overlap?

Cheers,

Seb

[Felix Hagemann]

Would you mind putting the pto and the photos somewhere on the web so
we can have a look at it?
This might be the easiest way to check what went wrong here.

Felix

[Klaus]

Hi Aleks,

On 24 Jul, 13:54, "aleks.cl...@gmail.com" <aleks.cl...@gmail.com>
wrote:

> No go, it does the same thing...without a "join" image, it creates the
> long view. With the join image, it tried to arrange the images in a
> circle.

Well, check on CP quality first.

My next approach would be
1) take out one "join" image"
2) put it in again, take out another "join" image
And use (optimising from anchor for 1 and 2 optimisation steps)
==> all images should be on a long view. Maybe there is some
horizontal displacement in between them.

3) put all images into optimisation, choose y,p,r,v in the drop-down
menu. The "v" is important, because that might be somewhat off, and
without optimising it, your pano may end up as 350 oder 370 degrees.
You may notice that during optimisation you read something like
"method 1" and then changing to "method 2".

Good luck

Klaus

[aleks...@gmail.com]

still nothing. any time I optimize with all the photos in there, it
gets put in a circle. same goes for another pan I shot of a REALLY
cluttered area, that has 30 CP's per. I uploaded the original kitchen
project:

http://built-it.net/kitchen.zip

[Seb Perez-D]

On Thu, Jul 24, 2008 at 16:16, aleks...@gmail.com
<aleks...@gmail.com> wrote:
>
> still nothing. any time I optimize with all the photos in there, it
> gets put in a circle. same goes for another pan I shot of a REALLY
> cluttered area, that has 30 CP's per. I uploaded the original kitchen
> project:
>
> http://built-it.net/kitchen.zip

Starting from the CP you used, but resetting all parameters to 0
(position, lens to a default of 50mm, etc.), and erasing the k2
element from the pto file (hugin complained about this one) I could
get a very good panorama. It seems that indeed the optimizer was lost
in a very dark place.

http://www.flickr.com/gp/51035756831@N01/3116L6

I uploaded the pto file here
http://groups.google.com/group/hugin-ptx/web/DSC04621-DSC04635.pto

Image is here http://farm4.static.flickr.com/3148/2698838454_6eebcfac1f_o.jpg

Cheers,

Seb

[Felix Hagemann]

Hi Aleks,

Seb already provided you with a new pto, but I had a go as well, so
here is another one:
http://hugin-ptx.googlegroups.com/web/new_aleks_clark.pto

Some remarks:
Your project contained quite a few horizontal control points. As far
as I know horizontal control points can only designate the horizon
itself in euqirectangular and cylindrical panos. So I deleted them.
Then I ran "Edit->Fine-Tune all Points" and deleted all normal control
points with correlation below 0.8.
And finally there were a couple of control points with high errors
left which turned out to be misplaced and were deleted.

Felix

[aleks...@gmail.com]

Wow, that worked rather well. I was able to reproduce your steps from
my initial project file, and arrive at the same panorama. However,
I've got to ask....what on earth is this k2 factor? I opened the
project file in a text editor and saw it and deleted it manually, but
I'd like to know what this does, where it came from, and why deleting
it fixes things....

The other project I mentioned that has the same problem had "k8" in
it, but deleting that still didn't fix anything.

Felix: thanks for the tips on CP optimization, I've been following
your procedure with some simpler shots, and have really noticed the
difference in quality of results.

Aleks

On Jul 24, 9:46 am, "Seb Perez-D" <sbp...@gmail.com> wrote:
> On Thu, Jul 24, 2008 at 16:16, aleks.cl...@gmail.com

[Felix Hagemann]

2008/7/25 aleks...@gmail.com <aleks...@gmail.com>:

>
> I've got to ask....what on earth is this k2 factor? I opened the
> project file in a text editor and saw it and deleted it manually, but
> I'd like to know what this does, where it came from, and why deleting
> it fixes things....

The k option in the p line of the pto file determines which of the
images is used as an anchor for color and brightness correction. I
don't think that the k option had anything to do with your problem and
that deleting it fixed anything.

The optimizer got stuck in a local minimum probably due to hfov (22.5
instead of 43 degrees) and barrel distortion (-0.5 vs -0.016) values
being way off. What solved the problems was reseting those parameters
and reoptimizing.

Felix

[aleks...@gmail.com]

Ah!

Yea, turns out when I did that thing with the measuring tape, I
calculated the angle of the right triangle, forgot to double it for
the other half...sigh. Anyways, everything seems to be working
properly now.

Question: the fine tuning results prompt talks about "error" in the
CP's, saying that it's bad if the error is <= (cp similarity
preference), and the it references the cp table. the cp table has a
distance column, not an error column. are these equivalent? or does
the cp table column relate to what the optimizer refers to as error?

Aleks

On Jul 25, 6:01 am, "Felix Hagemann" <felix.hagem...@gmail.com> wrote:
> 2008/7/25 aleks.cl...@gmail.com <aleks.cl...@gmail.com>:

[Klaus]

On 25 Jul, 14:34, "aleks.cl...@gmail.com" <aleks.cl...@gmail.com>
wrote:

> Question: the fine tuning results prompt talks about "error" in the
> CP's, saying that it's bad if the error is <= (cp similarity
> preference), and the  it references the cp table. the cp table has a
> distance column, not an error column. are these equivalent? or does
> the cp table column relate to what the optimizer refers to as error?

After "fine-tune all points", the distance column does not contain
distances but the correlation value. That is different from distance
indeed. It goes back to displaying distances after an optimisation.

Cheers
Klaus

[J. Schneider]

Klaus schrieb:

One could say this is a UI issue to be addressed after 0.7.0 - but isn't
it actually a bug if a column heading tells the user there were
different content in the column than there is actually? I'm tempted to
open one. Unfortunately the solution inevitably involves (frozen) strings.

regards
Joachim

[Klaus]

On 25 Jul, 18:24, "J. Schneider" <j-schn...@gmx.de> wrote:
> One could say this is a UI issue to be addressed after 0.7.0 - but isn't
> it actually a bug if a column heading tells the user there were
> different content in the column than there is actually? I'm tempted to
> open one. Unfortunately the solution inevitably involves (frozen) strings.

Yep, if I were you I'd put it in the tracker with a 0.7.1 or a 0.7.x
label (x>0).

Cheers Klaus