• The  [0 .. 255] values you are used to are encoding how bright the pixel is compared to the brightest pixel. 
  
• [0 .. 255] values are used because they fit a byte but what is really stored is a ratio in the range [0.0 .. 1.0]
  
• The [0 .. 255] are somewhat problematic, because used directly they encode as many dark levels as bright levels, but our eyes are more sensitive to difference in dark levels. So the correspondence between numbers and actual brightness is altered by a gamma-correction where ɣ=2.2, that gives more dark values
  
• So the value of something "half-bright", 0.5 is corrected to 0.5 ^ (1/ɣ) = 0.72974 which is 188 in the [0 .. 255] range(*)
  

(01-27-2024, 09:52 AM)Ofnuts Wrote: This is normal... Independently of any underlying representation, what is "midpoint gray"? Can we assume that it emits/reflects as much light as an area where half the pixels are black and half the pixels are white? Then:

Which side is closer to the middle? In fact, making the right side indistinguishable from the middle is a good way to tune your display...

Why is it so?

• The  [0 .. 255] values you are used to are encoding how bright the pixel is compared to the brightest pixel. 
  
• [0 .. 255] values are used because they fit a byte but what is really stored is a ratio in the range [0.0 .. 1.0]
  
• The [0 .. 255] are somewhat problematic, because used directly they encode as many dark levels as bright levels, but our eyes are more sensitive to difference in dark levels. So the correspondence between numbers and actual brightness is altered by a gamma-correction where ɣ=2.2, that gives more dark values
  
• So the value of something "half-bright", 0.5 is corrected to 0.5 ^ (1/ɣ) = 0.72974 which is 188 in the [0 .. 255] range(*)
  

Working directly on the gamma-corrected values, as Gimp did until 2.8, has plenty of side effects. For instance if you do a red/green gradient, you would expect the midpoint of the gradient to be yellow. 

* In Gimp 2.8, all you got was a brownish (128,128,0): , and the center of the gradient was noticeably darker that the sides.
* In Gimp 2.10, the midpoint color is (188,188,0) : , and the gradient luminosity is more even (though can ask the Blend tool to produce a "perceptual gradient" which is the 2.8-style gradient.

If you use the Pointer dialog or the Sample Points dialog you can ask for the Pixel representation, which in high-precision images is the actual [0.0 .. 1.0] brightness value.

(*) If you do the computation yourself, you find 186. Gimp in practice uses the SRGB color space which is a bit different.

(01-27-2024, 02:58 PM)Ellye Wrote: Thing is, for me currently, parity with other software environments is a more important factor right now.

To be more precise, I need parity with how browsers render HTML5 canvas - and they do not seem to take that last correction step you listed.
If I mix a 255 color with a 0 color on my browser, the result will be a 128 color - not a 188 color.

Is there any option on GIMP 2.10 to mimic this behavior, or is downgrading to 2.8 a better out for me?  

(01-27-2024, 03:19 PM)rich2005 Wrote:

(01-27-2024, 02:58 PM)Ellye Wrote: Thing is, for me currently, parity with other software environments is a more important factor right now.

To be more precise, I need parity with how browsers render HTML5 canvas - and they do not seem to take that last correction step you listed.
If I mix a 255 color with a 0 color on my browser, the result will be a 128 color - not a 188 color.

Is there any option on GIMP 2.10 to mimic this behavior, or is downgrading to 2.8 a better out for me?  

You can try painting in a transparent overlay, using perceptual mode. Might work for you.

example:  https://i.imgur.com/RVoNgpN.mp4