Is it a bug or a feature? 
Color RGB(1.0, 0.0, 0.45945) in different areas
I think it’s a feature but I’d like to be able to toggle it on/off for export reasons as well:
Hex codes don’t mean anything and should be removed. The issue is that Blender isn’t fully colour managed, and the UI picker does what it has done for years. That is, RGB values are display linear, with the potential to be set to scene linear, and the HSV rubbish is sRGB EOTF^-1 encoded. It’s largely a hot mess that needs fixing, but no one really cares.
Except if you want to paste a color value from Adobe’s CC suite, which is industry standard, that color value is represented by a hex code.
When Adobe is no longer industry standard, Blender can remove hex codes, but unfortunately not before.
1 Like
True.
Hexcodes are a compact single value color representation that work everywhere based on textual copy and pasting between different programs and web applications that deal with colors or colorschemes. It should not be removed.
1 Like
Something in between. It simply hasn’t been implemented uniformly. And while this is no bug per definition, it’s nonetheless bad. Thanks for bringing that up. This should really be fixed.
1 Like
How do Hex condes don’t mean anything? I’ve read this several times in similar discussions now but my understanding is that Hex-codes are just a different representation for RGB values, aren’t they?
Or in other words - it shouldn’t make a difference if you paste R, G and B individually or a compact single Hex-code, should it?
Everything is fine with hex code in the interface
As we see it gamma is correct everywhere
But in api blender, colors are in rgb format and you get confusion
Some value has to be stored internally, lets call this the raw value. Lets say we have in 8 bit per channel, so for RGBA we have 32bit. A channel is a binary representation of a value between 0…255.
Converting a colorchannels raw value in RGB values into the range between 0…1 of what is currently in bits between 0…255 could be done differently.
This could still be the raw numerical value ( x/255) just rangemapped or it could have been transformed by the colorspace. And this is where the problem kicks in. This is sometimes done and sometimes not.
If you enter 0…1 rgb fractional numbers, then sometimes they are treated as being part of the colorspace and sometimes treated as raw. The hexvalues instead, maybe because of their direct lossless convertibility are always treated as raw. Because of that the color produced by a hex is visually the same one. But entering a hex value still associates different rgb values to itself. And entering rgb values leads to different hex values.
The problem is that Adobe started life as a legacy application that dealt specifically with sRGB. Rendering and motion picture work has long since moved on.
Hex codes are an absolutely obfuscated method of communicating light intensities, and worse, people think they hold meaning. They don’t. They are simply cryptically encoded integer values tied to the basis primary light colours. Change the basis colours for wider gamut rendering, and those legacy anachronistic garbage values yield rubbish.
I’ve started a small series in an attempt to help out pixel pusher folks. Perhaps someone here might find it useful. I explain why everyone needs to understand that hex codes are rubbish, and why legacy applications need to wake up. https://medium.com/the-hitchhikers-guide-to-digital-colour
This is unequivocally false, and indeed part of the problem of comprehension. They aren’t magic. They represent encoded integer based increments of light emission from a display. They don’t explicitly control what chromaticity is referenced, and frequently are sRGB, which means they will absolutely fail in alternative contexts and models. Rendering and motion picture work especially.
The issue is that Blender still needs to fully colour manage the UI. It doesn’t. It still has some forgivable at the time legacy code paths, and non colour managed hex codes are a part of that.
Feel free to read the above link. Legacy display referred applications do plenty of things totally wrong, including Photoshop. It’s up to the pixel pushers to demand that their software that they invest time and money in do the right thing.
1 Like
You’ve gotta be kidding, right?
Instead of removing the only sane thing about the color picker in blender, how about fix once and for all those insane 0 to 1 numbers that blender gives us, huh?
Literally most softwares out there use 0 to 255 for RGB…
And degrees/percentage for HSV…
Why on earth do we have to deal with those unpractical 0 to 1 numbers in blender there? It doesn’t bother anyone?
So, let’s leave the last sane and standard thing (hex) about it alone, ok?
The 0.0 to 1.0 is the only sane thing going.
Again, hex codes represent integer values according to a transfer characteristic. Eight bit integers are no better, because so extremely few quality applications use eight bit any more.
An RGB code value represents some emission quantity defined by some transfer function. The transfer functions are not universal. The code values at 8 bit are not universal. The chromaticities of the RGB lights are not universal.
It is not 1994 any more.
Perpetuating broken ideas in a compositing / 3D application is part of the problem.
What feels broken is switching to blender from any app out there and have to deal with those numbers.
At least we should have an option to choose the most widely used method, which is the ones I showed above.
0 to 1 is a pain in the butt.
Hexcodes are hexadecimal values, no they aren’t magic and they are also not obfuscated.
They are 3 or 4 values concatenated into a single string.
Three linear independent chosen axes span a 3dimensional color space, often this is chosen to be R,G and B but it could be transformed to other bases. Any 3dimensional colorspace, eg CIE could be represented with a hexadecimal value. RGB is in most derived standards restricted to positive values, but the colorspace itself theoretically even wouldn’t have to be restricted to that. The colors we associate with that colorspace is a bit arbitrary and has to be defined in a standard to get meaning. Otherwise its just a 3dimensional space.
As we are working with computers that works with binary numbers, it was chosen to divide the colorspaces values into steps that are a power of 2. 8 bits per channel were a defacto standard for a long time. But if you don’t like that, it’s NOT the fault of hexadecimal values just of concrete file formats.
Now comes the math for you. 2^8 = 256 = 16^2. So two hexadecimal values can represent the same amount of different values as 8 bits in binary. So a 32bit RGBA value can be stored in 8hexadecimal values, higher bitdepths are possible too and just lead to longer hexcodes.I don’t know why you think this is NOT a single string/value or why this is NOT more compact than 32 binary values, in my life it is. I don’t know why you think they can’t be copied and pasted textually. Hexadecimal have 16 different values 0–9 and A–F. All part of the ascii table. In my world they can.
Even that you say that they are light emissions from a display is strictly speaking wrong. You are referring to RGB and not hexcodes.
I think you wanted to turn this into a discussion about indivually drawbacks of different colorspaces.
Sure is sRGB spanning a gamut and that has it’s limits as every gamut has, and trying to widen it have impact on where it’s useful, but that all is NOT the fault of a hexadecimal value. And changing the basis of an 3dspace doesn’t prevent you from displaying it hexadecimal. And mathematically does another set of basisvectors not change the space itself.
And if you associate the hexvalue with a colorspace it shares the colorspaces meaning, different colorspaces were built based on different assumptions for their usecase, so they have individual advantages and references. All this is mixed in your sentences into something that hardly makes sense.
In a world of binary computers, where hundrets of programs are defining their colors in rgb, hexvalues are exactly what I said, a compact single value color representation to interchange colors of an associated colorspace that is widespread and sufficent for many applications. And having a input color with a custom bitdepth doesn’t prevent the renderer from calculating the image with higher precisions.
To me there’s nothing wrong with hexvalues.
blender uses 32bits color thanks to that 0-1 values. You cant work with 256 tones in true 32bits. ask for 256 value is like ask for a FAT32 operative system because all usb and sd cards works with fat32
if you want to talk about apps and big guys, like always you like to tell. See substance and mary, both work with 0 to 1 values…
1 Like
You don’t get the point, it doesn’t matter. Just give me the option like the big boys do. Simple.
Substance, Mary, 3DCoat,… basically the only software to paint textures, don’t give you the option to use 0-256 value. What you big boys do you talk? Microsoft Paint? because that is the same color selector that Photoshop uses.
It’s simple, only exist one big boy, substance painter. Here you can see the color selector
1 Like
Bingo! That’s the big boy I’m talking about…
Float values do not work on eight bit integer increments. It is an incompatible paradigm, and let’s not even begin to discuss an emission intensity of 662.4 for example.
I started coding assembly at age nine on an Apple ][ and have been digging into colour science for the past fifteen years. Pretty sure I’m good with the math.
1 Like
There are softwares that allows you to choose the RGB range to be displayed in the UI, and that’s all I want, otherwise it will always be a pain in the ass to share colors between blender and something else.
I know that I can input the RGB value and divide… to get the real thing, but still, PITA