Rec. 709 vs sRGB (losing my mind!!!)

[Andrew Somers]

“I’ve been trying for SOOO long to figure out when to use Rec. 709 and when to use sRGB and I’m close to giving up and pretending like these things don’t exist in this world. However, I’ll give it one last try.

My questions right now:
(1) To achieve more realistic blendings and motion blur I want to work in a linear color space, but this means that I have to choose between Rec. 709 and sRGB – how do I know which one to pick? (I don’t have any delivery specifications – I’m creating films mostly for fun but they’ll probably end up on YouTube).
(2) Why should I even work in sRGB in After Effects when Premiere and FCPX uses Rec. 709 and the final export will be made from Premiere or FCPX?
(3) Is it a bad idea to embed Rec. 709 color profile when exporting PNG-images for the web, and why?”

For LINEAR Working Space:
First of all, if you are using 32 bit linearworking space (gamma 1.0) then it does not matter if you choose sRGB or Rec709 – both use the exact same primaries, so the only difference is the gamma curve. If you are working in linear gamma 1.0, there is no gamma curve (it is a straight line). In a linearized working space, the color profile you choose to work in will only affect the position of the color primaries and white point coordinates.

For GAMMA ENCODED Working Spaces:
If you are working in a gamma encoded space (i.e. not linearized), as you might in 16 bit mode, then pick the colorspace you are going to output to so there are no color rtransformations on output. This is particularly critical if you are working in 8 bit for some reason.

For Video:
The standard for HD video is Rec709. Rec709 is specified as a “scene referred” standard with a scene referred gamma of approx. 1.9 (it is not a pure gamma curve however, as there is a linearization for very dark levels). A scene referred gamma was chosen for the standard because the output gamma of a display is going to vary depending on the viewing environment and how that display is adjusted for same.

See: https://prolostx.squarespace.com/blog/2008/2/22/digital-cinema-dynamic-range.html

It’s useful to note that while the broadcast standard specifies 16 for black level and 235 for white, Quicktime and most web video codecs expect to see 0 for black and 255 for white, so when outputting video for web choose Rec709 (0-255) and not (16-235).

For Web Images:
The worldwide standard for web images is sRGB. When you output still images for use on the web, is it best to output them as sRGB. Embedding the colorspace here is optional, so long as you choose sRGB as the output colorspace.

For web use you should never use any colorspace other than sRGB, even with an embedded profile – many browesers and systems are not color managed, and so images not output as sRGB will not look correct even with an embedded profile.

[Andrew Somers]

Duplicate Post

[Andrew Somers]

Rec709 has always specified a gamma, it is:

It details the scene referred encoding gamma for cameras and Rec709 video signals.

It is scene referred, not output referred.

In the initial Rec709 spec (1993) output referred gamma assumed to be the “known quantity” of CRT type displays that were in use at the time. Output gamma was defined as Rec1886 in 2011for the display itself, and Rec2035 in 2013 to define the associated viewing environment.

A principle reason a scene referred profile was defined for the SIGNAL (i.e. how you OUTPUT from AE for example) was due to the unknown variations in viewing environment and how the monitor was adjusted for a particular environment.

The correct output gamma for a given display will vary based on the viewing environment.
Thus “scene referred” is the best practice for the signal.

When you *export* from AE using the “Rec709-elle-V4-rec709.icc” profile, it uses an approximate 1.9 Gamma Curve as defined in the standard (it is approximate because the standard defines a linearized portion near black that offsets the gamma curve slightly).

There are however other profiles floating around that are “named” Rec709 that are using other gamma curves, for instance the profile named “HDTV (Rec709)” seems to be using a 2.2 gamma curve. While this may be the appropriate one to use for WEB video, it is technically incorrect as far as the Rec709 standard is concerned.

[Chang Lee]

Nice tip, thanks

[Luiz Cruz]

Hey there, everyone!

Me, too, in 2020, am struggling to deal with profiles in web images/video, especially for social media. I have a client that one of his brand palette colors is #064C54. After a lot of research assuming CSS colors as a standard, I’ve found out that either using a non-color managed document or using an sRGB document on Photoshop (then outputting it to, say, a JPG file) will both output this color exactly like the CSS color so for their social media posts I’m using sRGB as a standard.

However I recently began creating small animated movies, also for their social media platforms. I make some of them on Premiere and some on After Effects, depending on the complexity of animations. I always use Media Encoder to render them. In Premiere, as I don’t have the option to choose a color profile, I noticed when I opened the video file on VLC, it reports a Rec. 709 embedded profile. In comparison to CSS colors, a solid that on Premiere was filled with color #064C54 will look off when using the outputted video file to the pure CSS, to the non-color managed JPG and to the sRGB JPG. If I open this video file on Chrome and use its eyedropper tool it reports the #074B56 color.

The same happens on After Effects. There, I created a background solid filled with #064C54 and it doesn’t matter if my composition is set to “HDTV (Rec. 709)”, “Rec. 709 Gamma 2.4”, “sRGB” or isn’t color managed the outputted video file shows exactly the same behavior: Chrome reports that color as #074B56. VLC doesn’t report an embedded color profile like on Premiere-outputted videos.

What is going on? How can I be sure these animations will carry the exact same color to the outputted video files? I’d really like to understand more about this subject.

[Andy Devries]

[Luiz Cruz] “The same happens on After Effects. There, I created a background solid filled with #064C54 and it doesn’t matter if my composition is set to “HDTV (Rec. 709)”, “Rec. 709 Gamma 2.4”, “sRGB” or isn’t color managed the outputted video file shows exactly the same behavior: Chrome reports that color as #074B56.”

What settings are you using in your output module? Most lossy video codecs will result in varying degrees of color compression…if I take a color solid, render it to 32-bit Prores 4444 (described by Apple as “visually lossless”), bring it back into AE and plop into the comp it originated from, then watch the Info tab while hovering over the image…I will see small deviations from the original solid (depending on where I’m hovering, which can be a little maddening). More lossy codecs will see more deviation.

From there…I would not consider eye-dropping in Chrome a suitable testing environment. Who knows what kind of voodoo might be happening there. Nor would I put much stock in whatever compression is performed platform-side (facebook, instagram, etc…yuck). You’re almost certainly going to get color shifts when compressed by their internal chopshop…welcome to the wild world of web video! The best we can do is manage color appropriately up until file output. Should a client complain that their color looked “off” on device XYZ on platform ABC…the best you can do is speak confidently of the work done up until the moment it left your machine.

[Olivié Charbonneau]

Thank you for your insight, very interesting.
So a profile using “Rec.709” in it’s name can be gamma 2.4 or 1.9 or 2.2 or something else…
We tempting to operate as if none of this interesting topic ever existed ☺

[Olivié Charbonneau]

Hey Luiz, maybe somewhere in the chain a Rec.709 profile is assumed instead of your sRGB.
Anyways in After Effects you can go into your Output module in the Render queue, and then beside “Main options” you have another tab “Color management” : here you can hopefully deal with your color shift.