Mosaic drag mode + keeping Tr parameters consistency on roll patch (vetting exercise)

[Darko Makreshanski]

Hi,

Here is the patch that I have proposed earlier.

It basically adds two things:

1. it includes a new drag mode in the fast preview for mosaic
panoramas where instead of changing orientation parameters it changes Tr
parameters
2. it keeps consistency in images on rolling when Tr parameters are
non zero (for yaw and pitch consistency cannot be preserved for non-zero
Tr parameters)

Basically I've added a option choice in the drag tab in the fast preview
window where the user can choose between normal and mosaic mode.

I know this is not the perfect way to switch between these modes as
ideally it should be in some upper level or maybe even automatic.
Also what is still needs to be done is that while in mosiac mode the
manual changing of orientation parameters (yaw, pitch, roll) needs to be
switched to manual changes of Tr parameters. Also maybe some interface
for changing the TrZ parameter as now only TrY and TrX parameters are
changed.

The system works in a simple manner. It uses the previous implementation
of finding the angles that correspond to the points on the screen, and
so I'm using these angles to determine the correspondent points on the
virtual plane and then calculate the shift.

For the keeping of consistency in rolling the corresponding AngleStore
class and its move method were changed to handle TrX and TrY parameters.
I could have also easily added the TrZ parameter, however this would
help much.

Best,
Darko

[darko]

> I could have also easily added the TrZ parameter, however this would
> help much.
>

I meant wouldn't help much

[Bruno Postle]

On Thu 08-Apr-2010 at 00:15 +0200, Darko Makreshanski wrote:
>
>Here is the patch that I have proposed earlier.

Thanks, it builds here (centos4 Linux) but I get a segfault when I
open the fast preview window. It may be a local problem, I'll try
again with a clean tree tomorrow.

--
Bruno

[Oskar Sander]

Sounds like an excellent addition! When could it be allowed into trunk?

I thought that yaw and pitch would be consistent also with non-zero X,Y,Z. I thought these angles would be applied around the
camera position, not the (0,0,0) coordinate.   Which way is it?

A suggestion for changing Z.  maybe left-clicking and scroll wheel up and down?

Cheers
/O

2010/4/8 Bruno Postle <br...@postle.net>

With a clean build it is now fine.

Using a project with lots of XYZ shifts that would normally get scrambled in Drag mode:  If I select 'mosaic' in Drag mode then left-mouse moves the photos around, and right-mouse rotates around the centre as expected.

Well done, this is a very useful patch.

--
Bruno

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

--
/O

[Darko Makreshanski]

Oskar Sander wrote:
> I thought that yaw and pitch would be consistent also with non-zero
> X,Y,Z. I thought these angles would be applied around the
> camera position, not the (0,0,0) coordinate. Which way is it?

> <http://groups.google.com/group/hugin-ptx>
I believe for yaw and pitch it is not possible to keep correspondence
with the current mosaic model. It is also logical, as the model assumes
that the photos are looking into some plane, and so there is only only
yaw/pitch value per image that depends on the camera's parameters with
respect to the plane.

Best,
Darko

[Bruno Postle]

On Fri 09-Apr-2010 at 12:47 +0200, Oskar Sander wrote:
>Sounds like an excellent addition! When could it be allowed into trunk?

It is probably ok as is, but I'm not sure if it needs the option to
switch modes. My understanding is that rotating the scene makes no
sense when there are XYZ offsets, similarly XY translation makes no
sense when there are no XY offsets. I think I need to do some
tests, but I don't know when.

>A suggestion for changing Z. maybe left-clicking and scroll wheel up and
>down?

Altering the panorama field of view has a similar effect.

--
Bruno

[Oskar Sander]

2010/4/10 Bruno Postle <br...@postle.net>

It is probably ok as is, but I'm not sure if it needs the option to switch modes.  My understanding is that rotating the scene makes no sense when there are XYZ offsets, similarly XY translation makes no sense when there are no XY offsets.  I think I need to do some tests, but I don't know when.

I think it is good to make it an explicit option to the user:

* One reason is that it would be good for the user (i think) to be able to start in the drag-mode to make a outline before the first optimization run. In that case all camera parameters start at zero and a automagic option would have to guess what the user wants to do.

* One other reason maybe is that even for a classical panorama, I may optimize on X&Y in order to compensate for a small change in camera position, so there may be a small X & Y displacement. (or is this scenario irrelevant?)


Abount Z shift: I'll start a separate thread on this topic, as I have more queries on how to use it...



--
/O

[Oskar Sander]

Any conclusions on including in trunk?

Cheers

2010/4/12 Oskar Sander <oskar....@gmail.com>

--
/O

[Bruno Postle]

On Tue 20-Apr-2010 at 21:06 +0200, Oskar Sander wrote:
>Any conclusions on including in trunk?

I've committed it, as I couldn't have (easily) stitched the mosaic
sent to the list a couple of days ago without it.

I still think that maybe it should switch automatically instead of
having a pull-down menu, but there is no reason why it can't be part
of the trunk until then.

--
Bruno

[Oskar Sander]

Cool, I'll play with that once I get hold of a testing version.

Did you mean that the optimization doesn't converge if you first didn't drag photos roughly in place first? Mentally picturing the mosaic mode-optimization, my (not so scientific) feeling is that it would always not be an unambiguous optimum, so either one or more of: good starting values for some position, boundary criteria or optimization strategies.

I read your project file. An optimization that would do the following might have worked from  scratch, don't you recon?:
1. Optimize individual image Y,P,R  based on vertical, and horizontal lines.
2. Optimize for all images X, and Y based on control point and lines
3. Optimize on "all"   (depending on how good the fit are one might want to include y,p,r,x,y,z, maybe fov and distortion)



Cheers
O

2010/4/20 Bruno Postle <br...@postle.net>

I've committed it, as I couldn't have (easily) stitched the mosaic sent to the list a couple of days ago without it.

I still think that maybe it should switch automatically instead of having a pull-down menu, but there is no reason why it can't be part of the trunk until then.

--

[Bruno Postle]

On Thu 22-Apr-2010 at 16:02 +0200, Oskar Sander wrote:
>
>Did you mean that the optimization doesn't converge if you first didn't drag
>photos roughly in place first? Mentally picturing the mosaic
>mode-optimization, my (not so scientific) feeling is that it would always
>not be an unambiguous optimum, so either one or more of: good starting
>values for some position, boundary criteria or optimization strategies.

Yes, but I haven't done enough testing: I've stitched a mural and a
painting with 10 to 15 photos each from all directions and the
optimiser found a solution immediately - The two photos of the roof
needed some nudging of positions, I don't know why.

--
Bruno