Build 21, Light & Kelvin

[Jonas Hed]

Hello!

I have not yet found any specification according the "native" kelvin degrees on Build 21. What would be a good kelvin for the lights and with what kelvin set on the camera?
Would a led light panel be suitable for a color test? (I must check what the correct kelvin specification is on them)

Thank you!

 

[Gunleik Groven]

The sensor is still daylight ballanced. The meters are still most correct @ daylight/320. You still get the highest DR and the lowest noise at daylight. You still risk blowing the red channel under tungsten if you auto-ballance and expose to the right.

In short:
The sensor is still the same, and the same conditions are still the most optimal.
BUT the developing tools have evolved to a stage where what is earlier "not useable" as a workflow approach, now works pretty well for a lot of work.

Except from that, the cam performs really fantastic.

 

[Jonas Hed]

Tack/thanks Gunleik!

I have noticed that if I set kelvin to about 3600 in Redcine less clipping in all the channels occur. Is this due to Redcine or would not that be the best kelvin to export in and later balance it on the dpx/tiff? Maybe this is totally wrong but I tried footage with daylight and many different colored objects.

The "zero"-value in both Redcine and redalert is 5600k but is that what I should choose?

 

[Gunleik Groven]

to check if there's actual clipping, check in the Lin image ("F" in redcine) or set the developing settings at 5k (or 5,6k - I've sorta stuck with the latter...)/320/-0.4 exposure and check the separate channels.

The red channel is especially prone to blowing if you tungsten ballance and expose to the right (under tungsten...), because a "degain" is applied in the metadata, so you are not warned when it goes, and thus you get really bad skintones.

This is about similar to the result you get on the whole image, if you set the cam to 100 ASA and expose to the rightest. (all channels blow, but the cam gives no warning).

Another risk with tungsten, is to really feed much less blue, than you need, because you start lighting for a gained blue-channel, and really end up feeding the cam much less blue than you could. Metadata doesn't affect what's recorded, but previewibg with 2looks" applied (and tungsten-ballance is really a "look") definitely can change how you light your shot, and thus give you far from optimal exposure.

 

[Gunleik Groven]

To add...

What you "should" choose, depends a lot on the project and what kind of resources you have access to (that is both human and technical...)

For "best" technical result (that is least noise, highest DR), you should go lin 16-bit tiffs..., but that's pushing a lot of work to the online.

The "nextbest" thing (again from a purely technical/DR/noise perspective) is to go for native settings and redlog, but that still pushes a lot to the online, and if the shot/li ghting was done with "daylight" or some other look, the signal in is probably pretty skewed to start with, and there can occur situations where it is hard to reproduce the intended colometry from set...

For tungsten shots, it is often pretty cool to start with/ play with a lower ISO/ASA settings in the developing stage and rise the brightness a bit + a carefull S-curve. You do NOT want to push the blacks in the developing stage. As that just is throwing info out and pushing info into the lower bits where nuances are lost.

Cheers!

 

[Jonas Hed]

Ok I thought the -0.4 exposure only needs to compensate on the older builds (up to 17) because I cannot see on any footage any clipping in highlights before or after lowering exposure -0.4 from Build 20/21 (in Redalert)?

I read that the reds native kelvin in RA in Build 20-21 is not correct at 5600k anymore. I will try to find the thread...

Cheers!

 

[Gunleik Groven]

It's 5000k

 

[Jonas Hed]

Thanks I'll stick with 5000K then and see if I can find some 5000K Lights...easy task

 

[Gunleik Groven]

Gels are nice...