Auto Bracketing and highlights

Started by garry23, January 01, 2018, 07:06:34 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

garry23

I have a use case where I was hoping the auto bracketing would help.

Namely, set the exposure for the shadow capture and let the auto bracketing capture the highlights.

The scene has a high dynamic range and very bright light sources, which seem to create problems.

The problem I'm facing is that the auto bracketing stops short of addressing the very bright highlight, ie it is over exposed in that area in RAW.

Here is a zoomed in JPEG from LR:





The auto bracketing does not have any settings, like ETTR, I'm wondering if it would be helpful to give the user some control in the auto bracketing, eg how many stops to keep going after the ML algorithm thinks its finished.

Cheers

Garry

a1ex

ML decides whether to continue or stop the bracketing based on Canon JPEG (it doesn't attempt to guess what LR is going to do with it, so that screenshot doesn't tell much).

Can you upload Canon JPEGs for one such bracketing sequence?

If the images were CR2: dcraw -e *.CR2 will extract the JPEGs (smaller size to upload).

garry23

@a1ex

Here is the JPEG extracted by dcraw from the RAW: that is the highlight capture




a1ex

You should have seen the following screen:



The highlight size is larger than the current threshold (0.15% above 235), so I'm afraid I don't know why it stopped...

Also did a similar test by pointing the camera at a light bulb; it stopped at 0.04% (the only overexposed thing in the image being the filament, covering about 10 pixels on the 720x480 screen).

Can you find a way to reproduce?

garry23

@a1ex

Just tried it on a different composition, but still high dynamic range.

I'm using a 5D3 and an 11mm Irix.

Latest experimental Lua Fix.

I tried 1 and 2 Ev steps in the auto.

Each time the process stopped at 0.15%.

Cheers

Garry

garry23

@a1ex

Just played around with picture styles, ie using monochrome the process goes lower than 0.15% on the same scene.

Does that mean playing with picture styles may help when auto bracketing?

Cheers

Garry

garry23

@a1ex

A further thought.

Using an 11mm lens, the highlight feature, a light, is small in terms of the pixel real estate.

Could this be 'the issue', ie 0.15% gets reached because there are not enough highlight pixels to drive the algorithm further.

If so, maybe this points to a need to rethink the algorithm wrt to focal length?

Or add on an option to take 'an extra one or two brackets'?

Cheers

Garry

a1ex

Well, 0.15 means a highlight ~4x smaller than in your sample image; it still seems a bit large though, so I'm considering changing the default.

In my quick test, 0.01% seems to be a bit too low (it keeps "underexposing" the light bulb); 0.05 is probably a bit more balanced.

Can you take a manual bracketing sequence on the same scene (until the light is no longer overexposed), in 0.5 EV steps, upload the preview JPEGs, and let me know at which of these pictures you think it's best to stop the bracketing sequence?

garry23

@a1ex

Will do, but can't at the moment.

By the way would you consider adding this default as a user variable, eg settable between, say, 0.2% and say 0.05% or 0.02%?

Cheers

Garry

a1ex

I'd prefer not to add YAMLMO (Yet Another Magic Lantern Menu Option) for no good reason; if a reasonable default can do the job, i'd prefer to use that.

garry23

@a1ex

Here are four JPEGs around where I think the highlight capture ought to stop. It is difficult to judge which one is 'right' as trying to capture the filament of the bulb is clearly too far.











I'll let you have a look and see what you think.

BTW I understand your YAMLMO and recognised this myself in my Focus Bar Script, where I wanted another script to change a variable. I 'solved' this by hiding the menu item from the user, thus respecting the YAMLMO but giving control over the variable via Lua. Would this be worth considering, ie so 'power users' could tweak the highlight condition via Lua. Just a thought.

Cheers

Garry

Cheers

Garry

garry23

@a1ex

As you look at the highlights threshold could you also look at shadow end. Once again I think it stops too soon. For example, in this sequence it stopped at least 2Ev down on where I would have liked. The darkest here is what the Auto Bracketing created, the additional ones are my manual add ons.

Once again, I feel that the 'adds ons' feature (highlights and shadows) would be a great (advanced) feature, possibly via a hidden menu item, ie low and high xEv add on brackets.








a1ex

Some notes to emulate the bracketing percentiles starting from JPEGs in QEMU

(I forgot to write them down, then had to look up the commands again)

1) convert the JPG to YUV422 (that's the format of Canon's image buffer)

convert GJG3582_thumb.jpg -resize 720x480! uyvy:- | convert -size 720x480 uyvy:- -channel GB -evaluate AddModulus 32768 +channel lv.uy


2) copy lv.uy to the virtual SD card and load it into the image buffer (this may go in the "Don't click me" test routine)

    enter_play_mode();

    struct vram_info * lv = get_yuv422_vram();
    void* vram = lv->vram;

    clrscr();
    int size;
    void * buf = read_entire_file("lv.uy", &size);
    memcpy(vram, buf, size);


3) copy the decision code into the test routine

    int under_numpix, over_numpix;
    int total_numpix = get_under_and_over_exposure(20, 235, &under_numpix, &over_numpix);
    int po = (uint64_t) over_numpix * 100000ull / total_numpix;
    int pu = (uint64_t) under_numpix * 100000ull / total_numpix;
    if (over_numpix  > 0) po = MAX(po, 1);
    if (under_numpix > 0) pu = MAX(pu, 1);
    bmp_printf(
        FONT_LARGE, 50, 50,
        "Under:%3d.%02d%%\n"
        "Over  :%3d.%02d%%",
        pu/1000, (pu/10)%100, 0,
        po/1000, (po/10)%100, 0
    );


4) run this in QEMU, on a DIGIC 4 model, as it won't work out of the box on D5 models. Reason: D4 models initialize their display buffer at startup; D5 models do that after entering LiveView or displaying some image in PLAY mode, neither of which are currently emulated.




With the above, the percentages are:

GJG3582_thumb.jpg: 0.58 over, 14.92 under
Test_1_thumb.jpg: 0.02 over, 88.84 under
Test_2_thumb.jpg: 0.03 over, 88.3 under
Test_3_thumb.jpg: 0.05 over, 85.81 under
Test_4_thumb.jpg: 0.07 over, 78.47 under
shadows_1_thumb.jpg: 0.63 over, 7.17 under
shadows_2_thumb.jpg: 1.37 over, 3.41 under
shadows_3_thumb.jpg: 4.91 over, 1.53 under

I'm not sure why it didn't take more shadow exposures, as the current shadow threshold is 2.5%...

garry23

@A1ex

So where does that leave us?

Keep the code as is?

Hardwire a tweak in the code?

Add in a hidden menu tweak that can be accessed from Lua.

Cheers

Garry

a1ex

I've fine-tuned the thresholds and also added some debug messages to the console. I have a feeling the issues were not really bad thresholds, but something else caused the bracketing sequence to stop earlier, so I'd like to find out why.

After a bracketing sequence that didn't work as expected, just open the console and take a screenshot. The last messages should let me figure out why the bracketing sequence stopped.