Digital Cinema Package

[M Most]

It's my big question too. I use easyDCP player, but demo version shows wrong colors. I don't know how to check it on computer.

The simplest way is to pay for easyDCP Player. A licensed version has a built in color space converter to allow you to convert from X'Y'Z' to RGB in real time.

 

[Pavel Klepinin]

The simplest way is to pay for easyDCP Player. A licensed version has a built in color space converter to allow you to convert from X'Y'Z' to RGB in real time.

The thing is, that making correct DCP pipeline is not about making money for me. As i work as sysadmin in cinema theater. So it's just for fun and i'm looking for zero-cost tools. And "zero cost" usually is an opposite to "the simplest way", unfortunately

 

[M Most]

The thing is, that making correct DCP pipeline is not about making money for me. As i work as sysadmin in cinema theater. So it's just for fun and i'm looking for zero-cost tools. And "zero cost" usually is an opposite to "the simplest way", unfortunately

I understand you "want" something for free, and I understand you want to do this "just for fun." But not everything is free. If you want to play baseball, you need a glove. If you want to play hockey, you need a stick, skates, and a lot of pads. If you want to use editing software, you need a computer, even if you get the software for free by stealing it. I would classify all of the above as things one might do "just for fun," but they all require spending a little bit of money. Why is what you're talking about any different?

 

[Pavel Klepinin]

I understand you "want" something for free, and I understand you want to do this "just for fun." But not everything is free. If you want to play baseball, you need a glove. If you want to play hockey, you need a stick, skates, and a lot of pads. If you want to use editing software, you need a computer, even if you get the software for free by stealing it. I would classify all of the above as things one might do "just for fun," but they all require spending a little bit of money.

I think there is some misundestanding of purposes. If i'd be wanted "simple way", i would buy easyDCP converter and do no things with Open Cinema Tools. So this thread would contist of just about one post "Buy easyDCP and be glad". But my main goal is to make ZERO-COST pipeline (this is the challenge, to build it, not to convert clips), and with help of OCT it's nearly done. And for secondary tools as controlling (not transforming) middlepipe colorcorrection i should use paid software? Do i?

understand you "want" something for free, and I understand you want to do this "just for fun."

Are you speaking slightingly of word "want"? Not "want" but make. I try to make this pipeline and share it among anyone who "want" it.

If you want to play baseball, you need a glove. If you want to play hockey, you need a stick, skates, and a lot of pads. If you want to use editing software, you need a computer, even if you get the software for free by stealing it. I would classify all of the above as things one might do "just for fun," but they all require spending a little bit of money. Why is what you're talking about any different?

Yes, there is a big difference. You are talking about real things, not information. Information tends to be paid unmonetary. See 'Free' by Chris Anderson.

ps Why did you mentioned stealing software?

 

[M Most]

Yes, there is a big difference. You are talking about real things, not information. Information tends to be paid unmonetary. See 'Free' by Chris Anderson.

I don't see how software is any different than hard goods (like baseball gloves and hockey sticks) other than the fact that the Internet has made it "easy" to get without paying for it. As for Chris Anderson, I wonder how many people would ever have read what he has to say if he didn't have a magazine that is printed and sold to put it in. If Wired only had an Internet presence - as he often suggests for others - he likely wouldn't be making a living from it. But I digress...

ps Why did you mentioned stealing software?

I mentioned it in the context of editing tools. You need a computer - which is something you probably have to buy - and you need software, which, depending on who you are, is either something you buy or something you download. Which, if it is a commercial program like, oh, Final Cut Pro, is stealing. Thus illustrating my point about the nature of the way a lot of people look at software and their entitlement to it. Not necessarily you, but many others.

By the way, one of the stated goals and purposes of the DCI specification was that everything in it be based on open source tools and methodologies. The intent was always to make it possible for anyone to build both DCPs and the tools to create them if they wanted to. There is nothing in the spec that is proprietary to any one company, and that was quite intentional.

 

[jamie parry]

making vs buying

making vs buying

I think the more technical guys here are talking about "playing" for education and amusement
if you want to play baseball presumably you can make a bat (from a stick)
grab a ball ( a pine cone) and catch with your bare hands....
then if you like that and you want to make yourself a better player you can take 2 paths.
1
if you are interested in the GAME result you buy/borrow better tools-bat ball glove
2
if you are interested in the mechanics of the game you can learn how to make better tools (yes for free except the TIME it takes to make)

i've done both things in the past and swapped over between ways of thinking.
if you want stuff good and fast and NOW you'll probably have to buy it
if you want to learn how something works you don't.

it's a philosophical thing i think. very deep for a camera forum...
and the geeks shall inherit the earth.
j

 

[Wolfgang Woehl]

1) audio. It seems that asdcp-test is used to create the audio.mxf file from single-channel 24bit WAV files. There don't appear to be command-line args to identify the number of audio channels or their location (aka L, R, sub, etc). How do we keep full control over the audio during this process, especially when we have stereo and/or 5.1 surround sound?

Solved. asdcplib's author John Hurst says:

"The order of channels in the file (when using the asdcp-test program) is the same as the order of the files on the command line. For a 5.1 track, the order should be L,R,C,LFE,LS,RS. asdcp-test can also use a directory as input. In this case, the files are ordered alphabetically. As an example, I often use numbers in the filenames to make the order correct:

$ ls pcm_files | sort
sync_test_00_l.wav
sync_test_01_r.wav
sync_test_02_c.wav
sync_test_03_lfe.wav
sync_test_04_ls.wav
sync_test_05_rs.wav
$ asdcp-test -c pcm.wav pcm_files"

For 7.1 see DCI specs 1.2 section 3.3.3 ("Channel mapping")

2) Previewing the final DCP. This has come up a few times on the thread. The corrected colors look strange on my computer LCD, of course. Is the only way to see how they ultimately look to take the DCP to a theater?

We have to keep in mind that a DCP is color transformed and gamma encoded for a specific display device (Xenon light DLP projector, 12bit primary range) which transforms the material back again to RGB. Hence, I think, the idea of "checking" a DCP on fluorescent backlit, 8bit LCDs with a relatively limited gamut is somewhat flawed. A DCP player like easyDCP can give you the colors you saw in your grading suite, at best. Which tells you zero about how they'll turn out on the theatre screen. But: Comparing these color impressions becomes part of a feedback loop and that in turn allows you to "judge" that transform.

3) More on colors. If my source material was finaled on a Mac, do I need to use a different gamma/color correction than the one presented in this thread?

I want to know, too. I think, with their latest OS release, Apple chose to align with the rest of the world wrt gamma. But it shouldn't matter as RGB colorspaces have well-defined gamma encodings. Does FCP adjust gamma on the way out to produce standard gamma encoded material?

4) Time. Converting to TIFFs and then to jpegs does take time. However, once the images have been extracted from the original movie file itself, the process is easily run in parallel. We're planning to distribute the conversion to a cluster of linux boxes, hopefully that will help. If we create any tools that facilitate this, we'll certainly share them.

Yes, please do, great. Also look into CUDA stuff. This allows for very cost-effective encoding solutions, based on off-the-shelf GPUs (cuj2k was mentioned, currently it can't handle 12bit/channel material plus it splits material into > 1 tiles, but that might be fixed soon)

Wolfgang Woehl

 

[Chris Perry]

Outstanding, thank you Wolfgang! I didn't realize that asdcp-test was so aligned with the spec that the order of audio files would match the channel mapping listed there. But I just confirmed, and the 5.1 order you passed on is straight from section 3.3.3.

Does FCP adjust gamma on the way out to produce standard gamma encoded material?

I'm not sure what FCP does on export. My film (http://www.bitfilms.com/tower37.html) was pure CG, and in my transfers to HDCAM and other formats the colors have been preserved very well. I will offer my visual report once I've seen the result of this DCP process on-screen; I would think an incorrect gamma problem will be rather obvious and will look for it.

For those interested, here are more details about OS X 10.6 and gamma: http://support.apple.com/kb/HT3712

- chris

 

[fabrizio carraro]

Why do you need to encrypt it?

The reason of encrypting it is to understand the whole process, with the final goal to write an utility able to get a key from a DCP workstation (such as Clipster) and generate new keys for all the servers that need to play the feature. Of course the DCP workstation has to give such an utility also other information (but this is what I would like to understand).

 

[Chris Perry]

Just as a heads up to the readers of this forum: I'm chronicling my quest to make a DCP completely with open source tools here: http://bitfilms.blogspot.com/search/label/DCP

The posts on this thread have been immensely useful this far (thanks)!

New questions from my most recent test on a Doremi DCP-2000:

Does anyone know what tag in the PKL (I'm assuming) controls the name that appears in the Doremi ingester program? When I ingested my test DCP today, it showed the UUID of the PKL instead of a nicer name.

Can any Doremi CineLister users report on whether the newly-ingested DCP should appear in the elements list right away, or if a restart is required?

Thanks again

- chris

 

[Wolfgang Woehl]

Chris,
try the <AnnotationText> tag.

 

[Chris Perry]

Will do.

Next problem: my frames are going from a QuickTime movie file to pngs (via mplayer), then tiffs (via convert), then j2c (via image_to_j2k). I just discovered that the PNGs being made by mplayer actually change based on the image content! All black frames are dumped as 1-bit PNGs, with 1 channel. Black and white frames are dumped as greyscale. Color frames are dumped as RGB.

All the steps of the pipeline handle these varying types of PNGs just fine, except that at the end, at the mxf stage, asdcp-test recognizes the inconsistency in the j2c files and barfs. In other words, the conversion through tiff and jpeg2000 seems to preserve the different number of samples.

What I really would love to do is force all the frames into RGB at any one of these steps. "convert" doesn't seem to want to allow that, at least from my look through the command-line options. I'll see what mplayer has to offer, though ideally I don't want to have to sit through that whole process again.

Suggestions for how to force these images to 3-channels would be appreciated. Thanks!

- chris

 

[Wolfgang Woehl]

Chris,

you might want to use ffmpeg instead of mplayer's brain-damaged png output. Or use mplayer's targa output. Or tell ImageMagick's convert to "-type TrueColor" with the right -depth parameter.

 

[Pavel Klepinin]

Next problem: my frames are going from a QuickTime movie file to pngs (via mplayer), then tiffs (via convert), then j2c (via image_to_j2k). I just discovered that the PNGs being made by mplayer actually change based on the image content! All black frames are dumped as 1-bit PNGs, with 1 channel. Black and white frames are dumped as greyscale. Color frames are dumped as RGB.

I've used film->png conversion at first, but, i don't really remember why, i replaced png by ppm. PNG is a better format in terms of size for exc., but ppm works well with different kinds of images, i've tested on black-white, grayscale and color images, it generates equal size images. As i understand it keeps the right bitdepth. And it generates the right mxf.

So why don't you use ppm instead of png. If it is a matter of size, you will delete temp images when it's done.

 

[Chris Perry]

For now, Wolfgang's "-type TrueColor" option on convert seems to be working, but I'll keep both recommendations in mind as I forge ahead!

- chris

 

[Chris Perry]

Well if it isn't one step it's another. I find mplayer's PNG export to be completely unreliable and basically unpredictable. Wolfgang warned me! When I run it on my whole movie, it messes up the colors (switching R for B it seems). When I run it on a subsequence, it makes perfect PNGs. So I tried ffmpeg instead, but the PNGs it creates are highly irregular (I suspect it is interleaving RGB when other tools expect them not to be, or vice versa). Any ffmpeg experts out there know the magic command-line tricks to output the channels differently?

Also, it seems like a huge weakness of mplayer and ffmpeg that they cannot reliably output a single frame synced in number with the entire film. What I mean is this: ffmpeg CAN output a range of frames starting at time X, but it numbers them 1, 2, ... N even if the first frame exported is, say, frame 1000. Too bad - it hampers my ability to run this export in parallel.

Thanks in advance for ffmpeg output suggestions regarding PNG. I'm also exploring other image formats as alternatives.

- chris

 

[Pavel Klepinin]

Why don't you use mplayer->PPM ?

Also, it seems like a huge weakness of mplayer and ffmpeg that they cannot reliably output a single frame synced in number with the entire film. What I mean is this: ffmpeg CAN output a range of frames starting at time X, but it numbers them 1, 2, ... N even if the first frame exported is, say, frame 1000. Too bad - it hampers my ability to run this export in parallel

I don't think it would be easy to find such software. Maybe you can make mplayers export to different folders frames from 0001 to 000N each and then moving and renaming files in one folder?

 

[Chris Perry]

Why don't you use mplayer->PPM ?

It turns out that with a single-video-stream QT movie, ffmpeg dumps compressed-but-lossless PNGs just fine. I will keep the PPM suggestion in mind, however.

I don't think it would be easy to find such software. Maybe you can make mplayers export to different folders frames from 0001 to 000N each and then moving and renaming files in one folder?

Yes, I considered this. I think that ffmpeg's -ss and -t options would allow for dumping, say, 1-second chunks to different folders, named accordingly. Then a simple script could rename them and stuff them together. Or, since this is really just one of the inputs to the process, we could use symbolic links to point to the real files.

- chris

 

[Sebastiano Melmoth]

Strange color behavour

Strange color behavour

Hello everybody.
I've been silently lurking this thread for a while, trying to learn my way in the world of DCP creation.
I happen to work in the digital cinema support field, so I have the opportunity to test the content on various server systems. To make a long story short, I succesfully created a small test clip, using open cinema tools, and starting from a set of 32bit TIFF files generated for me by a friend with After Effects (using color space XYZ). The DCP is perfectly working, but the strange thing is it seems the color depth of the frames has been reduced to 8bit during the wrapping to MXF. I say this because:
a) the same TIFFs were used with Fraunhofer EasyDCP creator and the video colors displayed correctly
b) I inspected the J2K files (created with image_to_j2k) with OPJViewer, and they seem to be ok.
I checked the options in asdcp_test, but I couldn't find anything related to color depth...

Any hints?

P.S.: Sorry for having hijacked the thread, but I thought this problem was related to the argument, and I've been following you for a while...

 

[Wolfgang Woehl]

Sebastiano, "a set of 32bit TIFF files" would suggest an 8 bit per component plus alpha channel file, I guess, so that might be funky. But this doesn't explain your varied results as asdcp-test would complain about non-12-bit-3-channel material.

You seing banding?