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’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
Am 28.07.2015 um 17:41 schrieb Carl Hetherington:
> Hi Carsten,
>
> Yes, it's a bit tricky ... in these cases the specified YUV to RGB
> conversion sort of means "if required". It would be better to grey it
> out if the content is not in YUV.
Yup - similiar for the case when using DCPs/MXF with or without recompression. I would choose 'none' for all these cases - assuming that the MXFs had been properly XYZ converted beforehand.
- Carsten
Hello there,
I played around with the DCP import feature of v2. I know quite a few people would love to be able to edit out certain passages of trailers, etc. - e.g. a trailing 'in 3D' or 'from Dec 5th'. This can be done, but with the current implementation only for both audio and video tracks of a DCP. Very often it would be necessary to do a split edit, apply different trim points to video and audio track. This can only be done in DCP-o-matic when importing the audio as a separate file. Now it is possible to extract an audio.MXF to a multichannel WAV file (DCP-o-matic will not read audio from an MXF file currently, as it is trying to find video in it). But maybe there is a way to dettach the audio track of a DCP so that it appears as a separate content? I know this leads to the discussion what DCP-o-matic is and should be capable of. But my intention is not to boost it's capabilities to a full fledged editor, but to make the most of the existing GUI with simple actions.
- Carsten
Hi all,
DCP-o-matic version 1.81.0 is now available from:
http://dcpomatic.com/download
This release includes:
Updated ru_RU translation from Igor Voytovich.
New pl_PL translation from Marek Skrzelowski.
Updated fr_FR translation from Thierry Journet.
Allow audio from different content streams to be used together in the same DCP (#274).
Set the default colour conversion slightly more intelligently depending on content type (#565).
Adjust colour conversion interface so that it's easier to use a preset.
Be more strict about what characters are allowed in DCP names.
Adjust job view in various ways (fixing #578).
Fix hang if you cancel a paused job.
Fix for distorted audio in some cases.
Slightly improve performance with high speed encoding setups.
Use j2c_<uuid>.mxf and pcm_<uuid>.mxf for picture/sound MXF filenames (#336).
Fix for failure to analyse audio or create DCPs with negative audio delay in some circumstances (#571).
Fix for failure to import video MXFs in some cases (#566).
Fix for crashes when using some colour conversions which result in out-of-range XYZ values.
Fix for failure to encode 3D from separate folders of images in some cases (#634).
Thanks are due to Carsten Kurz, Marek Skrzelowski, Thierry Journet and
Igor Voytovich.
With best regards,
Carl
Hi Carl - can you comment on the scaling types offered in DCP-o-matic? Is that performed by FFMPEG functions? I tried to look up the more exotic ones (e.g. 'X'), but did not find all references from here:
https://www.ffmpeg.org/ffmpeg-scaler.html
'X' could be the mysterious 'experimental scaler'?
I know it's useless for most applications except 'real' experimental ones, but I am currently missing 'nearest neighbor' or pixel repeat. I may find other ways to do what I want to do, but, just in case...
Wondering how I could downscale an image series with the most basic pixel repeat method. Maybe I have to batch image magick with the -sample resize option.
Leads us to my old issue that I think scaling options should be under the content tab and should be made content specific - not under DCP tab.
And that takes us to v2 where the strict separation of content and DCP options in the GUI is broken up (e.g. with audio). Anyone likes to discuss this?
I really preferred the strict separation of content related parameters and formal DCP parameters in v1. For my thinking, that is the most solid approach to create well defined compositions. Now that DCP-o-matic uses more inherent parameter constraining to assure formally correct DCPs, I would understand that it isn't necessary anymore - but I still don't like it ;-)
Anyone?
- Carsten
Hi all,
I plan to release version 1.80.0 (based on 1.79.8) within the next few
days. If anyone has any translation contributions or big problems with
1.79.8, do let me know.
Best regards,
Carl
I'm working on a video that was given to me by a film maker, it's an MP4
file and it has subtitles, the subtitles were given as a separate Excel
file. Does anyone know how I can use the .xls file as subtitles for an MP4,
or even to use it to make a new MP4/MKV file with subtitles embedded?
Below is an example of the xls file.
tc in tc out text 00:01:43:10 00:01:49:19 Stop spying you little perv
and fuck off! 00:03:29:11 00:03:31:22 Hey, cute boy. 00:03:31:22
00:03:35:01 Out! I´m taking a bath. 00:03:35:06 00:03:37:18 Get out Disa!
00:03:37:18 00:03:41:23 Mom tell Disa to go out!
I'm taking a bath.
Hello all.
While encoding a DCP from a Prores422HQ file last night, I noticed the
following error output:
[swscaler @ 0x103830800] Warning: data is not aligned! This can lead to
a speedloss
...lots of progress...
[prores @ 0x103811e00] invalid plane data size
[prores @ 0x103811e00] invalid plane data size
[prores @ 0x103811e00] ac tex damaged 3371, 1024
...progress until end
NB I was using dcpomatic_cli, rather than the GUI. The DCP-o-matic
project was created using the GUI, but then I use a script to call
dcpomatic_cli, in order to batch process multiple DCPs.
DCP-o-matic 1.79.0, Mac OS X 10.9.5.
A few questions:
1. These errors/warnings are not included in the log file - they were
just output to the terminal, presumably from FFMPEG. Shouldn't they also
go to the log file? If I'd run the encode from the GUI, the errors would
be silently ignored and there'd be no record of them.
2. Should I be worried about the "invalid plane data size" and "ac tex
damaged" lines? Presumably this indicates corruption in the source file,
but has FFMPEG quietly fixed that, or may the DCP be corrupt too?
3. Does "3371" indicate the frame number which is possibly corrupt?
4. I've noticed the "swscaler" warning message a lot before on various
files. Does this have a major impact on encode times?
I hope someone can advise...
Many thanks,
Jim
