hugin-devs team mailing list archive

[Gerry Patterson <679337@xxxxxxxxxxxxxxxxxx>]

I have looked into the code on this.  I am not familiar with what is
supposed happen but I have a guess:

When one takes a panorama with a single camera with a single response
curve, the output image will use this response curve as well.

When one takes a panorama with multiple cameras, each with their own
response curve, one of the response curves is chosen to be the one which
all others are referenced to.  These are the  "output" EMoR parameters,
as they are described in the code.  Right now, these are hard coded to
be whatever set of parameters are used for the first image.  Both nona
and the slow preview enforce this. This is why, when you change the EMoR
parameters for the first image (or any image who's EMoR parameters are
linked to the first image) all other images change since they are either
using these new EMoR parameters (same lens) or their response curve is
referenced to the first image.

However, in the case of the fast preview, while it  generates the LUT
for the output response curve, it is always for a output EMoR parameter
set of 0,0,0,0,0.  I think this is a bug and I have a patch which makes
it behave the same as the rest of the system.

However, I am thinking it would make sense to expose the choice of which
response curve to use as the output one instead of always picking the
one associated with the first image in the list.  Similar to how anchor
for exposure and anchor for position are used in the images tab.

Feedback is welcome here....

- Gerry

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/679337

Title:
  Camera response not assigned to the correct image?

Status in Hugin - Panorama Tools GUI:
  Confirmed

Bug description:
  Hugin apparently gives the wrong camera response to images, depending on the first image in the panorama.

Steps to reproduce:
1. Open Hugin
2. Add any two images
3. Assign a different camera to the second image
4. Change the camera response in the first image (for example, enter 5 in the bottommost box)
5. Look at the two images in the normal preview
5. Save pto file and generate with nona the two "remapped" files

Expected result: the preview of the first image and its remapped image has a strange color

Outcome: in the normal slow preview the first image is unchanged and the second one has a very strange color. The same is true for the remapped images. The GL preview (with Photometrics applied) shows the correct colors for the second image.

Fix: move up the second image (in the Images tab). Both bugs (in the output and in the preview) are fixed.