Grateful if anyone can give me a tip as to the optimal input format from Windows. Have tried DNxHR but noticed artifacts in the finished DCP. Have tried both DPX and TIFF from Resolve but there is a colour issue there, even if Resolve says it does the conversion the end result is less than acceptable
So any input is welcomed on this subject
Best input format from Windows
-
Carsten
- Posts: 2806
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
Re: Best input format from Windows
Can you supply a short snippet of DNxHR to us for testing? Preferably a passage that displays these artifacts.
I guess I would try ProRes. RGB Tiffs should be safe play as well, just avoid the XYZ conversion if you are not able to create a suitable inverse 2.6 gamma for this export. Is your Resolve project in 4k?
As I said elsewhere, going the image sequence route can be cumbersome, so avoid it if you are not forced into it for other reasons. An interleaved video+audio file is usually the better choice.
- Carsten
I guess I would try ProRes. RGB Tiffs should be safe play as well, just avoid the XYZ conversion if you are not able to create a suitable inverse 2.6 gamma for this export. Is your Resolve project in 4k?
As I said elsewhere, going the image sequence route can be cumbersome, so avoid it if you are not forced into it for other reasons. An interleaved video+audio file is usually the better choice.
- Carsten
-
tba
- Posts: 30
- Joined: Mon Jan 15, 2018 4:20 pm
Re: Best input format from Windows
Thanks. Prores is not an option from windows unfortunately. will post you a snippet from the DNx render by mail
Is there a list of codecs that DOM can handle?
Is there a list of codecs that DOM can handle?
-
Carsten
- Posts: 2806
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
Re: Best input format from Windows
Oh, I see, in Windows, yes, no Prores delivery...
Again, do you need 4k? If not try DNxHD.
My Resolve installation is working again, I should be able to do some tests.
In theory, DCP-o-matic should handle every codec that FFMPEG supports, however, some of the more exotic codecs may show issues, depending on the level of support in FFMPEG.
Resolve added Proes import a while ago. I am sure they will also implement Prores for Delivery at some time.
- Carsten
Again, do you need 4k? If not try DNxHD.
My Resolve installation is working again, I should be able to do some tests.
In theory, DCP-o-matic should handle every codec that FFMPEG supports, however, some of the more exotic codecs may show issues, depending on the level of support in FFMPEG.
Resolve added Proes import a while ago. I am sure they will also implement Prores for Delivery at some time.
- Carsten
-
tba
- Posts: 30
- Joined: Mon Jan 15, 2018 4:20 pm
Re: Best input format from Windows
What is the logic behind selecting colour conversion when loading a source file. E.g if I load a jpg2000 folder it suggests none but when loading a compressed 10 bit RGB it suggests REC 709. Can I rely on it always making the correct choice?
-
Carsten
- Posts: 2806
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
Re: Best input format from Windows
Basically you are free to configure any of the available color conversion schemes - just as you are for cropping, scaling, etc.
Upon loading a piece of content, DCP-o-matic tries to make an educated guess at the proper content attributes and parameters to set. Most of the time, it is correct, if not, you need to adjust.
The big difference with J2C or XYZ content is that it is the users expectation that DCP-o-matic should not touch this content, but pass this content through without alteration. In the case of J2C, the idea is to have all color/gamma processing applied in the previous grading process, and have the individual frames already compressed, so that conversion in DCP-o-matic also goes quickly (As such, I wouldn't even call it conversion anymore, but wrapping). It doesn't make sense to allow adjustment of other parameters in this mode, as then DCP-o-matic would have to decompress the J2C, do processing, then recompress. So, with that in mind, 'None' is the only useful selection for J2C and XYZ input files. The difference for e.g. XYZ-TIFF is that all color conversion to XYZ has been previously applied, including an inverse 2.6 gamma, so that all that is left for DCP-o-matic is the J2C compression, but no color conversion.
This caters for users expectations to have important image processing steps being performed in their editing/grading software.
Most other content types are either RGB/sRGB, or component video, where it is DCP-o-matic's duty to perform color/gamma conversion and J2C compression. The trouble is that Resolve currently neither does a J2C compression that is compatible with DCI servers, nor does it automatically correct XYZ gamma to 2.6 display gamma automatically. If you grade in rec709, you need to do the inverse gamma 2.6 as part of your Resolve project as the final stage prior to delivery. Neither Resolve J2C nor XYZ-TIFF delivered from Resolve is immediately compatible with DCI constraints. On the part of J2C, I consider this a flaw in Resolve, in the case of the missing XYZ/gamma 2.6, it is a user misconception about the way Resolve works. Gamma is part of the grading process, and should be adjusted intentionally if delivery needs a different gamma from grading gamma.
I wrote most of that already here: https://dcpomatic.com/forum/viewtopic.p ... =969#p3468
- Carsten
Upon loading a piece of content, DCP-o-matic tries to make an educated guess at the proper content attributes and parameters to set. Most of the time, it is correct, if not, you need to adjust.
The big difference with J2C or XYZ content is that it is the users expectation that DCP-o-matic should not touch this content, but pass this content through without alteration. In the case of J2C, the idea is to have all color/gamma processing applied in the previous grading process, and have the individual frames already compressed, so that conversion in DCP-o-matic also goes quickly (As such, I wouldn't even call it conversion anymore, but wrapping). It doesn't make sense to allow adjustment of other parameters in this mode, as then DCP-o-matic would have to decompress the J2C, do processing, then recompress. So, with that in mind, 'None' is the only useful selection for J2C and XYZ input files. The difference for e.g. XYZ-TIFF is that all color conversion to XYZ has been previously applied, including an inverse 2.6 gamma, so that all that is left for DCP-o-matic is the J2C compression, but no color conversion.
This caters for users expectations to have important image processing steps being performed in their editing/grading software.
Most other content types are either RGB/sRGB, or component video, where it is DCP-o-matic's duty to perform color/gamma conversion and J2C compression. The trouble is that Resolve currently neither does a J2C compression that is compatible with DCI servers, nor does it automatically correct XYZ gamma to 2.6 display gamma automatically. If you grade in rec709, you need to do the inverse gamma 2.6 as part of your Resolve project as the final stage prior to delivery. Neither Resolve J2C nor XYZ-TIFF delivered from Resolve is immediately compatible with DCI constraints. On the part of J2C, I consider this a flaw in Resolve, in the case of the missing XYZ/gamma 2.6, it is a user misconception about the way Resolve works. Gamma is part of the grading process, and should be adjusted intentionally if delivery needs a different gamma from grading gamma.
I wrote most of that already here: https://dcpomatic.com/forum/viewtopic.p ... =969#p3468
- Carsten