You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 2 of 4)
Then most likely you do not have enough file padding in your sequence numbers. You must always have at least 1 leading zero. So if you have something like:
film-001.j2c
film-002.j2c
...
film-999.j2c
filme-1000.j2c
it will cause an out of order issue.
Ok. What do you mean by wrong images? Also, I don't think Blender creates the proper type of JPEG2000 images.
To some degree, there is no absolute answer because the capabilities of the servers vary. Best practices is to use an EXT3 formatted drive with a 128kb Inode. The drive should be self powered and not USB powered. In most cases a flash drive will be fine.
If you use something like VirtualBox or VMware Fusion, you can install a Linux virtual machine and format a drive and copy over the DCP.
Many newer servers will read HFS and NTFS drives. The most important thing is to give yourself time to work through any issues. It's not something you want to try to do last minute, especially your first time.
JPEG2000 images must be DCI compliant which is based on JPEG2000 Profile 3.
Yes, you need to re-package. The MXF files have checksums to validate their integrity which will be different in this case.
The commands have --help to list specific options. The basic flow is
opendcp_j2k to convert to jpeg2000 and do XYZ color
opendcp_mxf to wrap the audio and jpeg2000 into MXF files
opendcp_xml to create the DCP package.
I'm not a color expert, so I don't know the detailed reasons. It has to do with XYZ having a larger gamut than RGB. It allows future flexibility. I'd suggest reading Color and Mastering for Digital Cinema by Glenn Kennel.
32-bit = 8bpp, show yes that should work. XYZ is required per the DCI specification.
and is there a leading zero in TAOWB_117529? It needs to be TAOWB_0117529.
You need to pad your filenames with leading 0's so that there is always at least one 0 in the sequence. So if you have say 15 frames, you need 3 digits for the sequence...
001.tif
002.tif
....
015.tif
I think this occurs will BMP files with alpha channel or certain bit-depths. It should work with 8 or 16-bit BMPs and no alpha channel.
Your image resolution is invalid, it can't exceed 2048x1080 for 2K. To conform to the majority of theaters your resolution should be:
1998x1080 (flat) or 2048x858 (scope)
You will need to crop/scale your image to match one of these.
Yes, it is normal for the colors to not look correct on an RGB monitor.
1. This is required for ordering and good practice with file sequences. Filenames are treated a strings, not integers. This can result in the following order
1.tif
1234.tif
2.tif
This would obviously lead to frames being out of order.
2. I'll see what the most common value is.
3. If you mean the XML files, these must be auto-generated UUIDs to ensure uniqueness.
You can clone the project...
git clone https://code.google.com/p/opendcp/
Ok, I will look into this. Thanks.
You need to create your MXF files as Interop, which can be done in OpenDCP. Changing the title does not change type of package.
The CLI applications have a --help option which will provide the usage and some examples.
The DCP you made with Clipster is an MXF Interop, while the one you made with OpenDCP is a SMPTE package. You'd need to create the same package type in both applications to compare them.
Reels are only supported using the CLI version of OpenDCP.
There was no bug fix related to lifted blacks. An additional transform was added to handle the different ways applications encode the gamma. If you are seeing lifted blacks, use the non-complex formula.
Make sure both the picture and sound MXF files were written as Interop format. You cannot mix and match SMPTE and Interop assets.
Ok, thanks for the information. I will take a look.
The GUI and CLI use the same code. It kinda looks like you have a wav file mixed in with your j2c files.
The file ordering is the order the OS lists them. They get sorted by OpenDCP after the are all collected.
Posts found: 26 to 50 of 76