HSV in viewport compositor give different result than on CPU. #107583
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
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#107583
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: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: AMD Radeon RX 5700 ATI Technologies Inc. 4.5.0 Core Profile Context 23.4.2.230412
Blender Version
Broken: version: 3.6.0 Alpha, branch: main, commit date: 2023-04-30 05:23, hash:
358ce4f52b58Worked: (newest version of Blender that worked as expected)
Short description of error
hsv saturation with the view port compositor seems to quickly hit a wall with saturated yellow and oranges and the colors will not skew towards the primary (red). In the Images below using a difference node to compare a saturation boost of 1.055 vs 2 the viewport one seems to tap out, even the oranges in the flower not saturate.
I have tested the sat with this image in davinci , photoshop, affinity and I can get similliar behavior. while the hsl in affinity behaves the same, the hsv behaves different but I can get skewing and darkening of the oranges by playing with the exposure before the hsv.
Playing the exposure in blender for this issue does not really help
In the uploaded images you can see the difference node results (sat 1.055 vs 2) and saturated image results (sat 2). Included screen shot of the same thing happening on a yellow cup
The viewport is on the left and the cpu compositor is on the right
Even if I boost the saturation to 6 , I can not get those oranges on the flower to darken and start skewing with the viewport compositor
If I use the YUV conversion nodes to boost color I can get the same look from the viewport compositor, but once I run it through the hsv
Exact steps for others to reproduce the error
use the blend file in the test.zip attachment and you can veiw the difference or saturation nodes. You can also plugin the orange rgb input i have there and see the skewing.
[Based on the default startup or an attached .blend file (as simple as possible)]
the hsv node before the hue correct seem to keep my colors for the cpu
while the expected result would be no color shifting, at least on the cpu side I can currently work around it with the hsv node beforehand.
edit:
the hsv node before the hue correct does not fully fix the color shifts for the cpu compositor , there is still a shift but but way more on the viewport compositor. My info on the hue correction node was just an extra piece of info.
The easiest way to see this issue is add a color correction node , boost the saturation all the way up and add an hsv node. the gpu and cpu compositor will be diff
hsv issue with viewport compositorto HSV in viewport compositor give different result than on CPU.I guess #107584 is the same problem?
added a smaller blend file to make it easy for anyone one else who looks at this.
left side of the image viewport comp and right side cpu comp
Did some more test on my end to find out why I was still getting shifts. Everything seem fine visually with blenders default color config, but when using agx from earychow or troy I can see the shifts visually. Tried a difference node and the shifts are still there just more visual with agx. I haven't tried an aces config yet on this.
Since agx from eary is trying to be included in the default config this will still be an issue.
the picture shows the difference with running the picture through the neutral hsv node compared with the node before it. The difference shows up with agx
edit:
tested an aces config and the shifts show up there as well
edit 2:
testing a hsv separate with before and after the hsv node, the values match up but the hue and saturation differ
I don't see the difference visually, how should i check this? should I probe screenspace pixel values? My display is sRGB...
Edit: Oh I see, I need to connect viewer to HSV node. in that case I can reproduce.
@omaremaradev the issue with the clamped saturation, can that fix be applied to the Hue Correction node as well? It would be needed for both viewport and cpu compositor. It would allow me to reduce certain node setups to work around the color shift issues
f9b5b0efd2@kevindonovan To clarify, is this issue still about an inconsistency with the GPU vs CPU compositors? Or is it a bad behavior in both implementations?
2.)all those node nodes show color shifts when using aces or agx configs
for number 1 , bring the neutral hue correction node inline with hsv node will at least make them all consistent.
for number 2, it is about bad behavior ,this can be tackled with a different bug report
This is probably just because the Hue Correction node clamps the saturation. It is unclear to me if this behavior should be changed as I am not familiar with the original implementation, and changing it would mean breaking backward compatibility, so we need to be careful. So this probably shouldn't be handled as a bug.
Can you create a new report and propose that new behavior there?
will do
one last thing. Other compositors allow out of gammut colors as well in their working space. They just give you options for the mapping. Input and output would have mapping options with a good default such as none (none, clip , sat, etc) and maybe a gammut node or gammut mapping settings on the color convertion node for when you need to juggle in the comp.
Because even in this case if Im going out to srgb then my gammut is clipped to that on output, I see no need for the hsv nodes to get involved with that prematurely.