Vertex color data seems to be distorted when used in material nodes, does anybody has similar issues? Looks like Blender modifies them for Cycles somehow. I am using VC not for coloring but for hinting shader about material properties at specific faces and need exact RGB values from Attribute node.

This happens with "shade" colors only, not with "pure" colors

Exact case:

  • When i am using pure colors in vertex color editor ( full red/green/blue/white) and read them via Attribute node in material - everything is fine, i get the same RGB values. So in case of (1, 1, 1), (0, 0, 0) color data is not lost.

  • But when i assign colors like (0.5, 0.5, 0.5) - "Attribute node" returns halved values, (0.21, 0.21, 0.21) for pure gray, for example.

In other words colors in Vertex color editor and "Attribute node" are not the same, there is a nonlinear mismatch. How this can be fixed? How real RGB, unaltered values of vertex color data can be read in material node?

For now, i manually reajdust values with pow(channel, 0.45188), which maps 0.5 in vertex color editor to 0.5 in Attribute node, but... that`s weird. Any help really appreciated.

  • $\begingroup$ I wouldn't say the color data is lost, looks like you face transform curves conversion when looking at the vertex colors assigned to material and rendered. How are you actually previewing colors, what material do you use? What view transform in the Color management settings are you using? $\endgroup$
    – Mr Zak
    Aug 9 '17 at 11:04
  • $\begingroup$ I preview vertex colors like this - Attribute node->diffuse shader->Diffuse color channel in Render Layer. I tried different color management settings in scene tab and must say while i visually see differences from switching color modes, the effect of "color distortion" still the same. Attribute node outputs "shifted" colors It really looks like "sRGB" implied for vc data, which is weird... Imho color space manipulations should be postponed to the latest steps $\endgroup$
    – IPv6
    Aug 9 '17 at 11:07

Vertex Colors are held in 8-bit sRGB format rather than 'raw' (linear) RGB. Therefore, what actually appears to be 0.5 in sRGB space actually refers to a different 'raw' value - hence the need to convert. See How to convert image pixel values from 8bit to 32bit properly? - answered.. but why byte image buffer is stored with non-linear color values? for some related discussion and links.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.