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 624026 - GEGL projection renders differently than the non-gegl one
GEGL projection renders differently than the non-gegl one
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
git master
Other Linux
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2010-07-10 08:47 UTC by Alexia Death
Modified: 2012-10-07 17:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Badly rendering image (635.11 KB, image/x-xcf)
2010-07-10 09:31 UTC, Alexia Death
Details

Description Alexia Death 2010-07-10 08:47:55 UTC
I have a sample image to go with it.
Comment 1 Alexia Death 2010-07-10 09:31:49 UTC
Created attachment 165609 [details]
Badly rendering image
Comment 2 David Gowers 2010-07-11 10:12:20 UTC
I can confirm this. The implementation of the Color layer mode seems to be the issue. The coloration of the result is actually better (that is, it transfers 'Color' better, in an abstract sense), but the brightness range seems to be compressed (from 0..100 -> 0...93, in terms of LAB color space)

There is also an issue where 'Color'-ized pixels become more solid than their source pixels -- although this may be by design, for layer mode consistency.
Comment 3 Martin Nordholts 2010-07-12 13:23:55 UTC
This was done on purpose, see bug 401754 and bug 325564. We have decided to fix th layer mode problems when we switch to GEGL and GIMP 3.0. Putting on the 2.10 (which should be renamed to GIMP 3.0) milestone so we don't forget to handle these differences for GIMP 3.0.
Comment 4 David Gowers 2010-07-12 14:43:31 UTC
In case I wasn't clear in my comment, this is not merely a difference: the GEGL color op should combine C and H of the covering layer with L of the underlying layer. However, the L channel seems to be clipped to 0..93 during the Color op (so the brightest brights are no longer quite as bright as they should be). .. this could also be caused by a bug in BABL LCH conversion, now that I think of it.
Comment 5 Michael Natterer 2010-07-12 17:30:57 UTC
As I have explained various times now, the way the various gegl-implemented
color layer modes handle alpha is entirely broken. You can't go porter-duff-ish
here. Instead, the layer's alpha and the pixel's alpha combined should
merely modify the stength of the applied effect. This way the layer modes
become useful; actually "alpha" compositing them renders them all useless.
Comment 6 Martin Nordholts 2010-07-12 18:03:12 UTC
@David: Yes you are right, there's a bug here too. Changing back title.

Regarding the alpha compositing model, I would argue that the legacy model is the broken one. But let's not discuss this here.
Comment 7 Alexia Death 2010-07-12 18:11:51 UTC
BTW, Anybody else notice that the icon, displayed on the task bar and in the tab image in SWM for the sample xcf is weird and theres a bright screen circle around the central object?
Comment 8 Martin Nordholts 2010-07-12 18:12:41 UTC
Yes I get that too.
Comment 9 Michael Natterer 2010-07-12 20:36:14 UTC
The legacy way of doing things may be broken, but so is the way the new
ops handle alpha. The legacy stuff at least has the advantage of producing
results that make sense in many cases. The new operations might be
mathematically "correct" in a compositing way, but they are uselsess
for any practical purposes.

The point here is that the layer on top which is in e.g. "color" mode
simply must not change the underlying alpha at all, it must only act
on colors. The old ops don't exactly do that and are clearly broken,
but they at least do something that resembles that.

The gegl color layer modes should do neither the old crap, nor do
something like alpha compositing. They should merely apply an effect
to the underlying colors and let alone alpha. And the strength of that
effect shall be determined by the pixel+layer opacity at each point.

This way they become useful for color corrections, when they do alpha,
they aren't.
Comment 10 Martin Nordholts 2011-03-14 07:13:05 UTC
I will fix this in 2.10, now we need to get 2.8 out. We should probably disable the 'Use GEGL' checkbox in 2.8 anyway. Moving to 2.10 milestone (Note that I renamed the old 2.10 milestone to 3.0)
Comment 11 Michael Natterer 2012-10-07 17:16:25 UTC
All layer modes have been redone as new operations for master, the
code that caused this is gone.