hugin has become unusable for me

[Jeffrey Martin]

hugin is destroying the exposure of my images. I posted about this before, but no one thought it was an issue. I can assure, it's a real problem with me - I can't use Hugin anymore! If anyone can help show me what i'm doing wrong, I would appreciate it.

Hugin did not used to change the exposure of my images unless I asked it to. Now it does, and I don't even know how to get it back.

This is what I get after I reset all color, exposure correciton, etc. using the "reset" button on the images tab:
http://dl.dropbox.com/u/14314213/Screen%20shot%202011-03-07%20at%204.29.34%20PM.jpg

here are the EV values I have for the images.
http://dl.dropbox.com/u/14314213/Screen%20shot%202011-03-07%20at%204.29.44%20PM.jpg

again, my camera is in auto-exposure, but i DON'T WANT TO correct for this - not until I ask hugin to correct it. when I load the images into hugin, generate CP's and optimize, it still changes the exposure in my images.

I am getting really frustrated - I hope someone can show me the way :-)

cheers,
Jeffrey

[Jeffrey Martin]

Oh, and if I reset all images' exposure to "zero" then they're 100% black. arrrrghh!! :-(

[Didgeridoohan]

Someone please correct me if I am wrong, but an EV of 35.8 seems very
large. Something's wrong here...

Maybe you can upload your images somewhere for someone to take a look
at.

/Johan

On Mar 7, 4:33 pm, Jeffrey Martin <360cit...@gmail.com> wrote:
> hugin is destroying the exposure of my images. I posted about this before,
> but no one thought it was an issue. I can assure, it's a real problem with
> me - I can't use Hugin anymore! If anyone can help show me what i'm doing
> wrong, I would appreciate it.
>
> Hugin did not used to change the exposure of my images unless I asked it to.
> Now it does, and I don't even know how to get it back.
>
> This is what I get after I reset all color, exposure correciton, etc. using

> the "reset" button on the images tab:http://dl.dropbox.com/u/14314213/Screen%20shot%202011-03-07%20at%204....
>
> here are the EV values I have for the images.http://dl.dropbox.com/u/14314213/Screen%20shot%202011-03-07%20at%204....

[JohnG]

Don't use the "Align" button on the "Assistant tab" ... ever! ;-)
When you want to calculate geometrical corrections use the "Optimise
Now!" button on the "Optimiser tab".
When you want to calculate exposure (photometric) corrections use the
"Optimise Now!" button on the "Exposure tab".

On "Cam/Lens tab" hit "Reset" to open the dialogue : check the boxes
for
-- Exposure ( to EXIF values )
-- Color
-- Vignetting
-- Camera Response
and hit OK.

Does this solve the first part of the problem ?

If not make sure you're not working in Linear color space:
--> File --> Preferences --> Control Points Editor (sic!) -->
curve ... try "gamma 2.2"

EV35 does sound way off, so there might be a Hugin bug. It might be
helpful if you could also post a pic of the preview without exposure
corrections for comparison.

:-J

[Dane]

It would be useful if the "align" button was split into 3 buttons:

"Find Control Points"
"Align Positions"
" Correct Exposure "

The Align is the only way cpfind works reasonably.

[Jeffrey Martin]

Hi,

i DIDN'T use the "align" button in this case, which is why this whole thing is frustrating me so much.

[Jan Martin]

Jeffrey,

I don't think this is a Hugin problem. More likely a user problem.

I already offered to have a look using Skype screen-sharing, to find out where you get it wrong repeatedly. The offer still stands.

Only alternative is you providing the images, so we can try ourself. However this won't fix your problem, just assure you that it can be done at all.

You need to make a decision.

Jan

On Tue, Mar 8, 2011 at 10:19 AM, Jeffrey Martin <360c...@gmail.com> wrote:

Hi,

i DIDN'T use the "align" button in this case, which is why this whole thing is frustrating me so much.

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

[Jeffrey Martin]

HI Jan,

It's the exact same problem as this thread.

https://groups.google.com/forum/?fromgroups#!topic/hugin-ptx/0hovcyE77Hk

I uploaded those sample images. different camera but same issue (images shot on auto exposure)

[Jeffrey Martin]

Ok, I found a "solution"

in camera/lens tab, reset all photometric info (exposure, etc.). reset the exposure to ZERO.

then in the preview window they are all black. to fix that, I reset the EV using the little arrow button.

But again, this didn't used to happen, and this is not so nice - and I really know what I'm doing. Pity anyone who tries hugin for the first time, they will probably give up and uninstall hugin.... which would be a shame. At any rate, can I file this as a bug?

Jeffrey

[Seb Perez-D]

On Tue, Mar 8, 2011 at 11:30, Jeffrey Martin <360c...@gmail.com> wrote:
> At any rate, can I file this as a bug?

If you provide a reproducible testcase and the expected behaviour, then yes!

Cheers,

Seb

[Jeffrey Martin]

Again, I did here https://groups.google.com/forum/?fromgroups#!topic/hugin-ptx/0hovcyE77Hk uploaded files and pto.

so i'll file a bug then :)

[Bart van Andel]

Setting the exposure to 0 usually isn't the right way. Under normal (daylight) conditions, you can normally expect exposure values between 7 and 15 (pretty wild but educated guess, e.g. see [0]). Resetting the exposure to EXIF values seems more likely to produce anything useful.

On my machine your problem isn't reproducable. I just tried your dog+grave test case using the 64bit version of Hugin 2011.0.0-beta2 (built by Matthew) on my Windows 7 (SP1) machine, using the following steps:

1. Open preferences and reset to default using the "Load defaults" button;

2. Drag & drop your images onto the Hugin window;

3. Press "Align" in the assistant tab;

4. Set the output width to 10000 on the Stitcher tab;

5. Press "Stitch now".

This produced a perfectly valid image, albeit a bit blueish (then again, the source images show the same kind of blueishness).

On the Camera and Lens tab, I can see that the EV of the images is between 12.6 and 15.4, as can be expected with auto-exposed images. Before I had pressed the "Align" button, the EVs were slightly different, between 12.6 and 16. This is normal behavior, since the Align button on the assistant tab also triggers exposure optimization.

For the sake of testing, let's run another test, this time manually, using the following steps:

1. Drag & drop your images onto the Hugin window;

2. On the Images tab, press "Create control points". Since we're using the default settings, CPFind is used, set to 10 points per overlap (which it ignores but that's another thing);

3. On the Optimizer tab, align using "Positions (incremental, starting from anchor)";

4. Still on the Optimizer tab, refine alignment using "Everything without translation";

5. In the Fast Preview, on the Move/Drag tab, press "Straigthen" (it doesn't seem to result in much change in this case);

6. On the Projection tab, select "Cylindrical" as output projection;

7. On the Crop tab, press "Autocrop";

8. Set the output width to 10000 on the Stitcher tab;

9. Press "Stitch now".

The resulting image looks much worse than the one produced by the first approach, probably mainly because I've skipped exposure correction entirely (and I didn't change the output EV either). I've checked that the EV values haven't changes since loading the images. The image alignment is also slightly better in the auto-generated version (I haven't done and control point cleanup).

I've attached the resulting .pto files (renamed to .txt to pass Google Groups type check) and the output (reduced to 1000 pixels wide, saved as jpg) so you can check. My guess is that there's something wrong with your setup somehow, but it's pretty weird behavior. FYI I haven't tried the 32bit version to see whether the problem exists there.

[0] http://en.wikipedia.org/wiki/Exposure_value

--

Bart

[JohnG]

Jeffrey, Bart and gurus,

I checked Jeffrey's dog-grave images' [www.vrlog.net/temp/dog-
grave-1row.zip] EXIF data in Lightroom3: they all appear to have valid
"Fnumber" and "ExposureTime" values and "ISOspeedRating" = 80. The
original input images are not overexposed. No obvious problems there.

Hugin 2011.0beta2 win32 shows their EVs ranging from 12.6 ( img# 0 )
to 16.0 ( img# 12 ) -- 3.3 stops is quite a lot of latitude for
Enblend to deal with ... a job for Enfuse methinks ?

Test # 1 After Load images, CPfind and Optimise *only* ( y p r ), the
Preview looks "burned out" - just like Jeffrey's screenshots and
Bart's second export. I noticed that ( IMG# 0 ) looks correctly
exposed. The (Images tab) A and C anchors were set to ( img# 0 ) as
per default. This image ( ...097.JPG ) happens to have the lowest EV
( 12.6 ) in the project. In the preview all the other images are
overexposed to some extent. Checking the "Photometrics" toggle in the
Preview tab improves the preview a bit, but not much. ( If there are
no photometric corrections, this toggle should not change the
appearance of the preview images ... ).

-- Exported as "Exposure-corrected LDR", and it looks like the Preview
Photometrics "on" version.

-- Exported as "Exposure fused from stacks" and it looked great!
( apart from a dark 'stain' on the snow below the sun ... to be
expected really.)

Test # 2 I repeated the process - from scratch, but moving the C and A
anchors to IMG# 12 ( EV 16) before running CPfind and Optimising only
( y p r ). No combination of C and A anchor positions made any
difference to the Preview - all images except IMG# 0 remained
overexposed.

Test # 3 I applied a basic exposure optimisation. With preview
photometrics *on*, the preview looks good - as you would hope. But
with preview photometrics *off* I got yet another version --"whacky"
exposure corrections that do not appear to resemble the input image
tonal values, or the initial "burnt out" preview! ; some of the images
appear to be uniformly tinted by various shades of dirty orange, some
look ok, and others are overexposed. The Preview is definitely adding
some kind of exposure compensation here.

Test # 4 Resetting all photometric corrections should return us to the
"burnt out" version ? No. We're stuck with the "whacky" version.
Switching Preview photometrics *off* only exaggerates the whacky
tints.

-- Exported as "Exposure-corrected LDR" and it resembles the "whacky"
tinted version, but with smoother seams.

-- Exported as "Exposure fused from stacks" and it appears identical
to the previous Enfused version.

-- Exported as "Remapped images, No exposure correction, LDR" and
reassembled roughly in photoshop. This output appears consistent with
the original input files, and fairly consistent with enfused outputs.
It is certainly different to both "exposure corrected LDR" outputs.

So yes, I can verify, Jeffrey is not insane :-) Despite every effort
to prevent it doing so, Hugin does indeed apply some kind of "exposure
normalisation to IMG# 0" to both Preview and Output. It therefore
appears to be impossible to export the pano without Hugin performing
some kind of photometric "correction"; the only workaround is to apply
explicit exposure correction, be it vig_optimise, enfuse or
hdrmerge. All in all, I can't imagine that this behaviour is "by
design". IMHO there is something buggy in Hugin's photometric
behaviour.

The problem might lie with the "exposure corrected LDR" output
settings ... but I don't see why this would loop back into the Preview
behaviour unless they share some "default" exposure handling code.

I suspect that the problem does lie within Hugin, not Jeffrey's files.
I think that Jeffrey's extreme image set actually demonstrates some
error which would normally get under the radar. This set of images
tests Hugin's claim to handle this kind of extreme auto-exposure case.

+1 to file a Bug Report, even if some people consider it a low
priority one. Many serious users, however, might well regard
unavoidable tone-remapping as a deal breaker.

:-J

On Mar 8, 2:42 pm, Bart van Andel <bavanan...@gmail.com> wrote:
> ...

> For the sake of testing, let's run another test, this time manually, using
> the following steps:
>
> 1. Drag & drop your images onto the Hugin window;
> 2. On the Images tab, press "Create control points". Since we're using the
> default settings, CPFind is used, set to 10 points per overlap (which it
> ignores but that's another thing);
> 3. On the Optimizer tab, align using "Positions (incremental, starting from
> anchor)";
> 4. Still on the Optimizer tab, refine alignment using "Everything without
> translation";
> 5. In the Fast Preview, on the Move/Drag tab, press "Straigthen" (it doesn't
> seem to result in much change in this case);
> 6. On the Projection tab, select "Cylindrical" as output projection;
> 7. On the Crop tab, press "Autocrop";
> 8. Set the output width to 10000 on the Stitcher tab;
> 9. Press "Stitch now".
>
> The resulting image looks much worse than the one produced by the first
> approach, probably mainly because I've skipped exposure correction entirely
> (and I didn't change the output EV either). I've checked that the EV values
> haven't changes since loading the images.

> ...

> My guess is that there's something wrong with your
> setup somehow, but it's pretty weird behavior. FYI I haven't tried the 32bit
> version to see whether the problem exists there.

> ...

[T. Modes]

> So yes, I can verify, Jeffrey is not insane :-)  Despite every effort
> to prevent it doing so, Hugin does indeed apply some kind of "exposure
> normalisation to IMG# 0" to both Preview and Output.  It therefore
> appears to be impossible to export the pano without Hugin performing
> some kind of photometric "correction"; the only workaround is to apply
> explicit exposure correction, be it vig_optimise, enfuse or
> hdrmerge.   All in all, I can't imagine that this behaviour is "by
> design". IMHO there is something buggy in Hugin's photometric
> behaviour.
>

That's simply wrong. The behavior is correct.
If you want no photometric correction set the exposure value of *all*
images to zero and set the *output exposure value* also to zero.
Or use reset exposure to zero (there was a bug introduced into the
reset exposure code some months ago, which resulted in a wrong output
exposure value. This should be fixed in the repository).

Thomas

[Bruno Postle]

On Tue 08-Mar-2011 at 18:21 -0800, JohnG wrote:
>
> I checked Jeffrey's dog-grave images'

> [www.vrlog.net/temp/dog-grave-1row.zip] EXIF data in Lightroom3:

> they all appear to have valid "Fnumber" and "ExposureTime" values
> and "ISOspeedRating" = 80. The original input images are not
> overexposed. No obvious problems there.
>
> Hugin 2011.0beta2 win32 shows their EVs ranging from 12.6 ( img# 0
> ) to 16.0 ( img# 12 ) -- 3.3 stops is quite a lot of latitude for
> Enblend to deal with

3.3 stops means that Hugin needs to scale the brightness of one of
the images x10 to get them to match. This is why you can't adjust
brightness (or colour balance) in an image editor, it only works in
a tool like Hugin that understands the camera response curve and
that will apply different scaling depending on the position of each
pixel in the curve.

This is also why the preview with the Photometrics checkbox disabled
looks wrong - This is a 'fast' option that only applies linear
scaling like an image editor. This default has been changed
recently, the preview will now always start with the Photometric
display enabled.

Jeffrey, we need to know why you think the result is wrong? i.e.
which of these possible results do you see:

http://www.flickr.com/photos/36383814@N00/5446447682/

--
Bruno

[JohnG]

Thank you, Thomas, for the pointers. So it's just a GUI problem, not a
bug.

The uncorrected preview requires explicitly setting EV=0 in two
places : first on the Cam/Lens tab ("reset" button) and on the Preview
tab ("mean exposure" button). Doing one without the other, or typing
"0" into the preview tab EV box, produces completely different
effects ... Could this be made a little more user friendly, perhaps ?

Camera/Lens tab -> Reset -> Exposure :
-- to EXIF values
-- to zero (no exposure correction)

Surely the EXIF values are, by definition, those of the input images
before/without Hugin's exposure corrections ? Reset to EXIF exposure
and/or colour values should remove any and all of Hugin's exposure and/
or colour corrections from the selected images - and the "Preview"
should reflect this automatically.

I think we need to avoid confusing 'EXIF' "Exposure Value" with
"exposure correction" calibrated as +/- n EV "stops". In photography,
"EV = 0" does not mean the same as "+/- 0 EV" [0]. I think this was
pointed out in the older thread ? This problem really does need to be
addressed.

:-J

[0] http://en.wikipedia.org/wiki/Exposure_value

[Jeffrey Martin]

Thomas - with all due respect, I think all you're doing for Hugin is fantastic - I fully disagree with you - this behavior is totally wrong!!! :-P
If I only generate CP's and render, why possibly would any photometric optimization be expected? If I use the "align images" button, then yes of course. But otherwise? It's unexpected behavior and bad UX in my opinion.

Bruno - the output I would expect in this case, would be to take the aligned images, warp them, and blend them. Not do any photometric changes whatsoever. If I click "align images" then yes, hugin does all the automagic correction of everything.

Furthermore, the idea that you should set TWICE the images to zero (exposure value, and output exposure value) to simply get a panorama which hasn't had its colors messed with, this idea is really not good, in my opinion.

Can we agree that this is a UI problem, and I will file a bug report about this?

Anyway, thanks everybody for listening, and for trying my sample images. I'm glad that at least I now know where the problem is coming from, and that I'm not insane...

Jeffrey

[Bart van Andel]

You're not insane, but this really isn't a bug. There's no photometric optimization going on here, Hugin is just handling exposure like it should. When it reads EV 12 in a source image, but the output image is set to 15 EV, it correctly applies a curve to the brightness value of the input image to get it to match with the selected output EV. What you want is to bypass this correct behavior, which can indeed be accomplished by setting every EV to the same value. Any value will do, 0 is just as right as 12, or PI, or whatever you like.

So, instead of filing a bug report, you should file a feature request for a checkbox (or another means of setting) to bypass EV computations for the stitching phase.

I hope this will clear up some misunderstandings about the way Hugin (correctly) handles EV.

--

Bart

[Bruno Postle]

On Thu 10-Mar-2011 at 06:19 -0800, Bart van Andel wrote:
>
> So, instead of filing a bug report, you should file a feature
> request for a checkbox (or another means of setting) to bypass EV
> computations for the stitching phase.

There already is one, actually two.

On the Stitcher tab, if you pick 'Exposure fused from stacks' then
no EV correction is applied to any of the photos, and enblend will
be used to blend adjacent photos (note that this still works even if
you don't have 'stacks').

If you pick 'Exposure fused from any arrangement' then again no EV
correction is applied, enblend is used to blend any photos with
similar exposure, then enfuse is used to join photos with larger
exposure differences (again this works even when you don't have full
'exposure layers').

--
Bruno

[Bruno Postle]

On Thu 10-Mar-2011 at 05:15 -0800, Jeffrey Martin wrote:
>
> Thomas - with all due respect, I think all you're doing for Hugin
> is fantastic - I fully disagree with you - this behavior is
> totally wrong!!! :-P
> If I only generate CP's and render, why possibly would any
> photometric optimization be expected? If I use the "align images"
> button, then yes of course. But otherwise? It's unexpected
> behavior and bad UX in my opinion.

As we say, it doesn't do photometric optimisation it just reads the
EXIF EV values. A bad user interface would be to do the wrong thing
by default. In the case of a panorama shot on auto-exposure,
ignoring the exposure differences just looks horrible. Hugin does
the right thing by default, but it allows you to do the wrong thing
if you really really want.

> Furthermore, the idea that you should set TWICE the images to zero
> (exposure value, and output exposure value) to simply get a
> panorama which hasn't had its colors messed with, this idea is
> really not good, in my opinion.
>
> Can we agree that this is a UI problem, and I will file a bug
> report about this?

Yes, but you need to rephrase it to describe the actual problem:

Resetting 'exposure' for photos should set the global exposure to
the average when you 'reset exposure to zero', as it already does
with 'reset exposure to EXIF values'.

--
Bruno

[JohnG]

Bruno, with a heavy heart, I must disagree.

On Mar 10, 11:45 pm, Bruno Postle <br...@postle.net> wrote:
> On Thu 10-Mar-2011 at 05:15 -0800, Jeffrey Martin wrote:

> ...

> As we say, it doesn't do photometric optimisation it just reads the
> EXIF EV values.  

But it then interpolates "photometric values" by combining the input
pixel values with the EV info. It previews these "crudely"
interpolated photometric values instead of the input values, and uses
them for output.

> A bad user interface would be to do the wrong thing
> by default.  In the case of a panorama shot on auto-exposure,
> ignoring the exposure differences just looks horrible.  Hugin does
> the right thing by default, but it allows you to do the wrong thing
> if you really really want.

Unfortunately these "default" results also look horrible, but what's
worse : they're *inexplicably* horrible.

When the "default" settings (ie. vig_optimise) don't - for whatever
reason - cut the mustard, surely the "right thing" is to help the user
figure out what is going wrong so he can fix it manually ? A clean
slate is usually a good place to start, followed by systematic trial
and error.

To switch off (uncheck) the previewed "Photometrics" only to find even
more weirdness going on 'underneath' is not helpful.

To "Reset Exposure to EXIF values" and still see unacceptable tone-
mapping anomalies is not helpful.

To "Reset Exposure to zero (no exposure correction)" and get a black
preview screen ... ? and then try "Reset Exposure to EXIF values"
again to get an almost all-white preview image ... ?

With the excellent and intelligible exposure correction available from
enfuse and vig_optimise, is there really a need for a "crude" top-
secret-back-up-default-auto-exposure-corrector as well ?

May I request a feature to simply disable this particular "default"
photometric interpolation, and instead default to the unmodified input
pixel values when vig-optimise corrections are unavailable / hidden /
reset / otherwise eschewed ?

:-J

[Jeffrey Martin]

I wholeheartedly agree with this.

On Friday, March 11, 2011 5:23:18 AM UTC+1, JohnG wrote:

Bruno, with a heavy heart, I must disagree.

To switch off (uncheck) the previewed "Photometrics" only to find even
more weirdness going on 'underneath' is not helpful.

To "Reset Exposure to EXIF values" and still see unacceptable tone-
mapping anomalies is not helpful.

To "Reset Exposure to zero (no exposure correction)" and get a black
preview screen ... ? and then try "Reset Exposure to EXIF values"
again to get an almost all-white preview image ...  ?

With the excellent and intelligible exposure correction available from
enfuse and vig_optimise, is there really a need for a "crude" top-
secret-back-up-default-auto-exposure-corrector as well ?

May I request a feature to simply disable this particular "default"
photometric interpolation, and instead default to the unmodified input
pixel values when vig-optimise corrections are unavailable / hidden /
reset / otherwise eschewed ?

this is why we have the "align" button. to do all this automagic stuff (which in many cases, really is magic, and definitely appreciated)

otherwise, hugin should only do ONLY what we tell it to. in my case, it was to generate CP's and optimize.
 

[Bob Bright]

On 11-03-10 06:19 AM, Bart van Andel wrote:
> You're not insane, but this really isn't a bug. There's no photometric
> optimization going on here, Hugin is just handling exposure like it
> should. When it reads EV 12 in a source image, but the output image is
> set to 15 EV, it correctly applies a curve to the brightness value of
> the input image to get it to match with the selected output EV. What
> you want is to bypass this correct behavior, which can indeed be
> accomplished by setting every EV to the same value. Any value will do,
> 0 is just as right as 12, or PI, or whatever you like.

I agree that the current behavior is correct, with one caveat: When
images are identified as belonging to stacks on the Images tab, hugin
should apply the same curve to all members of a stack, instead of
treating them individually. As things currently stand, hugin's default
behavior is to coerce the over- and under-exposed layers in a project
with exposure bracketing to the same exposure as the middle layer, so
dumping the EXIF values by resetting the input and output exposures to 0
(or 12 or PI ...) is mandatory.

Cheers,
BBB

--
Bob Bright
Vancouver Island Digital Imaging
(250) 857-9887
BBBr...@VictoriaVR.ca
http://VictoriaVR.ca

[Bob Bright]

On 11-03-10 03:45 PM, Bruno Postle wrote:

>
> Resetting 'exposure' for photos should set the global exposure to the
> average when you 'reset exposure to zero', as it already does with
> 'reset exposure to EXIF values'.
>

My version of hugin (currently 2011.0.0beta2) doesn't appear to reset
the output exposure when I reset image exposures to either zero or to
EXIF values -- I always have to click on the EV reset arrow in the
preview window to update the output EV. Am I doing something wrong?

[Bruno Postle]

On Fri 11-Mar-2011 at 13:39 -0800, Bob Bright wrote:
>
> I agree that the current behavior is correct, with one caveat:
> When images are identified as belonging to stacks on the Images
> tab, hugin should apply the same curve to all members of a stack,
> instead of treating them individually.

This should happen already, every photo from the same camera/lens
will share a response curve. Can you upload a .pto file that shows
this?

> As things currently stand, hugin's default behavior is to coerce
> the over- and under-exposed layers in a project with exposure
> bracketing to the same exposure as the middle layer, so dumping
> the EXIF values by resetting the input and output exposures to 0
> (or 12 or PI ...) is mandatory.

..but does it make any difference to your stitching results? Hugin
discards EV values when fusing stacks, and it needs the relative EV
values when merging a stack to HDR.

--
Bruno

[Bruno Postle]

On Thu 10-Mar-2011 at 20:23 -0800, JohnG wrote:
>
>To switch off (uncheck) the previewed "Photometrics" only to find even
>more weirdness going on 'underneath' is not helpful.

Who asked you to switch off photometrics?

>To "Reset Exposure to EXIF values" and still see unacceptable tone-
>mapping anomalies is not helpful.

Hugin doesn't do tone-mapping. Exposure fusion with enfuse does
something similar to tone-mapping, but if 'exposure fusion' is set
in Hugin then all exposure correction is disabled and EXIF values
are irrelevant.

>To "Reset Exposure to zero (no exposure correction)" and get a black
>preview screen ... ? and then try "Reset Exposure to EXIF values"
>again to get an almost all-white preview image ... ?

There are actual bugs in Hugin, resetting exposure to zero should
average the global exposure just as resetting to EXIF does - Jeffery
offered to submit this as a bug report in the tracker.

The white preview sounds to me like you have messed-up camera
response parameters - This is another problem altogether.

>With the excellent and intelligible exposure correction available from
>enfuse and vig_optimise, is there really a need for a "crude" top-
>secret-back-up-default-auto-exposure-corrector as well ?

You seem to be using different software, the default EXIF exposure
correction even without photometric optimisation works well here and
works fine with Jeffery's auto-exposed photos.

>May I request a feature to simply disable this particular "default"
>photometric interpolation, and instead default to the unmodified input
>pixel values when vig-optimise corrections are unavailable / hidden /
>reset / otherwise eschewed ?

Have you read the rest of this thread where various methods of
stitching without exposure correction have been described? Two of
them are actual options on the Stitcher tab.

--
Bruno

[Bruno Postle]

On Fri 11-Mar-2011 at 13:49 -0800, Bob Bright wrote:
>On 11-03-10 03:45 PM, Bruno Postle wrote:

>>Resetting 'exposure' for photos should set the global exposure to
>>the average when you 'reset exposure to zero', as it already does
>>with 'reset exposure to EXIF values'.

>My version of hugin (currently 2011.0.0beta2) doesn't appear to reset
>the output exposure when I reset image exposures to either zero or to
>EXIF values -- I always have to click on the EV reset arrow in the
>preview window to update the output EV. Am I doing something wrong?

Looks like this broke sometime in 2010.5.0, Thomas fixed it five
days ago - I need to check to see if the fix now works for both
cases.

--
Bruno

[Bruno Postle]

Yes, with a current snapshot the reset option now averages the
global exposure when you reset exposure both to zero and to EXIF
values.

--
Bruno

[Bob Bright]

On 11-03-11 02:01 PM, Bruno Postle wrote:
> On Fri 11-Mar-2011 at 13:39 -0800, Bob Bright wrote:
>>
>> I agree that the current behavior is correct, with one caveat: When
>> images are identified as belonging to stacks on the Images tab, hugin
>> should apply the same curve to all members of a stack, instead of
>> treating them individually.
>
> This should happen already, every photo from the same camera/lens will
> share a response curve. Can you upload a .pto file that shows this?

Attached is a .pto with 4 exposure-bracketed stacks (0/-2/+2). The
images were shot raw with a 5D MkII and Tokina 10-17 at 10mm, processed
to 8-bit .tif with RawTherapee, and added to a new project in hugin. I
set the lens type to circular fisheye/focal length 10mm/crop factor 1 on
the Camera and Lens tab, set a circular crop on the Crop tab, and then
organized the images into 4 stacks with yaws of 0, 90, 180, and 270 on
the Images tab. Other than that I haven't done any sort of alignment or
optimization.

Also attached are two screen shots. The first is of the slow preview
window with three adjacent images selected (the fast preview looks about
the same, exposure-wise). The middle image is from the 1st exposure
layer (EXIF EV 8.6), the image on the right is from the 2nd exposure
layer (EV 10.6), and the image on the left is from the 3rd exposure
layer (EV 6.6). As you can see, the preview is displaying all three of
them with more or less the same exposure, even though the left one is 2
stops overexposed and the right one 2 stops underexposed relative to the
middle one. The second screen shot shows them as they should appear,
after the input and output EVs have been reset to 0.

>> As things currently stand, hugin's default behavior is to coerce the
>> over- and under-exposed layers in a project with exposure bracketing
>> to the same exposure as the middle layer, so dumping the EXIF values
>> by resetting the input and output exposures to 0 (or 12 or PI ...) is
>> mandatory.
>
> ..but does it make any difference to your stitching results? Hugin
> discards EV values when fusing stacks, and it needs the relative EV
> values when merging a stack to HDR.
>

Yes, it does make a difference, although perhaps for an odd reason. I
almost never fuse or blend images directly in hugin. My main reason for
this is that most of my projects involve exposure bracketing, and enfuse
will regularly make a mess of things if I call it directly from hugin,
due to its inability to fuse smoothly over the zenith/nadir. So what I
normally do is optimize positions and lens parameters in hugin,
straighten the pano, and then do a photometric optimization on each
exposure layer separately. I then output all of the images that don't
span the zenith/nadir as remapped "Exposure corrected, low dynamic
range" images. Then I pitch the whole pano +90, and output remapped
zenith and nadir images, again as "Exposure corrected, low dynamic
range" images. All of these remapped images are then fed to a general
purpose "fuse-n-blend" shell script which among other things allows me
to specify which stacks of images are from the zenith and nadir. These
stacks get fused, blended, and then re-pitched -90 degrees prior to
being blended with the other fused stacks, so I avoid those starburst
artifacts that enfuse/enblend introduce when they try to fuse/blend over
the zenith/nadir.

All of this works only if the image EVs in hugin are set to the same
value (prior to photometric optimization, after which they're all still
pretty close to the same value). So yes, it really is mandatory for me
to discard the EXIF EVs in hugin. And again, the reason for this is
simply that hugin doesn't respect the fact that my images have been
grouped into exposure stacks on the Images tab, so it applies different
curves to the overexposed and underexposed layers to get them to match
the output EV. I expect that this would be a pretty easy thing to fix.
On the other hand, when you understand what's going on it's a pretty
easy thing to reset the input/output EVs to 0 too, so fixing it doesn't
seem terribly critical.

(It would be REALLY nice, from my perspective, if hugin could
automatically do all of the pitching/fusing/blending/re-pitching stuff
that I currently do partly by hand and partly with the aid of my
fuse-n-blend script. This is probably an ideal candidate for
implementing with Kay's python scripting interface, but since I don't
currently speak python it's going to be a while before I can seriously
contemplate doing it.)