Separate and Combine HSV distorts the hue value #42888

New Issue

Henrik Ohlin · 2014-12-13T19:59:33+01:00

Henrik Ohlin commented

2014-12-13 19:59:33 +01:00

System Information
Tried on more than one platform

Blender Version
Broken: 2.72.3 83cbcef and latest official 2.72b

Short description of error
Plugging the hue value into a color socket changes the value slightly.
Both from the Separate and the Combine nodes..

Exact steps for others to reproduce the error
Add two objects with emission nodes, the color node of one is connected to a combine HSV node with the values 0.75,1,1
while the other has the color set to the same values..
after a render one will notice a clear color difference. The combine HSV gives a hue value of 0.7892 instead of the 0.75 without..

**System Information** Tried on more than one platform **Blender Version** Broken: 2.72.3 83cbcef and latest official 2.72b **Short description of error** Plugging the hue value into a color socket changes the value slightly. Both from the Separate and the Combine nodes.. **Exact steps for others to reproduce the error** Add two objects with emission nodes, the color node of one is connected to a combine HSV node with the values 0.75,1,1 while the other has the color set to the same values.. after a render one will notice a clear color difference. The combine HSV gives a hue value of 0.7892 instead of the 0.75 without.. ![bug_combine_HSV.png](https://archive.blender.org/developer/F131209/bug_combine_HSV.png)

Henrik Ohlin commented

2014-12-13 19:59:33 +01:00

Changed status to: 'Open'

Henrik Ohlin commented

2014-12-13 19:59:33 +01:00

Added subscriber: @HenrikOhlin

Joel Godin commented

2014-12-14 03:18:58 +01:00

Added subscriber: @FloridaJo

Joel Godin commented

2014-12-14 03:18:58 +01:00

True. It appears by using OSX color picker, that a value of .7 for hue gives a closer color than .75.

blender-admin commented

2014-12-16 16:06:25 +01:00

This issue was referenced by 1549fea999

This issue was referenced by 1549fea9995c348bc14a9105df5e460644e2b33a

Sergey Sharybin commented

2014-12-16 16:46:27 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2014-12-16 16:46:27 +01:00

Sergey Sharybin commented

2014-12-16 16:46:27 +01:00

Closed by commit 1549fea999.

Closed by commit 1549fea999.

blender-admin commented

2014-12-18 08:58:25 +01:00

This issue was referenced by blender/cycles@da96c9dd48

This issue was referenced by blender/cycles@da96c9dd48977c96b4b1ca9b2887843596c7c1f4

Mai Lavelle commented

2014-12-23 12:15:45 +01:00

Added subscriber: @MaiLavelle

Mai Lavelle commented

2014-12-23 12:15:45 +01:00

Sergey, doesn't that just reinforce the incorrect behavior from #41287? The discrepancy between the HSV combine node and the color picker is caused by the incorrect behavior of the color picker, not from the HSV nodes. This likely needs more discussion, can this change at least wait until after the 2.73 release? This isn't a minor change and could cause drastic visual differences of existing shaders.

Sergey Sharybin commented

2014-12-23 16:40:09 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2014-12-23 16:40:09 +01:00

Yes and no. HSV does make no sense if the input color is in linear space and it wouldn't give you the same result as if you'll try to, say, bump saturation in gimp making control over the values totally unclear.

Mai Lavelle commented

2014-12-28 15:46:14 +01:00

Sergey, would you please give this a closer look?

While it is slightly confusing to have, say, Blender and GIMP behave differently, this is a result of the differing workflows of these programs... GIMP and other photo manipulation type software tend to go for a perceptual workflow so an artist can see directly what an image on a webpage or a print for instance will look like. Blender and other rendering software on the other hand have a linear workflow (you know all this...) Having such a workflow allows for physically based results as well as the ability to use real world measurements for input... unfortunately this means that, unlike the perceptual workflow, an artist can't directly see what result they will get. This is the nature of rendering software, and is why Cycles real time preview is so important. An artist can only really see what a color will look like after its been rendered.

It's also important to note that HSV is not a perceptual model, even though it sounds like it should be. (It's only defined in terms of primaries, without regard to how the visual system responds to those primaries, or what color space the primaries are in.)

To be sure of all of this I did some tests, the results of which are below. Each image is a careful recreation of the same scene, using the appropriate method for HSV input in each program... (HSV is 270 degrees from red, 100% saturation and value; background is 5% full intensity)

First thing of interest when I was putting this together is the surprising number of HSV nodes in Blender... theres a lot of them, only a select few are displayed here, but the results are consistent

Second, while the changeset introduced causes the Cycles HSV combine node to produce the same color as GIMP, this is quite a difference from the other nodes in Blender, as well as being divergent from other rendering software. It is also slightly meaningless to match GIMP here, for the reasons noted above.

The background in the image from GIMP is darker than all the others. This is due to the sRGB workflow. The two colors (disk and background) are, however, the same as all the others relative to the colorspace. The 2.73rc1 HSV combine result is inconsistent with everything else.

I'm concerned about the impact this change will have on Blender and the artists that use it. The inconsistency is confusing, previous node tress will behave in unexpected ways, and hardcoding a color transform into a node limits that nodes usefulness. Allowing artists to manually and explicitly choose what colorspace to use allows for greater versatilely and accommodates more workflows. This would also likely be easier to maintain.

Please consider reverting this changeset.

So as not to leave anyone with out a solution should anyone want to use HSV based on different colorspaces, I've included a blend file with two node groups that preform linear/sRGB conversions. (It'd be great to have such nodes as part of Cycles in the future...)

Thank you for all your hard work!

maiself_-_color_transforms.blend

Sergey, would you please give this a closer look? While it is slightly confusing to have, say, Blender and GIMP behave differently, this is a result of the differing workflows of these programs... GIMP and other photo manipulation type software tend to go for a perceptual workflow so an artist can see directly what an image on a webpage or a print for instance will look like. Blender and other rendering software on the other hand have a linear workflow (you know all this...) Having such a workflow allows for physically based results as well as the ability to use real world measurements for input... unfortunately this means that, unlike the perceptual workflow, an artist can't directly see what result they will get. This is the nature of rendering software, and is why Cycles real time preview is so important. An artist can only really see what a color will look like after its been rendered. It's also important to note that HSV is not a perceptual model, even though it sounds like it should be. (It's only defined in terms of primaries, without regard to how the visual system responds to those primaries, or what color space the primaries are in.) To be sure of all of this I did some tests, the results of which are below. Each image is a careful recreation of the same scene, using the appropriate method for HSV input in each program... (HSV is 270 degrees from red, 100% saturation and value; background is 5% full intensity) ![maiself_-_hsv_comparison.png](https://archive.blender.org/developer/F134043/maiself_-_hsv_comparison.png) First thing of interest when I was putting this together is the surprising number of HSV nodes in Blender... theres a lot of them, only a select few are displayed here, but the results are consistent Second, while the changeset introduced causes the Cycles HSV combine node to produce the same color as GIMP, this is quite a difference from the other nodes in Blender, as well as being divergent from other rendering software. It is also slightly meaningless to match GIMP here, for the reasons noted above. The background in the image from GIMP is darker than all the others. This is due to the sRGB workflow. The two colors (disk and background) are, however, the same as all the others relative to the colorspace. The 2.73rc1 HSV combine result is inconsistent with everything else. I'm concerned about the impact this change will have on Blender and the artists that use it. The inconsistency is confusing, previous node tress will behave in unexpected ways, and hardcoding a color transform into a node limits that nodes usefulness. Allowing artists to manually and explicitly choose what colorspace to use allows for greater versatilely and accommodates more workflows. This would also likely be easier to maintain. Please consider reverting this changeset. So as not to leave anyone with out a solution should anyone want to use HSV based on different colorspaces, I've included a blend file with two node groups that preform linear/sRGB conversions. (It'd be great to have such nodes as part of Cycles in the future...) Thank you for all your hard work! [maiself_-_color_transforms.blend](https://archive.blender.org/developer/F134045/maiself_-_color_transforms.blend)

blender-admin commented

2014-12-29 14:14:08 +01:00

This issue was referenced by c5927cd977

This issue was referenced by c5927cd97758baf3df30459d43dc7c6c488fc616

blender-admin commented

2014-12-31 21:23:39 +01:00

This issue was referenced by blender/cycles@78b4d7b962

This issue was referenced by blender/cycles@78b4d7b96289fe62b0db68dfcadd7af36fa67d56

blender-admin commented

2015-01-06 10:33:37 +01:00

This issue was referenced by b0dc79c14b

This issue was referenced by b0dc79c14bb89c030f56c6978e602ae90f8a70eb

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Separate and Combine HSV distorts the hue value #42888