| Welcome, Guest |
You have to register before you can post on our site.
|
|
|
What is the gamma encoding and why are my color computations wrong? |
|
Posted by: Ofnuts - 07-16-2024, 07:25 PM - Forum: Tutorials and tips
- Replies (9)
|
 |
So, you tried to predict or emulate Gimp's behavior with math and failed. And you wonder why. You have come to the right place, take a seat and fasten you seat belt. Also, make sure you check all images at their actual size (click on them to see them in a separate tab, and make sure your browser is exactly 100% zoom) otherwise some examples could seem to demonstrate exactly the opposite of what is stated in the text.
The root cause is that our eyes are not linear devices. If you double the power output (for instance, switch on a second light), you don't perceive the room twice as bright. Somewhat brighter, yes, but certainly not twice as bright. Furthermore, our eyes are more sensitive to small differences between dark tones that between light ones.
So, when pixel color values are encoded on a byte, encoding the physical output directly (which is what Gimp calls Linear light) wastes precious bytes values encoding bright nuances we can't perceive, and leaves a handful of values to encode all the subtle darkness nuances we can distinguish.
To avoid this, the values are encoded using a power law that has two nice advantages:
- The perceived "medium gray" is about half-scale
- There are many more values to encode low luminosity levels
The theoretical law is encoding = luminosity ** 2.2 (where a luminosity of 1.0 is maximum brightness) and then scaled to the [0 .. 255] range. So for instance physical medium gray (0.5) becomes (0.5 ** (1/2.2) ) * 255 = 186 (#BA) (the 2.2 value is what is known as the "gamma").
In practice images are encoded using a slightly enhanced law called the sRGB color space where the "physical" medium gray is #BC
So far, so good. So, where is the problem?
The problem is that if the gamma-encoded values are a good way to store the values, they cannot be used directly to compute things. For instance, the average color of an area with an equal number of black (#00) and white (#FF) pixels is not #80. This area emits towards your eyes half the power of the fully white area, so its average color is the "physical" medium gray, not the "perceived" medium gray as demonstrated by the picture below (that should be checked at full scale(*)):
Which side is closer to the middle? In fact, making the square on the right indistinguishable from the one in the middle is a good way to tune your display...
The rule is: when doing computations that are based on physical models (spoiler alert: most are), channel values should always be converted to physical values (Gimp's Linear light) before any math is applied to them.
This applies equally to the three color channels. For instance if you do a red-green gradient, you would expect the midpoint of the gradient to be orange.
- In Gimp 2.10, it is so, because the middle of the gradient is where half the power is red and half the power is green. In other words, each color channel emits half the full scale, so the middle color is #BCBC00:
- In Gimp 2.8, working directly on the gamma values, the middle color is #808000, which is a much darker brown:
.
As an exercise for the reader, here is the averaging of a pattern with three colors. Click for full scale display otherwise your browser is showing you the wrong colors!
If you use Filters > Blur > Pixellize on the pattern, you should obtain the same color.
All these examples show that the direct computation in the sRGB space produces results that are too dark.
Some more notes:
- Gamma-encoding is mostly used in low-precision modes (8-bit (from most image formats) and 16-bit integer (from PNG)
- Use of sRGB of course assumes that the images uses sRGB, if you load an image with another color profile, you have to use that color profile for the conversions.
- 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] linear light value.
Spreadsheet:
GammaSpreadSheet.zip (Size: 126.67 KB / Downloads: 335)
- ODS format for maximum compatibility
- Contains macros, so macros have to be enabled
- Shows formulas to convert from sRGB to linear and vice-versa
- Also contains functions for the same (LINEAR2GAMMA and GAMMA2LINEAR) that take [0 .. 1] values and return [0 .. 1] values (in other words you still have to scale to from [0 .. 255] values, but as a bonus it works with 16-bit values too...)
Python functions for same:
Code:
import sys,math
def srgbToLinear(v255):
v=v255/255.
return v/12.92 if v <= 0.04045 else math.pow((v+0.055)/1.055,2.4)
def linearToSrgb(linear):
srgb=linear*12.92 if linear < 0.0031308 else 1.055*math.pow(linear,1/2.4)-0.055
return 255*srgb
(*) Browsers scale images using the sRGB values directly, so scaled images may end up darker than the original image. The three-color average example above is a good example. At native size the linear average (right square) is identical to the pattern at the top, but if the image is scaled by your browser (just zoom in/out) your browser will gamma-average the pattern at some point and make it look like the bottom left square.
|
|
|
| Background disappears when using Scale Tool |
|
Posted by: yearofthegimp - 07-16-2024, 11:25 AM - Forum: General questions
- Replies (4)
|
 |
Brand new gimpster here, please be gentle!
I'm using GIMP 2.10.30 on Windows 10 64-bit.
(Irrelevant, but background): I am trying to prepare eight individual photo crops (of the same size), ultimately to drag into a master montage/canvas featuring all eight.
My problem:
I appreciate there will be easier ways of doing this, but as I'm a newbie, I am following Method 2 of this YouTube video as it seemed fairly straightforward to follow:
https://youtu.be/dQSlqcMCKx0?t=221
Unfortunately, when I get to the step where I choose the Scale tool (Tools>Transform>Scale), my background image disappears, and instead transforms into a chequerboard, meaning that I cannot resize the image behind the crop selection (see video), before ultimately making my chosen crop.
The best explanation I could find on gimp-forum.net replicating my issue was this one:
https://www.gimp-forum.net/Thread-Image-...y-to-scale
...but even after trying to follow these instructions it doesn't resolve and I am stuck. Please note that, as per a step of the video, I am deliberately setting the Opacity to 50 per cent so that I can see the background image and manipulate it to the preferred position behind my crop window before making the final crop.
I've spent several hours on this and (without wishing to go into too many details), the photos are of something I need to discuss with my doctor, so I'm anxious to get this over the line.
Here are a couple of screen shots: just in case you're scared of the sight of blood, I've changed the photos to two of my regular peanut butter sandwich-loving wild visitors instead!
On the first screenshot (having set the initial Crop window to my chosen 480x540 pixel size), things are going as planned:
However, on the second (after hitting the Scale Tool), two things occur differently from the YouTube Autobot video tutorial I have described above:
Firstly, the background image disappears
Secondly, the "handles" around the image and the centre square with a "plus sign" inside it appear around the crop selection, and not around the background selection and therefore do not allow me to resize (make smaller) so that my selection can be fitted into the 50 per cent opaque crop window.
As a reminder, from the video, this (below) is how I would hope to see things: chequerboard crop window, opaqued background image with handles round allowing me to drag and resize
To you guys it will be dead simple, I'm sure, but I'm losing the will to live here! Please dive in and help out, thanks.
|
|
|
|
| Add Transparent Window to Existing |
|
Posted by: DestructZero - 07-13-2024, 04:12 PM - Forum: General questions
- Replies (3)
|
|
I've searched all over and I can't seem to find the answer to my question. I have a PNG image of an airplane fuselage with two windows that are transparent. All I want to do is to add a third window between them, and I can't make it work. I've read that I need to create a new layer and 'Add Alpha Channel' but that option is greyed out. I also read that if I do Windows --> Dockable Dialogs --> Channels and see 'Alpha' as an option (which is there) that means the Alpha Channel has already been added, which I guess makes sense because there are already two 'windows' on the image that are transparent.
With that information, could someone please walk me through the steps to create a third window that will be transparent? The online videos and help I've found show me how to remove the background around a part of an image to make it transparent, but that's not what I need in this case.
Thank you very much for your help!
|
|
|
|
| Fill by line art with perfect edges on a B&W image or vice-versa |
|
Posted by: PixLab - 07-13-2024, 05:58 AM - Forum: Tutorials and tips
- No Replies
|
 |
No method is wrong, but some time I see convoluted methods to bucket fill with line art detection when there is a BackGround, where it can be extremely simple to bucket fill with line art detection and get perfect edges even with a BG.
Thus I'll show you one simple way without deleting any BackGround, no selection, no mode change in your tool settings.
GIMP has a layer mode in which we are interested, it's the Multiply mode for white BG or its opposite Screen mode for black BG
Get you image in GIMP, then:
- Create a new white layer (if the BG is white), and put it at the bottom
- Create a transparent layer above the white layer
- Put the top layer (original image) in Multiply mode (Screen mode for black BG)
- Bucket fill by line art the transparent layer
Done, perfect edges!
|
|
|
|
|
![[Image: rVJUESm.png]](https://i.imgur.com/rVJUESm.png)
![[Image: js4YXbm.png]](https://i.imgur.com/js4YXbm.png)
![[Image: SFgXGkj.png]](https://i.imgur.com/SFgXGkj.png)
