Exposure value handling weirdness

[Gerry Patterson]

Hi All,

Will working on a fix for 2805120  (https://sourceforge.net/tracker/?func=detail&aid=2805120&group_id=77506&atid=550441) I came across something that I would like some clarification on.

When one loads images into Hugin, it will attempt to compute an exposure value.  This only works if EXIF data in available in the image.  If not, the exposure value will default to 1.  Except if another image is already loaded in the panorama.  If that is the case, and it is the same size (and if the same make and model and focal length), then the exposure value from that image is copied to this one.  To me, this seems like madness.  I can understand what one may be wanting to acomplish with but...that small voice inside of me is saying "danger, Will Robinson, danger!"

The fun really starts when one loads an image without EXIF data and then later adds another with EXIF data.  The first image comes, asks for an HFOV and assumes an Ev of 1.  Ok, I can go along with that, gotta pick something right? 

Now, add the second image (with EXIF data).  Hey...It comes in with an Ev of 1 too...Nice....:-(  Since the second image is of the same dimension as the first, Hugin also assumes you are using the same lens and sets this image to the same HFOV that was guessed for the earlier image.  But this second image actually has EXIF data and one can obtain the the true HFOV.  So hit the load EXIF button.

Boom!

Now the exposure value of the second image is 13 stops higher than that of the first (in my test images).  But the HFOV is good..... You just have an image so bright in the preview that one might have well pointed the camera at the sun.

Now my questons:

Why does hugin deal with absolute values of exposures of images? 

Can we bring in all of the images with an exposure of zero and then just apply exposure compensation instead?

Regards,

- Gerry


--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[T. Modes]

>
> When one loads images into Hugin, it will attempt to compute an exposure
> value.  This only works if EXIF data in available in the image.  If not, the
> exposure value will default to 1.  Except if another image is already loaded
> in the panorama.  If that is the case, and it is the same size (and if the
> same make and model and focal length), then the exposure value from that
> image is copied to this one.  To me, this seems like madness.  I can
> understand what one may be wanting to acomplish with but...that small voice
> inside of me is saying "danger, Will Robinson, danger!"
>

I think this case is very rare, because this one works only if the
second image has some EXIF data (make, model, focal length) to make
the comparision. But in this case the chances are high, that also the
exposure time and f-stop can be read from EXIF. So this one happens
probably only when the image contains corrupt EXIF data.

> Why does hugin deal with absolute values of exposures of images?
>
> Can we bring in all of the images with an exposure of zero and then just
> apply exposure compensation instead?
>

When using LDR output (enblend, enfuse) relativ or absolute exposure
should make no big differences. But when output HDR images you get a
other output with an ev values of e.g. 13 than with ev 0. But I don't
know which output is preferred.

Thomas
--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Pablo d'Angelo]

T. Modes wrote:

>> Why does hugin deal with absolute values of exposures of images?
>>
>> Can we bring in all of the images with an exposure of zero and then just
>> apply exposure compensation instead?
>>
>
> When using LDR output (enblend, enfuse) relativ or absolute exposure
> should make no big differences. But when output HDR images you get a
> other output with an ev values of e.g. 13 than with ev 0. But I don't
> know which output is preferred.

The idea was that:

1. A relative exposure compensation cannot be read from the exif data.
Of course this only applies when hugin does read the images correctly.

2. If a "true" hdr needs to be generated, the exposure values of the
camera should be used (unless they are not accurate), because there is
an ambiguity when estimating exposure and response curve at the same time.

3. It becomes possible to directly combine HDR's produced by hugin from
the same camera, regardless of the source exposure, as they are all in
some absolute space. If camera manifactures would use the same
definition for ISO, this would even work across cameras, but probably
today it doesn't.

ciao
  Pablo

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Gerry Patterson]

On Wed, Jun 17, 2009 at 12:31 AM, T. Modes <Thomas.Modes@...> wrote:

I think this case is very rare, because this one works only if the
second image has some EXIF data (make, model, focal length) to make
the comparision. But in this case the chances are high, that also the
exposure time and f-stop can be read from EXIF. So this one happens
probably only when the image contains corrupt EXIF data.

Hello,

I'll have to review the code again, however I believe this is not the case.  It might have been the intention, but the way the objects are being reused, only the filename is changed and then a call to re-load the EXIF data is made.  Unfortunately, if there is no EXIF data the call returns without zeroing-out the previous files EXIF data.  So  the comparison makes a false positive thinking the EXIF data matches when indeed there isn't any data to match.  It looked strange to me, but I thought it might be the someone's intent.  If I patch the code to zero out the EXIF data before re-loading it, then the HFOV box pops up (as I would expect it to).

I propose the following:

1. Be a bit more stringent in what gets copied/assumed from one image to the another.
2. Be more determinstic.  The behaviour of what happens shouldn't change whether you add all the images at once, or one at a time
3. Remove the Load EXIF button.  Update the "Reset..." Dialog to allow more things to be reset to either 0 or EXIF data.  This would allow the user to re-compute the HFOV from EXIF without messing up the exposue value.  Right now both happen when Load EXIF is pressed
   
4. If there is a mix in images with and without EXIF data, reset all images to 0 exposure along with the preview exposure.  Or atleast give the user an indication of what might be happening instead of presenting either solid black or almost pure white images.
   

Any thoughts?

Best Regards,

- Gerry

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Gerry Patterson]

On Wed, Jun 17, 2009 at 1:06 AM, Pablo d'Angelo <pablo.dangelo@...> wrote:

The idea was that:

1. A relative exposure compensation cannot be read from the exif data.
Of course this only applies when hugin does read the images correctly.

 

Hi,

I wasn't implying that we read exposure compensation values, I just meant why not just work around 0 as the starting point for any corrections made by Hugin to the image exposure.   Basically what happens now when there is no EXIF data available.
 

2. If a "true" hdr needs to be generated, the exposure values of the
camera should be used (unless they are not accurate), because there is
an ambiguity when estimating exposure and response curve at the same time.

I see.  I was wondering if that was the case.

Thanks for your insight!

Best Regards,

- Gerry

--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

[Yuval Levy-6]

Sorry if I am getting in late into the debate - I'm catching up after
one month on the go.

On Jun 17, 10:35 pm, Gerry Patterson <thedeepvo...@...> wrote:
> On Wed, Jun 17, 2009 at 12:31 AM, T. Modes <Thomas.Mo...@...> wrote:
> > I think this case is very rare, because this one works only if the
> > second image has some EXIF data (make, model, focal length) to make
> > the comparision.

actually the case is not so rare. I sometimes load a stitched
equirectangular (first image, no EXIF) and the second image is a
normal rectilinear shot, straight out of RAW conversion, with EXIF
data.


> I propose the following:
>
>    1. Be a bit more stringent in what gets copied/assumed from one image to
>    the another.

agree if it is possible not to go back to the old and tedious process
of having to input HFOV for each and every image loaded that does not
have EXIF.

would it be possible to:
- first load all the picture and read whatever data is available
without asking anything to the user
- if there is missing information, present the user with a table where
each image is a row (ideally with a thumbnail in the first column) and
each piece of information is a column, so that the user can
conveniently link / copy them or enter individual values.

>    2. Be more determinstic.  The behaviour of what happens shouldn't change
>    whether you add all the images at once, or one at a time

+1


>    3. Remove the Load EXIF button.  Update the "Reset..." Dialog to allow
>    more things to be reset to either 0 or EXIF data.  This would allow the user
>    to re-compute the HFOV from EXIF without messing up the exposue value.
>    Right now both happen when Load EXIF is pressed

sounds like the "Reset..." button would be split to many buttons
across each of the columns of the table?


>    4. If there is a mix in images with and without EXIF data, reset all
>    images to 0 exposure along with the preview exposure.  Or atleast give the
>    user an indication of what might be happening instead of presenting either
>    solid black or almost pure white images.

the table would have one column for exposure which would give the
indication, and an option for the user to reset it?

Yuv
--~--~---------~--~----~------------~-------~--~----~
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 hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---