Why are some data subject to gamma correction and some not?

You can’t. Not without understanding that the values are encoded light intensities determined by some working reference space lights. If you take the transfer function values under sRGB’s transfer function encoded values and assume sRGB coloured basis primaries, copy them precisely even with decimals and decimals of float, and use them under another transfer function and different lights, you end up with random output.

The values are encoded to some transfer characteristic and represent three unique colours of light. Nothing about those two critical facets is communicated via the encoded values, and must be known / communicated via ancillary information.

I might show you, if I find some time… :+1:

I was not asking. I was stating.

You can’t.

Whatever man. I changed it already several times.

since you talked about big boys like and argument and big boys dont do it… you dont have any argument

As you brought it up, for precise values it will lead to “longer” numbers, if they are in front of or behind the comma.

And encoding floating points in hexvalues is also possible just uncommon and not as elegant. But Hexvalues are not restricted to integers.

Your point of view is set to one distinct usage of blender, most likely what you use it for and you assume thats the only usecase. So I guess further down the road you would tell me that blender should just support 64bit floating point values per color channel. But the in truth this is such a precision overkill for many things if not all. Blender should instead support a wide range of colordepths and diffent colorspaces for all the different usescases where a tool like blender is used for. And for many of them having 32bit RGBAs is still sufficient and then HexValues are a very practical standard here. If at some time in the future a significant number of 2d and 3d tools may swap to a minimum of 16 or 32 bit per channel than hexcodes could get updated to 16 or 32 digit hexcodes.

And Hexcodes could also be used to encode the floating points, lossless, even if it wouldn’t be very readable it would still be a valid way to copy its values with a single string as they are just a compact bit representation.

Programs could check the hexcode length and automatically differ between 32bit RGBAs and higher bitdepths and convert it to their internal bitdepth.

Regardless of a range comparison of floating points and integers at a distinct bitdepth, it gets increasingly uninteresting if a color encoding was encoded in a higher bit integer channel or floating point channel.

And for the most interchange usescases between programs such high bitdepths aren’t needed.

Let me finish this that I really didn’t want to say something mean about you even if I really disliked your way of argumenting and I disagree in lots of points.

And forgive me I’ll stop this discussion here. I also found its tone too combative, its not fair for this thread, as this all is offtopic and personally I’m not very interested in this dicussion . Feel free to disagree. :slightly_smiling_face:

I’m not a color master, but c4d has some rgb color range options to choose.

Anyway, hex is going nowhere, it’s still the most compatible thing in blender’s color picker. :wink:


Big boys is a reference to the big three, nothing else.

Keep that in mind when someone says that. :wink:

And you realize that the gist of what has been repeated holds true, no matter how wrong a couple of participants in this thread profess:

  1. Hex codes are relative to a particular colour encoding. They don’t hold meaning beyond being an obfuscated means of communicating integer values along a transfer function. They should not be used to communicate colour as they do not contain enough information.
  2. They are extremely problematic with float based encodings.

The entire reason people use them is fundamentally flawed and problematic to begin with, and under further inspection, a hexadecimal representation is problematic in other dimensions.

This reveals the absolute madness you are spiraling down. So now you want hexadecimal entry with a toggle to indicate whether it is integer encoding or IEEE 754 float[1]. As opposed to simply using a numerical value system that is vastly more clear and one that a great many people learn when they are ten years old or lower.

And this entire spurt of confusion highlights how fundamentally confused people are with respect to trying to elucidate the original poster’s valid question. All of this madness literally has nothing to do with this thread, in addition to being garbage ideas that a few folks are vehemently trying to keep other folks trapped in 1995, under the guise of reasons that hold nonsensical meaning in a pipeline in 2019.

Yeah, the big boys are the software that you decide. :rofl:

And if we talk about texture painting we use of better example in the world three softwares without advanced painting system.

I already replied your first two statements. And I dislike how you’re constantly bashing everyone. If you don’t want to rethink anything, ok, but then finally let’s stop discussing.
No i don’t want a float hexvalue I said its generally possible because hexdecimal values are just another numerical system, that has some very simple nice features that can be exploited for arbitrary binary values. I describe them, you don’t see them or don’t want to see, you don’t even see that a hexcode has a simple clipboard charakter. And now look how many lines this discussion has taken and you are still unspecific and exaggeratory. Sorry, I don’t see this leading anywhere. Give us a break. I’m out.

Go through the thread. Look at the reasons people think hex codes work. Learn that each and every example is utterly false.

End.

The poor original poster asked a question, and it was answered; Blender isn’t sufficiently managed. Hex codes are part of the problem.

End.

Is Adobe Photoshop one of the big boys mentioned above?

Maybe we should see what it does with colour and check if there is actually a problem with hex codes:

Same hex code, different colorspace. What happens? The same colour value produces different colours depending on the colorspace, and that’s perfectly fine as RGB is a device-dependent model.
However, people usually take hex codes as some sort of “universal” representation for colour, like an “exchange” format, because you know, it’s easier to copy and paste a single value than three.

That conveniency covers some complexity the artists need to be aware of: In which colourspace that colour is defined.
It’s not uncommon to see brand identity manuals with Hex definitions for the corporate colours.
What’s wrong with that?
Those hex are usually taken from Pantone books and are defined as sRGB, while Adobe insists on defaulting to Adobe RGB in some of their color presets.
Guess what happens when you create and AdobeRGB document and use that Hex “corporate” colour.

But let’s move forward and talk about bitdepth precision:

Here I changed both documents to 16 bit integer precision.
Check the colour picker: The RGB sliders are still expressed as 0-255 and the hex code is still 8 bit.
What you see there is one of the big boys doing it completely wrong.
Both the RGB sliders and the hex selector stopped having the required precision to pick the colour values that 16 bit precision allows!

And what about floats? It was said above that you could use floats with hex codes, right?
Well, it looks like Adobe decided to gut the hex values when you flip to 32 bit linear as it was obviously problematic.
They left an 8i RGB slider that sucks but it’s managed, allowing to translate 8 bit nonlinear triplets to 32 bit float automatically. However it’s not clear what colourspace it is using as source for the transform.

And it does matter, since it’s not just matter of “gamma correction”. When you move through different colourspaces you need to take in considaration not only the transfer function, but the primaries and white point of source and destination colourspaces.
Because, as you see in the screenshots above, the same triplet used in different colourspaces produces completely different results because, again, RGB is device dependent.

Of course we know that hexadecimal is just a number notation, but calling it a “code”, although technically correct, makes people think that they are getting some sort of unique ID for a colour, because for most of the people it’s data encode in a format they don’t understand (that’s why Troy says it’s obfuscated, and for most of the folks it is).

Having all simplified as a single value seems convenient, but it creates a whole set of problems that most of the users struggle with. Blender’s hardcoded transform from sRGB to linear rec.709, labeled as just “gamma corrected” is an oversimplification that in the end harms users.
Don’t believe me? Create a new image in the AdobeRGB, pick a colour and copy the hex code. Take that code to Blender, and see what happens with your colour.

Using RGB keeps visible the concept of dialing the intensity of three lights, which is exactly what a colour picked does. And luckily having that metaphor in front of you, you may ask the next important question: which colour are these red, green and blue lights?

2 Likes

https://medium.com/the-hitchhikers-guide-to-digital-colour

But when can expect new instalments? I’ve loved it, but need much much more. Slacker. LOL.

Fair. Very fair.

When this project wraps up I intend to tackle several more in the deeper zone.

1 Like