I want to mix some blender assets with preexisting footage but I can't get the colors to match exactly.

For example, create a new eevee scene with only a plane and a camera (no lights). Match the world surface color from an input image. Create a shadeless material for the plane, matching the emission color from the input image. Set color management to sRGB, Standard, None, Linear. Render.

Sample the output. Notice that the plane and background colors of the final render don't match the specified colors.

Note: Blender 2.80.

  • $\begingroup$ What happens if you specify the encoding as sRGB and set it as an emission of 1.0? $\endgroup$
    – troy_s
    Commented Sep 11, 2019 at 21:40
  • $\begingroup$ I'm not sure what you mean. Emission node strength is 1.0 and color management is set to sRGB. $\endgroup$
    – user19087
    Commented Sep 11, 2019 at 23:44
  • 1
    $\begingroup$ All pixels are emission. In a 2D scenario, you can perform animation as a direct emissive plane, or a plane of reflectance that you light. If you do a direct emissive plane of sRGB encoded values, identify the encoding as sRGB to the software, then emit at 1.0 units, you will see 1:1 with the input assuming the camera rendering transform matches. It’s a silly way to go about things, but it would deliver what you expect. It’s silly because if you are doing 2D work in a path tracing engine, it’s wiser to think like a traditional 3D scene. $\endgroup$
    – troy_s
    Commented Sep 12, 2019 at 19:52

2 Answers 2


Since the color management applies at the very end of the chain, the sRGB transform curve modify the RGB values.
You will see a perfect match if you set the color management to linear (display device to none) save it as tiff with the checkbox save as render enabled, this way you can visualize a linear render without transformation.

But remember for real light condition you need to set the display device to sRGB (if you have a sRGB monitor) otherwise you'll not see the light like in real life, due to all the transformation operating during the chain.
So depending of what you are doing exactly (you don't provide a lot of infos about your workflow) you need to choose the correct way of doing things depending if you want to display or work with your image and how you would mix different footages.

Here it's becoming a bit complex, remember real light intensity is linear, but the eyes apply a contrast curve (a bit like sRGB transform curve), so to see an image like we see the world with our eyes, we need to display a linear image with the monitor.

The chain is like this:

  1. The render is linear
  2. We save it with a sRGB transform curve (not linear anymore)
  3. The monitor transform it the opposit way, so the image is linear again
  4. The eyes apply a contrast curve and we see it like really world

Light intensity is linear but we don't see it linear. It's a really interesting and hard topic to dive in. Hope I have spread some light in.


After reading the Color Management and Color Picker sections of the Blender manual, I can only assume I'm seeing a bug in Blender.

RGB values in the Color Picker node are in linear Space. RGB values in the image Sample tool are in linear space. They match: good.

Open an sRGB image in GIMP. Use the color picker tool to sample a 4-pixel-radius region that is flat and uniformly shaded. Copy the RGB data into Blender's Color Picker node. Save the render in sRGB space, open in GIMP, and sample the same region. Colors do not match: expected, since the RGB values of Blender's Color Picker node work in linear space while GIMP's work in sRGB space. Switching GIMP to linear light encoding does not seem to affect GIMP's color picker.

Repeat the above procedure for HSV rather than RGB values. GIMP's color picker displays hue in [0-360] while blender uses [0-1], so you'll have to convert. Colors match: expected, since the HSV values of Blender's Color Picker node are gamma corrected (presumably for the current display device transform).

Repeat the above procedure for hex rather than HSV values. Colors do not match: unexpected, since the hex values are gamma corrected just like HSV/HSL values. The difference is slight and I can't help but wonder if this is an aliasing error, i.e. #E2D7C8 vs #E3D8C9.

The actual display device is irrelevant since we are sampling data values rather than visually comparing colors.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .