Is there a way to tell the camera to meter on human subjects' skin tones?

[mlrocks]

Is there a way to tell the camera to meter on human subjects' skin tones like face and eyes as the basis, then auto ETTR and dual ISO accordingly?
I used auto ETTR and dual ISO together, and found out that they are good for the whole scene, like a street with high rising buildings under the noon sun, but the human faces may be darkened.

[mlrocks]

Hope there is something like spot metering on the human skin or eyes, then ettr based on this. I guess the current versions of auto ETTR and dual ISO are based on Canon's matrix metering, which is actually very good for the whole scene.

[masc]

ETTR works for the entire picture, no matter what you record.

[mlrocks]

Thanks for the reply, MASC. Probably this auto ETTR + dual ISO is more useful for landscape than for street videography or portrait.

Another question: when I used 650D UHD 1X3 anamorphic 24 fps 10 bit color depth 14-bit lossless LJ92, sometimes the auto ETTR and dual ISO worked, sometimes they did not work. I activated as few modules as possible to avoid conflicts. For the dual ISO activated footage, I processed them in MLV App using force dual ISO on and interpolation Amaze, the footage in dark area showed very light purple/pink flicker. Sometimes in other modes, there was no such behavior. Maybe some specific presets are good for these two modules?

[masc]

It is known, that DualISO doesn't work good in MLVApp. Just don't use it. We well disable it for the next version. Instead use mlv_dump.

[IDA_ML]

It is known, that DualISO doesn't work good in MLVApp. Just don't use it. We well disable it for the next version. Instead use mlv_dump.

Well, it works for me and does a hell of a job when filming high-contrast scenes where the sensor does not provide sufficient dynamic range.  I have not noticed any flickering or disturbing behavior of any kind so far.  The result is so much better compared to a normal MLV that I will continue using Dual ISO every time when appropriate.  See (below) for yourself'.

I have just performed a short test to see how Dual ISO works with the latest v. 1.13 of MLVApp.  I filmed a high-contrast scene with the 5D3 at the anamorphic 1392x2340/24fps/12bit lossless mode with 1) Dual ISO 100/3200 and 2) Normal MLV without Dual ISO for comparison.  Here is the H.265 444 result out of MLVApp, after a few very conservative adjustments:

https://we.tl/t-kqfXZeCiio

I have also included a 1-frame MLV from the original files.  The above link will be active for 7 days.

Masc,

Personally I think that Dual ISO is one of the most revolutionary developments of ML since it provides the most naturally looking result compared to other HDR techniques.  I also use it a lot with Dual ISO still RAW files.  It works extremely well in low light when using the full-resolution live view mode at low shutter speeds hand held when you don't carry a tripod.  Filming short MLV clips at that setting and shutter speeds as low as 1/4 s. allows you to select the sharpest frame out of 20-30 frames in the clip.  It would be a great mistake if in the next versions, MLVApp is deprived of this fantastic feature.  My suggestion is to leave Dual ISO as it is.  People can then decide by themselves if it works for them or not.

[masc]

@IDA_ML: I agree that dualiso is great. But for the algorithm in MLVApp: it is proved to be wrong - I am a bit sad about that too. To get the mlv_dump algorithm into MLVApp is not impossible, but will need much much work because it is very different. If the MLVApp version works for you, it is luck - for many people it did not work and brings flickering, which does not show up when using mlv_dump.

[IDA_ML]

@IDA_ML: I agree that dualiso is great. But for the algorithm in MLVApp: it is proved to be wrong - I am a bit sad about that too. To get the mlv_dump algorithm into MLVApp is not impossible, but will need much much work because it is very different. If the MLVApp version works for you, it is luck - for many people it did not work and brings flickering, which does not show up when using mlv_dump.

Thank you for this clarification, Mask.  I still think that the current Dual ISO function should not be removed from MLVApp, even if there might be flickering in some cases.  Also, is there a specific version of MLV dump that works with Dual ISO?  If yes, could you please post a download link?  I will perform more tests and when I get flickering with MLVApp, I will see how it works with MLV dump.

And a final question.  Do you get flickering with your 5D3 when using Dual ISO?  I am asking because, watching these videos:

https://www.magiclantern.fm/forum/index.php?topic=26133.msg236318;topicseen#msg236318

also shot on the 5D3, I do not see any perceptible flickering.  Could the flickering issue be camera specific?

[Danne]

Old mlvfs dualiso code proven unreliable many times in Mlv app. Use latest version of cr2hdr for reliable results and 14bit. In Switch I use latest changes from a1ex.
Even if you get a few good results here and there in Mlv app eventually it'll break. More work needs to be done porting cr2hdr refinements imo or we need to face reoccuring issues around dualiso in movie files. Too bad really because with 1x3 binning dual iso is not that bad actually.

[IDA_ML]

Even if you get a few good results here and there in Mlv app eventually it'll break. More work needs to be done porting cr2hdr refinements imo or we need to face reoccuring issues around dualiso in movie files. Too bad really because with 1x3 binning dual iso is not that bad actually.

In fact, the results are excellent - very clean and with beautiful rich colors and a lot of detail!  This is because we've got plenty of vertical resolution.   Even aliasing and moire are pretty low.  I still don't undersdtand why "it will break eventually".  There must be a reason for that.  Is it a randomly occuring phenomenon?  Got to test it with the 100D too and see if I get flickering on that camera.

[theBilalFakhouri]

It would be a bad idea to remove Dual ISO processing in MLVApp, at least leave it there with "Outdated" warning, most of time it works greatly for me.

..for many people it did not work and brings flickering, which does not show up when using mlv_dump.

When using mlv_dump?! do you mean cr2hdr? or the way of extracting DNGs from MLV files is better in mlv_dump than MLVApp?

Note:
I have flickering issue when using Dual ISO with most 1x3 modes (14-bit lossless), this flickering does also shows when processing Dual ISO clip using the latest cr2hdr with "--same-levels" option, it's strange that this flickering happens in 4.3K/4K/UHD 1x3 modes, but not in 4.5K 1x3 preset which works greatly with Dual ISO and MLVApp processing, what I am saying is it's not completely a MLVApp fault . . it would be too bad to remove it as option for Dual ISO processing.

Last time I tried cr2hdr and had a flickering issue was 5 days ago, it's a fresh test.
Just in case if I was doing something wrong I can provide a short MLV with Dual ISO with flickering issue, if someone want to make a test to process it with cr2hdr (I tested both latest Linux and Windows versions, same result).

[mlrocks]

In fact, the results are excellent - very clean and with beautiful rich colors and a lot of detail!  This is because we've got plenty of vertical resolution.   Even aliasing and moire are pretty low.  I still don't undersdtand why "it will break eventually".  There must be a reason for that.  Is it a randomly occuring phenomenon?  Got to test it with the 100D too and see if I get flickering on that camera.

This makes sense that 1x3 modes have more vertical lines, so more resistant to aliasing and moire. I notice that for 1x3 UHD on 650D the dual ISO footage has very clean highlight area. At least I have not noticed anything significantly wrong. Whereas, for 1x1 1080p on 650D in dual ISO mode, although it does not have pink flickering in the shade area, it has something like rolling shutter effects (like a wheel constantly turning) in the highlight area. Because highlight area typically attracts eyes more, the effects are very noticeable.

[mlrocks]

It would be a bad idea to remove Dual ISO processing in MLVApp, at least leave it there with "Outdated" warning, most of time it works greatly for me.

When using mlv_dump?! do you mean cr2hdr? or the way of extracting DNGs from MLV files is better in mlv_dump than MLVApp?

Note:
I have flickering issue when using Dual ISO with most 1x3 modes (14-bit lossless), this flickering does also shows when processing Dual ISO clip using the latest cr2hdr with "--same-levels" option, it's strange that this flickering happens in 4.3K/4K/UHD 1x3 modes, but not in 4.5K 1x3 preset which works greatly with Dual ISO and MLVApp processing, what I am saying is it's not completely a MLVApp fault . . it would be too bad to remove it as option for Dual ISO processing.

Last time I tried cr2hdr and had a flickering issue was 5 days ago, it's a fresh test.
Just in case if I was doing something wrong I can provide a short MLV with Dual ISO with flickering issue, if someone want to make a test to process it with cr2hdr (I tested both latest Linux and Windows versions, same result).

If 4.5k 1x3 has no flickering, then very possibly this effect is preset dependent, or camera dependent, instead of MLV App dependent.

[Danne]

Last time I tried cr2hdr and had a flickering issue was 5 days ago, it's a fresh test.
Just in case if I was doing something wrong I can provide a short MLV with Dual ISO with flickering issue, if someone want to make a test to process it with cr2hdr (I tested both latest Linux and Windows versions, same result).

If you can provide a short mlv in which you safely could reproduce the flicker go ahead.
It could probably become flicker free. Besides it's maybe not even flicker due to same white level. Other issues causes flicker.
Could you try mlv_dump and cr2dr from this fork and branch? Also try and disable it any pixel fixing settings, maybe test without applying vertical stripes correction.
https://bitbucket.org/Dannephoto/magic-lantern_jip_hop_git/src/master/

Dualiso is having a lot of undeserved bad attention because of these, mostly fixed issues. It's not working well enough in Mlv app imo. If someone would fix it, that"s another story.

If 4.5k 1x3 has no flickering, then very possibly this effect is preset dependent, or camera dependent, instead of MLV App dependent.

Simply not. If you want to help please take the long route here, start by providing test mlv files. Important we stick to test files and exactly knows what code is being tested.

[theBilalFakhouri]

If you can provide a short mlv in which you safely could reproduce the flicker go ahead.

Okay, here you go:
https://drive.google.com/drive/folders/1GWcN1-BCmu-DarirzQQrYmSUI4ZwmWmK?usp=sharing

There are three MLV clips with Dual ISO (1x3 Binning, 14-bit lossless, straight out of the camera I didn't shorten it in MLVApp just in case, each clip is about ~3 seconds long):

-M03-2337 - 4.5K: Doesn't have flickering issue, can be processed in MLVApp without any problem.
-M03-2338 - 4.3K: Does have flickering issue, the flickering pattern is first frame is dark, second frame is bright, third frame is dark and so on, has flickering issue both in MLVApp and cr2hdr
-M03-2339 - 4K:    Does have flickering issue, the flickering pattern is the first two frames are dark, second two frames are bright and so on, has flickering issue both in MLVApp and cr2hdr

-After Dual ISO processing, set the exposure to +3.0 to make the flicker more visible.

I tried to with with disabled RAW processing (vertical stripes, bad pixels fix) using mlv_dump and cr2hdr, same problem . . the Linux cr2hdr version I have tested wasn't the latest one, couldn't compile it, but I used the latest cr2hdr for Windows and I had the same problem.

[reddeercity]

@ theBilalFakhouri ,did you enable the deflick.mo ?
I don't have any problem when the deflick.mo is enable and processed with either cr2dr or MLVFS .

[Danne]

I tried to with with disabled RAW processing (vertical stripes, bad pixels fix) using mlv_dump and cr2hdr, same problem . . the Linux cr2hdr version I have tested wasn't the latest one, couldn't compile it, but I used the latest cr2hdr for Windows and I had the same problem.

I tested my tools but couldn´t get the file to even open after conversion. That´s where I stop unfortunately. No time atm.
I am pretty sure that official cr2hdr don´t include a1ex final changes in cr2hdr. You could ask him for an updated verision or where to look. Since I don´t have my system all set with source tree etc I can´t really look for which fork was used but I am pretty sure I included the changes in my latest version. Since I really can´t get any data out of your file I need to check my tools as well.

On a sidenote. This is what tend to happen. A bunch of variables reinvestigated over and over without coming to any new conclusions. Long story short. dualiso is a wonderful thing. For photos. I you want to save yourself one week of hassle. Stay off the movie mode routine .

Thanks for the files by the way.

[mlrocks]

Out of curiosity, I did a test on 650D using the following mode:

1. movie crop, constant bit rate 2.0, on camera h264 codec, clear picture style, 1920x1080, 24 fps
2. movie crop, mlv raw, 1x1, 1800x1000, 14 bit, 14-bit lossless compression, 24 fps
3. crop, mlv raw, 1x1, 1920x1080, 14 bit, 14-bit lossless compression, 24 fps

I did not use dual ISO on 650D in these mode, only used auto ETTR.

Foliage test is actually a very good challenge for cameras and lenses. The stock h264 footage had much narrower dynamic range. The tree leaf edges were muddy. There was no comparison. The file sizes were almost the same as the mlv raw processed files (mlv app export h264 mp4 hq). Byebye, Canon stock codec.
The 1800x1000 mode had a little bit less resolution than the 1920x1080 1x1 mode. The 1800x1000 mode also has lower resolution magic zoom. However, in the 1800x1000 mode, the set button can be assigned to auto ETTR, which is very nice in a fast changing environment. The IQ of the 1800x1000 is good enough for sharing original footage on smart phones, for uploading onto youtube, vimeo, facebook, etc, and for broadcasting on TV. It is acceptable but not perfect on computer monitor in full screen mode.

I will test dual ISO on 5D3 in different modes in the near future.

[Audionut]

Thanks for the reply, MASC. Probably this auto ETTR + dual ISO is more useful for landscape than for street videography or portrait.

dual ISO is only for high dynamic range scenes, since it doesn't come for free and reduces resolution in the highlights and shadows.

ETTR is predominantly a highlight priority mode, with auto ETTR being an automated version. There's some nifty features of auto ETTR that will be useful for your situation though.

The first being Midtone SNR Limit, which will protect the midtones at the expense of the highlights.

Then you could try the auto ETTR option, Link to Dual ISO if the scene might have high dynamic range.

If you're happy to use the default Canon exposure meter, and skin tones are really important, set to camera to spot metering mode and meter the skin tone.

[mlrocks]

dual ISO is only for high dynamic range scenes, since it doesn't come for free and reduces resolution in the highlights and shadows.

ETTR is predominantly a highlight priority mode, with auto ETTR being an automated version. There's some nifty features of auto ETTR that will be useful for your situation though.

The first being Midtone SNR Limit, which will protect the midtones at the expense of the highlights.

Then you could try the auto ETTR option, Link to Dual ISO if the scene might have high dynamic range.

If you're happy to use the default Canon exposure meter, and skin tones are really important, set to camera to spot metering mode and meter the skin tone.

Thank you very much for the reply, Audionut.  I will try to optimize Midtone SNR Limit.
I found out that ml auto ettr is very useful on 5d3. On 650D, for 1x3 presets, I use manual ettr. Dual ISO is not working in either 5D3 or 650D.