[hugin-ptx] Linear Panorama (Photo Mosaic), new workflow X,Y,Z?

[Jasper Aorangi]

Good day All,
There seems to have been some big developments for Linear panoramas lately,
as such the great advice Bruno has been dishing up for such projects pre
X,Y,Z may be superseded (I think)
But the panotools wiki page on mosaic
(http://wiki.panotools.org/Stiching_a_photo-mosaic) seems to be a stub,
lacking a workflow for uninitiated users such as myself.

Is there a definitive workflow that I can follow (and append to the
aforementioned wiki page)?

Questions in my mind are of the following (and more...):
Do we still need to correct the images with full beforehand, are there any
special arguments to give to the alignment tool (ie pablos panomatic), what
optimizations for which conditions (which preset if at all), etc. dragging
in preview... etc.

Thank you all.
Jasper
--
View this message in context: http://old.nabble.com/Linear-Panorama-%28Photo-Mosaic%29%2C-new-workflow-X%2CY%2CZ--tp28505458p28505458.html
Sent from the hugin ptx mailing list archive at Nabble.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

[Bruno Postle]

On Sun 09-May-2010 at 15:03 -0700, Jasper Aorangi wrote:
>
> But the panotools wiki page on mosaic
>(http://wiki.panotools.org/Stiching_a_photo-mosaic) seems to be a stub,
>lacking a workflow for uninitiated users such as myself.

>Do we still need to correct the images with full beforehand

You can use 'normal' photos with the 'mosaic' mode, there is no need
to pre-process.

>are there any special arguments to give to the alignment tool (ie
>pablos panomatic)

These control point generators generally cope ok with parallax
differences between photos.

>what optimizations for which conditions (which preset if at all),
>etc. dragging in preview... etc.

You need to experiment, the current trunk has been fixed to allow
dragging in mosaic mode.

--
Bruno

[Jasper Aorangi]

Thanks Bruno,
Still a couple of Q's

>>Do we still need to correct the images with full beforehand

>You can use 'normal' photos with the 'mosaic' mode, there is no need
>to pre-process.

I have seen mention this 'mosaic' mode. Is this something I set somewhere
(and where)

>>what optimizations for which conditions (which preset if at all),
>>etc. dragging in preview... etc.

>You need to experiment, the current trunk has been fixed to allow
>dragging in mosaic mode.

>Bruno

I have seen mention that there are some parameters that dont work together
with x,y,z for optimisation, but a bit hazy.

Is it to be taken that 'mosaic' mode is simply normal workflow, but optimize
with x,y,z involved?

To prememt experimentation (optimizer hasnt produced a linear looking thing
yet, so cant ask the q out of experience...) Are the mumors of a limited FOV
still true? (i.e can we go off to infty in either direction)

There also seems to be alot of importance placed on the anchor, or first
image (both pre x,y,z, and current). What understanding can I take from
this? (i.e does it really matter)

Cheers.

--
View this message in context: http://old.nabble.com/Linear-Panorama-%28Photo-Mosaic%29%2C-new-workflow-X%2CY%2CZ--tp28505458p28507290.html

Sent from the hugin ptx mailing list archive at Nabble.com.

[Bruno Postle]

On Sun 09-May-2010 at 20:09 -0700, Jasper Aorangi wrote:
>
>Is it to be taken that 'mosaic' mode is simply normal workflow, but optimize
>with x,y,z involved?

Yes, this is how it should work.

> To prememt experimentation (optimizer hasnt produced a linear looking thing
>yet, so cant ask the q out of experience...) Are the mumors of a limited FOV
>still true? (i.e can we go off to infty in either direction)

It is limited to 180° which is 'infinity' for a rectilinear
projection.

--
Bruno

[Oskar Sander]

Please. expand on the linear panorama stub anyone.  I needed to illustrate for myself how the model works, in order to understand how to optimize and build projects.

A 1, 2 3  how-to would be a very useful additon.

2010/5/11 Bruno Postle <br...@postle.net>

To prememt experimentation (optimizer hasnt produced a linear looking thing
yet, so cant ask the q out of experience...) Are the mumors of a limited FOV
still true? (i.e can we go off to infty in either direction)

It is limited to 180° which is 'infinity' for a rectilinear projection.

However, that's the "panorama camera" limitation, not on the source images.  

It should be possible to get around just by setting a synthetic smaller FOV of each image, shouldn't it?  This will render a smaller scene to be seen by the panorama camera.   When doing a panorama of for instance a mural i would expect that you would like to view it in the end as with the perspective of a normal lens, i.e. 60-50degrees, for not to get any WA distortion.  A ultra wide angle rectilinear could be something below 90deg to put things into perspective.   180deg will be very distorted in the rectilinear projection.


Cheers
O

[Jasper Aorangi]

Oskar Sander wrote:
>
> Please. expand on the linear panorama stub anyone. I needed to illustrate
> for myself how the model works, in order to understand how to optimize and
> build projects.
>
> A 1, 2 3 how-to would be a very useful additon.
>

I was hoping to do this with my positive experience! Hasnt happened yet.
Maybee a differnt subject matter and more time and it will be pos. I would
have thought that the Author would have had all the know how to do this, but
usually wiki/docs are left to the user (Good for us, after all they make all
the goodies, cant expect them to do everything)

> 2010/5/11 Bruno Postle <br...@postle.net>
>
>>
>> To prememt experimentation (optimizer hasnt produced a linear looking
>>> thing
>>> yet, so cant ask the q out of experience...) Are the mumors of a limited
>>> FOV
>>> still true? (i.e can we go off to infty in either direction)
>>>
>>
>> It is limited to 180° which is 'infinity' for a rectilinear projection.
>>
>
> However, that's the "panorama camera" limitation, not on the source
> images.
>
> It should be possible to get around just by setting a synthetic smaller
> FOV
> of each image, shouldn't it? This will render a smaller scene to be seen
> by
> the panorama camera. When doing a panorama of for instance a mural i
> would
> expect that you would like to view it in the end as with the perspective
> of
> a normal lens, i.e. 60-50degrees, for not to get any WA distortion. A
> ultra
> wide angle rectilinear could be something below 90deg to put things into
> perspective. 180deg will be very distorted in the rectilinear
> projection.
>

I hope this nabble quote business works for normal group members.
I have been trying in vain to get useful results, auto control point
generation aside (panomatic only finds points in the cloud, celeste
helpfully removes them.. repeat loop..) I am finding that all my images get
a strange distotion through the middle, like the image is folded over
itself, but this is overlayed over the image... damn annoying. does this
after x,y,z optimisation.

On the panomatic-et.al bandwagon, I have been _trying_ (emp. failing) to
write a script to force panomatic to only connect points in a strip on the
image, and only consider adjacent images. This was ok, using imagemagic to
mask off the bits I dont want, but I cant figure out how to concatenate the
output from panomatic for each pair of images so that hugin can use this.
Any ideas? Is there any builtin functionality for this. (I remember years
ago you could tell hugin that the set was ordered.... glad to see that
dialogue gone... until now.)

Unfortunately the panorama may be doomed, wide angles for linear panos put
too much background info across too many frames. Will be a good experiment
for the new mask tool and enblend 8)

Thanks.

Jasper
--
View this message in context: http://old.nabble.com/Linear-Panorama-%28Photo-Mosaic%29%2C-new-workflow-X%2CY%2CZ--tp28505458p28577583.html

Sent from the hugin ptx mailing list archive at Nabble.com.

[Bruno Postle]

On Sun 16-May-2010 at 14:50 -0700, Jasper Aorangi wrote:
>
> On the panomatic-et.al bandwagon, I have been _trying_ (emp.
> failing) to write a script to force panomatic to only connect
> points in a strip on the image, and only consider adjacent images.
> This was ok, using imagemagic to mask off the bits I dont want,
> but I cant figure out how to concatenate the output from panomatic
> for each pair of images so that hugin can use this. Any ideas? Is
> there any builtin functionality for this.

The Hugin trunk has some new modes for matching projects by only
looking at adjacent images, see the 'multirow panorama' and
'prealigned panorama' control point detector types in the
Preferences window.

There are also 'ptochain' and 'ptofill' in Panotools::Script which
do similar stuff. These use 'ptosplit' and 'ptomerge' to mix .pto
project files (there is now an equivalent 'pto_merge' tool in the
Hugin trunk).

--
Bruno

[Oskar Sander]

Oh I forgot about those, I need to test...

* How about a corresponding CP-search strategy that would use "overlapping" instead of adjacent?  This could use the
layout drag mode to build the structure.


To compare with Adobe's photomerge. 
* In the start the photos are all in a "unused" pane
* You drag the photos onto the canvas
* Once you create a overlap by droping a image so it overlaps onother, PS will automatically try align these (probably search for CP and optimize alignment under the hood)

Cheers

2010/5/17 Bruno Postle <br...@postle.net>

The Hugin trunk has some new modes for matching projects by only looking at adjacent images, see the 'multirow panorama' and 'prealigned panorama' control point detector types in the Preferences window.

--
/O

[Bruno Postle]

On 17 May 2010 09:24, Oskar Sander <oskar....@gmail.com> wrote:
>
> * How about a corresponding CP-search strategy that would use "overlapping"
> instead of adjacent? This could use the
> layout drag mode to build the structure.

This is what the 'prealigned panorama' type does, it compares photo
positions and field-of-view to estimate which pairs of photos overlap.
So you can now work by dragging photos around the preview and using
this as a basis for control point detection.

Thomas recently added more-accurate code for stack-detection that
looks at the actual percentage overlap. This could be repurposed to
improve the 'prealigned panorama' thing.

--
Bruno

[T. Modes]

> On 17 May 2010 09:24, Oskar Sander<oskar....@gmail.com> wrote:
>
>> * How about a corresponding CP-search strategy that would use "overlapping"
>> instead of adjacent? This could use the
>> layout drag mode to build the structure.
>>
> This is what the 'prealigned panorama' type does, it compares photo
> positions and field-of-view to estimate which pairs of photos overlap.
> So you can now work by dragging photos around the preview and using
> this as a basis for control point detection.
>
> Thomas recently added more-accurate code for stack-detection that
> looks at the actual percentage overlap. This could be repurposed to
> improve the 'prealigned panorama' thing.
>

The prealigned panorama setting uses already the modified code. So this
should also work with the translations parameters.

Thomas

[Jasper Aorangi]

Bruno Postle-4 wrote:
>
> On 17 May 2010 09:24, Oskar Sander <oskar....@gmail.com> wrote:
>>
>> * How about a corresponding CP-search strategy that would use
>> "overlapping"
>> instead of adjacent? This could use the
>> layout drag mode to build the structure.
>
> This is what the 'prealigned panorama' type does, it compares photo
> positions and field-of-view to estimate which pairs of photos overlap.
> So you can now work by dragging photos around the preview and using
> this as a basis for control point detection.
>
> Thomas recently added more-accurate code for stack-detection that
> looks at the actual percentage overlap. This could be repurposed to
> improve the 'prealigned panorama' thing.
>

hmm using the prealigned mode made no difference for me. I was still
deleting control points from one end to the other 8)
Now with 145 images, and at least three points for each image pair,
optimizing for x,y,x or x,y,z,r,p still lumps all the images together in one
spot. Obviousley I am expecting them to have a great variance in x, and
slight variance in y and z.
What am I doing wrong? _or_ how can I get what I want from the
optimisation?

you said wrote earlier that there is no need to adjust for barrel distortion
and this was now taken into account, do I need to include a,b,c etc. in the
optimisation as well?

Cheers.

Jasper
--
View this message in context: http://old.nabble.com/Linear-Panorama-%28Photo-Mosaic%29%2C-new-workflow-X%2CY%2CZ--tp28505458p28648571.html

Sent from the hugin ptx mailing list archive at Nabble.com.

[Bruno Postle]

On Sun 23-May-2010 at 03:29 -0700, Jasper Aorangi wrote:
>>
> hmm using the prealigned mode made no difference for me. I was still
>deleting control points from one end to the other 8)
> Now with 145 images, and at least three points for each image pair,
>optimizing for x,y,x or x,y,z,r,p still lumps all the images together in one
>spot.

The prealigned mode is a recipe for generating control points with a
mixture of tools from autopano-sift-C. i.e. it relates to the stage
before optimisation.

>you said wrote earlier that there is no need to adjust for barrel distortion
>and this was now taken into account, do I need to include a,b,c etc. in the
>optimisation as well?

The 'align' button in the Assistant tab will adjust the 'b'
parameter automatically, which is usually sufficient. If you are
using the optimiser tab then you get to pick exactly which
parameters to optimise.

--
Bruno

[Jasper Aorangi]

Bruno Postle wrote:
>
> On Sun 23-May-2010 at 03:29 -0700, Jasper Aorangi wrote:
>>>
>> hmm using the prealigned mode made no difference for me. I was still
>>deleting control points from one end to the other 8)
>> Now with 145 images, and at least three points for each image pair,
>>optimizing for x,y,x or x,y,z,r,p still lumps all the images together in
one
>>spot.
>
> The prealigned mode is a recipe for generating control points with a
> mixture of tools from autopano-sift-C. i.e. it relates to the stage
> before optimisation.
>

I understand where prealigned/control point generation comes in. I was using
it in conjunction with panomatic, and having to call it through a wrapper
script to pass it the file list as per:
http://old.nabble.com/Align-with-lots-of-images%2C-Overcome-td28501969.html#a28501969
Should this have worked better?
Also completed a trial using imagemagic to mask the coloudy bits and the
lower foreground (i.e letterbox 8) did control point detection etc. on three
images at a time, and combining them as you suggested with pto_merge. The
output from this was worse unfortunatley. 57 disconnected regions vs 35 from
hugin.

>
>>you said wrote earlier that there is no need to adjust for barrel
distortion
>>and this was now taken into account, do I need to include a,b,c etc. in
the
>>optimisation as well?
>
> The 'align' button in the Assistant tab will adjust the 'b'
> parameter automatically, which is usually sufficient. If you are
> using the optimiser tab then you get to pick exactly which
> parameters to optimise.
>

That is the question tho. what parameters should I optimize? I have a
linear panorama, all points should be good, and no matter what optimization
I do I get nothing like what I would expect. all images are lumped together.
Henc I revert to asking the gurus 8).... what is *supposed* to work for
linear panorama? (bearing in mind it was a 10-22mm Canon efx (1.6x) lense at
11mm so lots of distortion).

Thanks again.

Jasper
--
View this message in context: http://old.nabble.com/Linear-Panorama-%28Photo-Mosaic%29%2C-new-workflow-X%2CY%2CZ--tp28505458p28655828.html

Sent from the hugin ptx mailing list archive at Nabble.com.

[Bruno Postle]

On Mon 24-May-2010 at 04:13 -0700, Jasper Aorangi wrote:
>
> I understand where prealigned/control point generation comes in. I
> was using it in conjunction with panomatic, and having to call it
> through a wrapper script to pass it the file list as per:
> http://old.nabble.com/Align-with-lots-of-images%2C-Overcome-td28501969.html#a28501969
> Should this have worked better?

This workaround shouldn't be necessary if you have autopano-sift-C
2.5.1, you can use these parameters in the Preferences (the list of
input photos is supplied within a temporary file):

Program: autopano-sift-c
Parameters: --maxmatches %p %o %s

> Also completed a trial using imagemagic to mask the coloudy bits
> and the lower foreground (i.e letterbox 8) did control point
> detection etc. on three images at a time, and combining them as
> you suggested with pto_merge. The output from this was worse
> unfortunatley. 57 disconnected regions vs 35 from hugin.

It is difficult to say without seeing the project. Can you open any
of these three-photos project files in Hugin and see anything wrong?

> > The 'align' button in the Assistant tab will adjust the 'b'
> > parameter automatically, which is usually sufficient. If you
> > are using the optimiser tab then you get to pick exactly which
> > parameters to optimise.
>
> That is the question tho. what parameters should I optimize? I
> have a linear panorama, all points should be good, and no matter
> what optimization I do I get nothing like what I would expect. all
> images are lumped together. Henc I revert to asking the gurus
> 8).... what is *supposed* to work for linear panorama? (bearing in
> mind it was a 10-22mm Canon efx (1.6x) lense at 11mm so lots of
> distortion).

For a linear panorama where the camera changes positions, the
subject is a flat surface (like a mural), and the initial estimate
of field of view is approximately right. With the current Hugin
trunk, you only need to optimise 'Positions and translation'. After
that you can try optimising 'barrel and view' too and see if this
improves things.

--
Bruno