mysterious dual iso colour flicker

[70MM13]

I shot a few scenes recently using dual iso for high dynamic range shots, and somehow the footage has a strange intermittent flickering of the colours, as though the gamma and colour temperature are being toggled back and forth.

It's quite pronounced when using mlvapp, and less so if the frames are extracted (without vertical squeezing) and then processed with cr2hdr, although it is still there, and unfortunately that introduces aliasing since it won't accept the squeezed files (from what I am seeing - has this changed?)

ANY help would be greatly appreciated.  This is a showstopper for me.  I'll take noisy shadows over this...

Please help!

thanks

https://drive.google.com/open?id=1UyKeZmNzaxvodNWA9yUPAIAq8FBFxJd-

[a1ex]

With cr2hdr, the flicker comes from this:

Code: [Select]

Linear fit      : y = 7.9666*x - 0.65
Linear fit      : y = 7.9500*x - 0.64

That is, the two exposures were matched slightly differently in the two images. That's because cr2hdr was written with still photos in mind, so it analyzes every single frame.

Solution: the algorithm should be updated to operate in two passes: one to analyze all images, and another to process all images with the same parameters.


Why did this large difference appear?

These two frames are underexposed - by at least 4 stops in the high-ISO frame. That is, the algorithm didn't have good data to perform a robust exposure match. Running cr2hdr with --iso-curve, to debug this process, shows some weird graphs.

One of the green channels from the bright image saturates in an unusual way. Not sure if that's a problem only in this particular clip, or in all clips recorded at the same settings. This could be a bug in crop_rec, or a quirk of the 1x3 readout. In any case, it's an issue with the raw image data (at capture time).

BTW, there's no point in using Dual ISO 100/800 in very underexposed scenes. You will get much better results with plain ISO 6400.

TLDR: edge case, can be fixed, not a priority for me atm.

[70MM13]

thanks for the info...  I was exposing for the sunlight in a dark area, so it is what it is...  what's the point of using dual iso if the highlights are blown out?

oh well.  thanks again for the info.

[a1ex]

Wait, were you using some kind of 10/12-bit recording? That doesn't play nice with Dual ISO, because of the reduced range (cr2hdr is hardcoded for 14-bit levels). In any case, I'm unable to locate any clipped highlights, so I thought the image was actually underexposed by 4+3 = 7 stops. My bad, it was only underexposed by 3 stops.

So, for this scene, you should have used plain ISO 800.

For Dual ISO, I recommend exposing to the right for the lower ISO. This was discussed many times in the past.

[70MM13]

i'm only responding now, so late, because someone else made reference to this thread recently:

the scene was not underexposed.

this is only a portion of a motion picture scene, one in which the lighting changes, as is apt to happen in MOTION pictures.

it was indeed exposed to the right, for a different part of the same scene not included in the tiny attachment.

the flickering issue persists to this day and it is not a corner case.  it happens whenever there is changing light during a scene that crosses the line between the two exposures.

it remains a showstopper for dual iso in real cinematic use.

[Kharak]

Commenting on a more than 1 and half year old “case”.

 Would be nice if you could clarify if you did record in lower bit depth in this case.

[70MM13]

the original mlv is long gone, so i cannot say for certain about any bit depth reduction on that file, but i gave dual iso another shot 2 months ago in one of my music videos and the problem was still there, and it was definitely 14 bit.  in this scene, i'm playing a synth in the studio, and the reflective highlights on the control knobs make the image flicker when i move around and block the reflections...

in another shot, pulsing LEDs on a synth made the image flicker.

it's not difficult to reproduce this issue.  just have a scene with wide dynamic range and a single light source (the kind you would be using dual iso to capture!) and see how the image changes when you block the light.

walking in front of a light bulb would work.

[Kharak]

Pulsing lights, exposure change when blocking/revealing light... sounds exactly like the issue with ACR flickering. because ACR processes one frame at a time and performs background adjustments to each frame depending on the light/exposure in the scene, you get flicker.

Only way to avoid it is by sticking to .DCP‘s and only adjusting exposure and WB parameters (which are not affecting the flicker).

Not saying you are using ACR, but a1ex already confirmed cr2hdr works on a frame by frame basis, so most likely the culprit regarding the flicker.

[a1ex]

Exactly that's why cr2hdr needs to use the same settings for the entire clip, rather than evaluating every single frame. That means, it needs two passes. There is a workaround, --same-levels, which still evaluates every single frame, but at the end it runs a second pass to equalize them. It's probably not as good as using the same settings from the beginning, but... the test clip used back then (2014) was a night clip with the subject performing in front of a light bulb.

Now the surprise - I've re-rendered your test clip, with and without --same-levels, and couldn't notice any flicker. Not sure where to look - I must be terrible at pixel peeping

Code: [Select]

mlv_dump --dng --no-stripes --no-fixcp M31-0934.MLV
cr2hdr --same-levels *.dng
ufraw-batch --exposure=10 *.DNG   # that's right, exposure boosted by 10 stops, otherwise it was pitch black :)


[70MM13]

that's great!  no flickering

i wish i had used such steps back when i did this footage.  i had used barracudaGUI and obviously something doesn't work there.  also mlvapp was/is the same.  i just tried it again with the latest version and it still flickers.

maybe they could look at your procedure and make sure they are doing it properly...

it's a shame i no longer have the source for that video.  i would reprocess it using your steps!

BTW: in this scene the camera is tilting from the forest floor to the sky.  it gets a LOT brighter

thanks for the info, hopefully it gets put to use!

[masc]

also mlvapp was/is the same.  i just tried it again with the latest version and it still flickers.

maybe they could look at your procedure and make sure they are doing it properly...

The used versions are very different. We had no success in trying what you suggest.

[70MM13]

is there anyone out there who is willing/able to port the mlv_dump code to mlv app?