At the bottom I have linked to 3 clips. (Obviously horribly color graded for test purpose) The first is 8 bit original, the second is 10 bit ProRes converted from 10 bit original and the last is 10 bit original. All from Fujifilm X-T3 and all imported to FCPX and color graded with no plugins but with a mask. 8 Bit gives me huge banding problem at bottom sky (mask border). The original 10 bit does not. So far it is OK, but the ProRes clip looks very much like the 8 bit clip. How could that be? (I converted the original 10 bit 4.2.0 file with Adobe Media encoder to ProRes 422.
I agree with Ben that you should use your original footage if your editing equipment can use your H265 footage.
I don't understand however why you are applying this badly adjusted keyed mask to test your footage ???
Since your footage is 4.2.0 you won't gain dynamic range by transcoding it to "ProRes 422" , you will only get easiness of playback ...so why not import it directly in FCPX it will Optimize it if necessary.
ProRes is a great codec and it will be about "lostless" from HQ and higher but since it is transparent it won't add information to the original file. Only file that are richer than the codec ( DPX sequence and some image sequence, some Red footage, Original camera ProRes, etc) can result in good dynamic ProRes 422 or 422 HQ for grading.
my 2 cents
What do you consider as banding in your test footage?
The problem might be the conversion by Adobe Media Encoder did not preserve the 10-bit nature of the original file. Banding is more often caused by insufficient luma bits than by insufficient chroma sub-sampling. IOW hypothetical 8-bit 4:4:4 material could cause banding on a blue gradient.
I didn't see you mention H265/HEVC but I have seen banding from that many times on a DJI X5S camera, but less when using H264 at the same bit rate, when both are 8-bit 4:2:0. So the compression algorithm itself can cause banding. We never see banding when the camera captures directly to 10-bit ProRes 422 HQ.
As you already said, the best and easiest solution is acquire in 10-bit 4:2:2 or higher, ProRes preferably. If not ProRes then ingest the 10-bit 4:2:2 material and either edit directly or transcode to proxies or optimized media (for performance). Transcoding to ProRes within FCPX will not improve image quality, just editing performance.
Sorry but in all the "ProRes white papers" apple is very clear about the fidelity of the various flavours of the codec and tend to agree that depending on the original they are visually lossless from HQ and up, however most are stable in multigenation encode-decode situation like for rendering cycles in FCPX.
One test I did to check codec quality is to encode from an uncompress original into a codec and then to layer the encoded clip over the original in "difference" composite mode, it's interesting to see the results.
A comparaison between AVID DNX... and the equivalent ProRes was always a lot of fun to observe ...
From APPLE ProRes White Paper
As you can see they all loose something from the Uncompressed 10-bit original. Right away there is a pretty big gamma shift from the original going to ProRes 4444 XQ. ProRes 4444 actually starts to shift the pixels around a little.
ProRes 422 HQ is interesting as it does not have the gamma shift that the 4444 codecs do and weirdly looks better though there is still some color shifting from the original. More shifting yet with regular 422 and some pixel shifts as well. Things start to fall apart with 422 LT and 422 Proxy is about as mushy as an MPEG-1 file.
I urge you all to download the images in this file and use Quicklook (space bar) and your arrow keys to cycle through them all so you can see the difference firsthand. -
- 508 KB
Here are the file sizes for the original 4 second media (30fps, 1080p)
Uncompressed 10-bit - 1.33 GB
ProRes 4444 XQ - 478.7 MB
ProRes 4444 - 329.3 MB
ProRes 422 HQ - 220.2 MB
ProRes 422 - 144.5 MB
ProRes 422 LT - 99.3 MB
ProRes 422 Proxy - 46.6 MB