Final Explanation of Gamma and Color Shift Problems

If Andrew, who is of the best expert on this forum, still have questions about that gamma headache.. then we are all lost, guys

I don't know much at all
I just try things to get to the bottom of it.
I think I was so wrong last time, now there is new light in the tunnel.
Shame no one with actual knowledge is able to comment, to simplify whole process.
I don't have anymore access to tools which would help to solve it once for all, so it's just all more of a guess Also Resolve is not bugs free which is not helping.

Another addition to this never ending story, from India this time:
https://wolfcrow.com/the-best-settings- ... -or-vimeo/

Another addition to this never ending story, from India this time:
https://wolfcrow.com/the-best-settings- ... -or-vimeo/

Thank for the link
I start to read it
Many Good informations .. thanks to the author
But some approximations that doesn't impact the subject.

SCR-20231202-ibrh.png (45.6 KiB) Viewed 223656 times

Full Level has no Super White Video Level has !!

SCR-20231202-icnj.png (45.86 KiB) Viewed 223656 times

"Have to" seems a bit strong
The good thing with resolve is that :
- you can Grade/Monitoring with Full Level then Deliver in Video Level
- you can Grade/Monitoring with Video Level then Deliver in Full Level
- you can Grade/Monitoring then Deliver with the Same Level

SCR-20231202-icza.png (50.79 KiB) Viewed 223656 times

You don't need to pay attention "first" ...only on the deliver page. It has nothing to do with the project settings

The author advise to read the Manual about Levels. I'm sure he did it ... but it does means he fully understand how it works.
I feel the same when I read Andrews post

Again I correct those "mistakes" ... so that we can discuss on the same page. I don't blame the author
I'll keep reading (the tests) the link

SCR-20231202-idur.png (43.26 KiB) Viewed 223627 times

Level conversions isn't relevant to RCM. It also works with Davinci YRGB Color Science.
He confused Level conversion with Colorspace Conversion (relevant to RCM/ACES)

SCR-20231202-iely.png (36.54 KiB) Viewed 223627 times

Another Confusion
Color Matrix is not Chroma sub sampling
Rec2020 4:2:0 and rec709 4:2:0 haven't got the same color matrix but have the same chroma sub sampling

The author also advices 709-A for Youtube/Vimeo which sounds a mistake to me.

If you graded in Rec.709 gamma 2,4, then you should use CST to export in Rec.709 gamma 2,2. The tag won't be correct for Youtube/Vimeo but you can overwrite it from the Deliver page in order to get 1-1-1.

Does YT read the tag at all?
In all my tests in the past it simply always passed video as is without any conversion giving it new tag of 1-1-1. My last test was quite long time ago though.
Test is simple.
Export some video with eg. 1-4-1 tag ( 2.2 gamma project), make a copy of it and re-tag with Mogurenko tool as 1-1-1. Send both videos to YT. Are they looking the same or not?
If the same then it would mean YT did not read/care about the tag. If opposite it means there was some conversion applied.

Does YT read the tag at all?
In all my tests in the past it simply always passed video as is without any conversion giving it new tag of 1-1-1. My last test was quite long time ago though.
Test is simple.
Export some video with eg. 1-4-1 tag ( 2.2 gamma project), make a copy of it and re-tag with Mogurenko tool as 1-1-1. Send both videos to YT. Are they looking the same or not?
If the same then it would mean YT did not read/care about the tag. If opposite it means there was some conversion applied.

I did the test you mentioned : import the same video (gamma 2.2) with 2 different tags (1-1-1 and 1-4-1) to YouTube.
The one tagged 1-4-1 is not right, with crushed blacks, etc.
The one tagged 1-1-1 is close to whats's been validated within in Resolve.

So YouTube cares about the tag of the video file uploaded.
It applies a conversion based on this tag.

Ok- this was not the case in the past. All was going trough YT "as is" regardless of the tag.
I assume this is good news.

Does YT read the tag at all?
In all my tests in the past it simply always passed video as is without any conversion giving it new tag of 1-1-1. My last test was quite long time ago though.
Test is simple.
Export some video with eg. 1-4-1 tag ( 2.2 gamma project), make a copy of it and re-tag with Mogurenko tool as 1-1-1. Send both videos to YT. Are they looking the same or not?
If the same then it would mean YT did not read/care about the tag. If opposite it means there was some conversion applied.

I did the test you mentioned : import the same video (gamma 2.2) with 2 different tags (1-1-1 and 1-4-1) to YouTube.
The one tagged 1-4-1 is not right, with crushed blacks, etc.
The one tagged 1-1-1 is close to whats's been validated within in Resolve.

So YouTube cares about the tag of the video file uploaded.
It applies a conversion based on this tag.

And the resulting tag is then set (by YouTube) to 1-1-1, after conversion? Is that correct?

And the resulting tag is then set (by YouTube) to 1-1-1, after conversion? Is that correct?

Once uploaded to YouTube, both video files can be downloaded from YouTube with the 1-1-1 tag.
YouTube overwrites the original tag.

Do you have Mac with ref modes?
If so check how YT looks in standard (default) screen profile and then with BT.1886 one (try to ignore brightness difference).

Do you have Mac with ref modes?
If so check how YT looks in standard (default) screen profile and then with BT.1886 one (try to ignore brightness difference).

I don't have reference modes on my Mac monitor.

YouTube does not read source NCLC tags. All that gets sent through is 1-1-1 NCLC, regardless of what the uploaded file's NCLC tags actually were.

If you want to control how your files appear on Apple devices when played on YouTube, your only option is to steer into the skid of how Apple interprets 1-1-1 NCLC tags for display.

That means either:

1. Grading on an Apple device display with Resolve's output color space set Rec709-A in a relatively bright surround lighting environment.

or

2. Conform your BT.1886 reference graded image for how Apple ColorSync interprets 1-1-1 NCLC tags taking into account both the dim surround reference lighting environment plus the difference between BT.1886 and ColoySync's interpretation of 1-1-1 NCLC.

Neither option is ideal, but it is what it is.

YouTube does not read source NCLC tags. All that gets sent through is 1-1-1 NCLC, regardless of what the uploaded file's NCLC tags actually were.

So how do you explain the results of the test I did earlier?
Thought it proved the opposite.

That means either:
1. Grading on an Apple device display with Resolve's output color space set Rec709-A in a relatively bright surround lighting environment.

or

2. Conform your BT.1886 reference graded image for how Apple ColorSync interprets 1-1-1 NCLC tags taking into account both the dim surround reference lighting environment plus the difference between BT.1886 and ColoySync's interpretation of 1-1-1 NCLC.

Neither option is ideal, but it is what it is.

YT use to pass content 'as is' just changing tag, but looks like now it's not the case.

3rd - use BT.1886 reference mode (when possible) during grade and when watching YT.

YT use to pass content 'as is' just changing tag, but looks like now it's not the case.

YouTube encoding only changes the NCLC tag to 1-1-1. The source tags are completely ignored. I constantly test this to confirm. Nothing has changed recently.

EDIT: I stand corrected. Despite just testing this all a few weeks ago, it does appear that YouTube has recently changed to actually adjusting the image when encoding to account for the NCLC tags for 2.2 gamma (1-2-1) and for sRGB encoding gamma (1-13-1). It treats 1-1-1 NCLC and 1-2-1 NCLC as the same, along with any other that has unspecified tags.

YT use to pass content 'as is' just changing tag, but looks like now it's not the case.

YouTube encoding only changes the NCLC tag to 1-1-1. The source tags are completely ignored. I constantly test this to confirm. Nothing has changed recently.

I have uploaded 2 times the same gamma 2.2 video, 1 times with tag 1-1-1 and 1 time with tag 1-4-1.
The videos are very different from each other on YouTube.
Did I do anything wrong here?
Sorry but this is quite confusing.

Could someone else do the same test and give us their results?

YT use to pass content 'as is' just changing tag, but looks like now it's not the case.

YouTube encoding only changes the NCLC tag to 1-1-1. The source tags are completely ignored. I constantly test this to confirm. Nothing has changed recently.

3rd - use BT.1886 reference mode (when possible) during grade and when watching YT.

Reference mode on the Mac solves nothing since Apple device owners are not turning on reference mode when viewing YouTube.

You send same file tagged differently and check YT preview?
It may depend what tag is saying- some tags may be passed through, others converted. Try 1-1-1 and 1-4-1.

Well- if you have ref modes and you want correct preview then you can turn it on. For those who don't care it doesn't matter as they "don't care"

To have it more universal we need an introduction of BT.1886 tag, so modern SDR content can be tagged accurately. Other solution is to have OSX setting which would automatically turn on ref mode for 1-1-1 tagged video (same as iPad Pro does when ref mode is enabled).

You send same file tagged differently and check YT preview?

That’s indeed what I did.

That’s indeed what I did.

And how did you create those files?
To isolate that single variable of the NCLC tag, the underlying image data needs to be identical in both uploaded files, and the only difference between the two files should be the NCLC metadata. If the image data is different, the files will of course look different from each other on YouTube.

Question, is there a good software on Windows to check the quicktime tags/change them that is simply to use (no command lines) and it doesn't cost a insane amount?

Exporting from Resolve and only changing the tagging on the deliver page should produce equal files with only the tagging changed. This should give you a means to upload to YouTube two same files with different tagging.

That’s indeed what I did.

And how did you create those files?
To isolate that single variable of the NCLC tag, the underlying image data needs to be identical in both uploaded files, and the only difference between the two files should be the NCLC metadata. If the image data is different, the files will of course look different from each other on YouTube.

How I did it?

I have used a previous gamma 2.2 master files that I had exported with tag 1-1-1 for web delivery.
I have duplicated the file and changed its tag to 1-4-1 with AMCDX Video Patcher.
Then I have uploaded both files to YouTube.
The results are different.

Looks like you don’t trust my process.
What am I doing wrong here?

Exporting from Resolve and only changing the tagging on the deliver page should produce equal files with only the tagging changed. This should give you a means to upload to YouTube two same files with different tagging.

Yes, indeed, this is another option.

Question, is there a good software on Windows to check the quicktime tags/change them that is simply to use (no command lines) and it doesn't cost a insane amount?

You can use the free software AMCDX Video Patcher.

The one tagged 1-4-1 is not right, with crushed blacks, etc.
The one tagged 1-1-1 is close to whats's been validated within in Resolve.

Can you elaborate on "Crushed black" ?
Even with Conversion (Gamma 2.2 ➧ gamma 1,96) Blacks & Whites shouldn't be touch, only the grey areas

Crushed black could be a Level issue…

The one tagged 1-4-1 is not right, with crushed blacks, etc.
The one tagged 1-1-1 is close to whats's been validated within in Resolve.

Can you elaborate on "Crushed black" ?
Even with Conversion (Gamma 2.2 ➧ gamma 1,96) Blacks & Whites shouldn't be touch, only the grey areas

Crushed black could be a Level issue…

The 1-4-1 version is very dark and contrasty.
There is no level issue considering that the original gamma 2.2 tag 1-1-1 file is quite correct and that the duplicate version (with the issue) is the exact same file but with tag 1-4-1.
If there was a level issue, it would be present on both files, because it has nothing to do with the tags.

Can anyone else do the same test?
It’s pretty quick and easy to do.

The 1-4-1 version is very dark and contrasty.

Sorry to insist, but what you describe again look like a lot to Level issue.
I understand that both of you files have the same coded values (color data)
You only change the color space tag.
1 - are your sure that both of your file have a Level tag
2 - if so, are they the same ?
3 - if there is no level tag in both file, could we consider that YT assume 1-4-1 tagged files are Full and don't apply any colorspace conversion? I know it's tricky
I'll do some testing

I'll did "same" test as Bastien
I get a Linear grey

SCR-20231204-jary.png (26.75 KiB) Viewed 222923 times

I do a deliver with Tag 1-1-1 & 1-4-1
I duplicate the 1-4-1 in the finder and change its tag to 1-1-1 with AMCVX videoPatcher
I upload thoses 3 files to Youtube
I download those 3 file from Youtube ➧ they are all tagged 1-1-1 (MediaInfo)
I import them in Resolve, they are all the same in the Waveform.
here are 1-4-1 and 1-4-1 modified in 1-1-1 in Youtube

SCR-20231204-jdhv.png (214.84 KiB) Viewed 222923 times

They look identical to me

It shows that Youtube ignore the tags and don't do any colorspace conversion
Am I doing something wrong ?

One of you checks the look in youtube, other after download in Resolve…

Youtube might aswell store the color tagging in database, not read it from transcoded file for all we know. If this were the case, tagging in the file you download would be irrelevant in the context of youtube playback.

One of you checks the look in youtube, other after download in Resolve…

I also check in YouTube . I joined a screen capture. haven't you seen it ?

Youtube might aswell store the color tagging in database, not read it from transcoded file for all we know. If this were the case, tagging in the file you download would be irrelevant in the context of youtube playback.

I agree

It's not possible probably because it's not a standard
Standard is viewing at 2.4 gamma (or more precise around 2.4 defined by BT.1886 ), not encoding at 2.4.

Hello
I'm always struggling about what you say.
And I'read it severals time from you in the forum
I need some clarifications please

When grading in resolve (rec709Gamma 2,4 Output colorSpace with RCM), there are encoding values that are sent to the monitoring in the SDI
1- Do you say thoses values aren't encoding with gamma 2.4 through the SDI with the monitoring set to gamma 2.4
If I Change my Resolve output colorspace and monitoring to gamma 2.6 ... The monitoring show the same reproduction. And the values sent in the SDI aren't encoded with gamma 2.6 ?
2 - I always thought that encoding values sent in SDI are exactly the same as the encoding values sent to :
the viewers (before any ColorSync transformation applied)
the videos Scope (before any settings applied)
the deliver page (before any render setting applied)
Am I wrong ?

What I want to clarify is
If my grading monitor is set to Gamma 2.4 ➧ then my file from deliver has gamma 2.4 encoding values, hasn't it ?
if not what about P3-D65 gamma 2.6 color space grading and delivering scenario ?
Thanks

‚Rec.709’ seems to be not 1:1 pipe which means encoding decoding gamma are not the same. Over the time we had different decoding gammas, probably due to fact that originally industry ‚forgotten’ to specify it.
To my knowledge encoding gamma for 2.4 setting in resolve is 1.96 and not 2.4. Same is for ‚scene’ setting. It’s up to viewing device to use ‚correct’ decoding gamma. What travels over SDI is rather 1.96 encoded data which based on your monitor setting is displayed in 1 or another way ( you have no idea about math behind ref screens/TVs settings).
Place where it’s somehow ‚visible’ is new reference modes on Macs. There you can see that BT.1886 preset applies ‚gamma boost’ with value of 1.22 ( 2.4/1.96). If your video would be encoded with gamma of 2.4 then this preset would give ( after boots) very wrong end result. Question is: is it just an Apple interpretation of of BT.1886 or do all devices work this way?
There is a thread where some user reports all of this. His findings seems to align with above ( and negate my previous statement about 2.4 gamma tags etc.). I can’t find this thread but there is useful info there.

2.6 DCI is ver different story - I would say this is 1:1 pipe so SDI transmit 2.6 encoded data.
Same for HDR format. It’s only Rec.709 which seems to be messy as decoding gamma was never defined in original spec ( until BT.1886 came).

Well, I have done the test another time to make sure that I haven't done anything wrong during the process.
Please find the following documentation about my workflow and conclusions.

DaVinci Resolve - Project settings :



I have set everything to Rec.709 Gamma 2.2 to simplify the process and to be sure that we are only working in this very color space and gamma.
During the entire test, I have double checked that the input color space on all the files in the color page is correctly set to Rec.709 Gamma 2.2 (which is defined in the project settings).

DaVinci Resolve Timeline :
A simple SMPTE color bars generated by Resolve.

DaVinci Resolve - Export settings :
Color Space Tag : Rec.709
Gamma Tag : Rec.709-A
This results in the following NCLC tag : 1-1-1

Color Space Tag : Rec.709
Gamma Tag : Gamma 2.2
This results in the following NCLC tag : 1-4-1

I have exported both files and re-imported them inside Resolve, they look the same.
So it's behaving as expected. There is no issue at this point.

You can check the comparison here :

From Resolve to YouTube :
Then, I upload both files to YouTube and check the results in the YouTube video player.
You can check both files via the link below.

[A] Gamma 2.2 tagged 1-1-1 uploaded here :

[B] Gamma 2.2 tagged 1-4-1 uploaded here :

As you can see, the [B] video tagged 1-4-1 is darker than the [A] video tagged 1-1-1.
I have checked on both web browsers, Safari and Chrome. The result is the same.

First conclusion :
YouTube is considering the NCLC tag of the video file to modify how it's displayed.

From YouTube back to Resolve :
Let's do the another test of downloading the videos back from YouTube and reimporting them inside Resolve.
As we know, the [B] 1-4-1 video has been retagged 1-1-1.
So we have two videos with the same tag and supposedly the same gamma 2.2.

Comparaison of both videos within Resolve :

Now this is interesting, the original [A] 1-1-1 video file is correctly displayed, similar to the SMPTE color bars generated inside Resolve.
However the [B] video retagged 1-1-1 is not the same anymore when imported in Resolve.
The [B] video is darker even inside Resolve, so it is showing similar to how it was when streamed on YouTube.

Second conclusion :
YouTube is not only changing the NCLC tag of the downloaded video file, forcing it to be 1-1-1.
YouTube is also changing the video gamma, definitively, after its conversion (based on the original NCLC tag) once the video file is uploaded.
It is impossible to retrieve the original gamma of the file that's been uploaded.

I have checked again and again but I don't see any error on my test...

So I am wondering, did you follow the same workflow Olivier?

I hope this can help to better understand what's going on.

Exporting from Resolve and only changing the tagging on the deliver page should produce equal files with only the tagging changed. This should give you a means to upload to YouTube two same files with different tagging.

That's what I was saying earlier. No need an extra software. You can export directly in Rec 709 gamma 2,2 with a 1-1-1 tag.

All points to YT performing conversion.
Try exporting file tagged as 2.4 gamma (1-2-1+2.4 gamma) and check this on YT.

All points to YT performing conversion.
Try exporting file tagged as 2.4 gamma (1-2-1+2.4 gamma) and check this on YT.

Please find the SMPTE color bars set to gamma 2.4 with the Resolve project settings, and exported with the 1-2-1 tag :

The video is identical to the previous gamma 2.2 tag 1-1-1 video, within YouTube.
The file downloaded from YouTube (retagged 1-1-1) is also identical to the SMPTE color bars when re-imported inside the Resolve project.

Well, I have done the test another time to make sure that I haven't done anything wrong during the process.
Please find the following documentation about my workflow and conclusions.

DaVinci Resolve - Project settings :



I have set everything to Rec.709 Gamma 2.2 to simplify the process and to be sure that we are only working in this very color space and gamma.
During the entire test, I have double checked that the input color space on all the files in the color page is correctly set to Rec.709 Gamma 2.2 (which is defined in the project settings).

DaVinci Resolve Timeline :
A simple SMPTE color bars generated by Resolve.

DaVinci Resolve - Export settings :
Color Space Tag : Rec.709
Gamma Tag : Rec.709-A
This results in the following NCLC tag : 1-1-1

Color Space Tag : Rec.709
Gamma Tag : Gamma 2.2
This results in the following NCLC tag : 1-4-1

I have exported both files and re-imported them inside Resolve, they look the same.
So it's behaving as expected. There is no issue at this point.

You can check the comparison here :

From Resolve to YouTube :
Then, I upload both files to YouTube and check the results in the YouTube video player.
You can check both files via the link below.

[A] Gamma 2.2 tagged 1-1-1 uploaded here :

[B] Gamma 2.2 tagged 1-4-1 uploaded here :

As you can see, the [B] video tagged 1-4-1 is darker than the [A] video tagged 1-1-1.
I have checked on both web browsers, Safari and Chrome. The result is the same.

First conclusion :
YouTube is considering the NCLC tag of the video file to modify how it's displayed.

From YouTube back to Resolve :
Let's do the another test of downloading the videos back from YouTube and reimporting them inside Resolve.
As we know, the [B] 1-4-1 video has been retagged 1-1-1.
So we have two videos with the same tag and supposedly the same gamma 2.2.

Comparaison of both videos within Resolve :

Now this is interesting, the original [A] 1-1-1 video file is correctly displayed, similar to the SMPTE color bars generated inside Resolve.
However the [B] video retagged 1-1-1 is not the same anymore when imported in Resolve.
The [B] video is darker even inside Resolve, so it is showing similar to how it was when streamed on YouTube.

Second conclusion :
YouTube is not only changing the NCLC tag of the downloaded video file, forcing it to be 1-1-1.
YouTube is also changing the video gamma, definitively, after its conversion (based on the original NCLC tag) once the video file is uploaded.
It is impossible to retrieve the original gamma of the file that's been uploaded.

I have checked again and again but I don't see any error on my test...

So I am wondering, did you follow the same workflow Olivier?

Now I see what you called "darker" and I agree it's not a level issue, but a gamma issue

In Your first conclusion. you assume Colorspace transformation is done for displaying only not for encoding
how can you be sure of that ?
It goes with the fact that YT ignore tag for encoding…

In your Second conclusion you show that YouTube does a colorspace conversion for encoding value.
I agree with that . It's the opposite of your first conclusion and what I tested earlier
I'll re-do the same test as yours

I see tests were done with 2.2 based project. I think it would be easier if we do Rec.709 scene.
If we started with 2.2 exported file tagged accordingly (1-4-1) we should end up with end file as Rec.709 1-1-1 which should display correctly in Resolve (assuming YT done good conversion). It was not the case meaning YT is not done correct conversion.

‚Rec.709’ seems to be not 1:1 pipe which means encoding decoding gamma are not the same. Over the time we had different decoding gammas, probably due to fact that originally industry ‚forgotten’ to specify it.
To my knowledge encoding gamma for 2.4 setting in resolve is 1.96 and not 2.4. Same is for ‚scene’ setting. It’s up to viewing device to use ‚correct’ decoding gamma. What travels over SDI is rather 1.96 encoded data which based on your monitor setting is displayed in 1 or another way ( you have no idea about math behind ref screens/TVs settings).
Place where it’s somehow ‚visible’ is new reference modes on Macs. There you can see that BT.1886 preset applies ‚gamma boost’ with value of 1.22 ( 2.4/1.96). If your video would be encoded with gamma of 2.4 then this preset would give ( after boots) very wrong end result. Question is: is it just an Apple interpretation of of BT.1886 or do all devices work this way?
There is a thread where some user reports all of this. His findings seems to align with above ( and negate my previous statement about 2.4 gamma tags etc.). I can’t find this thread but there is useful info there.

2.6 DCI is ver different story - I would say this is 1:1 pipe so SDI transmit 2.6 encoded data.
Same for HDR format. It’s only Rec.709 which seems to be messy as decoding gamma was never defined in original spec ( until BT.1886 came).

thanks for your answer

Now I see what you called "darker" and I agree it's not a level issue, but a gamma issue

In Your first conclusion. you assume Colorspace transformation is done for displaying only not for encoding
how can you be sure of that ?
It goes with the fact that YT ignore tag for encoding…

In your Second conclusion you show that YouTube does a colorspace conversion for encoding value.
I agree with that . It's the opposite of your first conclusion and what I tested earlylier
I'll re-do the same test as yours

My first conclusion just states that YouTube doesn't ignore the tag of the file uploaded.
Indeed, at this point of the test, I was only able to judge what was displayed.

My second "updated" conclusion is showing that YouTube is re-encoding the file in another gamma, depending on the tag, during its internal process ingesting the uploaded files.
This is kind of expected as YouTube doesn't offer any sort of "download original file" option in its settings (Vimeo has this option). The re-encoded version is the only one they keep on their servers ; it's the one that is streamed, that shows up on our displays and that can be downloaded afterwards.
I guess it's also easier to serve a video that is already re-encoded in the delivery gamma rather than converting the original file 'on the go' for streaming with another gamma.

My previous explanation was structure in a way to show my process and progressive conclusions along the test. Sorry if this is confusing.

Please re-do your test because it looks like you don't find the same results.

Also BT.1886 spec clearly says that:
"This Recommendation does NOT change any signal parameters defined in Recommendation ITU-R BT.709; legacy installations are not impacted."
so I would assume encoding gamma is not changed since very first introduction of Rec.709.

...

Please re-do your test because it looks like you don't find the same results.

Regardless of what YT does it has not done right thing.
Your "perfectly real by nature and tag" 2.2 gamma file did not end up correctly as Rec.709 1-1-1 file which means conversion is wrong. If YT is normalizing files then downloaded B file should show in Resolve good bars.
No idea how your 2.2 based file tagged as 1-1-1 is showing fine bars in Resolve (we lie about its real nature).

I see tests were done with 2.2 based project. I think it would be easier if we do Rec.709 scene.
If we started with 2.2 exported file tagged accordingly (1-4-1) we should end up with end file as Rec.709 1-1-1 which should display correctly in Resolve (assuming YT done good conversion). It was not the case meaning YT is not done correct conversion.

Do you mean test again with those settings?



Then export with tag 1-4-1, upload to YouTube, download from YouTube, import in Resolve, and compare with the SMPTE color bars inside the same Resolve project?

Correct me if I misunderstood something.

No- don't use 2.2 on output. Just use Rec.709 gamma in Resolve 18.6.3.

No- don't use 2.2 on output. Just use Rec.709 gamma in Resolve 18.6.3.

So with a CST from Rec.709 Scene to Gamma 2.2, right ?
Correct me if I am wrong, but we want to export a video file with gamma 2.2.

Let me know precisely which test you are looking for.

No, we don't want 2.2 as somehow it only convolutes (for me) whole test.
2.4, Rec.709 (Rec.709 scene) are all the same-1,96 curve based. 2.2 gamma is really 2.2 curve.

No, we don't want 2.2 as somehow it only convolutes (for me) whole test.
2.4, Rec.709 (Rec.709 scene) are all the same-1,96 curve based. 2.2 gamma is really 2.2 curve.

If you want me to check something, let me know precisely which test you are looking for.

All set to Rec.709 (scene).

All set to Rec.709 (scene).

Then all the files are the same within Resolve :
- the original SMPTE color bars generated
- the exported Rec.709 Scene (1-1-1) file from Resolve
- the same Rec.709 Scene(1-1-1) file uploaded and then downloaded from YouTube
When all of those files are imported inside Resolve, they match.

This is normal because the file has the tag 1-1-1, which matches what YouTube is expecting.
When the tag is 1-1-1, YouTube is not converting the gamma of the video.
What is the point of this test?

I thought we were trying to show that YouTube reads the tags and applies a gamma correction to the video file depending on the tag (other than 1-1-1).
I guess I am missing something here.