Andrew Kolakowski wrote:Bryan Worsley wrote:Bryan Worsley wrote:
Edit: After further testing, I've changed my view on that. With 8-bit 420 inputs, exporting to a 10-bit 422 format (say DNxHR-HQX) does ANYWAY make for higher precision in applied color transforms ('grades'), irrespective of whether optimized media are generated (in the same format and resolution) and applied on the timeline or not. Furthermore, exporting the optimised media itself does not improve on that. So really the only benefit in generating 10-bit 422 optimized media for 8-bit 420 sources is for timeline performance....as well as the gratification of seeing smoother scope profiles on the timeline as transforms are applied. That's good.
Converting 8bit to 10bit is not going to make your footage "more grading resistant" or give any advantage in Resolve in terms of quality. This would only be true for some advanced 8bit->10bit conversion, but this is not what Resolve does.
Andrew Kolakowski wrote:.... but it doesn't really matter if you use 8bit intermediate or 10bit. Calculations are done at 32bti float, so data once decode gets always converter to this format and then back to some other when send to the codec for the export.
Resolve is not a transcoder, where you can avoid some not needed conversion steps (e.g. RGB<->YUV or 8bit<->10bit). Resolve has to normalise all incoming data to 32bit float format.
As I already mentioned for this reason Resolve is not the best choice when you need to convert YUV based formats to other YUV based ones as it will always force conversion to 32bit float 4:4:4.
I understand better what you were saying now. Here's one of a set of tests I ran, again purely to inform myself on the subject from an in-use perspective (sort of), but maybe of general interest.
I took an 8-bit greyscale ramp and rendered out from Resolve (all at Full Data Levels) to Uncompressed 422 10-bit and 8-bit. And then analysed the files with the AVISynth Histogram filter:
http://avisynth.nl/index.php/HistogramI used FFMS2Mod for decoding with and without dithering and converted to 8-bit 420 with ConvertToYV12. So 'without dithering' was via YUY2 and 'with dithering' was facilitated by the 'enable10bithack' option, coupled with f3kdb_dither, via YV16. I know you are well familiar with all of this AVISynth stuff Andrew, so don't need to go into further details and post the scripts.
Here are the results obtained with the Histogram plugin - first in 'Levels' mode which displays the YUV Histogram:
http://i.imgur.com/KQEiupF.png...and then in 'luma' mode which, quote ".....
will amplify luminance, and display very small luminance variations. This is good for detecting blocking and noise, and can be helpful at adjusting filter parameters. In this mode a 1 pixel luminance difference will show as a 16 pixel luminance pixel, thus seriously enhancing small flaws"
http://i.imgur.com/mZBemNm.pngI then ran the same tests, this time applying contrast S-curve (strength 1.4) in Resolve.
The YUV Histograms:
http://i.imgur.com/vav6cHP.pngAnd in amplified 'luma' mode:
http://i.imgur.com/4MUlE72.pngThe point this illustrates ? No, exporting a graded 8-bit source as 10-bit 422 does not in itself make for greater 'grade resistance' i.e. less tendency to introduce or exacerbate (existing) banding/posterization artifacts when the tonal curve is pushed - what I referred to (rightly or wrongly) as 'precision'. What does give the perception of 'grade resistance' however is when dithering is applied in the conversion back to 8-bit 4:2:0.
And here (as relevant to the thread topic) are the results obtained when that uncompressed 10-bit 422 render (where contrast had been applied) was transcoded to x264 (CRF 10) with ffmpeg (CLI), which does apply dithering by default in the conversion of 10-bit 422 to 8-bit 420. And for comparison, the same project rendered out to Resolve's own H264 format at Best quality:
http://i.imgur.com/Hs7H4Z4.pnghttp://i.imgur.com/QL6thyV.pngI should be stressed of course that the AVISynth Histogram 'Luma Mode' analysis is amplifying trace anomalies that may or may not be obvious to the naked eye, but this does support the observation made by Survivor_Films:
Survivor_Films wrote:I just tested the MP4 encoding in R14 on its 'best' settings and it's not really usable for any kind of delivery - horrible macro-blocking in the shadows and smearing of grain - here's a comparison:
(I've brightened the bottom version so you can see more clearly against a bright backdrop)
BTW - this was all done with Resolve 12.5.5; I know what you are going to say Al - it would be interesting to repeat the tests with Resolve 14 beta and compare H264 mov and mp4, but as I stated:
Bryan Worsley wrote:I have no intention of going back at Resolve 14 beta. Resolve 12.5.5 is stable and adequate for my present needs.
And this was primarily for my own interest.