Auto ETTR based on RAW histogram (ettr.mo)

[a1ex]

I have some problem, when I using ETTR with 1/2 stop for shooting timelapse and postprocess it with LRTimelapse. LRTimelapse can work only with step 1/3 stop. Can I change some settings ETTR for change step from 1/2 to 1/3?

You'll have to change the code, and it's not trivial. You'll need to disallow 1/2-stop exposures and account for the rounding used in 1/3-stop mode (actually 3/8 and 5/8).

To my knowledge, LRTimelapse is a commercial program, so you might have better luck with feature requests there.

That said, we have our own deflickering tools that do not use the EXIF info at all. Some examples:
- Deflicker module (original version, not very practical, as deflickering is best done in post)
- Bridge script (similar algorithm, but requires proprietary software)
- mlvfs --deflicker and mlv_dump --deflicker (for MLV timelapse, e.g. silent pics or raw video)

The same deflickering algorithm is available in Darktable.

[Psih]

The smaller the steps, the better the results - therefore I need this option and I am ready to pay for this option. Can somebody do it?

[Audionut]

The smaller the steps, the better the results

Proof.  Use images, we already understand the science.

[Psih]

I'm getting better results, when I stop shoot with ETTR and start use qDSLRdashboard. The transition between day and night is more smooth. I can't provide any proof, only my experience on shooting timelapse. I'm regularly shoot timelapses and I want this option and I can pay. If it is impossible, I will search another way (timelapse+ for example).
I'm sorry for double post.

[Audionut]

The transition between day and night is more smooth.

Post processing issue.  The following may help.

That said, we have our own deflickering tools that do not use the EXIF info at all. Some examples:
- Deflicker module (original version, not very practical, as deflickering is best done in post)
- Bridge script (similar algorithm, but requires proprietary software)
- mlvfs --deflicker and mlv_dump --deflicker (for MLV timelapse, e.g. silent pics or raw video)

The same deflickering algorithm is available in Darktable.

[Psih]

Post processing the same in both case (ETTR and qDSLRdashboard) and I don't think that problem is in one. I think, if this feature is so difficult, I can find another way. Timelapse+ cost 400$. If nobody can't solve this problem, this is sad, but I will buy Timelapse+.

[Audionut]

If you're not willing to spend time solving the post processing issue, part with your $400.  That choice is entirely yours.

Exposure matching is exposure matching.  Doesn't matter how different the images are, whether those images are captured with 1/3 stop or 1/2 stop exposure settings (exposure is changing during day > night even with exact same camera exposure settings), there is an exposure difference, and this exposure difference needs to be calculated.

If the post processing software is struggling with the difference between camera exposure settings (1/3 vs 1/2 stop), then the issue lies within the post processing software.

Having narrower exposure differences is always better (from a pure quality standpoint).  Mostly for pixel peeping, but credit where it's due.  However, and to answer your other question.

You'll have to change the code, and it's not trivial. You'll need to disallow 1/2-stop exposures and account for the rounding used in 1/3-stop mode (actually 3/8 and 5/8).

I would advise leaving the comfortable box, trying other post processing software, before parting with $400, but it's your $'s and your decision.  Personally I've had good results with the bridge script, but I was only playing, nothing serious, and I've not used the mlvfs or mlv_dump options.

For me, the end goal is not to provide a finished product that everybody can consume. I'd rather see it as an open software platform where others can program their own enhancements and share them with the community

This is a development based community, where we contribute with skills and knowledge, not monetary offers.

[a1ex]

Just FYI - an older example with the deflicker algorithm used in the tools mentioned earlier:

Don't know whether the transition is smooth enough for your needs or not, but I'm pretty sure that using 1/3 stops instead of 1/2 won't make any noticeable difference. You may notice exposure jumps much larger than 1/2 EV in the input video (the one displayed in smaller size).

[c_joerg]

Exposure matching is exposure matching.  Doesn't matter how different the images are, whether those images are captured with 1/3 stop or 1/2 stop exposure settings

Just for understanding.
This video is made with 1/3 stops end I can't correct the pumping sun in post because the core of the sun is blown out.

If I were to create these recordings with ETTR then you could probably correct it but then I would lose a lot of information especially in the dark areas.

I really like the CHDK part where I can change exposure in 1/96 stops...

[Audionut]

If I were to create these recordings with ETTR then you could probably correct it but then I would lose a lot of information especially in the dark areas.

There's built in protection for shadows..

My bold.

Last week I had some time to play with ETTR and I think I've found a way to avoid the severe underexposure in scenes with high dynamic range (e.g. like this).

https://bitbucket.org/hudson/magic-lantern/commits/fcdc23eb5d7d

How it works:
- If the midtones get too noisy, the ETTR algorithm will stop underexposing.
- Same thing if the shadows get too noisy.

How to quantify "too noisy"?

For midtones it's easy: the median "brightness" gives you the signal level, so we can use the SNR. So, when I say the midtone SNR is 5 EV, this means half of the image has a SNR less than 5 EV, and the other half has a SNR higher than 5 EV. Pretty easy and statistically robust.

For shadows, I've chosen the 5% percentile. So, in this context, the shadows having a SNR of 3 EV means 5% of the image pixels have a SNR lower than 3 EV, and the other pixels will be brighter than that.

Keep in mind that 5% is bigger than you may think, since it refers to image area, not linear size. The linear percentage is roughly 22% (1/4.5).

So, you can choose 2 noise limits, one for midtones and one for shadows, and the image will not get noisier than that (but you may lose some highlights). This setting has the highest priority, so it will sacrifice highlights even if you disallow clipping from the other settings.

I'm not yet sure what are some good defaults for this new trick, so it's turned off by default.

[mothaibaphoto]

ETTR in recent builds is not usable in low light.

I used to shoot a lot of timelapses before 4K video era begins.
I even shared my hard earned settings for getting amazing sunrises:
https://www.magiclantern.fm/forum/index.php?topic=18730.msg178621#msg178621
Recently i tried to shoot timelapse with recent build and failed.
Now i try to sort out whats wrong.  What i found: as long, as i reduce light, the image on LCD gets more pixelated,
histigram shows overexposure, ETTR shortens exposure(!!!), but screen gets only brighter and brighter and, finally complete white.
It saves completely black DNG, of course.
I compared the ettr source of recent build with the old one.
I found suspicious new code:

Code Select Expand

if (overexposed_percentage > 0 && (auto_ettr_midtone_snr_limit || auto_ettr_shadow_snr_limit) && !dual_iso)
I enabled DualISO, to test, whether this is the source of problem - and it disappeared.
Instead of white screen I gets correctly exposed images with several second exposures.
I decided to comment this out and try without DualISO - problem persist.
DualISO fixes the problem somehow, but that code is not the source of it.
So, i stuck on it, have no more ideas, my humble skills don't allow me to find why it used to work but no more

[a1ex]

Can you upload some sample images used by ETTR to meter from?

In other words, if you have used ETTR outside LiveView, the CR2 files should be enough, but if you have metered in LiveView, you will need to provide DNG frames from LiveView.

What i found: as long, as i reduce light, the image on LCD gets more pixelated,

If you have attempted to meter long exposures from 1/30" LiveView frames... I'm not sure what I can do.

[mothaibaphoto]

If you have attempted to meter long exposures from 1/30" LiveView frames... I'm not sure what I can do.

Yes, it's seems that is the point: ETTR (not me) tries to calculate exposure from that mess.
Finally, it deals with completly white LCD preview, but saves completely black DNG.
And only if DualISO is activated, it calculates exposure from actually taken images.
How can I avoid this? As I mentioned, I shoot timelapse:
Photo mode Live view, silent Full-Res, compressed DNG (tried MLV, the same story).
It used to work all the time this way.
I think it's unnecessary to upload the perfectly black DNG.

[a1ex]

I think it's unnecessary to upload the perfectly black DNG.

If ETTR metered from there, the image might be relevant.

I've tried to reproduce the issue on crop_rec_4k build and I think I've figured it out. During the timelapse, camera stays outside LiveView, in powersaving mode, with mirror up; the screen turns on for a few seconds for reviewing each image. ETTR is definitely metering from captured images.

When pointing the camera from some relatively dark scene (after it settled to 0.5" at ISO 100) to some very dark scene (that would have required 16" at some higher ISO), the first image was nearly black (as expected) and ETTR switched the exposure to 1/8000 (without any intermediate steps). That only happens when it believes the image is extremely overexposed.

Checking the white level of the black DNGs revealed values below 2500, which is clearly incorrect. This appears to be introduced by a change discussed around here: in photo mode, ML raw backend tries to guess the white level starting from the value reported by Canon (as that appeared to be a better approximation than some hardcoded value, i.e. what earlier builds did). The issue is that in FRSP mode, unlike regular photo mode, Canon code does not report any white level; it reports 0, so ML ended up scanning for the brightest pixels in the actual image. If these brightest pixels appear as a peak on the right side of the raw histogram (quite likely to happen with a dark frame), ML assumes the image is overexposed and picks a white level right below that "pitch black".

Please try some less bleeding-edge build (either unified or lua_fix) and report back.

[mothaibaphoto]

Thank you, a1ex, you are very helpful, as always!!!
I updated that code in raw.c: when silent enabled, your old code is running:

Code Select Expand


    if (!lv)
    {
if (is_module_enabled("silent"))
{
/* at ISO 160, 320 etc, the white level is decreased by -1/3 EV */
/* in LiveView, it doesn't change */
int iso = 0;
if (!iso) iso = lens_info.raw_iso;
if (!iso) iso = lens_info.raw_iso_auto;
static int last_iso = 0;
if (!iso) iso = last_iso;
last_iso = iso;
if (!iso) return 0;
int iso_rounded = COERCE((iso + 3) / 8 * 8, 72, 200);
float iso_digital = (iso - iso_rounded) / 8.0f;

if (iso_digital <= 0)
{
raw_info.white_level -= raw_info.black_level;
raw_info.white_level *= powf(2, iso_digital);
raw_info.white_level += raw_info.black_level;
}

raw_info.white_level = autodetect_white_level(raw_info.white_level);
raw_info.dynamic_range = compute_dynamic_range(black_mean, black_stdev_x100, raw_info.white_level);
}
else
{
/* start at Canon's white level, and autodetect from there
* Canon's guess may be up to 0.38 EV below the true value - or maybe more?
* http://www.magiclantern.fm/forum/index.php?topic=20579.msg190437#msg190437
*/
int canon_white = shamem_read(0xC0F12054) >> 16;
raw_info.white_level = autodetect_white_level(canon_white);
raw_info.dynamic_range = compute_dynamic_range(black_mean, black_stdev_x100, raw_info.white_level);
printf("White level: %d -> %d\n", canon_white, raw_info.white_level);
}
    }


That fixes the problem, but... now it occasionally ens up stuck with "Raw error".
Need long(5+ sec) exposures, high ISO(400+) and DualISO disabled.
There are 6 occurences of that message in source, so I made all 6 different and found,
that it is the first one in the auto_ettr_step() procedure in ettr module.
It looks like i leave DualISO enabled even if overcast

[a1ex]

now it occasionally ens up stuck with "Raw error".

I highly doubt leaving dual iso enabled is going to fix this. The code snippet you have found simply selects some different heuristic for fixing overexposed highlights (a quirk that I need to fix somehow, but not related to your errors).

The "raw error" coming from raw.c also has different causes. Look for this line:

Code Select Expand


    else if (QR_MODE) // image review after taking pics


and you'll be able to see these conditions. Wherever the code is returning 0, that's some error condition. If you turn these dbg_printf's into plain printf's, you'll see these messages on the console.

Most likely, the failure reason is some black level check gone wrong, possibly caused by hot pixels. Look for this line:

Code Select Expand


            /* for debugging: if black check fails, save the bad frame as DNG */


and enable that block, i.e. turn it into if(1). You'll get these bad frames saved as DNGs on the card.

These DNGs will allow me to re-run the entire thing (raw overlays + ETTR code) from QEMU, on exactly the same image that caused trouble.

[mothaibaphoto]

That debugging kinda works... once, and crashes the camera with ERR70 on top LCD
Nethertheless, here is bad dng and 3 generated crash logs:
https://www.dropbox.com/sh/8h4ssn4l8v1mjjo/AABFZ9T1zwDKMFhSJWakZxAfa?dl=0

[a1ex]

Indeed, a hot pixel in the optical black area. Need to use robust statistics for checking the noise levels, i.e. MAD instead of stdev.

That ERR70 must be caused by ML allocating a huge chunk of memory while Canon code is still processing the image. Adding some delay might fix the error. Removing that malloc and saving the DNG directly might work, too. Both changes will interfere with LiveView (where I had to use that debugging code).

[mothaibaphoto]

Ok, thank you!!!
I had that "Raw error" occasionally from time to time before.
It's not so serious problem due it's rare.
At least, now I know that it could be avoided by DualISO( I'm sure, tried several times).
That incorrect canon's white level with silent was real show stopper, and gladly it fixed.

[yoback]

Hey, can someone tell me where can I download it for canon 6d? I was serchin for a 2 hours..