Color ramp values limited to 4.875 maximum #40131

New Issue

Campbell Barton · 2014-05-10T22:43:33+02:00

suboptimal commented

2014-05-10 22:43:33 +02:00

(Migrated from localhost:3001)

System Information
Windows 64bit, GTX 760

Blender Version
Broken: 2.70 7891899
Worked: 2.70a

It is not possible to set a color value for color ramp points over 4.875 (RGB 40.460938), any higher value will be cut off. As far as I can tell, this problem probably appeared with the recent changes to color ramp nodes.

In any blendfile, add a color ramp node in any node editor mode (composite, materials, texture), edit the point color and change the value in hsv color picker mode to something greater than 4.875.

**System Information** Windows 64bit, GTX 760 **Blender Version** Broken: 2.70 7891899 Worked: 2.70a It is not possible to set a color value for color ramp points over 4.875 (RGB 40.460938), any higher value will be cut off. As far as I can tell, this problem probably appeared with the recent changes to color ramp nodes. In any blendfile, add a color ramp node in any node editor mode (composite, materials, texture), edit the point color and change the value in hsv color picker mode to something greater than 4.875.

suboptimal commented

2014-05-10 22:43:33 +02:00

(Migrated from localhost:3001)

Changed status to: 'Open'

suboptimal commented

2014-05-10 22:43:33 +02:00

(Migrated from localhost:3001)

Added subscriber: @suboptimal

Campbell Barton commented

2014-05-12 05:31:41 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-05-12 05:31:41 +02:00

It works fine for me, both in RGB and HSV views setting values up to 10000 for eg.

Can you give exact steps to redo the bug?

It works fine for me, both in RGB and HSV views setting values up to 10000 for eg. Can you give **exact** steps to redo the bug?

Antonis Ryakiotakis commented

2014-05-14 00:59:22 +02:00

Added subscriber: @Psy-Fi

Antonis Ryakiotakis commented

2014-05-14 00:59:22 +02:00

I have managed to reproduce here actually, I'll see if there's an option influencing this

Antonis Ryakiotakis commented

2014-05-14 01:03:11 +02:00

My steps:

On issue.blend

Try to edit the selected color of the color ramp by bringing up the color wheel.
Select HSV method and on the V slider ctrl click and enter, 200 for instance.
You should be able to see it.

My steps: On [issue.blend](https://archive.blender.org/developer/F88885/issue.blend) Try to edit the selected color of the color ramp by bringing up the color wheel. Select HSV method and on the V slider ctrl click and enter, 200 for instance. You should be able to see it.

Antonis Ryakiotakis self-assigned this 2014-05-14 01:21:07 +02:00

Antonis Ryakiotakis commented

2014-05-14 01:21:07 +02:00

It may be due to the changes for the color wheels too, though I can reproduce on Cube widgets too. Let me take a look first

Campbell Barton commented

2014-05-14 23:59:31 +02:00

@Psy-Fi from your test file.

Enter 200 in V
It stays set to 200
Select RGB display and all are set to 293057.5625

This is odd, but what would you expect?

@Psy-Fi from your test file. - Enter 200 in `V` - It stays set to 200 - Select RGB display and all are set to `293057.5625` This is odd, but what would you expect?

Antonis Ryakiotakis commented

2014-05-15 19:54:04 +02:00

The issue is caused by going back and forth between linear and display spaces in the color picker code, check do_color_wheel_rna_cb. It's really weird that this is not happening in your system...maybe a different OCIO version? In any case, I'm not sure we can do a lot in this case. There's some logic that could be simplified there, thus avoiding that conversion, but upon re-evoking the color picker, there will be a new conversion, changing the hsv values again.

Solution would be to use linear for hsv for linear space colors but that is too big a change right now before the release. That was how it worked initially but for this release I was against it because HCL is naturally bound at 1.0 value, which means display space always and also I pushed more for correctness of the color wheel. That means, user should get the color (s)he sees while he chooses and that is only possible if HSV values are in display space. Unless we support a per pixel color transform (which I consider a TODO), we won't be able to select the correct color due to the way color interpolation works. I'd say to not change anything right now but I'll try to fix things for next release here with proper interpolation/color space support. Then we can also explicitly restrict the HCL representation to 0.0-1.0 lightness and unrestrict the HSV one.

The issue is caused by going back and forth between linear and display spaces in the color picker code, check do_color_wheel_rna_cb. It's really weird that this is not happening in your system...maybe a different OCIO version? In any case, I'm not sure we can do a lot in this case. There's some logic that could be simplified there, thus avoiding that conversion, but upon re-evoking the color picker, there will be a new conversion, changing the hsv values again. Solution would be to use linear for hsv for linear space colors but that is too big a change right now before the release. That was how it worked initially but for this release I was against it because HCL is naturally bound at 1.0 value, which means display space always and also I pushed more for correctness of the color wheel. That means, user should get the color (s)he sees while he chooses and that is only possible if HSV values are in display space. Unless we support a per pixel color transform (which I consider a TODO), we won't be able to select the correct color due to the way color interpolation works. I'd say to not change anything right now but I'll try to fix things for next release here with proper interpolation/color space support. Then we can also explicitly restrict the HCL representation to 0.0-1.0 lightness and unrestrict the HSV one.

Fazekas Laszlo commented

2014-05-18 18:52:16 +02:00

Added subscriber: @totoro-4

Fazekas Laszlo commented

2014-05-18 18:52:16 +02:00

@Psy-Fi How the HSV values are connected to the RGB values? If the OCIO works differently in different versions, maybe it is better to convert between RGB and HSV using normalized values and multiply them back to the correct level.

Antonis Ryakiotakis commented

2014-05-19 14:15:04 +02:00

I'm not sure if different versions are the cause of the difference. That's just conjecture on my part. But here I can see that the values change as soon code enters the color conversion.

Generally, rgb should be converted to HSV on its native space and converted to display later. However that requires a per pixel shader to do correctly. I will try to fit this in for 2.72 but for a bugfix that;s not possible. Also there should be a clear separation of what color pickers should actually do if their function is to set an approximate color with an arbitrary HSV value, it's a different use case than selecting an exact color to what you see on the wheel.

I'm not sure if different versions are the cause of the difference. That's just conjecture on my part. But here I can see that the values change as soon code enters the color conversion. Generally, rgb should be converted to HSV on its native space and converted to display later. However that requires a per pixel shader to do correctly. I will try to fit this in for 2.72 but for a bugfix that;s not possible. Also there should be a clear separation of what color pickers should actually *do* if their function is to set an approximate color with an arbitrary HSV value, it's a different use case than selecting an exact color to what you see on the wheel.

Fazekas Laszlo commented

2014-05-19 16:09:10 +02:00

My test was with Blender 2.70a (f93bc76): click on the material tab at the properties, click on the diffuse color (of the default cube), and change R to 10000 (G= 0.8, B=0.8). Then if I switch to HSV, I see H=0, S=1, V=10000. If I change V to -for example- 9999 and go back to RGB mode, I get R= 9999, G= 0.8, B=0.8. I think this is the good behaviour.

This is how Blender 2.70a (f93bc76) works under Ubuntu 12.10. It seems I don't have any installed libOpenColorIO.so here.

On another machine with Ubuntu 14.04 the exactly same Blender is also working good. Here the OCIO is libOpenColorIO.so.1.0.8

BUT the Blender if I compiled from source (193e77c) on this same Ubuntu 14.04 machine:

When I change R to 10000 then I get H=0, S=0.814, V=4.875. I cannot set V to higher value. If I go back to RGB, I see R=40.44, G=0.8, B=0.8

The colors of the wheel and the cursor positions are seems good in both versions (not going to extreme colors if you set something above 1.0). Only the numeric part has this bug.

My test was with Blender 2.70a (f93bc76): click on the material tab at the properties, click on the diffuse color (of the default cube), and change R to 10000 (G= 0.8, B=0.8). Then if I switch to HSV, I see H=0, S=1, V=10000. If I change V to -for example- 9999 and go back to RGB mode, I get R= 9999, G= 0.8, B=0.8. I think this is the good behaviour. This is how Blender 2.70a (f93bc76) works under Ubuntu 12.10. It seems I don't have any installed libOpenColorIO.so here. On another machine with Ubuntu 14.04 the exactly same Blender is also working good. Here the OCIO is libOpenColorIO.so.1.0.8 BUT the Blender if I compiled from source (193e77c) on this same Ubuntu 14.04 machine: When I change R to 10000 then I get H=0, S=0.814, V=4.875. I cannot set V to higher value. If I go back to RGB, I see R=40.44, G=0.8, B=0.8 The colors of the wheel and the cursor positions are seems good in both versions (not going to extreme colors if you set something above 1.0). Only the numeric part has this bug.

Fazekas Laszlo commented

2014-05-21 06:36:15 +02:00

So the problem I think is that linear color space has no limitations (ie. V is the max(R,G,B) always). But when you changed this to sRGB this connection is not linear (at V=4.875 you get 40.44 for R, what happens at 10000? I'ts probably infinite...). sRGB is correct only between 0 and 1. What if you use linear space or scaled normalized vectors above V=1?

Campbell Barton commented

2014-05-21 08:20:03 +02:00

@Psy-Fi - quick note, my test was without OCIO (disabled in my build).

Troy Sobotka commented

2014-05-23 01:55:10 +02:00

Added subscriber: @troy_s

Troy Sobotka commented

2014-05-23 01:55:10 +02:00

"sRGB is correct only between 0 and 1. What if you use linear space or scaled normalized vectors above V=1?"

This is incorrect.

sRGB as a standard, is a display referred space with values that exist within the bounded 0..1 range.

Blender however, is a scene referred model that by default assumes sRGB primaries on most input images. The values can range from zero to (theoretical) infinity with no special meaning to the value of 1.0; all values are merely a radiometric ratio of the sRGB primaries.

So while the bulk of input images will end up display linear (linearized sRGB within the 0..1 range), the internal model has no such limitation and permits textures and such to emit HDR wide values. The primaries however, remain within the gamut of the working space, which by default, is assumed sRGB.

This issue has further complexities of attempting to use an HSV model (by nature typically display referred) in a scene referred context.

"sRGB is correct only between 0 and 1. What if you use linear space or scaled normalized vectors above V=1?" This is incorrect. sRGB as a standard, is a display referred space with values that exist within the bounded 0..1 range. Blender however, is a scene referred model that by default assumes sRGB primaries on most input images. The values can range from zero to (theoretical) infinity with no special meaning to the value of 1.0; all values are merely a radiometric ratio of the sRGB primaries. So while the bulk of input images will end up display linear (linearized sRGB within the 0..1 range), the internal model has no such limitation and permits textures and such to emit HDR wide values. The primaries however, remain within the gamut of the working space, which by default, is assumed sRGB. This issue has further complexities of attempting to use an HSV model (by nature typically display referred) in a scene referred context.

Fazekas Laszlo commented

2014-05-23 07:04:34 +02:00

Okay, then I say it seems the HSV<->RGB conversion used by Blender now works well only between 0 and 1. Above V=1, it is an extrapolation and goes to infinity quickly when converting from HSV to RGB. As you said, it is a display reffered space. You cannot display colors with V>1 correctly. But we need these cases too. For the rendering I'm sure Blender uses linear color space. In linear space the conversion is very simple and has no similar problem: V is always the maximum value of R,G,B, S is the minimum value and H is an angle on a color wheel.

Troy Sobotka commented

2014-05-23 15:16:35 +02:00

“Okay, then I say it seems the HSV<->RGB conversion used by Blender now works well only between 0 and 1. Above V=1, it is an extrapolation and goes to infinity quickly when converting from HSV to RGB.”

I agree, all color pickers should be able to work at any stop in an image. Psy and I had a discussion about this. The current issue is that Blender still has quite a few places where the model is inferred to be display referred, as opposed to scene referred. This is an incorrect inference, and requires some of the algorithms to be refactored for HDR values.

Sadly some of the compositing nodes also use this incorrect assumption, and therefore fail miserably on scene referred data.

I suspect Psy will have a good idea on how to negotiate this in a subsequent version.

“Okay, then I say it seems the HSV<->RGB conversion used by Blender now works well only between 0 and 1. Above V=1, it is an extrapolation and goes to infinity quickly when converting from HSV to RGB.” I agree, all color pickers should be able to work at any stop in an image. Psy and I had a discussion about this. The current issue is that Blender still has quite a few places where the model is inferred to be display referred, as opposed to scene referred. This is an incorrect inference, and requires some of the algorithms to be refactored for HDR values. Sadly some of the compositing nodes also use this incorrect assumption, and therefore fail miserably on scene referred data. I suspect Psy will have a good idea on how to negotiate this in a subsequent version.

Antonis Ryakiotakis commented

2014-08-04 15:40:51 +02:00

Changed status from 'Open' to: 'Duplicate'

Antonis Ryakiotakis closed this issue

2014-08-04 15:40:51 +02:00

Antonis Ryakiotakis commented

2014-08-04 15:40:51 +02:00

✘ Merged into #41287.