Inconsistent behavior of bpy.types.Image.pixels depending on image precision #117830

New Issue

Eugene-Kuznetsov · 2024-02-05T11:04:59+01:00

Eugene-Kuznetsov commented

2024-02-05 11:04:59 +01:00

Attached file contains two textures 'tex_test1' and 'tex_test2'. Both are set to 'sRGB'.

Trying to pull colors out of these textures with a script produces:

>>> bpy.data.images["tex_test1.png"].pixels[0:3]
(0.2635093033313751, 0.18732529878616333, 0.1290532946586609)

>>> bpy.data.images["tex_test2.png"].pixels[0:3]
(0.501960813999176, 0.3607843220233917, 0.2823529541492462)

The same colors are shown by the color picker tool in the image editor.

However, it's obvious that tex_test1 is actually lighter than tex_test2. With a "separate color" + "greater than" shader node combo, you can establish that these texture nodes output R=0.26 and R=0.22 respectively.

The discrepancy occurs because tex_test1 is float (RGBA16F) and tex_test2 is byte (RGBA8). As far as I can tell, what happens is this:

If the texture is byte, image editor and 'pixels' both return whatever is actually stored in the texture file, before colorspace conversion. The shader receives data after conversion from whatever is specified in the texture node (in this case, sRGB) to scene linear.
If the texture is float, contents of the file is converted from sRGB into scene linear right away, and then everyone (the image editor, 'pixels', and the shader) get the same data.

This becomes a problem because it inteferes with the ability to use 'pixels' in scripts (e.g. for color matching/blending). If all my textures are byte and I need to determine the color that corresponds to a particular pixel, I can write
mathutils.Color(bpy.data.images["tex_test1.png"].pixels[0:3]).from_srgb_to_scene_linear()

But this stops working for float textures and it's not at all obvious why (or even what makes those textures different, since nothing in the documentation gives any hint that float textures behave differently).

Attached file contains two textures 'tex_test1' and 'tex_test2'. Both are set to 'sRGB'. Trying to pull colors out of these textures with a script produces: ``` >>> bpy.data.images["tex_test1.png"].pixels[0:3] (0.2635093033313751, 0.18732529878616333, 0.1290532946586609) >>> bpy.data.images["tex_test2.png"].pixels[0:3] (0.501960813999176, 0.3607843220233917, 0.2823529541492462) ``` The same colors are shown by the color picker tool in the image editor. However, it's obvious that tex_test1 is actually lighter than tex_test2. With a "separate color" + "greater than" shader node combo, you can establish that these texture nodes output R=0.26 and R=0.22 respectively. The discrepancy occurs because tex_test1 is float (RGBA16F) and tex_test2 is byte (RGBA8). As far as I can tell, what happens is this: * If the texture is byte, image editor and 'pixels' both return whatever is actually stored in the texture file, before colorspace conversion. The shader receives data after conversion from whatever is specified in the texture node (in this case, sRGB) to scene linear. * If the texture is float, contents of the file is converted from sRGB into scene linear right away, and then everyone (the image editor, 'pixels', and the shader) get the same data. This becomes a problem because it inteferes with the ability to use 'pixels' in scripts (e.g. for color matching/blending). If all my textures are byte and I need to determine the color that corresponds to a particular pixel, I can write ```mathutils.Color(bpy.data.images["tex_test1.png"].pixels[0:3]).from_srgb_to_scene_linear()``` But this stops working for float textures and it's not at all obvious why (or even what makes those textures different, since nothing in the documentation gives any hint that float textures behave differently).

srgb_bug.blend

1.0 MiB

Eugene-Kuznetsov added the

labels 2024-02-05 11:05:00 +01:00

Iliya Katushenock added the