Hi all,
DCP-o-matic 1.82.0 is released, and it includes:
Fix for crashes or colour errors on left/right crop in some circumstances.
Fix to recognise .w64 and .flac as audio files.
New da_DK translation from Anders Uhl Pedersen.
Fix display of non-Latin characters in some cases on Windows.
Use 96kHz DCP audio when sources are sampled at more than 48kHz.
Thanks to Anders Uhl Pedersen and Patrick Haderer.
Get it from http://dcpomatic.com/download
All the best,
Carl
Hi all,
The 2.x branch of DCP-o-matic is now in "string freeze" for the 2.2.0
release. That means that none of the translatable strings will change
before 2.2.0, so now would be a good time for translators to send any
updates to their i18n files.
I know we experimented with Zanata but there weren't really any positive
remarks about it so if it's ok with everyone I will stick with the old
method of editing .po files...
Current i18n status and information is here:
http://dcpomatic.com/i18n
Please don't hesitate to send any queries to the list or to me directly.
Thanks and best regards,
Carl
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
>
I am away from the cinema from 5th August until 25th August and will have limited access to emails.
For business related matters please contact rebecca(a)saffronscreen.com.
For technical matters please contact andy(a)saffronscreen.com.
Thanks
Paul
I am away from the cinema from 5th August until 25th August and will have limited access to emails.
For business related matters please contact rebecca(a)saffronscreen.com.
For technical matters please contact andy(a)saffronscreen.com.
Thanks
Paul
I am away from the cinema from 5th August until 25th August and will have limited access to emails.
For business related matters please contact rebecca(a)saffronscreen.com.
For technical matters please contact andy(a)saffronscreen.com.
Thanks
Paul
I am away from the cinema from 5th August until 25th August and will have limited access to emails.
For business related matters please contact rebecca(a)saffronscreen.com.
For technical matters please contact andy(a)saffronscreen.com.
Thanks
Paul
I’ve been able to compile DCP-o-matic on Raspberry Pi 2’s using the Raspian disk image. I had to install a few packages and compile/install a couple of third party libraries. I also had to make some changes to the script file to take into account that the CPU is an ARM chip, and not Intel x86.
Carl, any chance you’d be willing to take on another platform for your package distribution? Raspian is a direct Debian implementation, so you should be able to re-use a lot of your setup.
I’d be willing to donate a configured Pi 2 to the project if that would help.
-David
