Hi,
I’m a bit confused… I explain
with gimp high bits depth we can work with 32 bits color depth pixel value…
why into color picker RGB values range from 0 to 100 instead from 0 to 2^32 ??
and hexadecimal color value is from 00 to FF ( 255) values??
Surely I’m missing something 
Hi @dafrasaga,
What settings do you have under image/precision?
Or do you mean in the Change Foreground Color dialogue?
Have fun!
Claes in Lund, Sweden
Hi Claes,
I mean into Change Foreground Color dialogue…
Cheers
Gimp operates internally using 32-bit floating point precision, regardless of the precision the user chooses - this user choice regarding precision only affects how the pixel values are stored in RAM. The lower precision user choices benefit users with very large images and/or machines with not very much RAM.
Floating point (regardless of the bit depth) works with the display range from 0.0f to 1.0f, plus whatever channel values less than 0.0 or greater thn 1.0 might be required to encode out of gamut or out of display range images.
So technically to reflect the precision at which GIMP actually works, the color picker RGB values should read out between 0.0 and 1.0 instead of between 0.0 and 100.0. The main reason for multiplying the floating point values by 100 for the color picker seems to be to make it easier to use the sliders. For Curves and Levels this “100 times” the actual floating point values makes it possible to refine changing the black point, without showing the user several more decimal places, which would make for a messy and difficult to use UI,
The Change FG Color, Levels, and Curves dialog all use the 0.0 to 100.0 display range. But the Histogram and Threshold use 0.0 to 1.0 for the display range. It might be nice if all the dialogs used the same range.
See this bug report: Bug 788938 – Desire for 8bit integer RGB color pane.
But now we can generate only 100 shades instead of 255…
There must be other things under …
No, floating point precision encodes considerably more shades than 100 and considerably more shades than 255.
The exact number of numerically different increments per channel depends on a lot of stuff, but from a user perspective, 32-bit floating point offers you considerably more increments than 16-bit floating point, at least as many and hopefully more increments than 16-bit integer (depending on this and that), and fewer increments than 32-bit integer.
Just for my interest: What’s that “this and that”, given the fact that a IEEE 754 float has a 23 bit mantissa?
Ok, I can deduce with 32 FP we ha a lot of shades… but with the slider I can go fro 0 to 100, only …
For one thing, it depends on other things that are happening in the background in whatever image processer is using floating point processing. A lot happens in the background in babl/GEGL/GIMP.
For another thing, and this is stretching my knowledge of floating point arithmetic, floating point uses part of its precision to encode the decimal information, and part to encode the stuff before the decimal. Over the range of possible floating point values, at the upper end, there’s less “stuff” available to encode the stuff after the decimal point, or whatever serves for a decimal point in floating point. My apologies, I’ve read through various papers, but a lot of what I read on this topic I promptly forgot as being of no practical use for the kind of editing I do, including forgetting the actual technical terms. But searching the internet for papers on floating point arithmetic will turn up the relevant information.
For a third thing, it depends on the file format used to save the image to disk. See this article:
http://www.anyhere.com/gward/hdrenc/hdr_encodings.html
Hopefully someone with more precise knowledge of floating point will chime in.
Regarding “background processing”, I’ve asked the GIMP devs what the “throughput” precision is, but I don’t think anyone has come up with any formal measurements. I do a lot of testing to make sure that resulting values for this and that seem reasonable, and so far I haven’t had any reason to say “this operation doesn’t produce precise enough results”.
Well, the slider has one value after the decimal point, so that gives 1000 increments.
it’s time to go to the oculist…I’m so blind
Cheers
Well, I do not claim to have precise knowledge of all floating-point weird aspects (that are many), and I have no knowledge about GIMP internals, but with a 23-bit mantissa you can represent precisely all integers in the range [-2^23, 2^23].
Hi @agriggio and thanks! for taking the time to correct my misrecollection/misunderstanding of whatever it was I read way back when. I really do mentally classify stuff as “pertinent to editing” and “not so pertinent” and tend to promptly forget anything in the “doesn’t seem pertinent” category.
For HDR scene-referred representation, of course precision for very high values becomes very important. So far personally I don’t do that kind of editing, but high bit depth GIMP seems to be heading in that direction, can already handle aspects of same. So here are two questions:
First, does anyone know if “all integers can be represented precisely” also means there are the same number of available steps/numbers/mathematical increments between one integer and the next - for values in between the integers, regardless of the magnitude of the integers"?
Second, what does “integer” mean? Base ten integers? Base two integers? Something else? I’ve been wondering about this but I’m not really sure how to even ask the question, but apparently banks use an entirely different type of floating point “something or other” to handle currency.
Hi @Elle,
No, “all integers” means just that, i.e. all numbers belonging to the Z ring that are between -2^23 and 2^23 inclusive can be exactly represented 
Regarding the values “in between”, no, there’s no such guarantee. In fact, floats are denser around 0 and get progressively sparser the further away you move from 0. (That’s why the decimal point “floats”, so to say…).
Well, for integers it doesn’t matter, you can always represent them accurately (within the bounds). For fractional numbers then the choice of base/radix does matter, as there are some numbers that can be represented accurately in decimal but not in binary, and more in general the actual bounds on the errors you get while performing operations might be different. That’s why the financial world uses its own conventions, because even apparently tiny rounding errors can lead to big money losses… But in a general photography forum, I suppose you can ignore all this
I have a difficult time wrapping my head around the idea that a binary floating point number can exactly represent all integer numbers within a specified range. But poking around the internet, this is true.
Oh, wait, of course one can count in binary! 0, 1, 10, 11, 100, etc. Now I feel silly 
Now I just wait for someone to implement radices in the color picker as well.
That’s when the real fun begins. I can imagine Elle wanting to multiply layer 6 with
layer 9 – and she will quickly find that the result is 42.
/Claes in Lund, Sweden
Well, one answer to questions about the universe is - or was, pending subsequent research - 42:
Just for someone reaching here needing right now for fine control of colors in GIMP 2.10 - I’ve just answered how to workaround the context-colors limitation when you know what you want to get:
TL;DR: paint using the 1/256 precision available, and then use opacity/color/paint tools to multiply what is on the image by the needed amounts.