Does Resolve Studio support ICtCp color?
Posted: Sat Dec 19, 2020 1:00 am
Does Resolve support ICtCp color?
https://forum.blackmagicdesign.com/
https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=129718
Tom Roper wrote:If you render an intermediate from Resolve in linear RGB, then x265 can set color matrices to ICtCp without the saturation, hue and luma crosstalk inherent in Y'CbCr.
Tom Roper wrote:ICtCp color is an exclusive feature of Dolby Vision.
Tom Roper wrote:Use Resolve to render a 4:4:4 linear RGB colorspace intermediate for input to x265. Then use x265 to output an HEVC 10b 4:2:0 ICtCp UHD file compatible with UHDTV Alliance 4k ultra hdr premium.
Tom Roper wrote:And 9-16-14 would be correct, for BT.2020 primaries, PQ (ST2084) transfer and ICtCp matrix coefficients.
Tom Roper wrote:x265 puts in the metadata.
Tom Roper wrote: BMD are not exporting a playable-ready DV file afaik.
Tom Roper wrote:x265 puts in the metadata. BMD are not exporting a playable-ready DV file afaik.
Andrew Kolakowski wrote:They are in 18b02.
Files are recognised (by players which support DV) properly, eg. QT-X works fine.
viewtopic.php?f=33&t=151575#p847344
video_signal_type_present_flag equal to 1 specifies that video_format, video_full_range_flag and
colour_description_present_flag are present. video_signal_type_present_flag equal to 0, specify that video_format,
video_full_range_flag and colour_description_present_flag are not present.
NOTE 4 – Some of the semantics of video signal type parameters associated with video_signal_type_present_flag equal to 1 are
expressed in terms of the properties of source pictures prior to operation of the encoding process, which is outside the scope of this
Specification. This is partly for historical reasons and due to the common general practice of how the indicated data is typically
described in industry publications. The actual intent for providing this syntax in the bitstream is to assist decoding systems to properly
interpret and make effective use of the decoded video pictures, e.g., for use by the display process (which is also outside the scope
of this Specification, but for which having an indication of how the pictures should be interpreted is important).
Tom Roper wrote:
Tom Roper wrote:My way of avoiding the confusion when grading in Resolve is to set the wfm to "full" and then grade between 64 and 940 while visualizing the overshoots (940-1023) and undershoots (0-64) of super-white and sub-black, then rendering as "limited" with checkbox for "retain sub-blacks and super-whites checked."
Tom Roper wrote:My way of avoiding the confusion when grading in Resolve is to set the wfm to "full" and then grade between 64 and 940 while visualizing the overshoots (940-1023) and undershoots (0-64) of super-white and sub-black, then rendering as "limited" with checkbox for "retain sub-blacks and super-whites checked."
Olivier MATHIEU wrote:Tom Roper wrote:
That confirms what Andrews says. x265 is writing all metadata (even the QT tag).
But I was focusing on QT tags, and they may be aren't needed, are they ?
I need to know more about VUI parameters ... If you have links
Thanks
Andrew Kolakowski wrote:It's good to have them, but in case of DV core info is in h265 private headers as well and this is what may be taken as priority anyway. It really depends on the playback system. Typically container headers are higher priority than video essence ones. Best if both are there and aligned
Andrew Kolakowski wrote:Scope full= grade to limited and then export to limited= totally wrong end result. This is no go for sure!
Don't think about limited when you grade etc. in Resolve. When you export then think about it. That's it.
Olivier MATHIEU wrote:I can't reproduce what you've told
I'm misconfused by my understanding of Levels :
The black in the waveform will be coded as 64 in deliver page with video levels and 0 with full levels
The black in resolve is represent in the waveform by 64 with video scale and 0 with full scale
So the 64 in wfm full scale isn't black (for resolve). How can you manage to make it black in the deliver page?
What Am I missing ?
Thanks
Tom Roper wrote:The wfm scaling doesn't change what you encode, only how you visualize data.
Tom Roper wrote:When you render output as "video" or limited terminology as I used earlier (same thing) with the checkbox for "retain sub-blacks and super-whites," you are outputting 0-1023 just like full. If you don't check the box, everything below and above 64-940 is hard clipped.
Tom Roper wrote:There is no difference between full 0-1023 and video 0-1023.
Tom Roper wrote:If you grade with wfm full, there is possibility, even likelihood that some above black data are being clipped because you can't see below the line.
Tom Roper wrote:The wfm scaling doesn't change what you encode, only how you visualize data. When you render output as "video" or limited terminology as I used earlier (same thing) with the checkbox for "retain sub-blacks and super-whites," you are outputting 0-1023 just like full. If you don't check the box, everything below and above 64-940 is hard clipped. People from pal countries often misunderstand this.
There is no difference between full 0-1023 and video 0-1023. When the checkbox is checked, you are including the wfm data below 64 and above 940. When the checkbox is cleared you are not. If this was somehow punching holes in the universe, why would Resolve include it? Don't be swayed by one-way pedants, these options exist for a reason.
Tom Roper wrote:
If you grade with wfm full, there is possibility, even likelihood that some above black data are being clipped because you can't see below the line.
Olivier MATHIEU wrote:Tom Roper wrote:If you grade with wfm full, there is possibility, even likelihood that some above black data are being clipped because you can't see below the line.Olivier MATHIEU wrote:I agree but Those invisible values can be exported with Video Levels with the checkbox ON, no ?
Andrew Kolakowski wrote:No idea what is has to do with PAL countries.
Andrew Kolakowski wrote:Tom Roper wrote:
Preserving super w/b on export should be hardly ever used and it's not a setting which should be touched for broadcast delivery. Do you think you can really keep things within 64-940 on scopes? You have same margin of error as trying to keep it in full scale. Nothing different, but when it comes to final end result it's quite different.