[Sebastian Leitner]

hey there! just a quick remark. it’s not really a bug, it comes down to some simple things:

if you convert h264 to PRORES you are also converting a) color space and b) bitdepth. let me clarify: a DSLR usually records h264 in 8bits (4:2:0) and rec709 color space whereas PRORES is a sRGB (full range colorspace) format with 10bits (4:2:2 color sub sampling). the difference is basically gamma, meaning you introduce a gamma shift of approx. 0.2 when converting from one format to the other. depending on the direction it gets brighter or darker.

this also applies when converting PRORES (or any other sRGB 10bit format) to let’s say BluRay h264 rec709 8bits format.

final cut pro 7 is the only software i know that can distinguish between those details. if you open it up in final cut pro X it won’t show. there h264 and PRORES mostly looks the same. it might even be off (too dark often) because values are converted to fit the standards.

the problem is further problematic when generating a DCP for the cinema. you need to know what exactly was the color space of the source clip and which it was graded in. DCP is 12bits XYZ color space (so yet another conversion in dynamic range – which will be visable in gamma – color and luma wise). but that’s another story.

so bottom line: always try to level everything to sRGB 10bit if you can. or intriduce the right adjustment layer (0.2 gamma value change – basically midtones – plus or minus depending on oyur conversion direction)

[Sebastian Leitner]

glad it worked out for you!

two remarks:

please stick to “real” tools for DCP creation. DCP-o-matic is fine for creating jp2000 but adobe media encoder is not! there is a free afterFX plugin though for creating compliant jp2k files.

the adobe suite is not there yet, it might be faster but not necessarily safer.

any NTFS drive should have a master boot record, so be sure to set that when formatting on mac or linux.

as you can see, DCP is a very complex thing ,)

[Sebastian Leitner]

you are welcome! creating one master DCP for a festival for example is usually not the problem. the trouble starts with multiple copies on different storage types for example.

every DCP is ingested and never played back from an external device. depending on the brand of the server and the firmware version, EXT2 256 is fine. but that does not apply to a broader cinematic release with multiple drives sent out. but normally, a server that can read NTFS also reads EXT2 256 (but one never knows before and that’s why you stick to the DCI standards which any server accepts).

in my experience NTFS or else is fine in 80% of the cases. of course i talk only about a master DCP.

the possible issues are as follows:

a) is the hard disk readable (right file format, healthy drive without bad sectors, USB2.0 or better eSata compatible) – you can check the SMART STATUS (bad sectors, health) via linux’ “disk utility” if your external casing supports it. piece of advice: do not use WD external USB drives. they are the most incompatible. if possible stick to CRU casings and 3.5″ hard disks.

b) if the disk is accepted by the server (no “read error” pops up and the DCP shows n the browser) the DCP needs to be fully ingested. possible errors: “hash check failed” – most common because any digital copy can be corrupted and is very likely to be. always have a safe master DCP on an external disk. data gets corrupted by: disk failure, shutting it off without ejecting it, format failure. always CLONE your drive (either with the right software or hardware), takes way longer but ensures quality. and always do a hash check of the new copy in EASYDCP PLAYER.
another error you could run into here is: “ingest failed” with no further info. that sometimes happens if you have more than one DCP on the drive. usually there is something wring with the CPL file. sometimes you have to try several times with USB drives.

c) unfortunately being ingested fully does not assure playability just yet. make sure your DCP is INTEROP (IOP) and not SMPTE. the latter is still not officially supported by the DCI. the first trailers as SPTE will come out 2016. SMPTE is necessary for 3D, 4K and HFR and therefor needs more caring hands. be sure to watch a film in full length in the cinema before releasing it or presenting it to the public. sometime DCPs are fine until the very last minutes. also listen for audio quality issues and sync.

cinema servers are not fail proof either. it depends on the person who operates it as much as it does on the supplied DCP. i could go into more detail if interested but all you need to know was already mentioned here. try to stick to the legacy format and find a friendly cinema and operator to help finding the best practice. once found, stick to the exact workflow.

cheers

[Sebastian Leitner]

some remarks on this:

keep in mind, the j2k DCP files are sRGB gamma 2.6 and 12bit.
so if you have prores it is native 2.4 gamma und you only see 2.2 in final cut for example (often referred to as “the quicktime bug”, actually not a bug, simple specs)
so DCP conversion would stretch gamma to 2.6 by 0.2. rec709 will be converted to sRGB if you select to render the files in 10bit (be sure to set your project/comp to that value)

now, be careful:; paragon EXTFS is NOT DCI-conform because it writes an inode size of 265KB instead of 128KB and also it is very slow and buggy. hash checks sometimes fail. the same goes for their NTFS plugin which is faster (use TUXERA NTFS for that).

kepp in mind that any digital copy (if not CLONED) is likely to flip a bit which would end up in a server not accepting the DCP. start into ubuntu for example from a live DVD and from there copy everything on an EXT2 volume (change inode size before that)

here are some steps:

-partition table must be MBR
-inode size should be 128, and
-drive should be ext3 file system
I’ve got many DCP packed and I try to do it only like this and I didn’t had any problems or complains with it.. So I do it in linux (open suse) following these steps:
-plug new disk (usb2/3 (portable ones) or e-sata (CRU))
-open GPrated (install it from online repo)
-check witch disk drive is new one, in my case it’s sdd (I’ve got two internal disks, sda and sdb with one partitions per drive (sda1 and sdb1)
-deleted default partition (deleted sdd1 wich is default partition witch is external portable drive formatted by default), apply changes in GParted
-make default partition table for empty drive and make it MBR
-make new partition and set format to ext3 (leave all settings default)
-apply changes in GParted and when format is complete close it
-open terminal as root (type sudo su and again type your pass and hit enter)
-format that partition again but this time set inode size to 128 (type mkfs.ext2 -j -I 128 /dev/sdd1 and hit enter)
-now mount your partition with sudo mount /dev/sdd1 /mnt/disk and make directory for your dcp with sudo mkdir /mnt/disk/dcp
-make permissions for that directory so that you can write to it with sudo chmod -R 777 /mnt/disk/dcp
-copy dcp files (assets) to that directory
-and when copying finishes make that directory read only and executable with this command chmod -R 755 /mnt/disk/dcp
-and last step unmount disk with sudo umount /mnt/disk

if you want to test your DCP and you definitely should, you can hash check the copy with EASY DCP PLAYER DEMO (press “h”) and you can play back any part of the DCP (up to 15secs) with CINE PLAYER by doremi (trial version) in the right RGB color space. also good for audio sync (no surround though).

also: if you are using EASY DCP for making the package, it is likely to be not 100% conform. stick to INTEROP packages (24p, IOP, 2K) to guarantee compatibility. there is not a single professionally made DCP out there in SMPTE, because many servers do have problems with it. NTFS is widely supported by most servers, depending on the firmware version.

e.g.: sony does not allow SMPTE DCPs but reads NTFS, doremi reads basically everything but is very conservatives regarding hashes. so if your copy has one bit turned, it will fail.

good luck! more questions or requests? get in touch with me: mail(at)sebastianleitner.com