Suggested Black levels and Black Gamma for low-ish light: Cinegamma 1

G

Gene Sung

Veteran
I'm shooting a music video this weekend.

A lot of will be shot in a dark room, lit artificially. I will be using Cinegamma 1

My question is, what would you guy suggest the Black level and Black Gamma settings be. I'm thinking the director will probably crush the blacks a bit more since it will be a dark room, so probably going for more of a contrasty look.

The higher the black level and black gamma, the more noise is introduced into the blacks, correct? So should I keep those two settings at 0 or even lower?

Any other suggestions?

Thanks
 
Have you tried cinegamma2, i'm not in front of anything that i can confirm but i did a lot of low light night stuff under that, i found that out of all the gammas it lifted the shadows more and better than the others. ISO goes down to 500 i think. This is in exchange for less top end and i think cinegamma2 clips at 100%.

Until i start into post i don't know whether my tiny amount of R&D was correct (i had the camera very close to the shooting date and no time at all to test properly)

It certainly looked good on the DP6/internal monitor/checking rushes. My theory was that clipping at 100 meant allocating more bits to the shadows/mids than the higher part of the curve. That is really based on the (un)educated guess that the 0-100 would fill the 0-255 output (i am going to DNxHD via external recorder which complicates matters because DNxHD keeps colours broadcast safe but because it's in 10 bit then the full range of the camera is recorded between those upper and lower 10 bit limits)

I would really like to know how to open up a raw .mov file and check the values inside, before it gets imported into something. Just so i can see for sure what is being recorded. There are so many steps to getting visible data that you're never sure what different apps are doing...

cheers
paul
 
cuervo said:
where did you hear that DNxHD keeps colors broadcast safe? That's not my experience.
Click to expand...

I'd noticed that DNxHD (in this pipeline anyway) was raising the blacks compared to the native AVCHD, i'd pestered blackmagic about this because my concern was that their implementation of DNxHD was clipping the blacks and whites to the 16-235 range, BMD said that the DNxHD container had everything in. Therefore the only way that it could do this would be to put the 0-255 into 64-940 range. Taking the files into AE and grading accordingly seemed to support this was the case.

So i can't say for sure but this has been my assumption so far but i could be misinterpreting various flags in the files. It's a bit of a black art working out what the camera is writing and the workflow after those various stages.

It's fair to say not DNxHD itself but more likely BMD implementation on their Shuttles specifically.

cheers
Paul
 
Paul...
I've been after BMD to PROPERLY implement their usage of DNxHD since they released the Hyperdeck product line. To date, they have not admitted they have an error.

Concurrently, I use BMD's Resolve software, which is a different division of BMD. It's quite clear that the DNxHD codec records full range 0-255 data necessary for the superblacks and superwhites some HD cams are capable of recording. This is verified when I bring these files into the WFM and Histogram within Resolve, as well as the WFM within Avid's Media Composer. The DNxHD codec does, indeed, have a flag that tells whether the data should be interpreted as full range(0-255) or remapped to broadcast legal range(16-235). Implementation of this flag is not being done correctly with BMD's implementation. DaVinci Resolve seems to have gotten this right. I'm not sure why the Davinci folks aren't talking to the BMD Hyperdec codec people.

AFAIK, this issue of remapping superblacks and superwhites (i.e. an RGB range of 0-255) to IRE's of 16-235 is a BMD codec implementation (Hyperdeck) bug and NOT a limitation of DNxHD.

In my own testing of BMD's implementation of the DNxHD codec, I can confirm that you're not losing any data. It isn't being clipped, however it is mapped into the 16-235 RGB color space. However, you raise an interesting question. My tests were done, exclusively with the DNxHD 10-bit version of the codec. If a user is working with the 8-bit version, is something being lost when remapping to 0-255? If you're using an HD cam capable of sensor data in the 0-255 range, then BMD is automatically remapping on their initial data recording. Is this, perhaps, an error in converting YCbCr color space to RGB color space? I'm not knowledgeable enough to answer these questions.

Curiously, enough, I wonder if this problem isn't related to the Quicktime luminance problems that have existed for years. No one seems to have a handle on this issue; and, I find it extremely frustrating that even the experts don't seem to understand the color space issues.
 
Last edited:
i think it's clearly a problem with your post software, i have 2 x BMD recorders, and the DNxHD footage goes into Avid MC & Avid|DS at full range... and it is NOT mapped to 16-235 or properly 64-940 as it's a 10bit codec... it's all there full range 0-1023 every time

I'd look to your choice of post software, chances are that it's the problem, the codec works, just need a toolset that can also work properly.. some use the Qt decoder from your desktop and you can be limited by that, some use custom decoders that maintain the integerity of the media, that would be the tools i use.....

d
 
Dermot,
What you say is true, as I suspect, when you IMPORT the DNxHD codec into MC with the 601/709 option, but, doesn't hold true if you write to the Hyperdeck in the OP1 MXF format..

Are you recording to the Hyperdeck as MXF-OP1, or as a wrapped DNxHD MXF file? My issues exist only with OP1 files as recorded into the Hyperdeck, then brought straight into the Avid MediaFiles/MXF folder.

edit: sorry to the OP for hijacking his thread. This discussion, if worthwhile, should be carried on in its own thread.
 
Stop hijacking my thread Dang It! LOL :)

Anyways, what do you guys suggest setting the black levels and gamma for, when shooting in low light, high contrast situations? Should I just keep the number lower as opposed to higher?
 
i'm recording DNx wrapped as Qt...

So not even tested with the OP1 as DS gags on them = we need to transcode for finishing, i'd rather use AFE without media and in DS link back to the camera orignals for finishing

I set exposure with a lightmeter normaly, and dial black levels as needed per shot/scene, my default is -15 tho

Probaly not a good idea if your post workflow clips data under 64 tho!
 
I've seen a lot of profiles using a positive number for black levels. I usually shoot CG1 or cG4, and set my black levels according to artificial color levels shown on my monitor. Usually, I end up around -7, and as low as -15, in order to get a hint of crushed black. I, rarely shoot higher(closer to zero) than -7. But, keep in mind, as Dermot said, this puts blacks in the 0-64 RGB category. CG1 will give you more latitude in the shadows than CG4, so, it would seem CiG1 is preferable for low light. Your best process would be to beg, borrow, or steal a monitor with a waveform monitor or artificial colors display, so, you can get a feel for what black levels and gamma work for your scene.

I suppose if you're really concerned with importing broadcast legal levels, I'd go with CG2 and Black level at 0, but, without a histogram, you're shooting in the dark(pun intended) And without any bright hilites, I'd run the knee all the way out to 105%.
 
Last edited:
You must log in or register to reply here.
Back
Top