To try and find out which is the optimal source format from Davinci Resolve into DoM I have run some tests. The results are to be found in the attached XLSx file along with a Word doc with a snapshot of the same scene from the respective DCP viewed in NeoDCP player.
As all the subsequent source files and their DCP's were compared under the exact same conditions I think it is a fairly ok test.
A couple of things stand out...
The DNxHD 10 bit is a disaster, tried it twice and it was just as bad both times and therefore not included in the Word doc.
The TIFF 16 bit RGB source consumed most disk space but gave (IMHO) the best result.
In 2nd place (visually) came the jpeg2000 source but checkout how long it took to render from DR !
If you're in a hurry then the Compressed RGB 10 bit would seem to be the best bet
Comparison of render times and quality
-
tba
- Posts: 30
- Joined: Mon Jan 15, 2018 4:20 pm
Comparison of render times and quality
You do not have the required permissions to view the files attached to this post.
Last edited by tba on Mon Feb 05, 2018 3:47 pm, edited 2 times in total.
-
Carsten
- Posts: 2804
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
Re: Comparison of render times and quality
The render time for JPEG2000 from Resolve may take long - but that is normal for JPEG2000. If this output is intended for DCP creation, then the benefit would be that DCP-o-matic would fly through these JPEG2000 files, so in the end, it would be much faster than any of the other workflows.
I can only guess that you chose to apply a scaling in DCP-o-matic, so that recompression did occur (which is normally not necessary for JPEG2000 files).
BUT - as DCP-o-matic then just passes through the J2C images, these DCPs created from Resolve JPEG2000 image series will create playback errors on DCI servers, because that J2C is not DCI compliant. So, as long as BMD has not solved that issue, stay away from the JPEG2000 option IF the target is DCP creation with DCP-o-matic. For other purposes, Resolves J2C is probably fine...
Now, what strikes me is that the JPEG2000 from Resolve is not only compressing to J2C, but also doing a color conversion to XYZ properly, as the DCP turns out to have proper color.
Then why is XYZ TIFF so far off in color? I remember a discussion on the mailing list where one user had ordered a series of TIFFs in XYZ from a posthouse, and noticed the same greenish tint in them, making them unusable for DCP-o-matic.
Why does Resolve seem to do a proper XYZ for J2C, but not for XYZ-TIFF?
Weird...
Your bad results with DNxHD may occur because you choose a bad output resolution. AVIDs DNxHD codecs are based on a set of fixed parameters. As far as I know, DNxHD does not support DCI resolutions, it is limited to 1080p and 720p. Only DNxHR supports DCI 2k, DCI 4k, and UHD resolutions. You may wonder why Resolve supports creating DNxHD at other resolutions, but you should ask BMD that question. I didn't try myself yet, but the resolution issue may be your problem with DNxHD, as I see you are still creating full container DCPs (2048*1080). I know many people who use DNxHD for DCP creation as their standard workflow, but they may simply use 1080p.
However - as far as I know, DNxHD is limited to 4:2:2 color sampling, only DNxHR supports 4:4:4. As such, one would qualify DNxHR better suited for DCP intermediate codecs.
Resolves compressed TIFFs use LZW compression - that is a lossless compression. Being simple and losless, the compression factor is rather small, as you can see from the difference between uncompressed and compressed TIFF. As the image content is 100% identical to uncompressed TIFF, there should be no difference in compression time in DCP-o-matic. The reason you do see differences in this case seems to be storage bandwidth. Creating LZW compressed TIFFs takes a little bit more time due to the compression, but then a little less time for file writing (1/3 less storage space in your case).
As you can see, DCP creation from compressed and uncompressed TIFF is nearly identical.
Keep in mind that both AVI as well as Quicktime also offer uncompressed options. They are basically wrapping image series into a single file. This single file thus will grow very large (similar to combined image series size). I don't know if AVI or MOV are file size restricted when created from resolve (and with the intention to be read successfully by DCP-o-matic). The benefit would be that multichannel audio can be included with the video for both AVI and MOV.
- Carsten
I can only guess that you chose to apply a scaling in DCP-o-matic, so that recompression did occur (which is normally not necessary for JPEG2000 files).
BUT - as DCP-o-matic then just passes through the J2C images, these DCPs created from Resolve JPEG2000 image series will create playback errors on DCI servers, because that J2C is not DCI compliant. So, as long as BMD has not solved that issue, stay away from the JPEG2000 option IF the target is DCP creation with DCP-o-matic. For other purposes, Resolves J2C is probably fine...
Now, what strikes me is that the JPEG2000 from Resolve is not only compressing to J2C, but also doing a color conversion to XYZ properly, as the DCP turns out to have proper color.
Then why is XYZ TIFF so far off in color? I remember a discussion on the mailing list where one user had ordered a series of TIFFs in XYZ from a posthouse, and noticed the same greenish tint in them, making them unusable for DCP-o-matic.
Why does Resolve seem to do a proper XYZ for J2C, but not for XYZ-TIFF?
Weird...
Your bad results with DNxHD may occur because you choose a bad output resolution. AVIDs DNxHD codecs are based on a set of fixed parameters. As far as I know, DNxHD does not support DCI resolutions, it is limited to 1080p and 720p. Only DNxHR supports DCI 2k, DCI 4k, and UHD resolutions. You may wonder why Resolve supports creating DNxHD at other resolutions, but you should ask BMD that question. I didn't try myself yet, but the resolution issue may be your problem with DNxHD, as I see you are still creating full container DCPs (2048*1080). I know many people who use DNxHD for DCP creation as their standard workflow, but they may simply use 1080p.
However - as far as I know, DNxHD is limited to 4:2:2 color sampling, only DNxHR supports 4:4:4. As such, one would qualify DNxHR better suited for DCP intermediate codecs.
Resolves compressed TIFFs use LZW compression - that is a lossless compression. Being simple and losless, the compression factor is rather small, as you can see from the difference between uncompressed and compressed TIFF. As the image content is 100% identical to uncompressed TIFF, there should be no difference in compression time in DCP-o-matic. The reason you do see differences in this case seems to be storage bandwidth. Creating LZW compressed TIFFs takes a little bit more time due to the compression, but then a little less time for file writing (1/3 less storage space in your case).
As you can see, DCP creation from compressed and uncompressed TIFF is nearly identical.
Keep in mind that both AVI as well as Quicktime also offer uncompressed options. They are basically wrapping image series into a single file. This single file thus will grow very large (similar to combined image series size). I don't know if AVI or MOV are file size restricted when created from resolve (and with the intention to be read successfully by DCP-o-matic). The benefit would be that multichannel audio can be included with the video for both AVI and MOV.
- Carsten
Last edited by Carsten on Wed Feb 07, 2018 2:51 pm, edited 2 times in total.
-
tba
- Posts: 30
- Joined: Mon Jan 15, 2018 4:20 pm
Re: Comparison of render times and quality
Not sure if 'fly through' is the best way of describing it but I tried your suggestion of 2k DCI flat w no scaling and the result is not that much faster in total .. see attachment
What is interesting is that the DCP is either 22gb or 11 gb in size depending on the source format, any idea why that is and should I assume that bigger is better?
What it comes down to in the end I think is what to do in DR and what to let DoM handle eg scaling, coding/recoding etc.
What is interesting is that the DCP is either 22gb or 11 gb in size depending on the source format, any idea why that is and should I assume that bigger is better?
What it comes down to in the end I think is what to do in DR and what to let DoM handle eg scaling, coding/recoding etc.
You do not have the required permissions to view the files attached to this post.
-
Carsten
- Posts: 2804
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
Re: Comparison of render times and quality
How long is that testpiece in playtime? I think the right checkbox to choose in resolve delivery is 'render at source resolution'. However, to my knowledge it is possible to have projects with different source resolutions, and I don't know how that would come out, so, choosing the lowest common source resolution is probably that best choice, which would be 1920/1080 in typical cases. Then do cropping, etc as necessary in DCP-o-matic.
I recently made a dcp using only J2C image series, and it took only a few seconds, because the J2C is the heavy part, and that is done already.
What type of machine/CPU are you using?
Long story short - I think Resolve has many output delivery options that do not fit together properly, creating broken or useless output. One has to find those that fit the purpose. When you do some research, it appears that Mac users frequently use Prores, while windows users often resort to DNxHD/DNxHR.
- Carsten
I recently made a dcp using only J2C image series, and it took only a few seconds, because the J2C is the heavy part, and that is done already.
What type of machine/CPU are you using?
Long story short - I think Resolve has many output delivery options that do not fit together properly, creating broken or useless output. One has to find those that fit the purpose. When you do some research, it appears that Mac users frequently use Prores, while windows users often resort to DNxHD/DNxHR.
- Carsten