10 bit logarithmic format vs. 16 bit linear format

Hi Christina... also answered on the COW.

DPX can be either log or linear and you will find that 10 bit log is more like about 14 bit linear which makes it a close competitor to 16 bit lin.
Film scanned to .cin or .dpx is best served by using a log transfer function since it has about a 16 stop latitude from DMin to DMax which completely outclasses anything solid state to date, even RED.

For that reason, film scanned to 16 bit linear will work... without all the antilog stuff... but 10 bit log will get you there, too, and you won't have to go to Lustre, BaseLight, Pablo, Scratch, etc.

jPo

To complicate the issue, some applications import 10-bit log as 16-bit lin anyway. I know Shake does this but I don't know if Color does or not.

Its all in the mapping.

The computers utterly don't care whether its "log" or "linear", its what the operators are seeing displayed that differs in translation, and you have to tell them what it is. Otherwise its just a set of numbers and "10" is still ten, unless you re-map it.

Yes, SHAKE wants to deal with 8/16/24... but 10-bit IN still goes out 10 bit, unless you byte-process it down to 8. And BTW, SHAKE no longer functions in 10 bit or above with updated Quicktime codecs.

In the end, its exactly like driving your Oldsmobile at Indy. It doesn't turn your dad's car into a Dallara/Lotus. So bringing 8-bit or 10-bit, LOG, or LIN, into a higher bit resolution container doesn't really help it attain higher performance. But it costs more.

jPo

JP Owens wrote:
So bringing 8-bit or 10-bit, LOG, or LIN, into a higher bit resolution container doesn't really help it attain higher performance. But it costs more.

JP,

Because of the way that log allocates those bits, does it feel different Color'ing in log than lin? More control in the shadows and mids where log puts the emphasis?

Or am I making no sense with a stupid question?

TIA

pi