Posts: 6
Threads: 2
Joined: Jan 2024
Reputation:
0
Operating system(s):
- Windows Vista or 7, 8, 10 (64-bit)
Gimp version: 2.10
01-27-2024, 05:03 AM
(This post was last modified: 01-27-2024, 05:06 AM by Ellye.)
Suppose I have a pure black (#000000) layer and a pure white (#FFFFFF) layer.
They are one on top of the other, both with normal blending. The one above is 50% opacity.
I'd expect that the resulting color would be a midpoint gray (#7F7F7F). And I'm pretty sure that's what I used to get on GIMP until recently, and it's still what I get on other softwares.
Instead, I'm getting #BCBCBC - a far brighter color.
This is not just about layer blending either - any brush with some kind of transparency or anything like that - the result of mixing colors always come up brighter than I'd expect.
I tried both "Perceptual Gamma" and "Linear Light" modes, no change.
Video demonstrating (I compare with Paint.Net on it, but the result there is the same on any other software aside from GIMP - from Photoshop to html rendering in web browsers):
https://www.youtube.com/watch?v=OfAXikmC...e=youtu.be
Posts: 6,405
Threads: 279
Joined: Oct 2016
Reputation:
566
Operating system(s):
Gimp version: 3.00RC1
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.
Posts: 6
Threads: 2
Joined: Jan 2024
Reputation:
0
Operating system(s):
- Windows Vista or 7, 8, 10 (64-bit)
Gimp version: 2.10
01-27-2024, 02:58 PM
(This post was last modified: 01-27-2024, 03:10 PM by Ellye.)
(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.
Thanks for the explanation!
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?
Posts: 7,179
Threads: 155
Joined: Oct 2016
Reputation:
1,008
Operating system(s):
Gimp version: 2.10
(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
Posts: 6
Threads: 2
Joined: Jan 2024
Reputation:
0
Operating system(s):
- Windows Vista or 7, 8, 10 (64-bit)
Gimp version: 2.10
01-27-2024, 03:59 PM
(This post was last modified: 01-27-2024, 03:59 PM by Ellye.)
(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
Thanks!
Perceptual mode on the layer properties does work for what I want!
|