Hue correct node does not match other hsv nodes #107942

New Issue

kevin donovan · 2023-05-15T16:20:41+02:00

kevin donovan commented

2023-05-15 16:20:41 +02:00

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.3.230420

Blender Version
Broken: version: 3.6.0 Alpha, branch: main, commit date: 2023-05-14 19:50, hash: 1ad4f67d7802
Worked: (newest version of Blender that worked as expected)

Short description of error
unmodified hue correct node giving diff results than hsv node. The color should not be modified by this node if no settings have been changed and both node should have the same output util modified.

will reference this post #107583

Exact steps for others to reproduce the error
plugin the viewer to the hue correct and hsv node and the colors will be diff. there is no modification on these nodes

[Based on the default startup or an attached .blend file (as simple as possible)]

**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.3.230420 **Blender Version** Broken: version: 3.6.0 Alpha, branch: main, commit date: 2023-05-14 19:50, hash: `1ad4f67d7802` Worked: (newest version of Blender that worked as expected) **Short description of error** unmodified hue correct node giving diff results than hsv node. The color should not be modified by this node if no settings have been changed and both node should have the same output util modified. will reference this post https://projects.blender.org/blender/blender/issues/107583 **Exact steps for others to reproduce the error** plugin the viewer to the hue correct and hsv node and the colors will be diff. there is no modification on these nodes [Based on the default startup or an attached .blend file (as simple as possible)]

simple hue.blend

865 KiB

kevin donovan added the

labels 2023-05-15 16:20:42 +02:00

Omar Emara commented

2023-05-15 17:16:18 +02:00

This is because the Hue Correct node sanitizes the new saturation by clamping it into the [0, 1] range.
The following #107943 report is probably related due to the sanitization done after HSV to RGB conversion.

I am not sure if this behavior should be changed, especially since it will break backward compatibility, maybe @Jeroen-Bakker have an opinion.

This is because the Hue Correct node sanitizes the new saturation by clamping it into the [0, 1] range. The following #107943 report is probably related due to the sanitization done after HSV to RGB conversion. I am not sure if this behavior should be changed, especially since it will break backward compatibility, maybe @Jeroen-Bakker have an opinion.

kevin donovan commented

2023-05-15 17:31:21 +02:00

as with my other bug report, this clamping will be more of an issue with aces and agx; maybe a clamping button like the mix node or delaying for blender 4.0.

Iliya Katushenock commented

2023-05-15 17:33:12 +02:00

If it were geometry nodes, we would simply start creating the color clamping node after the modified node in all old files.

Omar Emara commented

2023-05-15 17:36:47 +02:00

@mod_moder Versioning would be harder than that, because the clamping happens during the hue correction operation, not at the end, that is, it is not simply clamping the output.

kevin donovan commented

2023-05-15 17:46:13 +02:00

This is the type of graph I have to build to work around the the saturation and color shifting issue for the hue correct.

hueco.jpg

64 KiB

Philipp Oeser commented

2023-06-22 14:46:30 +02:00

So, do we consider this confirmed? (not sure either).

Maybe @brecht can make a decision? Same for #107943

So, do we consider this confirmed? (not sure either). Maybe @brecht can make a decision? Same for #107943

Brecht Van Lommel commented

2023-06-22 15:14:38 +02:00

Compositing nodes in general can not be expected to work with out of gamut colors, and this type of clipping should be expected. The correct workflow would be to either:

Use an OpenColorIO configuration that has a scene linear colorspace with wide gamut, like ACEScg.
With the defautl OpenColorIO configuration: in compositing nodes convert everything into e.g. ACEScg, do compositing in that space, then convert back to sRGB.

Nodes can not distinguish between a value that is out of gamut, and one that is in gamut but out of the [0, 1] range. In this .blend file, I would consider the fact that the Color Correction node produces out of gamut colors to be the problem.

We plan to improve Blender support for wide gamut color space, and bundle such an OpenColorIO configuration with Blender. But I don't think removing such clamping in nodes is the solution.

Compositing nodes in general can not be expected to work with out of gamut colors, and this type of clipping should be expected. The correct workflow would be to either: * Use an OpenColorIO configuration that has a scene linear colorspace with wide gamut, like ACEScg. * With the defautl OpenColorIO configuration: in compositing nodes convert everything into e.g. ACEScg, do compositing in that space, then convert back to sRGB. Nodes can not distinguish between a value that is out of gamut, and one that is in gamut but out of the [0, 1] range. In this .blend file, I would consider the fact that the Color Correction node produces out of gamut colors to be the problem. We plan to improve Blender support for wide gamut color space, and bundle such an OpenColorIO configuration with Blender. But I don't think removing such clamping in nodes is the solution.

kevin donovan commented

2023-06-22 21:06:58 +02:00

the same issue happens when using an aces config and agx config with rec2020 working space. should not get different results from adding hsv, hue correct, or separate /combine hsv when none of those nodes have been modified. If those nodes clip gamut they should be consistent in doing so

kevin donovan commented

2023-06-23 15:56:09 +02:00

Added a video to show the problem. In the video by adding an hsv node before the huecorrect node I get the same color output as the hsv node, but before that the huecorrect is giving bad behavior. These are both neutral nodes.

hsvc.mp4

23 MiB

Brecht Van Lommel commented

2023-06-23 16:06:07 +02:00

If you make colors outside the rec2020 gamut then there will indeed be the same problems as well. The compositor should make it difficult to generate such out of gamut colors in the first place, because they will cause problems. If not with the HSV node then certainly with other nodes.

If the HSV node can be implemented in a way that it doesn't clamp out of gamut colors without breaking other use cases, that's fine with me. It's possible to preserve backwards compatibility with a boolean option on the node for the legacy behavior, which can be tucked away in the node options sidebar.

But if that is fixed, and then the next bug report comes for another node that can't be fixed, it will still have to be rejected.

If you make colors outside the rec2020 gamut then there will indeed be the same problems as well. The compositor should make it difficult to generate such out of gamut colors in the first place, because they will cause problems. If not with the HSV node then certainly with other nodes. If the HSV node can be implemented in a way that it doesn't clamp out of gamut colors without breaking other use cases, that's fine with me. It's possible to preserve backwards compatibility with a boolean option on the node for the legacy behavior, which can be tucked away in the node options sidebar. But if that is fixed, and then the next bug report comes for another node that can't be fixed, it will still have to be rejected.

kevin donovan commented

2023-06-23 16:20:01 +02:00

One more video using agx this time. Similar situation happens with aces config.

edit: here I think the agx config is doing its job and dealing with the out of gamut colors and once I add the hsv it clips it giving bad results.

One more video using agx this time. Similar situation happens with aces config. edit: here I think the agx config is doing its job and dealing with the out of gamut colors and once I add the hsv it clips it giving bad results.

hsvagx.mp4

25 MiB

kevin donovan commented

2023-06-23 17:34:38 +02:00

If you make colors outside the rec2020 gamut then there will indeed be the same problems as well. The compositor should make it difficult to generate such out of gamut colors in the first place, because they will cause problems. If not with the HSV node then certainly with other nodes.

If the HSV node can be implemented in a way that it doesn't clamp out of gamut colors without breaking other use cases, that's fine with me. It's possible to preserve backwards compatibility with a boolean option on the node for the legacy behavior, which can be tucked away in the node options sidebar.

But if that is fixed, and then the next bug report comes for another node that can't be fixed, it will still have to be rejected.

I think the option in the side bar would be a great option. I have not experienced this issue so far with my heavy lifters YUV and RGB sepa/comb. I have created group nodes to work around this issue for hsv, hsv separate and combine (issue on combine end), and hue correct on my end. (HSL sep/comb also has the issue)

This probably requires more testing but those nodes create an addition layer of clipping that is not visible without them.

the attached picture show the main the workhorse of my hsv group nodes.

I guess this is something that can be tackled if it becomes an issue for more people. I only found out about it because the viewport compositor gives me enough performance to use some of my Davinci resolve grading techniques

Thanks for the response.

> If you make colors outside the rec2020 gamut then there will indeed be the same problems as well. The compositor should make it difficult to generate such out of gamut colors in the first place, because they will cause problems. If not with the HSV node then certainly with other nodes. > > If the HSV node can be implemented in a way that it doesn't clamp out of gamut colors without breaking other use cases, that's fine with me. It's possible to preserve backwards compatibility with a boolean option on the node for the legacy behavior, which can be tucked away in the node options sidebar. > > But if that is fixed, and then the next bug report comes for another node that can't be fixed, it will still have to be rejected. I think the option in the side bar would be a great option. I have not experienced this issue so far with my heavy lifters YUV and RGB sepa/comb. I have created group nodes to work around this issue for hsv, hsv separate and combine (issue on combine end), and hue correct on my end. (HSL sep/comb also has the issue) This probably requires more testing but those nodes create an addition layer of clipping that is not visible without them. the attached picture show the main the workhorse of my hsv group nodes. I guess this is something that can be tackled if it becomes an issue for more people. I only found out about it because the viewport compositor gives me enough performance to use some of my Davinci resolve grading techniques Thanks for the response.

904ec.jpeg

56 KiB