Exposure tab - troubles

[paul womack]

Under what conditions would the exposure parameters for an image remain
unchanged (and, as far as I can tell, wrong) under exposure optimisation?

I have a fairly mundane capture of a map, taken with a pano head,
and the light changed during the capture sequence. In any case, I was
using auto-exposure so as to ensure that the captured data
had the least chance of being blown out or filled in.

On two of the maps this approach has worked perfectly,
but on one of them, about 5 (out of 16) images
have completely unchanged parameters,
and look "wrong", in that the boundaries are quite
obvious, and the darkness and colour quite
different under preview, compared to adjacent images.

All the images have the same lens, and each image
is in a separate stack, so I'm a little confused.

I have tried resetting the exposure parameters
back (Ev, colour balance, vigenette and camera response)
and re-optimising, but to no avail.

What could cause this?

BugBear

[Bruno Postle]

On 21 September 2015 11:02:10 BST, paul womack wrote:
>Under what conditions would the exposure parameters for an image remain
>unchanged (and, as far as I can tell, wrong) under exposure
>optimisation?

When exposure optimisation misbehaves, then you need to try these, in order: reset to camera EXIF Eev values; if this is OK, then try just optimising Eev without any other photometric parameters; probably optimising color balance is safe at this point too.

Vignetting calculation requires a large overlap between photos; similarly, response curve calculation requires heavy vignetting and/or variable exposures between shots.

(You can't calculate the sensor response curve with a set of photos on locked exposure and a lens with no vignetting)

--
Bruno

[Carlos Eduardo G. Carvalho (Cartola)]

2015-09-21 7:02 GMT-03:00 paul womack <pwo...@papermule.co.uk>:

I was
using auto-exposure so as to ensure that the captured data
had the least chance of being blown out or filled in.

Usually I do the opposite and I've always seen that a panorama should be shot in manual mode keeping the same settings in all pictures exactly to allow a better stitching.

To deal with big light differences I usually do multiple exposure and post fusion of them or take RAW pictures measuring light in a medium light point of the scene. In any case I also keep the same image treatment on all images that will be stitched together.

Carlos E G Carvalho (Cartola)
http://cartola.org/360
http://www.panoforum.com.br/

[Paul Womack]

Ah - I was optimising "everything", so your advice may well be what I need. I'll try it and report back.

 BugBear

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/E365A1AD-8B7E-45DE-9112-48139735D229%40postle.net.

For more options, visit https://groups.google.com/d/optout.

[Paul Womack]

Since I don't have a wide angle lens (only 38mm) I have to take a lot of shots; HDR on top of that becomes a lot of work.

I took a semi-spherical of my garden to use as a Stellarium landscape, and it was 67 images. At f4.5, Shutter speeds varied from 1/800 for the sky to the South, to 1/15 in the shadows under the trees to the South.

Hugin optimised the exposures beautifully, for a seamless stitch. Optimised Ev varied from 8.9 to 14.2

Even 3 level bracketing would have required 201 images!

   BugBear

--

A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CALW1f7hJjN%2BtVGF%3DRDwOwEqyX2cLOuKDshZbL_p1PZBygYs3yg%40mail.gmail.com.

[Paul Womack]

A quick 'n' dirty trial shows substantial improvement. I'll pursue this further.

Thanks for the help.

 BugBear

[paul womack]

Paul Womack wrote:
> A quick 'n' dirty trial shows substantial improvement. I'll pursue this further.
>
> Thanks for the help.

Good news - my results are much better.

Bad news - I think I've hit an exposure optimisation bug.

I attach a PTO file and two trivial images (flat colour, for max compression).

When I try to optimise the exposure I get the error
message "no overlapping points found, Photometric optimisation
aborted", but the preview clearly shows an extensive overlap area
between the two images.

Have I hit a bug, or have I misunderstood something?

BugBear

[Terry Duell]

Hello Paul,

On Tue, 22 Sep 2015 23:28:52 +1000, paul womack <pwo...@papermule.co.uk>
wrote:

[snip]

>
> When I try to optimise the exposure I get the error
> message "no overlapping points found, Photometric optimisation
> aborted", but the preview clearly shows an extensive overlap area
> between the two images.
>
> Have I hit a bug, or have I misunderstood something?
>

I had a look at your project, to see if I could learn something.
I see the same behaviour here.
I experimented a bit, and found that by dragging the images so they both
have much smaller pitch values, the exposure optimises OK.
I know it's not an answer to your question.


Cheers,
--
Regards,
Terry Duell

[bugbear]

Sounding a lot like a bug. Perhaps the pre-check doesn't
implement the full transform model?

BugBear

[bugbear]

bugbear wrote:

>>
>> I had a look at your project, to see if I could learn something.
>> I see the same behaviour here.
>> I experimented a bit, and found that by dragging the images so they both have much smaller pitch values, the exposure optimises OK.
>> I know it's not an answer to your question.
>
> Sounding a lot like a bug. Perhaps the pre-check doesn't
> implement the full transform model?

I've added this to launchpad;

#1500342 exposure optimiser incorrectly ignoring some pairs

BugBear

[bugbear]

bugbear wrote:

> I've added this to launchpad;
>
> #1500342 exposure optimiser incorrectly ignoring some pairs

I note that this is now "Fixed in changeset f2e38d537544"

Can anyone tell me (or estimate)
how long such a fix will take to emerge in the packagers PPA?

BugBear

[Stefan Peter]

Hi BugBear

This fix has (yet) only been applied to the tip. So the best place to
have a look at the outcome would be “Nightly Builds” at
https://launchpad.net/~hugin/+archive/ubuntu/nightly/+packages

And here you are:
hugin (2015.1.0+hg7143+dfsg-0ubuntu1~trusty) trusty; urgency=medium

* Nightly build of hugin.2015.1.0.f2e38d537544 for trusty
* Several fixes for photometric optimizer [1500342]
* Update internal roi before sampling
* Pass correct image variables to point sampler
(after internal centering the panorama the old/initial image variables
are not valid any more, take instead the centered value)
* Added const keyword to help compiler (tmodes, 2015-09-29)

-- Stefan Peter (Nightly hugin builds) <hu...@speter.ch> Wed, 30 Sep
2015 08:17:32 +0200

Please check it out and let the list know if your problems are fixed.

With kind regards

Stefan Peter

[bugbear]

Stefan Peter wrote:

>
> Please check it out and let the list know if your problems are fixed.
>
> With kind regards

I have downloaded that version, and ran it on a small
failure case (I deliberately had my camera
on aperture priority mode, since light levels
in the room could change - it had windows!)

However I also had my camera on auto white balance,
which was going crazy as I moved to different areas of the map.

I can confirm that, in my 16 image "small map"
the exposure optimise worked beautifully
on both EV and Er/Eb, to the extent that the GL preview
now appears seamless.

I will now try my 173 image (*) "big map"

BugBear

(*) The map is around 5 feet by 10 feet, the archive had no table big enough to handle it in
its entireity, I was using a cantilevered tripod (Benbo) with a 30 inch reach. I was taking
around A4 size section with an 8Mpixel camera, to achieve 300 dpi. Each frame
involved reposition the tripod.

[bugbear]

bugbear wrote:

> I will now try my 173 image (*) "big map"

That worked too (took a while though...)

I hereby declare the bug fixed ;-)

BugBear

[bugbear]

And ... I've run headlong into another.

I was attempting to add another image, one with
a reference card in short, to the big pano.

I got "(hugin:10422): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion 'width > 0' failed
/usr/include/wx-3.0/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type
"

And the resulting pto file will cause this assertion error on hugin startup.

I attach the resulting poisonous file.

BugBear

[T. Modes]

Am Mittwoch, 7. Oktober 2015 11:37:51 UTC+2 schrieb bugbear:

And ... I've run headlong into another.

I was attempting to add another image, one with
a reference card in short, to the big pano.

I got "(hugin:10422): GdkPixbuf-CRITICAL **: gdk_pixbuf_new: assertion 'width > 0' failed
/usr/include/wx-3.0/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier<T>::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type
"

Totally unrelated to the first bug.
 

And the resulting pto file will cause this assertion error on hugin startup.

Please report the next time the full back trace in the debug assertion dialog.

I attach the resulting poisonous file.

It would be nice if you could (for the next time) reduce/cleanup the test pto file for testing. 
Over 100 files, distributed over several subfolder, is difficult for testing.

Nevertheless, it should be fixed in repository.

[bugbear]

"Darn"

I was premature. The optimisation was indeed (as of 7/10/2015) much better.

But whilst trying to tweak it, I discovered another instance of the
"no overlapping points found, Photometric optimisation aborted" bug.

I have re-checked that the version of Hugin I'm running (2015.1.0.1e9a3ac68d2a)
does indeed fix the original fault I reported.

But the attached file shows a similar fault.

(I've cut this down from 195 files to 2)

BugBear

Operating System: Linux 3.13.0-65-generic x86_64
Architecture: 64 bit
Free memory: 5922844 kiB

Hugin
Version: 2015.1.0.1e9a3ac68d2a
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/bugbear/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP
Monitor profile: LIFEBOOK AH532

Libraries
wxWidgets: wxWidgets 3.0
wxWidgets Library (wxGTK port)
Version 3.0.0 (Unicode: wchar_t, debug level: 1),
compiled at Dec 2 2013 15:56:33

Runtime version of toolkit used is 2.24.
Compile-time GTK+ version is 2.24.22.

libpano13: 2.9.19
Boost: 1.54.0
Exiv2: 0.23
SQLite3: 3.8.2
Vigra: 1.10.0
LittleCMS2: 2.5

[T. Modes]

Am Dienstag, 20. Oktober 2015 14:43:46 UTC+2 schrieb bugbear:

But whilst trying to tweak it, I discovered another instance of the
"no overlapping points found, Photometric optimisation aborted" bug.

But the attached file shows a similar fault.

(I've cut this down from 195 files to 2)

Thanks for stripping down. That makes debugging a lot easier.

I found the issue and fixed in changeset daffca65ed45. It was an issue with the translation parameters and the center pano horizontal function, so on the first look total unrelated to the the photometric optimizer.

[bugbear]

T. Modes wrote:
>
> Thanks for stripping down. That makes debugging a lot easier.
>
> I found the issue and fixed in changeset daffca65ed45. It was an issue with the translation parameters and the center pano horizontal function, so on the first look total unrelated to the the photometric optimizer.

Looks like my project is throwing up several bugs - I must be doing something
unusual.

Many thanks for this (and previous) bug fixes.

BugBear

[bugbear]

The new version definitely fixed my reported bug.

However, I have a more general difficulty.

In my large panorama (173 images), after exposure and colour optimisation
I still have a severe, localised, discontinuity in tone/colour.

And yet, if I use the preview to select ONLY those two images,
and optimise, they match each other nicely.

Now, my data has at least one property which
exposure optimisation may well not handle nicely.

My image were captured as a mosaic using a moving
tripod, which cast a shadow in a different place
on the subject at each instance. Many areas of the pano
do indeed have different pixel value on different sub-images.

But this capture fault applies (sadly) to the whole
pano, but the particular difficulty only arises in one corner.

So - how good should I expect the result to be?

Does the exposure optimiser work like the usual
geometric optimiser, using (complex) alorithms
to minimise overall error? If so I really
would not expect what I'm seeing (unless there's a bug...).

Or is it more direction/piecemeal, matching up successive pairs?

BugBear

[bugbear]

bugbear wrote:

>
> But this capture fault applies (sadly) to the whole
> pano, but the particular difficulty only arises in one corner.
>
> So - how good should I expect the result to be?

I have cut the problem down to a 4 image pano, which can
be downloaded (for the next week) from this link:

https://www.hightail.com/download/bXBaK2VqRnc1Ujd2WnRVag?cid=tx-02002207340200000000&s=19102

I suspect my problem is caused by the fact that the (11 foot x 5 foot) map
was actually captured in 4 sessions, moving and/or rotating the map
to render successive quarters accessible to my tripod/camera.

As such, the lighting (just an archive room) was not only non uniform,
but the map was in a different place (relative to the lighting) for each
session. In this example, the visual discontinuity "just happens"
to be on a session boundary.

So - what's the best that can be done with this flawed
data?

BugBear

[Bruno Postle]

On 21 October 2015 11:25:38 BST, bugbear wrote:
>
>As such, the lighting (just an archive room) was not only non uniform,
>but the map was in a different place (relative to the lighting) for
>each
>session. In this example, the visual discontinuity "just happens"
>to be on a session boundary.
>
>So - what's the best that can be done with this flawed
>data?

In this situation you need to calibrate vignetting and camera response separately - then only optimise exposure and white balance in a project where shadows move around.

--
Bruno

--
Bruno

[bugbear]

I'm not sure how that would work; the "vignette" (AKA non uniform lighting) is much larger
than a single image. Surely vignette calibration applies to (correct) a single image?

BugBear

[Bruno Postle]

On 21 October 2015 at 11:47, bugbear <bug...@papermule.co.uk> wrote:
>>
>> In this situation you need to calibrate vignetting and camera response
>> separately - then only optimise exposure and white balance in a project
>> where shadows move around.
>
> I'm not sure how that would work; the "vignette" (AKA non uniform lighting)
> is much larger than a single image. Surely vignette calibration applies to
> (correct) a single image?

The vignetting calculation corrects a uniform light fall-off between
the centre of the image and the edges, this should be consistent for
any camera/lens/aperture/zoom setup, so you only need to calculate it
once. Similarly the camera response curve should be consistent for
each camera sensor (depending on your RAW workflow).

Optimising these things in a scene where stuff moves around results in
the blown-out weird-colour output. It isn't going to help in the way
that optimising a,b,c,d,e lens parameters sometimes helps with
parallax.

In your difficult scene, optimising exposure (Eev) and white balance
(red/blue parameters) can't go much wrong and should be fine.

--
Bruno