New subject: [DCP-o-matic] Default colour space changed in 1.79.0

6 Jul 2015

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 

Re: [DCP-o-matic] Default colour space changed in 1.79.0