Landscape and portrait images can't share a lens

[Nicolas Pelletier]

As I was stitching, I got this.

HuginBase::PanoramaMemento::loadPTScript(): Landscape and portrait images can't share a lens

error on script line 2792:

ERROR:  (..\..\..\hugin\src\hugin_base\panodata\Panorama.cpp:2373) HuginBase::PanoramaMemento::loadPTScript(): Landscape and portrait images can't share a lens

error on script line 2792:

ERROR:  (..\..\..\hugin\src\hugin_base\panodata\Panorama.cpp:2373) HuginBase::PanoramaMemento::loadPTScript(): Landscape and portrait images can't share a lens

error on script line 2792:

Reading the error, my fault! I did mix both type of images (didn't know I couldn't)

Can I in the GUI know which image is which? so I can separate them back into 2 lenses?

Should this not matter? as in if it's a landscape, just flip it and the behavior will be the same?

Thank you!

More info,

Vista running the install kit of RC4

[Seb Perez-D]

On Thu, Jul 16, 2009 at 04:56, Nicolas
Pelletier<nicolas....@gmail.com> wrote:
> Can I in the GUI know which image is which? so I can separate them back into
> 2 lenses?

Int the image tab you should be able to see the size of the images.
The horizontal and vertical images have the dimensions swapped. Then
it should be easy to give a different lens to both.

Cheers,

Seb

[Bart van Andel]

> Int the image tab you should be able to see the size of the images.
> The horizontal and vertical images have the dimensions swapped. Then
> it should be easy to give a different lens to both.

I've always wondered why this is necessary. I would rather have Hugin
treat them as the same lens (which it basically is), with the same
parameters. Everything should be the same, except the image is rolled
90 degrees. Why isn't this implemented this way? Images rotated "just"
45 degrees can share the same lens, whereas images rotated 90 degrees
cannot?

[Seb Perez-D]

On Thu, Jul 16, 2009 at 13:18, Bart van Andel<bavan...@gmail.com> wrote:
> I've always wondered why this is necessary. I would rather have Hugin
> treat them as the same lens (which it basically is), with the same
> parameters. Everything should be the same, except the image is rolled
> 90 degrees. Why isn't this implemented this way? Images rotated "just"
> 45 degrees can share the same lens, whereas images rotated 90 degrees
> cannot?

I thought that Nicolas meant that the input images were rotated, not
with the roll parameter in Hugin (I don't know how you can have an
input image rotated 45º). Images with different roll parameters can
share the same lens (I do that all the time).

As for the reason, if I were pressed to answer: Hugin calculates the
horizontal field of view based on the width of the image. Whether the
image is horizontal or vertical changes this width, and the code would
need to change a lot for this to work.

Cheers,

Seb

[Nicolas Pelletier]

Thanks for the info.

I'll be sure I have them all lined up the same way before the next panorama. Which they typically are. Only the bottom shot gets sometime interpreted by the camera as a landscape.

And yes, I was talking about the original orientation of the image.

Since we are in the topic of lens sharing. I would guess the reason I cannot share a lens for images of different size is the same?

When I mean same size, I mean I export my 30+ images at 1600-1200, "hug" them, save the lens.

I do another pano with images exported at 800-600, made with the same glass. I cannot reuse the lens.

So I don't mean mix and match in the same pano.

nick

[Bruno Postle]

On Thu 16-Jul-2009 at 08:11 -0400, Nicolas Pelletier wrote:
>
>Since we are in the topic of lens sharing. I would guess the reason I cannot
>share a lens for images of different size is the same?

These are limitations of the panotools lens model:

The first problem is that lens correction parameters are locked to
the narrowest width of the image, but the angle of view parameter is
locked to the horizontal width - So landscape and portrait images
need to have different 'lenses'.

The second problem is that the d and e lens shift parameters are
measured in pixels and not as a ratio - So different resolution
photos can't have the same 'lens'.

--
Bruno

[Nicolas Pelletier]

Thanks for the info.

nick

[J. Schneider]

Hi,
I am wondering about two things:

Why can't hugin check for this user input error beforehand? (I
understand it quit with the mentioned error report. Anyway the report
should be clear everyday language.) This I would consider a bug.

One step further: I have understood why portrait and landscape images
can't share a lens in the panotools lens model - but this should be
transparent to the user. Hugin should be able to recognise that two
images have been taken with the same physical lens but different
orientation (of course this is only an assumption, but it only assumes
as well that images of same size and orientation share a lens).
Now hugin could either assign different lenses by itself or even better
do so only internally and display them to the user as sharing a lens (so
there would be "user lenses" and "panotools model lenses"). OK, the
latter would confuse people who have learned the whole stuff earlier.

regards
Joachim

[Bart van Andel]

Well, by "rotated 45 degrees" I just mean rotated by tilting the
camera. And why would it need a lot of code change? Maybe I'm
overlooking lots of problems here, but isn't it just a matter of
discarding the EXIF rotation (or applying a rotation to the image data
before exposing it to the Hugin core) and replacing it with a roll of
90 or 270 degrees upon loading the image (which would also happen when
loading images without EXIF information)? Of course the HFOV field
will then sometimes be a VFOV really, but the same is true when
holding the camera at a 45 degree roll: strictly the HFOV won't be
"horizontal" then.

On 16 jul, 13:38, Seb Perez-D <sbp...@gmail.com> wrote:

[Bruno Postle]

On Thu 16-Jul-2009 at 19:39 +0200, J. Schneider wrote:
>
>Why can't hugin check for this user input error beforehand? (I
>understand it quit with the mentioned error report. Anyway the report
>should be clear everyday language.) This I would consider a bug.

I can't reproduce the error.

If I take four identical landscape images, but then rotate one to
portrait format, hugin insists on using two lens numbers.

If I then manually force them all to be 'lens 0', I can stitch but
get an error message, hugin doesn't crash and the output is created.

--
Bruno

[Nicolas Pelletier]

When I wrote the original post, hugin was still running, so I did not know if the input would come out.

As you said, it does.

I don't know if the result is 100% the same as if the lenses were setup as 2 instead of one, but it seemed ok!

Thanks,

nick

[Rogier Wolff]

On Thu, Jul 16, 2009 at 11:14:51AM -0700, Bart van Andel wrote:
>
> Well, by "rotated 45 degrees" I just mean rotated by tilting the
> camera. And why would it need a lot of code change?

Yes. But you can't store them in a file that way.

Let me explain by showing you my workflow....

My camera has a sensor. So it tagges the images about which side is
up. When I come home I (sometimes) run a script that takes each image
and rotates the JPEG (losslessly) so that it is right side up (*).

Usually this results in all images for hugin to be portrait 2592x3872
images. However if I have taken portrait mode circular shot, but
realize I've missed a part, say towards the ground, I sometime put my
camera back in landscape mode, and shoot the remaining shots.

I could of course rotate these too, and put them in portrait mode.
But by the time I realize this, I'm well into hugin and have done
some work to generate the pano.

Roger.

(*) gqview, the version I have here, annoyingly builds up the image
top-down, and when it's done, it realizes that the image is rotated
and rotates it. This is annoying when viewing images. So that's why I
rotate the images.

--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

[Bart van Andel]

On 17 jul, 09:00, Rogier Wolff <rew-googlegro...@bitwizard.nl> wrote:
> > Well, by "rotated 45 degrees" I just mean rotated by tilting the
> > camera. And why would it need a lot of code change?
>
> Yes. But you can't store them in a file that way.

Of course, I know. They can be stored in 90 degree increments.

>
> Let me explain by showing you my workflow....

> [...]

That more or less answers my question. By pretty obvious preprocessing
the images you can effectively work around the Hugin limitation of
combining landscape and portrait orientation images from the same
camera into one lens. "Forgetting" an image shows where the problem
is. That's why I don't get it that Hugin can't do this by itself, if
it's really just this simple.

I guess this would be called a feature request :)

--
Bart

[Rogier Wolff]

Still..... I just scetched the way I ran into this item. More
"plausible non-user-error" situations could arise. For example, my
camera doesn't rotate the image, but just uses the exif tag to
indicate which side is up. How about a camera that does the lossless
jpeg rotation itself? And if you're calling me rotating my camera for
a second row a user-error, I want to say that there are good reasons:
It takes about 16 images to make a 360 pano in portrait mode. To
augment that with some extra visual information in the "down"
direction, I need only 5 more images in landscape mode. That reduces
the complexity of the hugin process enormously.

Anyway, with a simple preprocessing trick in hugin, it shouldn't be too
hard to make this work.

When an image is "portrait" (vsize > hsize), rotate it by -90 degrees
internally, and set the default roll parameter to 90. Nobody would
notice.

Now, the "hfov" parameter always refers to the longest side of the
image. (and might need an eventual rename....)

And linking portrait and landscape images from the same lens becomes
easy.

Roger.

[Jim Watters]

Rogier Wolff wrote:
> Anyway, with a simple preprocessing trick in hugin, it shouldn't be too
> hard to make this work.
>
> When an image is "portrait" (vsize > hsize), rotate it by -90 degrees
> internally, and set the default roll parameter to 90. Nobody would
> notice.
>
> Now, the "hfov" parameter always refers to the longest side of the
> image. (and might need an eventual rename....)
>

Yes, the better thing to do would to to have a wide and narrow FoV
parameters. Both Panotools and Hugin should be updated.

No need to auto rotate an image by +90/-90 degrees unless the image has
exif data stating the image should be rotated but is not. But then you
still get the problem of saving the project. Opening these images into
an image editing program that when opened auto rotates the image and on
save removes the exif data. When the project is opened again these
images will need to have their initial auto rotate removed. Maybe the
script should keep track of the exif data about rotation separately.

> And linking portrait and landscape images from the same lens becomes easy.
>
> Roger.

The Panotools Radial Shift and was changed to be this way by Helmut
Dersch back in 1999 and I updated radial brightness falloff back in 2003.

[Nicolas Pelletier]

In my opinion, the why, if, exif and all should come back to one question.

I have 2 pictures I need to stitch. One if portrait, one is landscape.

Will any of the module end up with a different result than if I had 2 portraits.

I don't mean 2 lens vs 1. But will the control points be different? will the optimizer fail in one case but not the other? or be more precise in one case? Will enblend\enfuse render them differently?

If the answer is no to all of them, then in my opinion, picture orientation is not a variable in stitching, and therefore is not a variable the user should have to manage manually.

What do you think?

nick

[Thomas Steiner]

2009/7/17 Rogier Wolff <rew-goog...@bitwizard.nl>:
>
> ... For example, my

> camera doesn't rotate the image, but just uses the exif tag to
> indicate which side is up. How about a camera that does the lossless
> jpeg rotation itself?

BTW: Probably this is true for every image size of any camera, but
isn't a lossless jepg rotation only possible for images with sizes
that can be writen as 2^n or multiples? (So a 2x3 pixel images cannot
be rotated lossless.)
Thomas

[Seb Perez-D]

On Fri, Jul 17, 2009 at 16:58, Thomas Steiner<finbre...@gmail.com> wrote:
> BTW: Probably this is true for every image size of any camera, but
> isn't a lossless jepg rotation only possible for images with sizes
> that can be writen as 2^n or multiples? (So a 2x3 pixel images cannot
> be rotated lossless.)

The blocks are 8x8 or 16x16, so the image size has to be a multiple of
8 or 16. From what I've read, almost all digital cameras produce JPEGs
which follow this rule.

Cheers,

Seb

[Bart van Andel]

> BTW: Probably this is true for every image size of any camera, but
> isn't a lossless jepg rotation only possible for images with sizes
> that can be writen as 2^n or multiples? (So a 2x3 pixel images cannot
> be rotated lossless.)

JPEG operates on 8x8 pixel blocks, so if the resolution is a multiple
of 8, it's easy. "If the image is not an exact multiple of 8 pixels in
width or height, it is temporarily padded out to that size" (quoted
from "The image processing handbook" by John C. Russ, page 118), but I
don't know what happens when you try to rotate that.

[Thomas Steiner]

Ok, I see, thanks guys...
Thomas

2009/7/17, Bart van Andel <bavan...@gmail.com>:

--
Von meinen Mobilgerät aus gesendet

[Rogier Wolff]

The left and top sides of the image start with a "full" 8x8 block.
If you rotate by +/-90 degrees one will become the other, but either
the right side will become top, or the bottom side will become left.

So, when that side is not at a multiple of 8, that side will have to
be padded out.

However for digital camera images, this is not likely to happen.
All my cameras have provided 8x8 aligned images.

Here is the list of supported resolutions for ONE camera of each of
the manufacturers from the first half of the alphabet. (I got bored
and this proves my point I think...)

There is ONE resolution that is not evenly divisible by 8. It's likely
a type from dpreview.

agfa DC600UW 2816 x 2112, 2048 x 1536, 640 x 480
canon EOS 500D 4752 x 3168 3456 x 2304, XXX 2353 x 1568
casio EX-Z29 3648 x 2736, 3648 x 2432, 3648 x 2048,
3072 x 2304, 2304 x 1728, 1600 x 1200, 640 x 480
Epson R-D1x 3008 x 2000, 2240 x 1488
Fuji Z300 3648 x 2736, 3648 x 2056, 2592 x 1944, 2048 x 1944,
1920 x 1080 1600 x 1200, 640 x 480

HP MZ67 3264 x 2448
Kodak Z1485IS 4352 x 3264, 4352 x 3264, 4352 x 2896, 4352x 2448,
2592 x 1944, 2592 x 1728, 2592 x 1456, 2048 x 1536,
2048 x 1360, 2048 x 1152, 1800 x 1200, 1920 x 1080,
1280 x 960

Konika Z6 2816 x 2112, 2272 x 1704, 1600 x 1200, 640 x 480
kyocera M400R 2272 x 1704, 1600 1200, 1280 x 960, 640 x 480

(the sensor is usually a bit bigger than this to prevent the
algorithms in the camera to have to special-case the borders. And they
don't want to handle partial jpeg blocks. So they simply chose a size
evenly divisible by 8.)