Extra black frame between reels

[rajeevs]

Thank you Carsten !
I have sent an email with the DPX file to Carl .

Hoping for the best solution!

[Carsten]

Hmm, which software did you use to convert to these DPX? It may be you used the wrong parameters?

It seems a common selection is print density, which is normally used only for actual print film output. Then there is the choice between linear and logarithmic. So, it may be your DPX are actually not log, but 'crushed', or both.

Here is some good information on DPX files:

https://www.imagemagick.org/script/motion-picture.php
https://documentation.apple.com/en/colo ... tasks=true

Actually, Google has a great number of good search results for these issues.

I believe we would need a special 'DPX' color preset in DOM in order to manually override, and have a log gamma option there as well.




- Carsten

[rajeevs]

Dear Carsten ,

Thanks a ton for looking in to the issue ! The DPX files were given to me by a colorist . The software that was used to generate them was Resolve . I checked with him again today and he was sure it was Linear .
I am not sure if it is a software error in Resolve or a manual mistake in selecting the format .

Is there a way out for me ? Please let me know

Since you say my DPX files could be crushed , I am just curious how DOM handles them well in v2.10.5 before the fix went in for the log format .

[Carsten]

Try the new 2.11.21

Also, if 2.11.21 does not fix it yet, you may try to create your DCP with 2.10.5, use the 'split by video content' reel segmentation under DCP.
Afterwards, you should try to 'reuse' the separate MXF reels that have been created and chop off only the single black frames using 'Timing'. Not elegant, but it should still create a correct DCP.

https://forum.blackmagicdesign.com/view ... 21&t=41097

The fact that DOM 2.10.5 renders your DPX files right, unfortunately, doesn't mean it is acting correct on DPX files in general - you were just lucky.

I don't know wether Carl want's to correct the black frame issue for 2.10.5 and issue a new release version, e.g. 2.10.6

Unfortunately, my Resolve machine ist broken currently, so I can't look into the DPX export. Handling export options in Resolve is not as easy as people think, especially when it comes to embedding the right gamma.

- Carsten

[rajeevs]

Dear Carsten,

Thank you for the wonderful idea , I will try to do a DCP with 2.11.20 now and if it doesn't work will try it on 2.10.5.
Will keep you posted on this .

Thanks to Carl for getting a fix and a new version !

[carl]

I think the DPX thing should be better in 2.11.21 but it's fiddly to say the least!

[Carsten]

There is one specific trouble with using Resolve, and file formats as DPX:

First of all, it is evident, since the DSLR-filming revolution, that film makers, DOPs, DITs, colorists, etc. try to maintain as much image quality/dynamic range throughout the production, from capture to end. One aspect of that ambition is to choose tools like Resolve, another is using file formats that support maximum latitude, 10 or 12 bits, etc.

Now, the problem in Resolve is, that exporting to one of these file formats does not guarantee the image is properly transformed from the grading color space into the output color space. People seem to think, if e.g. they choose J2K output, these J2Ks are DCI compliant J2Ks. This is not the case. Some fileformats have specific colorspaces and gamma associated with them. When choosing them for export, Resolve does NOT automatically transform the color space or gamma - as a professional tool, Resolve expects YOU to cater for that color space conversion and gamma correction in your processing pipeline. One nasty aspect of a specific gamma is that gamma is baked into your data. It is not just a 'flag' that is interpreted. You could have a gamma of 4.5 baked into a TIFF, or a gamma of 1.5. If you are lucky, that specific gamma value has been indicated in some file header. But if not, or if your target application does not read or interpret that flag, you actually don't know what happened to your data. That way, you can easily export J2Ks from Resolve with a non-DCI compliant gamma of 2.2, which will show wrong on a DCI system (2.6). If you have your grading color space set to rec709 in Resolve, because that is what your video monitoring setup supports, you need to transform your gamma to 2.6 before you export to an XYZ TIFF or J2K. Because the idea of creating XYZ in resolve is that you bypass all color processing in DCP-o-matic - so you simply can not expect DCP-o-matic to adjust just a single aspect of an input file characteristic that you left out in Resolve.

Many people suggest DPX for final output, as that is known to be a PRO format. However, many aspects of DPX are not targeted at final mastering format, but for post production interchange. e.G. there is a data encoding range option that is targeted at transferring images from the editing stage to the grading stage in order to maintain highlights and blacks for the grading process. The DCP mastering does not need that specific encoding range, or may not even be able to interpret it. Also, one of the main applications of DPX was to encode digital image data for an analog/photographic film transfer, using log encoding. Now, it is clear this doesn't make sense for DCP creation, as there is no specific log encoding/interpretation needed in the digital conversion to DCP.

As a general rule, I can only suggest to use common file formats with known specifics. There is little sense in creating an intermediate XYZ encoded 2.2 TIFF or J2K from Resolve, because that format is not a proper standard. If you create XYZ, then it should be targeted at the DCI gamma of 2.6.
A full range 12/16 Bit RGB-TIFF with a typical gamma of 2.2 or 2.4 is completely okay, as DCP-o-matic can deal with this properly.

Many people are able to use Resolves color grading capabilities with great creative effect. However, being creative does not necessarily mean they fully understand the processing pipeline and implications of the various input/output transforms. Digital color interfacing is an extremely complicated matter (still). If you receive footage, ask them why the chose the specific format, and what specific parameters they chose for what reason. Be suspicious if they can't answer that question.


- Carsten

[rajeevs]

Dear Carsten ,

Thank you for the detailed explanation about DPX files . I will keep those in mind when I create files for DCP.

Finally I was able to successfully create a DCP without any issues in v2.10.5 by following your method of individually creating mxf files and then by changing the timings . It worked perfectly! Thanks for the idea !!

I was unable to create it in v2.11.21 as the timings weren't calculated perfectly ( 1 sec of video was removed before the end trim) but I should thank Carl for fixing issues and creating a new version within 2 days . Appreciate your dedication and hardwork!


I am going to a test it tomorrow in a theater to see if everything plays fine there . Hope it works well!
I will let you know tomorrow .

-Rajeev

[rajeevs]

The image quality of the DCP was excellent when projected in the theater !
No problems of black frames and all .

Thanks again to Carl & Carsten! You guys rock!!

DoM is a boon to indie film makers .