Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Digital Cinema Package

Does anyone know if EasyDCP player compensates for the XYZ colorspace to show the right colours? I am looking at my j2c files and they have a strange kakhi green colour shift. When I look at the DCP made from the j2c files in EasyDCP player, I have the same colour shift, and not a correct colour interpretation. Is this normal or did something go wrong? (I hope not)
How are you viewing the images?
The Player (licensed version) has an XYZ to RGB converter if you are viewing in RGB colour space, eg on a Dreamcolor monitor setup to emulate DCI-P3 (or rec709 if that's the route you've taken).
Otherwise you need to view in DCI-P3 XYZ colour space (eg Barco or similar DCI spec projector).
In the unlicensed demo version, the converter is greyed-out....
 
Last edited:
So, in short, on my Apple Cinema Display setup in a standard way will not show the right colours.
But I can personalise the colour space on my mac. Maybe I can setup the right colourspace on the screen. This could be the next challenge.
 
So, in short, on my Apple Cinema Display setup in a standard way will not show the right colours.
Correct, not unless you have the licensed version (Easy DCP Player) and invoke the XYZ->RGB conversion.
But I can personalise the colour space on my mac. Maybe I can setup the right colourspace on the screen. This could be the next challenge.
Glenn Kennel's very comprehensive book (Color & Mastering for Digital Cinema) has all the info you need about the colour spaces, white points, primary values etc. I don't know whether the Apple Cinema Display covers the gamut you need, or allows the precise colorimetry adjustments.... maybe someone else could chime in on that.

cheers
 
Hi,

Is it possible to create a 3D MXF Interop DCP with opencinematools that works with Dolby DSS100?

I've read some conflicting information about this. All information points out that you can create these files in 2D, but there could be some incompatibility with 3D? The following thread is what I'm talking about:

http://code.google.com/p/opencinematools/issues/detail?id=17
 
Why are colors so different in final DCP to the original master?
I made a test with demo version of EasyDCP.
 
Why are colors so different in final DCP to the original master?
I made a test with demo version of EasyDCP.
DCP's are in XYZ colour space, not RGB, so everything appears to have a greenish cast on an RGB monitor. Unfortunately, you have to do a shit-load of reading to get comfortable with DCP's.... I'm part way there... must tackle encryption at some point!
Digital Cinema projectors normally play in XYZ colour space, but can be switched between either one (or 709, or.....)
Oh, and unless they've changed the software in the demo recently, Easy DCP normally expects rec709 colour gamut input, not P3 (wide gamut)... its in their notes, but I haven't checked for a while.
 
Well would be good to know before I spend $700 :) and then get nothing.

Ill investigate further. thanks Martin!
Adding 2c worth to some older posts I missed...
A couple of months ago we put a copy of Wraptor on a legacy Intel Mac... its "legacy" because all our other systems have moved on, but we have a need to occasionally generate a test DCP from Final Cut source material (rec709), and this does the job nicely, with some caveats of having to prepare the image files to correct size beforehand... there are things broken in Wraptor's final version.
The Mac is still useful for tape capture and other things, just can't be linked into our main edit systems.
cheers
 
So, in short, on my Apple Cinema Display setup in a standard way will not show the right colours.
But I can personalise the colour space on my mac. Maybe I can setup the right colourspace on the screen. This could be the next challenge.

If you have After Effects CS3 or higher loaded on a Mac, there should be some profiles available under the Displays/Color control panel. One of those should be Digital Cinema Package XYZ, Gamma 2.6. You could try that, it should give you a reasonable facsimile of what you're looking for.
 
So the only way to see if you have done is OK is by playing your DCP's on theater projector...
Does easyDCP make the final encryption?
I'm new at this...

Thanks
 
So the only way to see if you have done is OK is by playing your DCP's on theater projector...

Basically, yes. But that would be the case even if you were projecting from a Quicktime file, a Bluray disk, or an HD videotape.
 
So the only way to see if you have done is OK is by playing your DCP's on theater projector...

Thanks

Fortunately, no. On my russian forum user named Alexander from Karisma Films production has just told me, that there is a wonderfull player named Stereoscopic Player, that can DCP correcting colors for RGB monitor.
I think it aslo can show your dcp project as anaglyph video so you can check your depth effect as well.

Download Stereoscopic Player.
 
The Stereoscopic Player's dev, Peter Wimmer, has put quite some effort into optimizations of openjpeg's _decoder_ sections (see http://groups.google.com/group/open.../f7753f4dadd74cb0?show_docid=f7753f4dadd74cb0 for general discussion and http://code.google.com/p/openjpeg/source/detail?r=557 for code). These will move upstream and allow for significantly faster decoding.

Still, because realtime decoding of 2K JPEG2000 essence@24fps is a beast of a workload for any poor little general-purpose cpu Wimmer is using a number of clever fallbacks plus load-balancing to pull it off. Needs fast iron.
 
A question:
Is copying the DCP into Ext2 or Ext3 the final process?
Is that the encryption?
I always thought that encryption was a process made to protect the film in a way that no one could handle the data but digital projectors...
Any explanation will be appreciated.

Thanks
 
ect2 and ext3 are linux disk formats. Most servers I have seen read NTFS and FAT32.
I have no idea about encrytption as my film is not worth stealing. Actually, if anyone is interested in stealing it, I would be very flattered. You can show a film without it being encrypted.
 
I always thought that encryption was a process made to protect the film in a way that no one could handle the data but digital projectors...

You thought right. Basically it works like this:

a) The DCPs content (trackfiles) gets encrypted. Result: encrypted trackfiles and a key. If you have the key you can decrypt the content. Anywhere. Like on your laptop.

b) You keep the key in a very safe place. Now you can distribute your encrypted DCP to pretty much anyone. No playback without the key. If you lose the key all distributed DCPs would become unusable. Unfortunate, but not disastrous. You can make a new encrypted DCP and a new key.

c) Key's crucial (You want noone to have it) so when you want to give it to someone you encrypt the key with the public part of a digital cinema server's certificate. The secret part of that certificate is stored in another (supposedly) very safe place: secured storage on the cinema server board.

d) This becomes a KDM or key delivery message and you could put it on billboards. Only the targeted cinema server can make use of it. It decrypts the KDM to get the content key, checks its validity (timespan) and decrypts the content upon playback. This relation to a specific cinema server gives distributors the fine-grained playback control they need.

Major distributors would probably segment content keys, I don't know.

It's a neat system, in theory. You only need 2 safe places and a couple of guardians (for example a list of trusted devices and a mechanism to revoke trust). The communication channel between the 2 safe places can be quite insecure: DCPs on disks anyone can copy, KDMs via email anyone can read.

In practice, I guess and I'm speculating, there's an Emmentaler-like landscape of pitfalls, lurking just around the corner:

Implementation flaws can weaken key strength severely (Many successful crypto-attacks in the past were based on weak key generation).

Very safe places are expensive and hard to build and maintain and get impractical fast. People seem to tend to want to bypass security wherever it gets in their way of work. So they take work home, on memory sticks, which they lose (Remember the London bloke who lost health insurance data of, what, all british subjects in the tube?). People work on non-authorized copies of data etc.

Most dangerous pitfall, in my book: Obscurity. If you don't communicate how you handle security-related work then it's only a matter of time until a certified and theoretically safe path diverges. Workarounds and improvisation and a blinding fog make you stumble around. Noone can help you because you can't talk about practices in the facility. Because it's so freaking secret. This is not a rant, mind you. Look at the SMPTE standards. They don't describe exactly how it's done. Obscurity. Dead-end technology-wise, I think. Loads of examples.

Mike, what do you think about this? Am I totally off and standards are observed precisely and practices are exchanged on a regular basis in order to check and adjust deviations?
 
Look at the SMPTE standards. They don't describe exactly how it's done. Obscurity. Dead-end technology-wise, I think. Loads of examples.

Mike, what do you think about this? Am I totally off and standards are observed precisely and practices are exchanged on a regular basis in order to check and adjust deviations?

All of the security in the DCI specification and the SMPTE implementation of it is based on FIPS 140-2 (I'm going on memory here, I think it's level 2), which is a standard published by the National Institute of Standards and Technology, an entity run by the U.S. federal government. Everything about it is documented and publicly available. In fact, everything in the Digital Cinema specification is based on existing open standards, that was part of the DCI mandate.
 
Yes, open standards, I'm aware of that. Yet I'm speculating about implementation pitfalls and practices and whether the exact process of protecting content is subjected to (transparent) scrutiny. Which -- I would think -- is crucial to security.
 
Back
Top