A Rec709-A official workflow from BMD?

There is much contradictory suggestions about a proper workflow for Rec709-A, internet delivery.
The more the forums I read, the more I am lost due to divergent point of views that cancel each other.

A dozen of "experts" have published complex tests, and they have concluded suggesting workflows to the confused community that differ greatly from each other. I will mention only two experts for illustration.

I.E. Dmitry Shijan opened his Final Explanation of Gamma and Color Shift Problems https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=101253 suggesting repeatedly this setting for sRGB internet delivery:

YRGB project with “Use Mac Display Color Profiles for Viewers” turned ON
Timeline to Rec.709 A
Final CST (color space transform) node to Rec.709/rec709 gamma
Set tags in Render Settings to rec.709/rec709

However this "serious" website suggest another setting which deliver totally oposite results here: https://www.thepostprocess.com/2020/03/ ... -displays/

ThePostProcess_InfographicSeries2_MacDisplays_QT_Tagging.jpg (354.9 KiB) Viewed 10187 times

As far as I can see, this workflow will deliver in Rec709-A, which is not a deliver format according Dmitry, however this second workflow gives me great results everywhere with projects previously graded in Rec709/gamma 2.4, then added on final CST Input gamma: "gamma 2.4" then the rest "Use timeline". Despite acording to Dmitry this should be a bad practice, but Dmitry workflow lead me to hugue gamma shifts.

There is too much information/noise about this topic, and personaly I haven't found an official setting or official information from BMD. With so much noise, which "unoficcial expert" we should believe?

Has BMD offered an "official" procedure for internet delivery concluding with so many divergent procedures around?

This appears to be another one of the major problems in Resolve that Black Magic chooses to remain silent on rather than be adults and admit they screwed up.

Follows is a video Daria Fissoun colab'd on the topic. She leads the official BM color training (though I don't think she actually works 'at' BM)

I luckily do not have a Mac, so I have no clue what method works best.

I've watched the video and is adding more confusion. The video recommends several settings with "maybes", and then recommends to "go and test yourself if it works for you".

By reading the comments, it's clear that nobody has clear idea of what setting is the proper one, and when someone proposes a definitive setting, then other folks state that they still get gamma shifts.

I wish BMD has some words to guide us to a definitive setting that works for everybody on all kind of scenarios

I wish BMD has some words to guide us to a definitive setting that works for everybody on all kind of scenarios

Agreed. I can't believe we still have this problem years in.

If your audience is Mac then simply use Rec.709-A.
If your audience is ANY then there is no single setting.

There was a guy who tried to contact relevant bodies regarding this and:

"I contacted the ISO via twitter and they referred me to the ITU, which have not responded yet concerning an ITU-R BT.1886 NCLC tag standard."
It was 2 years ago

Maybe some petition, website etc. ?
Really no people with some ISO/ITU contact to help?
There is no money for anyone in it, so there is 0 interest.

I produce content for web almost exclusively and to be honest the whole Rec.709 debacle is still a huge issue for most web content because most browsers and players don't convert to computer display but at the same time there's the argument that Rec.709 grading is 2.4 in dim surround which is different than 2.2 in average/bright surround and the average display brightness of computer or phone displays.

But I can assure you that all the content I've seen delivered to us externally that was created for broadcast looks flat for web unless you apply a rec.709 to srgb gamma conversion.

We actually grade and finish on sRGB displays instead of Rec.709 so what we see is what we get and for web this works miles better than a full rec.709 workflow. As for graphics the colors stay true to original because we don't convert them (Premiere Pro doesn't). I know this is not the "proper" way but treating everything as unmanaged (but making sure the sources are sRGB) gives more consistent results. Until Apple, Microsoft and software vendors sort their **** out I don't care about the proper way.

If your audience is Mac then simply use Rec.709-A.

This is also the weirdest statement. How do you have an audience that is Mac?? I can't think of any content that only people with a MacBook or iMac would watch.

It does exist

Don't use 2.4 gamma for web (2.4 is for broadcast and has not much directly to do with Rec.709).
Use sRGB (or 2.2) and this will be better to cover your wild audience needs.

We actually grade and finish on sRGB displays instead of Rec.709 so what we see is what we get and for web this works miles better than a full rec.709 workflow.

The most coherent workflow I've heard for internet delivery.
Can you define in detail your DVR settings please? (I mean preferences & timeline settings, color space transform output, deliver settings...).

This will help a lot to the community delivering for internet. And I will personaly appreciate your shared experience.

Another question. How do you manage your workflow to deliver properly both on SRGB and rec709? Do you use Handbrake ar the end stage?

This sums it well with some guides as well:

Can you define in detail your DVR settings please? (I mean preferences & timeline settings, color space transform output, deliver settings...).

We don't use Resolve but Premiere Pro and After Effects. But the same principles apply. If you don't manage anything but your display is calibrated to sRGB then all your output files which are automatically set to rec.709 will display just as what you saw in the viewer (because most players don't manage).

You also have to understand that in the case the output file would be displayed properly it would have increased contrast / compressed shadows instead of feeling flat so keep that in mind. But from what we can tell both Mac and Windows machines and several mobile devices will display it just as is and it looks fine. (Fun fact on Vimeo the auto generated still and preview thumbnail when hovering the timeline will show the proper conversion but the playback itself doesn't.)

This sums it well with some guides as well:

It also seems like most of the conversation is revolving around Quicktime deliverables but my methodology is purely based on delivering H.264 MP4 files which don't have that tagging system afaik.

Another question. How do you manage your workflow to deliver properly both on SRGB and rec709? Do you use Handbrake ar the end stage?

We use the reverse process so still everything sRGB based but for broadcast we convert the entire deliverable from sRGB to Rec.709 gamma and then create the broadcast files from that.

This sums it well with some guides as well:

It also seems like most of the conversation is revolving around Quicktime deliverables but my methodology is purely based on delivering H.264 MP4 files which don't have that tagging system afaik.

h264/5 have private headers and if they are set then some players (including OSX color engine) will read them (same way as they read MOV ones).
Color managing is difficult subject, but not having it today (where you have more and more monitors with around P3 gamut) is not really a solution either. You can't display sRGB/Rec.709 file on P3 display without managing- it will be so oversaturated. You can't display HDR file on sDR monitor as is. It's not anymore just sRGB gamma/gamut to deal with.
Solution is introduction of new universal tag value which would describe video graded with 2.4 gamma. This is key element which ISO/ITU keeps ignoring. Then if you have some color management things can be converted to display profile. For properly tagged files it's all working fine on OSX.
Note that for HDR (which has all needed, up to date tagging) everything works much better- there is no such a mess like with SDR. Accuracy of the end display is a different matter- 1st we need a reliable pipe.

Another question. How do you manage your workflow to deliver properly both on SRGB and rec709? Do you use Handbrake ar the end stage?

Grade to eg 2.4 (if you need broadcast files) and when needed just add conversion node to desired gamma eg. sRGB when going to web.
If you have 2 files done this way and play them in QTX then they both will look identical to the eye. This is beauty of a properly managed preview when things work properly.

This sums it well with some guides as well:

Thanks Andrew. That is a very interesting video. I have watched it three times now !! Still need to do it again I think. I am still a little confused so need some more info. Is this an issue for grading and rendering on a Mac to an mov file ? Does the same thing occur on a PC ? Does it occur rendering to h265 ? Reason is I am thinking of getting Mac Mini Max ( if they appear ) since the opportunity to upgrade my GPU on my PC is not possible since there are none available and if they were they may be just as expensive as a Mac Mini !! I will still then go between them. Will likely use an external NVME exFat formatted drive. If I do get a Mini the PC and the Mini will use the same monitor, jut different input. I have an ASUS 32"

Take care not to put the data base on the exFAT drive. It doesn't work.
Media files or .drp will be fine.

Take care not to put the data base on the exFAT drive. It doesn't work.
Media files or .drp will be fine.

Understood. Will be media and drp as needed. Just hope the Mini appears at the rumoured event next week !

Color managing is difficult subject, but not having it today (where you have more and more monitors with around P3 gamut) is not really a solution either. You can't display sRGB/Rec.709 file on P3 display without managing- it will be so oversaturated. You can't display HDR file on sDR monitor as is. It's not anymore just sRGB gamma/gamut to deal with.

I'm well aware of this that's why I said using calibrated sRGB monitors. Most webplayers are in fact managed just the gamma side of things are handled incorrectly so your P3 MacBook will still display Rec.709 colors properly from what I've seen. The same counts for most of the fancy phone displays.
And yea HDR is a whole other topic .

On the NLE side of things using a wider than deliverable monitor will only work if you let it take the .icc profile into account and this works if you work in Rec.709 but for everything to make sense all your non video assets like sRGB logos need to be converted to Rec.709 too and you'd want to do a conversion back to sRGB before export for web.

Both directions of the approach work I'd say but I just trust a hardware calibrated sRGB limited monitor more than a P3 display with an .icc profile on the software side.

This sums it well with some guides as well:

Thanks Andrew. That is a very interesting video. I have watched it three times now !! Still need to do it again I think. I am still a little confused so need some more info. Is this an issue for grading and rendering on a Mac to an mov file ? Does the same thing occur on a PC ? Does it occur rendering to h265 ? Reason is I am thinking of getting Mac Mini Max ( if they appear ) since the opportunity to upgrade my GPU on my PC is not possible since there are none available and if they were they may be just as expensive as a Mac Mini !! I will still then go between them. Will likely use an external NVME exFat formatted drive. If I do get a Mini the PC and the Mini will use the same monitor, jut different input. I have an ASUS 32"

It's generic problem, not really Mac related. What is Mac related is previewing, not creation. Creation is Resolve taks and if you have accurate monitoring it's irrelevant if you use Mac or PC for Resolve (or Linux.). With new Macs you should have "accurate" preview even in GUI (as accurate as screen itself), which on Windows is not really possible. This is now true even for HDR, so for prosumer work may be enough. Preview GUI pipe on new Macs should be now "precise", so it's all down to screen accuracy. In the past GUI preview was rather unreliable.
Problem is with choice of gamma (and here your main target audience eg. Mac vs PC makes difference). 2.4 is not going to work well for web. Preview one PC is mostly done based one sRGB/2.2 gamma (I think), where one Mac it's in reality 1.96 gamma (due to lack of proper tag for modern 2.4 gamma). If you create content "for all" then you need to find best compromise and that video is about it. In some way PC preview is "better" (reverse gamma is more standard), but there is no proper color management. In other Mac preview is "better" (if tag is correct than preview is properly color managed and accurate which matters because Mac screens are wide gamut), but currently (due to lack of widely adopted tag) display is based on 1.96 gama which is not what anyone grades to.
Ignorance and lack of any action from all different companies (also institutions like ISO/ITU) which could help is very sad.
Some solution would be for Apple to update math behind Rec.709 tag (but this is more a hack than proper solution) to use 2.4 gamma, but real solution is for ISO/ITU to introduce BT.1886 tag, so people could start tagging files as 2.4 gamma based (then this would go to h264/5 specs as well as MOV etc. for proper wide adoption). If MS would also add proper color management one Windows then everything would be as it should and videos would look the same (on the same monitor) regardless of player/OS etc. This is more of a dream unfortunately

If I edit on a new Mac Mini but then move files over to the PC for final export and encoding ( output for me will be DVD, Bluray and USB mp4 files. No MOV files at all ). I will use the same PB328Q as my editing monitor but on the PC may also look at output over IP4K to a Benq 4K preview monitor. Intermediate file for encode will likely be Canopus HQX or Cineform with encode being done by TMPGencMW7. ASUS PB328Q is full sRGB monitor. So is this an issue of monitoring and export on a Mac because of Mac OS color management?

If you use accurate monitoring for both OSes (specially when you use same monitor) then there is no reason for any problems. Use export format which is YUV based (mentioned Canopus HQX, DNxHR HQX, ProRes, Cinefrom YUV, 10bit YUV uncompressed) with 3rd party encoders like ffmpeg, Handbrake, TMPGenc, etc. and things should never go wrong. Final file imported back to Resolve (and interpreted properly) should always look same as your original timeline. OSes play 0 role here.
Rest is as I said- choice of gamma which you grade to. For DVD/BD you rather want to use 2.2 or 2.4 (your monitor needs to always follow your choice accordingly) and for web probably best is sRGB. Of course in todays reality if you push file to eg. YT it will look different when watched on PC and Mac, but it's out of your control.

If you have 2 machines do a test. Connect same monitor over BM card on PC and on Mac over clean (and windowed as test) GUI feed (just tick "Use Mac color profiles"). Open same project (or file but with exactly same interpretation/project settings) in Resolve and keep switching preview between PC and Mac. Preview should look identical to the eye (use latest Mac OSX and Resolve).

Interesting! I am under the impression that using an output of Color Space Rec 709 with Gamma Rec 709-A resolves nearly all issues with Web streaming and phone viewing? The default is Rec 709/2.4 unless you checkmark "use separate color space and gamma" in the project color management tab.

(Subjectively I see that working on my own devices)

Rec.709-A will give you correct preview on Macs, but then rest requires own versions.
Rec.709-A for Mac streaming, 2.4 for brodcast and sRGB/2.2 for PC preview.
For QT X preview Rec.709-A, 2.4 and sRGB will be fine.

There may be change coming to Vimeo which will let you use sRGB so then this should work fine on Mac and most PCs as well. Took them few months to push my proposal as feature request, but still no guarantee it will happen.

Rec.709-A will give you correct preview on Macs, but then rest requires own versions.
Rec.709-A for Mac streaming, 2.4 for brodcast and sRGB/2.2 for PC preview.
For QT X preview Rec.709-A, 2.4 and sRGB will be fine.

There may be change coming to Vimeo which will let you use sRGB so then this should work fine on Mac and most PCs as well. Took them few months to push my proposal as feature request, but still no guarantee it will happen.

Thanks!!