YouTube changes my colors (desaturates, adds reds, washes out to 16-235)

[ibreakphotos]

Hey guys.
I started making lightroom and photoshop tutorials on youtube and, while I'm pretty familiar with both of those, I'm quite a noob at video. I record my screen using Camtasia (save as .avi) and then compress this avi to a .mp4 file with handbrake.

I have noticed that my videos don't look the same after uploading - they lose a lot of contrast. I googled a bit and found out things about color profiles, and the difference between TV and PC profiles, with TV profiles rendering a 16-235 range of brightness values, and PC 0-255... And I think this is what's happening with my videos.

Check example here: https://forum.videohelp.com/images/imgfiles/HLKnQ2b.jpg
You can see that the right side is a lot more desaturated and it overall lacks in contrast. (When I do "video enhancements" in the video manager by increasing the contrast to 1, the washing out is kinda fixed, but the color go completely off and are more red, while they should be yellow)

Since I make photoshop/lightroom tutorials, color accuracy is very important for me and I want to fix this ASAP. However, I haven't been able to fix this. The matter is further complicated by the fact that some other monitors display my video properly, so I thought it's a problem with my graphics card. I have a nVidia GTX 760 and after changing the dynamic range to 0-255, the video looks normal: https://forum.videohelp.com/images/imgfiles/Z4Uj8Rm.png
However, this is a fix for ME, not for all the people out there who maybe didn't check this option.
I'm wondering is there a solution to make my video appear as accurate as possible on most monitors and devices people use. If I'm showing a photography technique and my colors are off, that's quite bad, so it's very important.
I've increased the contrast in the video enhancements of youtube and it does help somewhat, but it still isn't the color accuracy that I want.
The video in question is here: https://www.youtube.com/watch?v=aInyjiH5TxQ and a screengrab from the original .avi: https://forum.videohelp.com/images/imgfiles/97q0amy.jpg

So, how do I convert my files to the correct color profile?

Thanks to anyone who can help, as I actually stopped making videos alltogether until this issue is fixed :/

[jagabo]

Upload a short sample of the MP4 video you uploaded to Youtube and a corresponding AVI (MJPEG I'm guessing) from Camtasia.

[ibreakphotos]

I actually uploaded the original .avi file to youtube because I saw some color issues already in the mp4.

Samples:

avi: https://drive.google.com/file/d/0BypaXaeNvz2eSE5nS3lQQ2wwd1k/edit?usp=sharing
mp4: https://drive.google.com/file/d/0BypaXaeNvz2eVUdydUFQNFA2OEU/edit?usp=sharing

(you can download the file using the icon on the top)

[jagabo]

Your MP4 video has the right levels But it's marked as rec.709 color when the RGB source was converted to YV12 with a rec.601 matrix. That is causing the reds to brighten and greens to darken:

https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p...=1#post2045830

You need to convince the software to convert from RGB (in the AVI) to YV12 (in the MP4) with a rec.709 matrix, not the rec.601 matrix it used. Or you can flag the MP4 video as rec.601.

Since you used x264 in Handbrake you can flag the video as rec.601 by entering:

colorprim=bt470bg:transfer=bt470bg:colormatrix=bt470bg

into the x264 Extra Options field. I don't know if Youtube obeys the flag though (many players don't either). It may assume all HD is rec.709. In which case you'll have to find some software that does the RGB to YUV conversion correctly (I didn't see any options for this in Handbrake). In AviSynth it's a simple as

AviSource("sample.avi")
ConvertToYV12(matrix="rec709")

But Handbrake doesn't accept AviSynth scripts. Does the Techsmith codec or Camtasia let you encode as YUV with a rec.709 conversion?

[ibreakphotos]

Thanks for the diagnosis

I have tried with the flag in extra options in handbrake, but it did not work... And Camtasia doesn't let me encode as YUV with a rec.709 conversion, I can only choose the number of colors... (16-bit, 24 bit)

It seems that AviSynth is the last option. I have already tried with it, but I'm having trouble with setting up the script to work. :/

Additionaly, I have After Effects, will it let me color manage properly (I have tried already on my own, but get even worse results)?

[jagabo]

It seems that AviSynth is the last option. I have already tried with it, but I'm having trouble with setting up the script to work. :/

I'm sure there are other options but for AviSynth -- how far have you gotten? Can you open a script with just

AviSource("sample.avi")

How about a script with just

ColorBars()

You can use VirtualDub to open AviSynth scripts. Many media players will open and play them too.

If you are running 64 bit Windows be aware that the 32 bit and 64 bit video systems are completely separate except for the final output to the screen. If you use a 32 bit editor/player you need to use 32 bit AviSynth and 32 bit filters (if you use 3rd part filters). If you are using a 64 bit edtor/player you need to use 64 bit AviSynth and 64 bit filters.

[Skiller]

I don't know if Youtube obeys the flag though (many players don't either). It may assume all HD is rec.709.

YouTube indeed doesn't care about the flags, Rec.709 simply always assumed – even for SD uploads.

[ibreakphotos]

I'm sure there are other options but for AviSynth -- how far have you gotten? Can you open a script with just

AviSource("sample.avi")

How about a script with just

ColorBars()

You can use VirtualDub to open AviSynth scripts. Many media players will open and play them too.

If you are running 64 bit Windows be aware that the 32 bit and 64 bit video systems are completely separate except for the final output to the screen. If you use a 32 bit editor/player you need to use 32 bit AviSynth and 32 bit filters (if you use 3rd part filters). If you are using a 64 bit edtor/player you need to use 64 bit AviSynth and 64 bit filters.

I can do your sample script (AviSource), but when I open in in VirtualDub, the frames skip and are mostly just black with the picture here and there.

I tried the one with the conversion step, and this is what I get: https://forum.videohelp.com/images/imgfiles/oxglqzw.jpg

It's actually the opposite of what I want. The colors are too red after AviSynth. I don't think this is solving anything; the original avi displays colors properly: the problem is when I upload it to youtube or convert to mp4: then the colors get messed up and they also get washed up, which isn't the case in the avi.

[ibreakphotos]

I don't know if Youtube obeys the flag though (many players don't either). It may assume all HD is rec.709.

YouTube indeed doesn't care about the flags, Rec.709 simply always assumed – even for SD uploads.

Sooo, sorry for the dumb question, but how do the videos from other people render properly and the colors are matched, without the washing out effect that I get/see?

I can't comprehend where exactly the problem starts and, hence, how to fix it.

[smrpix]

The two files you posted are identical. The problem may be in your Nvidia card settings since video overlay and "regular" monitor video can be adjusted separately.

[poisondeathray]

In short, there is no actual problem with levels with the videos or youtube. That is something with your screenshot taking process, or your configuration with your graphics card, or renderer

Part of another problem is the techsmith 2 codec. It outputs RGB, but opensource decoders like ffmpeg/libav decode it as YV12. That's why even if you upload it as the original, there could be discrpancies with what you want (YT uses ffmpeg/libav derivative for decoding and encoding)

And the official windows VFW decoder has problems with black frames (this has been reported before) - that's why you see flashes in vdub

There are some inconsistencies between what you are reporting. Your splitscreen pic suggests "avi from camtasia " is using 709, or direct RGB, but when I open up with camtasia decoder directly (outputing RGB) , the colors it looks like 601 from ffmpeg/libav would have been used. Note none of those aspects affect the levels.

[poisondeathray]

To explain better, look at your split screen photo. I've reposted it here



In the RGB screenshot, "black" edge around the border of "IBreakPhotos" logo is at RGB 0,0,0 for the "AVI" left hand side, but "black" is RGB 16,16,16 on the right hand or "handbrake" side. Obviously that's wrong

If you view or take a screenshot properly, black would be at RGB 0,0,0 for the "handbrake" side as well, in fact it is when your sample MP4 or AVI is downloaded

Just because your computer / gfx card isn't setup properly, doesn't mean everyone else has the same problem . And by the same token, there might be others who have the same setup issue (you have no control over that)



The other issue is Rec709 vs. 601. Again this doesn't affect levels, only the skin tones and color shift. I've posted resized screenshots of 709 vs. 601 should look like. When I use the Techsmith decoder, it outputs RGB and looks like the 601 screenshot. All videos on youtube will look like the 709 screenshot, when you convert it properly using 709 (YT converts back to RGB using 709), even in SD regardless of flags

601



709

[ibreakphotos]

Thanks for your replies, guys.

Part of another problem is the techsmith 2 codec. It outputs RGB, but opensource decoders like ffmpeg/libav decode it as YV12. That's why even if you upload it as the original, there could be discrpancies with what you want (YT uses ffmpeg/libav derivative for decoding and encoding)

Which codec would you recommend to avoid this issue? I can choose between these:

In the RGB screenshot, "black" edge around the border of "IBreakPhotos" logo is at RGB 0,0,0 for the "AVI" left hand side, but "black" is RGB 16,16,16 on the right hand or "handbrake" side. Obviously that's wrong

If you view or take a screenshot properly, black would be at RGB 0,0,0 for the "handbrake" side as well, in fact it is when your sample MP4 or AVI is downloaded

Just because your computer / gfx card isn't setup properly, doesn't mean everyone else has the same problem . And by the same token, there might be others who have the same setup issue (you have no control over that)

I take a screenshot just by pressing Print Screen. I paste it into Photoshop and save as web (with sRGB color space). So I actually see 16, 16, 16 on my monitor.

I get it that I can force my graphics card to use the 0-255 range instead of the 16-235 - I have said that I tried it and it worked in the first post! BUT - I don't want to do it. I can see OTHER videos on youtube with normal 0,0,0 black levels, and although it might be a problem with my configuration, it can be circumvented so even though there is an issue, colors are displayed as they should be. My question is - how do I do that?

The other issue is Rec709 vs. 601. Again this doesn't affect levels, only the skin tones and color shift. I've posted resized screenshots of 709 vs. 601 should look like. When I use the Techsmith decoder, it outputs RGB and looks like the 601 screenshot. All videos on youtube will look like the 709 screenshot, when you convert it properly using 709 (YT converts back to RGB using 709), even in SD regardless of flags

The problem is that on youtube the video looks like on the first screenshot (601), while it should look like the second (709). This is independent of my graphics card - I had my girlfriend take a screenshot of the youtube video and send it to me. It looks too red, like 601.

I mean, feel free to check out the video on youtube, it's not like I'm trying to further complicate things.

So the issues are:
1) I need to force everyone with a configuration similar to mine to display the 0,0,0 black levels (it's possible, obviously, as if it wasn't possible, ALL youtube videos would have 16,16,16 for black, which they don't)
2) Colors must render as in the second screenshout (709), while on youtube they render as 601

[poisondeathray]

1) Capture. I would always capture screen tutorials as some RGB format. Because that's what the original format being captured is (your screen). If you capture as some YUV codec, there will be a colorspace conversion, possibly subsampling , and other issues such as matrix used. By using RGB, YOU have control over what happens next. On windows you can use other lossless RGB codecs like UT Video Codec (set to RGB), Lagarith (if your computer is fast enough) set to RGB. These will be huge in filesize, but smaller than uncompressed RGB

2) As mentioned above, typically there are 2 settings for GPU's, One is the "desktop" settings, which affect things like browsers, photos, normal apps; and the GPU overlay renderer, which affects video applications which use GPU overlay . Things like video players use the 2nd setting, and it should be set to 0-255 for a computer monitor (that' s not "forcing", that's "proper" because an 8bit computer monitor calibrated for sRGB for web/ graphics/photo will be using RGB 0-255, not RGB 16-235. Now a broadcast monitor with studio RGB configuration (not sRGB) might be set up differently, if you have a secondary monitor hooked up differently)

3) YT - this is where it can get complicated because YT and flash can also use GPU acceleration , or it can be toggled off. There are differences between browsers/os and flash version. There was a change around flash 10 (we are at 14.x now) where everything uses 709 for display. Before it was 601, but there are some differences betwen chrome vs. firefox, and the windows version of firefox vs. linux.

Before, the old behaviour was entirely based on HW on vs. off. 601 was used for everything if HW accel is on. HW off, and flash would actually use the colormatrix flags to determine 601/709 (ideally that's how it should be, but people might be confused as how to "flag" videos)

To add to the mess, we have HTML5 now, not just flash. It used to be in Firefox 709 is always used. Chrome used to use 601 for HTML5, not sure what the current status is

For me, your YT video looks like the 709 screenshot. But again, that's going to change depending on how you have things configured, HW on or off, browser, os, etc....




*Best practice is to use 709 to convert to YV12, and flag it as 709 as well. You cover the most bases, platforms , os's , configurations, and are the most accurate (If you download the actual video, it will be technically "correct")

The ONLY way you can be color accurate (and even then 99% people dont have properly calibrated displays so the point is moot), is if you use some RGB format. This avoids all the YUV<=>RGB mess. Of course flash , HTML5 and YT doesn't support it.

[ibreakphotos]

1) Capture. I would always capture screen tutorials as some RGB format. Because that's what the original format being captured is (your screen). If you capture as some YUV codec, there will be a colorspace conversion, possibly subsampling , and other issues such as matrix used. By using RGB, YOU have control over what happens next. On windows you can use other lossless RGB codecs like UT Video Codec (set to RGB), Lagarith (if your computer is fast enough) set to RGB. These will be huge in filesize, but smaller than uncompressed RGB

2) As mentioned above, typically there are 2 settings for GPU's, One is the "desktop" settings, which affect things like browsers, photos, normal apps; and the GPU overlay renderer, which affects video applications which use GPU overlay . Things like video players use the 2nd setting, and it should be set to 0-255 for a computer monitor (that' s not "forcing", that's "proper" because an 8bit computer monitor calibrated for sRGB for web/ graphics/photo will be using RGB 0-255, not RGB 16-235. Now a broadcast monitor with studio RGB configuration (not sRGB) might be set up differently, if you have a secondary monitor hooked up differently)

3) YT - this is where it can get complicated because YT and flash can also use GPU acceleration , or it can be toggled off. There are differences between browsers/os and flash version. There was a change around flash 10 (we are at 14.x now) where everything uses 709 for display. Before it was 601, but there are some differences betwen chrome vs. firefox, and the windows version of firefox vs. linux.

Before, the old behaviour was entirely based on HW on vs. off. 601 was used for everything if HW accel is on. HW off, and flash would actually use the colormatrix flags to determine 601/709 (ideally that's how it should be, but people might be confused as how to "flag" videos)

To add to the mess, we have HTML5 now, not just flash. It used to be in Firefox 709 is always used. Chrome used to use 601 for HTML5, not sure what the current status is

For me, your YT video looks like the 709 screenshot. But again, that's going to change depending on how you have things configured, HW on or off, browser, os, etc....




*Best practice is to use 709 to convert to YV12, and flag it as 709 as well. You cover the most bases, platforms , os's , configurations, and are the most accurate (If you download the actual video, it will be technically "correct")

The ONLY way you can be color accurate (and even then 99% people dont have properly calibrated displays so the point is moot), is if you use some RGB format. This avoids all the YUV<=>RGB mess. Of course flash , HTML5 and YT doesn't support it.

Thanks again, your replies are really helpful. <3

I tried exporting as .avi with Lagarith set as RGB (also - RGB or RGBA?) and actually got the black levels of 16, 16, 16. :/

Then I tried with the UT video codec in RGB which rendered the proper black levels, but the colormatrix (profile?) was off.

Ugh.

[poisondeathray]

I tried exporting as .avi with Lagarith set as RGB (also - RGB or RGBA?) and actually got the black levels of 16, 16, 16. :/

Then I tried with the UT video codec in RGB which rendered the proper black levels, but the colormatrix (profile?) was off.

Ugh.

There should be no "colormatrix" for RGB recording. The matrix determines what equations are used for YUV<=>RGB conversions.

Here's the thing : RGB is RGB. Crazy revelation isn't it ? 8bit RGB to 8bit RGB, nothing is converted in terms of the pixel format


What do you mean "exporting as avi ?" Do you mean recording from camtasia ? Then what? How are you reading RGB values ? What software ?

[ibreakphotos]

There should be no "colormatrix" for RGB recording. The matrix determines what equations are used for YUV<=>RGB conversions.

Here's the thing : RGB is RGB. Crazy revelation isn't it ? 8bit RGB to 8bit RGB, nothing is converted in terms of the pixel format


What do you mean "exporting as avi ?" Do you mean recording from camtasia ? Then what? How are you reading RGB values ? What software ?

Oh, right. I have no idea how video processes color profile information.

I export as avi from camtasia (already saved project, screen recorded), then I play the output in BSPlayer and grab a screenshot from it.

[poisondeathray]

I export as avi from camtasia (already saved project, screen recorded), then I play the output in BSPlayer and grab a screenshot from it.

If you've exported it as RGB with either ut video or lagarith, then it should look identical to the screen when it was captured

RGB 1,1,1 would be RGB 1,1,1 ; RGB 2,2,2 would be RGB 2,2,2 ; etc....

Then the problem is BS Player configuration, perhaps the renderer configuration

In vdub, options => preferences, display => UNcheckmark use Direct X for display. Push save, ok. Close & reopen vdub. Open the avi in vdub. video=>copy source frame to clipboard. Paste in your image editor

And unlike YUV video, when you take a screenshot from an RGB video as a RGB png , bmp, or tiff, there is no YUV => RGB conversion, there should be nothing to go wrong unless there is an intermediate stage like a renderer

(JPEG is a different story. It's actually stored as YUV, but commonly decoded as RGB)


Another method is to use avspmod with avisynth. You can configure an RGB color picker so when you hover over the preview it will read out values in the info bar. It also tells you in the info bar you what colorspace the video or image has been opened with

[ibreakphotos]

I export as avi from camtasia (already saved project, screen recorded), then I play the output in BSPlayer and grab a screenshot from it.

If you've exported it as RGB with either ut video or lagarith, then it should look identical to the screen when it was captured

RGB 1,1,1 would be RGB 1,1,1 ; RGB 2,2,2 would be RGB 2,2,2 ; etc....

Then the problem is BS Player configuration, perhaps the renderer configuration

In vdub, options => preferences, display => UNcheckmark use Direct X for display. Push save, ok. Close & reopen vdub. Open the avi in vdub. video=>copy source frame to clipboard. Paste in your image editor

And unlike YUV video, when you take a screenshot from an RGB video as a RGB png , bmp, or tiff, there is no YUV => RGB conversion, there should be nothing to go wrong unless there is an intermediate stage like a renderer

(JPEG is a different story. It's actually stored as YUV, but commonly decoded as RGB)


Another method is to use avspmod with avisynth. You can configure an RGB color picker so when you hover over the preview it will read out values in the info bar. It also tells you in the info bar you what colorspace the video or image has been opened with

Ok, thank you very much for both your help and patience, I'll try this tomorrow and upload a sample video to youtube to check if everything's according to specs. Hopefully, it will be.

[poisondeathray]

Ok, thank you very much for both your help and patience, I'll try this tomorrow and upload a sample video to youtube to check if everything's according to specs. Hopefully, it will be.

That's only as far as your computer and screen capture so far...

YT is a different matter as described above. Even if video is "correct", how it looks on YT depends on your OS, broswer, HW on vs HW off, HTML5 vs. Flash, etc...

[jagabo]

Which codec would you recommend to avoid this issue?

UT Video Codec has the ability to convert RGB to YV12 or YUY2 on the fly when compressing, with either either rec.601 or rec.709 matrices.

<edit>

Well, this is weird. I just tried it and the codec seems to have rec.709 and rec.601 backward. With VirtualDub giving it the original RGB, when you select "UtVideo YUV420 BT.601 (ULY0) VCM" as the encoder the file gets rec.709 colors. When you select "UtVideo YUV420 BT.709 (ULY2) VCM" the file gets rec.601 colors. So if you switched to this codec you would want to use the BT.601 setting to get rec.709 colors.

[jagabo]

I tried the one with the conversion step, and this is what I get: https://forum.videohelp.com/images/imgfiles/oxglqzw.jpg

Keep in mind that VirtualDub converts YUV video to RGB for display using a rec.601 matrix. So the rec.709 YV12 output of the AviSynth script will be displayed incorrectly in VirtualDub. But if you save it to a file in Fast Recompress mode the YV12 will pass through VirtualDub unchanged.

[ibreakphotos]

Which codec would you recommend to avoid this issue?

UT Video Codec has the ability to convert RGB to YV12 or YUY2 on the fly when compressing, with either either rec.601 or rec.709 matrices.

<edit>

Well, this is weird. I just tried it and the codec seems to have rec.709 and rec.601 backward. With VirtualDub giving it the original RGB, when you select "UtVideo YUV420 BT.601 (ULY0) VCM" as the encoder the file gets rec.709 colors. When you select "UtVideo YUV420 BT.709 (ULY2) VCM" the file gets rec.601 colors. So if you switched to this codec you would want to use the BT.601 setting to get rec.709 colors.

I've tried everything you guys have said, but to no avail.

When I convert to UtVideo (either RGB, rec.601 or rec.709), I get a color shift.

So I undid everything and started back from zero. I went to the control panel and checked that my color range is 0-255. This "fixes" the black point. I wanted to deal with the color separately.

As I have said, if I convert to anything using UtVideo codec, I get a shift in color.

These are the original colors:



This is what I get:



IF I export directly from Camtasia as a mp4 file and compress it with handbrake, my colors are good when I play the file back in BSPlayer, but when I upload to youtube, something happens and my colors are wrong again:



And this doesn't even begin to address the black point.

Now, can anyone suggest something in a step-by-step manner, so that I end up with the colors that the original file has? Because frankly, this is getting very frustrating and if I can't make sure that the video that people are seeing has roughly the same RGB values as the ones that are intended, than I'll have to reconsider my choice to contribute to youtube altogether.

[newpball]

These are the original colors:


[Attachment 27355 - Click to enlarge]

This is what I get:


[Attachment 27356 - Click to enlarge]

For starters it would help if you could upload both images uncompressed PNG so we can do a mathematical comparison.

[ibreakphotos]

These are the original colors:


[Attachment 27355 - Click to enlarge]

This is what I get:


[Attachment 27356 - Click to enlarge]

For starters it would help if you could upload both images uncompressed PNG so we can do a mathematical comparison.

Sure.

Here is the PNG from lightroom (so, a desktop screenshot, how the colors "should be"):


This is how Camtasia captures it:



I forgot if I uploaded this version or the one after handbrake, which format it was (it was a long time ago, I have both mp4 and avi files), but this is how it looks on youtube now in 1080p:



In any case, this is how the .avi looks like (the second mp4 is identical to the avi):

[jagabo]

VirtaulDub always converts YUV to RGB with a rec.601 matrix, for display or filtering. So if VirtualDub gets rec.709 video it will display/and or filter it with a rec.601 matrix. You have to make sure it doesn't convert the YUV to RGB -- which means setting it to Fast Recompress mode (no filtering). It will still display incorrectly in VirtualDub but the output file will retain rec.709 colors.

[newpball]

Anyone aware of tests to see if Youtube supports RGB through HTML5?

[poisondeathray]

Anyone aware of tests to see if Youtube supports RGB through HTML5?

It doesn't , HTML5 doesn't either through VP8/9 . There are future plans to support RGB eventually in VPx, but that doesn't mean Youtube will get it , or if it will be supported in browsers. Certain versions of flash actually supported 10bit AVC, even 422 (you could run it on your own site), but YT never got it - they always re-encoded to the garden variety 8bit 4:2:0 . And no version of flash ever supported AVC encoded as RGB.

The problem now is the inconsistencies between various browsers, flash , HTML5, HW on /off . You never get the same thing displayed for everyone, even if you don't use youtube and control everything on the server side .