After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760766 - invert-linear behaves strangely
invert-linear behaves strangely
Status: RESOLVED NOTABUG
Product: GEGL
Classification: Other
Component: operations
git master
Other Linux
: Low minor
: ---
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on:
Blocks:
 
 
Reported: 2016-01-18 00:21 UTC by Jehan
Modified: 2016-02-03 19:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Comparing color information before/after gegl:invert-linear (49.44 KB, image/png)
2016-02-03 13:04 UTC, Jehan
Details
gegl:invert-linear on grayscale gradient. (80.37 KB, image/png)
2016-02-03 16:28 UTC, Jehan
Details

Description Jehan 2016-01-18 00:21:12 UTC
- cd to GIMP source root.

- run:

> gegl -x "<gegl> <node operation='gegl:invert-linear'></node> <node operation='gegl:load'> <params> <param name='path'>icons/Symbolic/128/gimp-wilber.png</param> </params> </node> </gegl>" -o gimp-wilber-inverted.png

`gimp-wilber-inverted.png` is a slightly different grey, but clearly not to be considered "inverted". I know that invert-linear and invert-gamma would render differently, but here it seems quite wrong.
Comment 1 Øyvind Kolås (pippin) 2016-02-03 08:35:47 UTC
Just like invert-gamma wouldn't make an sRGB 8bit gray of 127 very different from 127 when inverted... (255-127=128) there some gray values will map to  close gray values for invert-linear as well. It sounds like invert-linear is behaving like expected.
Comment 2 Jehan 2016-02-03 13:04:53 UTC
Created attachment 320332 [details]
Comparing color information before/after gegl:invert-linear

Hi,

I am not speaking of inverting grey colors close to the median. I am speaking of very light (or very dark) grey colors which stay very light (or dark) while still being "slightly" different.

Attached is a screenshot where I ran gegl:invert-linear on the file icons/Symbolic/128/gimp-wilber.png which is in GIMP repository.
I picked the left Wilber (the original) and the right one (after gegl:invert-linear) and added both results of the color picker, side by side in the same image. The color changed, but this is *not* an inversion.
Comment 3 Jehan 2016-02-03 13:05:05 UTC
Reopening.
Comment 4 Øyvind Kolås (pippin) 2016-02-03 15:36:27 UTC
The median for linear invert is not 128 / 50% gray... add a rectangular selection with a grayscale gradient in it to see how that selection gets flipped.. and colors close to your trouble color becomes the mirroring point on the gradient...
Comment 5 Jehan 2016-02-03 16:28:16 UTC
Created attachment 320367 [details]
gegl:invert-linear on grayscale gradient.

Really? I thought invert-linear was exactly this (channel colors are "linear", so the median point is the half of the max value, no?), and you also wrote in comment 1 that the inverse of 127 was 255 - 127 = 128 (in 8 bit channel).

This also corresponds to the op code:

> out[0] = 1.0 - in[0];
> out[1] = 1.0 - in[1];
> out[2] = 1.0 - in[2];
> out[3] = in[3];

> grayscale gradient in it to see how that selection gets flipped

I did what you proposed. The grayscale gradient indeed gets a similar inverse as the Wilber. So if I pick a similar #bebebe color in the gradient, which is 190 per channel, I would expect the inverse of this being 255 - 190 = (65, 65, 65).
Instead I get (184, 185, 185) (also for some reason, the first channel is even off 1 compared to the others).

So I don't understand. Is there something else to the linear-invert algorithm?
Comment 6 Jehan 2016-02-03 19:24:40 UTC
Ok after discussing on IRC with Pippin, the problem was the following:
- invert-linear means that the inversion is made in linear light space.
- invert-gamma always invert in sRGB/gamma-corrected space.

The Wilber was a sRGB image. Converting to linear light, the gray value was now 131, which is very close to the half of 255 (the "flipping" point). This explains the very small color shift.

So this was not a bug, but a misunderstanding of what was the invert-linear operation on my side.
Closing.