6 Jul
2015
6 Jul
'15
2:07 p.m.
Hello all.
I just realised that I sent the message below a while back only to Carl
and not the list.
Can anyone shed any light on how to deal with video which has "headroom"
in the signal (i.e. white is not completely white, black is not
completely black)?
Many thanks,
Jim
On 22/06/2015 17:19, Jim Dummett wrote:
Hi Carl.
Hmm... I must admit I'm a bit baffled. We've been using sRGB setting
as standard and found it gives the best results. I'm going to have to
do further tests in a cinema.
This may be related to another question which I've been meaning to ask
for a while...
As far as I'm aware, standard output from Final Cut Pro 7 to ProRes
Quicktime places black at value of 16, white at 235 (out of full gamut
of 0-255 for 8-bit encoding). i.e. it leaves headroom above white and
below black, so there can technically be levels which are "whiter than
white". This I guess is to be compatible with the broadcast TV world,
where levels below 16 and above 235 are considered out of gamut and
illegal.
Presumably, though, a DCP can use the full spectrum of 0-255. So pixel
which has luminance level of 16 would be dark grey rather than
completely black.
So... how does one take that into account in the colour conversion to
XYZ space? Does DCP-o-Matic's transform do this already? I believe in
DVS Clipster there is an option for this where you select whether the
source's black and white levels are "full" (0-255) or "head"
(16-235)
and performs the transform accordingly.
I wonder if the reason why we've found sRGB encoding works is that the
gamma skew it introduces roughly compensates for the input not being
full gamut? But, even if that is the case, it's clearly not the right
way to do it.
Apologies if the above is a bit confused or erroneous. In truth I find
the intricacies of colour space hard to get my head around (tried to
read your and Dennis Couzin's paper on the subject, but the maths were
well above my level). But if anyone has any ideas on this subject,
would love to hear them.
Many thanks,
Jim
On 21/06/2015 16:42, Carl Hetherington via DCPomatic wrote:
Hi Jim,
While teaching a group of people how to use
DCP-o-matic last weekend
(DCP-o-matic is now on the syllabus at London Film School!), I came
across the change in v1.79.0 that default colour space conversion is
now
Rec709.
For the majority of the people who'd brought their film to test on, we
found that sRGB was the best setting for them. We were comparing their
source files (mostly Quicktime) to the resulting DCP viewed in Doremi
Cineplayer (evaluation version) and found that Rec709 was changing the
colour balance of the image (most notably, making it darker).
What was the rationale for changing the default to Rec709?
Rec. 709 is thought to
be the best guess for HD (i.e. roughly 2K pixels
across) material; it is the default output from Final Cut Pro 7, for
example.
And is there any way to examine a Quicktime file
to find out what
colour
space it's in? With shorts filmmakers, they often don't know
themselves!
There is, unfortunately, no easy way to do this. There are some
QuickTime headers that you can read with tools such as QT Edit
(http://www.digitalrebellion.com/promedia/) but I haven't personally
tried that.
Presumably the default output from Final Cut Pro,
Premiere Pro etc
remains sRGB rather than Rec709?
This would seem unlikely. Almost all
"video" formats represent colour
as YUV, not RGB, so use of the sRGB colour conversion settings doesn't
make much sense.
It's strange that sRGB is closer to Cineplayer for you than Rec. 709.
If you use sRGB with DCP-o-matic you are going to get a gamma
correction which results in a lighter image than that for Rec. 709, and
it is odd that Cineplayer "agrees" with that lighter gamma.
Have you ever compared the output of Cineplayer on your system to a
projected image? Is it accurate?
Best regards,
Carl
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic