Vertex color gradient is not linear

Question

I am painting the default cube through vertex coloring. I paint the bottom four vertices as (0.25, 0.25, 0.25) and the top four vertices as (0.75, 0.75, 0.75).

When I inspect the result in VERTEX PAINT mode (using hotkey S to get the color), the bottom of the cube is indeed (0.25, 0.25, 0.25) and the top is (0.75, 0.75, 0.75).

However, the middle point of the cube is not (0.5, 0.5, 0.5), it is ~(0.56, 0.56, 0.56). Somehow the gradient is not linear. I don't think its an issue with sRGB vs Linear, because otherwise the bottom and top values would also be wrong, but it's just the values in between. So what is the issue here? I really need a linear gradient.

EDIT. related issue: https://developer.blender.org/T71835 This says it has something to do with how the vertex colors are stored (8-bit sRGB apparently).

Code to reproduce this issue:

"""Script that checks vertex color interpolation error on the default cube.

run command: `blender --python gradient_error.py` (opens blender)
"""

import bpy

# Set up scene
sce = bpy.context.scene

# Select cube
scene = bpy.context.scene
for ob in scene.objects:
    ob.select_set(False)
    if ob.name == 'Cube':
        ob.select_set(True)
obj = bpy.context.view_layer.objects.active

# Get cube data
mesh = obj.data
vert_list = mesh.vertices

# Get the color map
if mesh.vertex_colors:
    color_map = mesh.vertex_colors.active
else:
    color_map = mesh.vertex_colors.new()

# apply colors
i = 0
for poly in mesh.polygons:
    for idx in poly.loop_indices: #vertices
        loop = mesh.loops[idx]
        v = vert_list[loop.vertex_index]
    
        z_coord = v.co.z

        # Paint bottom 4 vertices 0.25, top 4 vertices 0.75.
        if z_coord < 0:
            color_map.data[i].color = (0.25, 0.25, 0.25, 0)
        else:
            color_map.data[i].color = (0.75, 0.75, 0.75, 0)
        i += 1

# Give it this new material
mat = bpy.data.materials.new('vcolor_material')

# Deactivate shadows
mat.shadow_method = 'NONE'

# Apply material
mesh.materials.append(mat)

# Set Flat lighting and show Vertex Coloring
my_areas = bpy.context.workspace.screens[0].areas
my_shading = 'WIREFRAME'
for area in my_areas:
    for space in area.spaces:
        if space.type == 'VIEW_3D':
            space.shading.light = "FLAT"
            space.shading.color_type = "VERTEX"

bpy.ops.object.mode_set(mode='VERTEX_PAINT')

print("\nRan succesfully.\n")

Answer 1

The gradient is linear but not in the colourspace you are expecting - as evidenced by the following :

Here the Attribute node is making the Vertex Color (Col) available to the shader. This is split into separate RGB components and compared with the Generated 'X' coordinate (which runs from 0.0 at the left to 1.0 at the right of the cube).

The gradient is linear but the end points are not as you expect (ie, the blue vertical grid-line is at X=0.5 and the gradient line runs from about 0.05 at the bottom through to around 0.525 at the top). This is due to sRGB colourspace conversion.

Your values of 0.25 and 0.75 relate to those 'absolute' values of approx 0.05 and 0.525 when converted from sRGB into the 'true' brightness - the sRGB colourspace is intended to make the most of an 0-bit integer representation of the brightness to make it as visually diverse as possible - so values at the start/end of the range and compressed/expanded to suit what would be noticable when displayed on a screen to the human eye.

See https://en.wikipedia.org/wiki/SRGB and note the red line on the following graph :

Using the axis values at the bottom and right of the graph you can see that 0.75 on the x-axis converts to around 0.5 in 'intensity' - your Python code is applying the sRGB value of 0.75 and producing an 'intensity' of approximately 0.525 for the upper limit. Similarly, the lower 0.25 is being converted at the bottom end of the graph to a much smaller 'intensity' value. That 'intensity' is what is being linearly interpolated to produce your resultant vertex colour gradient - not your original sRGB values.

Answer 2

If you only need grayscale data to be used in shader nodes, here's an ugly workaround - use alpha channel instead. In your script I set the alpha values to 0.25 and 0.75 respectively and using a greater than 0.5 node visually confirmed that the alpha channel is interpolated lineary.

Perhaps other attributes could be used as well, like UV.

I'm afraid a cononical explanation is beyond me, but here's a thread that discusses the issue. The workaround is based on the linked answer

https://github.com/KhronosGroup/glTF-Blender-IO/issues/542#issuecomment-569361267