Gradual exposure transitions?

[uuderzo]

Hello all!
I'm trying to shoot clips in Aperture priority mode while moving from dark to light areas. While in the live view i see a very nice exposure ramping, if i review the MLV sequence in post i notice jumps in exposure.
I tried to use the deflickr module and to follow some post processing workflows, for example by correcting the black and white levels on the DNG sequence with EXIFTool, but they are the same over the whole clip.
What should i check to reproduce those smooth exposure transitions in my editing environment? (Resolve in my case)
Thank you!

[uuderzo]

Maybe i did something dumb...
I'm using MLRawViewer to convert MLV to CDNG sequences. Do i need to set something to enable smooth exposure transitions?
Would enabling video logging on the 5DMKIII add some support infos to help in the conversion?
Or simply it's not possible and the only way is to shot in manual mode?

Thank you again!

[a1ex]

MLVFS has support for smooth exposure transitions (deflicker).

In camera, these transitions currently use digital ISO adjustments, which do not affect the raw image data (so it only works "out of the box" in H.264).

It can be rewritten to use only shutter adjustments and full-stop ISOs, just there wasn't any pressing need to do so.

[uuderzo]

Thank a1ex for the reply.
I'm fine with digital ISO adjustments, definitely better than changing the shutter speed.

What i'm finding really difficult is to use MLFS + PFM (i'm on Win7x64) to get my files (i managed to create the MLV virtual folder but didn't understand how to pass the deflicker parameter so at the end i get the same result as MlRAWViewer).
Anyway, if i activate the video logging (which produces a frame by frame log file along the MLV file, with all parameters changes) is there some application that can leverage on this information to render a correct video sequence?
I'm just asking because i don't really know how to handle this log file by myself, and if it can be of any help.

Thanks!

[dmilligan]

The PFM version of MLVFS is very old and doesn't have the deflicker stuff. You'll need the latest version (dokany). Also, the deflicker amount computed by MLVFS is added as metadata to the DNG, not all raw processors honor this tag (ACR does, others IDK).

[uuderzo]

Thanks dmilligan for the hint!

Finally managed to understand how to achieve my result:
1) enable raw logging into Magic Lantern. Without raw logging no smoothing is possible
2) install MLVFS... not butter smooth but i guess it's not meant to be super easy. anyway, installed
3) resolve recognizes the metadata as it reacts correctly.

Now i'm asking myself if the deflicker algorithm speed can be biased. Is the result computed over all the clip length as some kind of interpolation? I noticed that the deflicker parameter drives some kind of exposure level, not smoothing time. I guess that modules such as exposure ramping are not effective in biasing the speed, as they are developed for timelapse...

I beg your patience... I suppose that the best way to get what i want is to plug a cinema lens with declicked aperture ring and work with aperture while shifting from light to dark zones... and deflicker is some kind of "placebo" feature? without offence to the feature itself, just to understand the feature.

Thanks again!

[dmilligan]

The deflicker algorithm simply attempts to hold the exposure (the apparent brightness) of every frame constant. It simply adjusts the exposure of each frame so that the median matches the given parameter. It analyzes actual image data and gives no regard to exposure parameters or anything else.

I suppose it would be possible to write a different sort of algorithm that does closer to what it seems you want, either by logging the digital ISO values in the MLV file and then using those in the exposure offset tag, or by detecting changes to exposure parameters (full mlv_rec only, wouldn't work with mlv_lite) and automatically ramping between them.

[uuderzo]

Now the current algorithm is more clear to me, thanks dmilligan!

What i expected is to keep the current exposure as it is, and just ramping between ISO steps, which is different from the deflicker algorithm that is based only on the current frame analisys. This way the image would be kept as near to the original shot as possible, with a slight adaption only when ramping.
Something like a new iso-smooting-frames parameter, that let the user specify how many frames (at maximum) take for a ramp. Obviously if a ramp needs less frames to be accomplished, less frames would be used. Sure this algorithm needs to know what's before and what's after the current frame. I don't know MLVFS internals, i can imagine you already keep some kind of cache with frame parameters so you don't need to rebuild everything from scratch, but i'm just guessing.

I am a programmer but i fear i would take forever to wrap my mind around MLVFS code... i have not big money for my project (otherwise i had purchased a set of Rokinon Cinema lenses LOL) but if a contribution can help the development please let me know!

P.S. regardless i activate or not RAW video logging in movie tweaks, i cannot manage the 5DMKIII to produce the video *.log file with parameters changes. And MLFVS shows an empty *.log file. Where i'm wrong? I supposed that ML would write a sidecar log file, but this doesn't look so. It's all kept into the MLV file?

Thanks!

[Danne]

Is it ramping you´re after? Seen dmilligan script here?
http://www.magiclantern.fm/forum/index.php?topic=8850.0

[mothaibaphoto]

@uuderzo: Don't mislead folks here and on BM forum: DR not only ignores ACR metadata tags, but not supports RAW parameters ramping at all. Read more here:
http://www.bmcuser.com/showthread.php?5007-Setting-Exposure
I wish to be wrong, though.

[uuderzo]

@Danne: This may be what i'm after. I stopped using Bridge several years ago but now i'll give it one more  spin! Thanks.

@mothaibaphoto: I didn't mean to mislead anyone. Sorry if what i wrote made me looking a bad-guy. I simply performed some tests and drawn some conclusions. Too bad information is so fragmented that is very difficult to find an easy answer. Or maybe i didn't search enough, it's possible.

I simply performed the following tests:
1) Extracted the frames with MLRAWViewer: noticed that there are huge steps in exposure on my footage.

2) Extracted the frames with MLVFS with no parameters: same huge steps.

3) Extracted the frames with MLVFS and --deflicker parameter: noticed a better smoothing in exposure steps, not what i'm after but better than nothing. Given that dmilligan wrote that the deflicker algorithm writes into DNG metadata and that not all NLEs can interpret such metadata, by noticing a difference in DR my conclusion was that DR supports the metadata. Maybe this is a wrong conclusion so if you can correct me i'm more than happy. But i'm not a bad guy, just trying to learn something new.

P.S. The thread you linked stopped at 2013. Maybe more recent DR version addressed the metadata issue? Don't know.

[a1ex]

I am a programmer but i fear i would take forever to wrap my mind around MLVFS code... i have not big money for my project (otherwise i had purchased a set of Rokinon Cinema lenses LOL) but if a contribution can help the development please let me know!

That means the most difficult part is overcoming your fear of digging in a foreign codebase.

This particular task should be doable with shell scripting around mlv_dump and exiftool. All the metadata logged in a MLV is available with mlv_dump -v, and exposure compensation for DNGs can be set using exiftool (or, if your raw processing software doesn't follow any exposure-related tags, some sidecar files in the format supported by your raw processor should do the trick).

The lowest common denominator would be white level. For example, to make the image twice as bright (+1 EV of exposure compensation), simply set white level twice as small, relative to black level - which will be simply (old_white + black) / 2. A more general formula would be new_white = (old_white - black) / exposure_factor + black.

The problem with this approach is that you cannot use negative exposure compensation if your footage has overexposed areas (otherwise you'll just get pink highlights). In this case, letting the raw processor do the exposure compensation will most likely enable its highlight recovery routines, with better results in those areas where only one or two color channels are clipped.

Otherwise, changing white level with the above formula guarantees linear changes in brightness (while the exposure compensation implemented in your raw processor may not be linear - for example, a positive exposure compensation may also use some highlight roll-off; in this case, the exposure jumps will probably not be compensated perfectly). That's just theory, as I've only tried the deflicker method in my modified clone of ufraw, and that was years ago.

[dmilligan]

DR not only ignores ACR metadata tags, but not supports RAW parameters ramping at all.

The tag in question is not specifically ACR metadata (XMP Exposure), but rather a tag that's part of the DNG spec called BaselineExposure. It *should* be honored by all raw processors, but that doesn't mean it is.

[uuderzo]

Gave a spin to Bridge. Guess that CS5 is a bit too "vintage" for the script as apparently there is no result (watching with Bridge).
Anyway i fear that this would not be the right solution for Resolve, if Resolve is not capable to understand ACR metadata. The alternative algorithm that dmilligan suggested for MLVFS looks more appealing for my case.

I will try to dip my foot into dmilligan code, hope being able to remember how to code in C (usually a Java developer, with some spare time C++).
My offer for a contribution is still valid, anyway