Hi all, wondering what best practices are for working in Rec709 color space? Unlike Maya, Blender doesn’t seem to have any Rec709 presets. Is another one of these options equivalent, or do I need to do some manual work to stay in Rec709 space? Here’s what I’m seeing:
Image texture color space options: XYZ, sRGB, Raw, Non-Color, Linear ACES, Linear, and Filmic Log.
Render color management - display device options: sRGB, XYZ, None
Render color management - view transform options: Standard, Filmic, Filmic Log, Raw, False Color
Thanks so much for this! Sorry to hear that rec709 has been removed. You’d think it would be in there as it’s a very popular and standard color space in a number of settings. I’m still relatively new to the Blender community - what’s the best way/where’s the best place to advocate for it to get brought in?
In the workaround you linked to, Step 1 links to the OCIO configurations at https://opencolorio.org/configurations/index.html, but it’s actually a broken link. Can you help me find what I should be downloading? I found this downloads page - should I be downloading “Core Library v2.0.0” from there? Or something else?
Most people use ACES or sRGB now of days I think to be honest for color space compatibility between programs.
Besides the site I shared earlier, there is also Blender Developer Talk. Here is one of the core Blender developers discussing how to request features as well.
You’re right. I think they moved it to their download page.
First of all, do you mean all three components of the Rec.709 colorspace (primaries, transfer function, white point) or just the primaries?
Second, do you mean you need to set Rec.709 as the “working space” for rendering? If that’s the case I would say it’s a bad idea since Rec.709’s transfer function is not linear, many of the maths only make sense in linear state. Or if you mean Linear Rec.709, Blender’s awfully named “Linear” space is already the Linear Rec.709, and it is the current default working space.
Third, do you mean Rec.709 colorspace with the piece-wise transfer function, or the BT.1886 space with Rec.709 primaries and 2.4 power function? Because a lot of people actually are talking about the 2.4 function when they say Rec.709.
Fourth, do you mean you have a Rec.709 encoded texture that you want to import to Blender, or do you mean you want to export a texture encoded in Rec.709?
These are the things that I cannot tell from your question description, I am curious about the answer.
This section is supposed to be the “kind of monitor you are using”, there isn’t a CIE XYZ monitor, and of course you cannot have a “none” monitor, so basically Blender currently only support sRGB monitor (not even display P3, so if you are using Mac with Apple P3 monitor you are not seeing the correct color with default Blender).
These are source input colorspace, this means if you set this texture as sRGB, the texture willl be transformed from sRGB to the current working space upon import, so when you connect it to some other nodes in the shader editor, the color data flowing between the node connections are already in the working space (which is again already Linear Rec.709). If you have a Rec.709 encoded texture though, it is true that you currently have no way to correctly import it.
But this is a rather strange need actually, as Rec.709 is more widely used as a display standard instead of an file encoding standard. Or are you talking about Linear Rec.709?
Again, we need to clarify what you actually want, or we would just have a lot of confusion.
Without the OP clarifying what he meant, I find this confusing. For example this post you linked here talked about using the ACES 1.0.3 OCIO config, and you said:
The use of the term “preset” is extremely confusing here. After looking at the link I guess you mean the Rec.709 in the “View Transform” list.
But!!! The ACES 1.0.3 config has mistakenly put the display devices list in view transform. Therefore the Rec.709 you see there, you shouldn’t touch it if you are not using a Rec.709 monitor.
If the OP is asking for Linear Rec.709 to be the working space, he actually already gets it with default Blender. By using ACES config he is using ACEScg as working space and that will not be what he said:
By choosing Rec.709 in that list, you are telling Blender to transform the render at the very very end of the chain (even after compositor), to transform it to Rec.709 encoding for your hardware Rec.709 monitor to decode it. Do you call it “working in Rec.709 colorspace”?
Without clarifying what the OP is talking about, and with unclarified terms like “preset”, this conversation is getting super confusing now.
This thread title says the color space, Rec709. I believe that clarifies what the OP wants.
ACES was one of many of the downloadable presets. However, the title of the link was asking for Rec709 as well. I am well aware that neither of the OPs wanted ACES. This is why I provided a Rec709 preset download solution, which conveniently was also a ACES preset solution.
Again he need to clarify what he meant by “Working in Rec.709 colorspace”.
Like here:
You mean OCIO config. And “preset” has been used several times in this thread and I don’t think they all mean OCIO config. Again, confusing.
Again it is not clear what he meant when he said he wants Rec.709. Because we are already using Linear Rec.709 in default Blender. This is getting confusing.
EDIT: I just realized you said the title of the link, not the title of this thread.
No, your link was asking for a wide gamut working space, with primaries wider than Rec.709. This means the link you posted was asking “how to not work in Linear Rec.709”, quite the opposite of what this thread is about.
Again it was for the Rec.709 monitor, it will transform it to a Rec.709 hardware monitor at the very end of the chain even after the compositor if you use it. It doesn’t change the working space. If you use the ACES config you are using ACEScg as working space, not Rec.709. And the OP asked for:
This is getting super super confusing if we don’t clarify the specifics.
Thanks for all of your input on this and apologies for the confusion. Admittedly I’m a bit out of my depth on some of what you’re mentioning and asking about. I’ve never worked in ACES, and there’s still a lot I need to learn about color management. Already you’ve given me a lot of new information to look into which is super helpful. Perhaps the best way to go about it is to tell you what I’m trying to solve in a particular project, in case you’re able to offer further guidance.
I’m importing 360 footage into a Blender 3D scene to use as an HDR, as well as background imagery. So it both lights up the scene and is visible in the background, with 3D elements in the foreground. The footage was shot on a camera in Rec709 color space. Ideally I’d like to be able to stay in a consistent color space the whole way through, but right now when I bring my rendered image sequence into Adobe After Effects, the colors of the background don’t match up to the original footage, no matter whether I’m interpreting as Rec709 or sRGB in After Effects. Just trying to figure out a good workflow to ensure that the HDR/video footage being rendered out of Blender matches the original video footage. Given what you’ve said, it would seem that Blender’s default is already in Rec709 color space, but I’m having a hard time getting things to match. Thanks in advance for any further advice/clarification you can offer on the process!
Do you mean you have no problem importing the HDR 360 footage into Blender, but after you export the 3D render from Blender to AE you get problems? am I understanding this correctly?
If that’s the case what’s your exported file format? Is it EXR by any chance?
I’ve been using PNG, but maybe EXR would be a better choice here going forward. Particularly when I start getting into wanting multiple render passes.
I may have been overthinking things. I ended up doing several visual A/B tests, comparing how the footage looked on its own vs. when imported into AE with different color interpretations, and same with rendering from Blender. What the issue ultimately ended up being was that the View Transform was set to the default “Filmic” and not “Standard,” within Color Management in the Render Properties. Once I changed it to “Standard”, the colors matched perfectly. Interestingly, even though it seemed the original footage was Rec709, the way to get it all to match was to use sRGB color space in every other program. I’ll have to check with our cinematographer to confirm their camera settings. But for now, everything seems to be working.
I believe AE has a plugin for OCIO, you should be able to use that plugin to load up Blender’s OCIO config and use Filmic in AE.
Again, colorspaces each has three components: Primaries, White Point (which chromaticity do you encode as R=G=B), and transfer function (like power function, or some other curves etc.)
sRGB uses the same primaries and white point (D65) as Rec.709, which means we can say sRGB and Rec.709 are only different in their transfer functions. Generally we can say Linear sRGB (sRGB with Linear tranfer function) = Linear Rec.709 (Rec.709 with Linear transfer function). Their relationship is closer than you think.
This means unfortunately AE by default is not capable of handling open domain (0 to infinity) data like EXR, but again I have heard there is a plugin to load OCIO so you can give it a try. I haven’t tried it though.
You can output any colorspace using ACES color managment, including Rec709. Yet you will have to learn somethings about it. I recommend reading the official Primer Guide, and watching video.
Thank you so much for your explanations! This is an ever-deepening rabbit hole haha, and I’m seeing how important it is to learn more about this process when doing VFX and combining footage with 3D in Blender. Much appreciated.
This is wrong. Not sure what looks correct to you but I can tell this is an ACEScg encoded sweep being wrongly assumed as Linear Rec.709/sRGB encoding.
Do the red shifting to orange and blue shifting to purple look correct to you?
Look at my test image:
See the TCAMv2 result? That’s what I call “correct” in objective tristimulus values sense (chromaticity linear). Look at AgX, that’s what I call closer to “correct”. (Yes AgX is still not chromaticity linear, AgX is a bridging step towards a brighter future, so it’s still not the best one.)
