Byte vertex colors are sometimes interpolated in sRGB, sometimes linear #92444
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
11 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#92444
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Linux
Graphics card: Intel Integrated
Blender Version
Broken: 2.93.0, 3.0.0 Alpha at
8c21667Worked:
Short description of error
A Data Type: Byte Color color attribute is interpolated in sRGB space when subdividing or using the knife, but in linear space when interpolating across a tri in the viewport. I expect it to be consistent.
This is different than Data Type: Color (FLOAT_COLOR) attributes, which are always interpolated in linear, and vertex colors in pre-2.8 versions, which are always interpolated sRGB.
Exact steps for others to reproduce the error
Add a plane, paint one corner white, the others, black. Add a Subdivision/Simple modifier and turn up the levels. Look at the result.
I expect it to approach the ideal bilinear result in linear space, but it's clearly approaching the ideal bilinear result in sRGB space. Same thing for manually subdividing with the knife.
Addition after 3.2
IMO since there is a new way to get linear vertex colors, it would be nice if FLOAT_COLOR attributes always interpolated in linear space and BYTE_COLOR attributes always interpolated in sRGB. 2.8 removed the ability to get sRGB interpolation and it would be nice to have both options (pre-2.8 files would also be viewable with the intended interpolation).
Added subscriber: @scurest
#98905 was marked as duplicate of this issue
Subdivsion/Simple: vertex colors are interpolated in sRGB spaceto Subdivision/Simple: vertex colors are interpolated in sRGB spaceAdded subscriber: @iss
Changed status from 'Needs Triage' to: 'Needs User Info'
I can confirm this, even though it could be considered feature request, on the other hand this may be quite easy to change. Can you perhaps give more practical example where this causes problems? Since this is issue with modifier, this could also break existing files that rely on this type of interpolation. My point is that benefits of fix should probably outweight potential issues.
I don't have a practical problem, I just expect it to be consistent.
Actually it's even simpler for a tri: I expect the appearence not to change at all under simple subdivision, but it does.
I checked 2.79 and it does have this property. So it seems since then, the viewport has changed to interpolate in linear space, but the Subdivision modifier was not similarly updated.
Continuing to check, things get even worse. Edit mode operations like knife cut also interpolate in sRGB space. That means if you ever edit the geometry after vertex painting, you wind up with a random mishmash of different interpolation methods.
I think 2.79 was actually much better. It consistently interpolated in sRGB.
Changed status from 'Needs User Info' to: 'Confirmed'
Ok will confirm then and let module owners decide on this matter.
Added subscriber: @JulienKaspar
Changed status from 'Confirmed' to: 'Needs User Info'
I cannot reproduce this issue anymore. It seems to be fixed with the recent commits for the color attribute changes?
It now interpolates the colors correctly in linear space, even when adding cuts in edit mode.
@JulienKaspar Just tried with 3.3 alpha. Are you testing with a new FLOAT_COLOR ("Data Type: Color") attribute? That does work, which isn't surprising since I assume subdiv/knife is just interpolating whatever is stored. But the old BYTE_COLOR ("Data Type: Byte Color") attributes are still the same.
IMO since there is a new way to get linear vertex colors, it would be nice if FLOAT_COLOR attributes always interpolated in linear space (they do), and BYTE_COLOR attributes always interpolated in sRGB (they do for subdiv/knife, but not for viewing). 2.8 removed the ability to get sRGB interpolation and it would be nice to have both options (pre-2.8 files would also be viewable with the intended interpolation).
Subdivision/Simple: vertex colors are interpolated in sRGB spaceto Byte vertex colors are sometimes interpolated in sRGB, sometimes linearChanged status from 'Needs User Info' to: 'Confirmed'
Ah yes it only happens with byte color. Thanks for the quick response.
Added subscriber: @Frand
We have a game project that extensively uses vertex colors and now color attributes. Modifiers should not change the behavior of color interpolation.
As per 3.2 release notes: ”Different from the old vertex colors, color attribute values are in scene linear color space instead of sRGB color space.”
We use gradients quite a bit, and sRGB fringes are something we'd prefer to avoid. For example the red-on-green here. Turning on subdivision affects the colors significantly.
Added subscriber: @EAW
@Frand's file from the merged commit.
blending_bug.blend
Added subscriber: @Jeroen-Bakker
Not sure. I expect to use the color space during painting. But rendering to be linear. Might be confusing to some users. But making them more consistent might not solve any problems. Perhaps introduce several along the way. IMO we should mention what we decide in the manual.
This is the reasons being color space aware is important. Modern render engines are linear and cannot handle other types.
I would rather suggest to have a color space selector for color attributes. This is being discussed.
IMO this isn’t a bug, but a symptom.
I’d focus on the fact that modifiers should be transparent to whatever the method is. Right now, the subdivision modifier does not respect this, causing unwanted artifacts.
Yes totally. I would say that all tools would follow the decision we make, including modifiers.
Added subscriber: @RedMser
Added subscriber: @standard_owl
I use vertex colors on all my meshes that I export to Unreal. In most cases, I just use an ancient script to set vertex colors which still works. It creates Byte Color on face corners.
However, applying colors via Geometry Nodes and applying that modifier (manually or during export) changes the object's color attribute to float color. Looks fine in Blender but cannot be exported. To make it work, the GeoNodes modifier needs to be applied and the color attribute needs to be set to Byte Color manually afterwards. Not sure if this actually belongs here – would be great if such issues were sorted out though! Using 3.2.0.
Added subscriber: @dmitryberezovsky.art
blender 4.0.2
id assume this is related
if not i can make a separate issue
this is a bit complicated but...
this isnt dependent on color space or renderer (even non blender made renderers have this issue)
the vertex color interpolation between 0 and 1 is fine
but any step in-between is where things get screwy
its like the interpolation is being applied between each color mix instead of just the full range?
so 0 to 1 is again fine
but 0 to 0.5 or 0.5 to 1 isnt
another issue is this makes it impossible to correct the srgb curve to linear if needed
edit: fixed image lol
edit2: OH a workaround i did for this was to make a script that took the original non color corrected colors (Vertex Colors in the data api. NOT the attributes, those are always "corrected" to the wrong values) and split them into individual UV maps
definitely not ideal