On 10/04/2010 04:17 AM, David Gowers (kampu) wrote:
Try making a flat region of color #2a7e23, selecting Pencil tool,
choosing Color mode and a large brush, and painting #11e500 repeatedly
over the same area.
[...]
In general, you can manifest this bug by picking a dark color,
making a
On 09/14/2010 09:23 PM, yahvuu wrote:
yep, that yields the desired RGB triple 255, 179, 128 for the example under
discussion (i.e. blending red over white using 'color mode').
However, after reading some more code, i'm less than shure it does so for
the right reasons. Same goes with my
From eb812a330b272dd1579093ae7d9d3076c77e652b Mon Sep 17 00:00:00 2001
From: Rupert Weber g...@leguanease.org
Date: Sun, 12 Sep 2010 21:40:19 +0200
Subject: [PATCH] app/gegl: Let GEGL assume sRGB for layer modes
GEGL was using babl's RaGaBaA for color layer modes.
Changed to R'aG'aB'aA for correct
Just discovered that the clipping in the new layer modes needs more work.
It's not a problem with colors that originated in sRGB, but the layer
modes can easily construct colors outside sRGB, or even
invisible/virtual colors.
The current behavior is different from floating point/GEGL
On 09/12/2010 11:37 AM, Rupert Weber wrote:
Just discovered that the clipping in the new layer modes needs more work.
Problem solved.
Not reposting the patch for now to keep the noise down, as I'm sure
there will be other small issues.
Rupert
About bablizing the layer modes: I spent a little time with babl and all
I can say right now is that it will definitely take a while to get that
done.
So far it's been like a set of Russian puppets, and I don't think I've
even reached the innermost yet.
I wouldn't dare to give an estimate, but
On 09/06/2010 09:17 PM, Sven Neumann wrote:
I am not so happy about the choice of the term obsolete. The old layer
modes are not obsolete. I'd suggest to use the term legacy instead.
I'm ok with either.
The obsoleteness is what I tried to find out earlier. Right now GEGL
doesn't support the
Hi,
just wanted to get this out before another week passes, as I probably
won't be getting to it before next weekend (or maybe the odd sleepless
night).
I posted an update to the patch to
https://bugzilla.gnome.org/show_bug.cgi?id=325564
which now hides the old layer modes unless they
On 08/30/2010 09:34 PM, Martin Nordholts wrote:
Is it decided that GEGL will not support the legacy modes, or should
they be implemented in GEGL as well to retain backward compatability?
There is one big issue left to settle: whether e.g. a Screen pixel
composited onto nothing should result
so I've played around with babl a bit, and quite a few questions came
up. Is there a separate babl mailing list?
Getting the conversions symmetric is possible, but at a cost. Without
any other changes, increasing the bits from 16 to 20 gives perfect
round-trip accuracy, but it also becomes
On 08/24/2010 11:11 PM, Sven Neumann wrote:
And no, I didn't ask you to work on the GEGL modes, I just ask you (or
actually anyone) to use and improve babl when it comes to pixel format
conversions.
Maybe I'm just paranoid, but I'm afraid that might turn out to be
equivalent.
Using existing
On 08/24/2010 07:46 AM, Martin Nordholts wrote:
With your patch applied, there are two variants of the color-related
layer modes. Legacy and obsolete broken variants that new images don't
need, and your correct useful new variants.
We are working hard on improving the UI, and having two
On 08/24/2010 04:20 AM, David Gowers wrote:
I hope you're not associating the quite suboptimal way in which GIMP
currently uses GEGL, with BABL's speed or lack of speed.
BABL just processes raw pixel buffers. A converter function just
accepts a source and a destination pointer, along with a
On 08/24/2010 12:21 PM, Øyvind Kolås wrote:
Such an error should be unacceptable, the conversion code for CIE Lab
in babl are symmetric.
and the problems begin... that's what I meant
I suspect that the code is already triply duplicated now then, the
original GIMP CIE Lab code in
On 08/24/2010 04:20 AM, David Gowers wrote:
I hope you're not associating the quite suboptimal way in which GIMP
currently uses GEGL, with BABL's speed or lack of speed.
Just did a quick test:
1Mio random pixels passed to babl as one buffer (=one function call) vs.
passing the same buffer
On 08/24/2010 05:21 PM, Martin Nordholts wrote:
I imagine the solution to be along the lines of:
[...]
Cool, thanks. That gives me a good headstart.
But I probably won't be able to dive in there before the weekend.
* Add the obsolete layer modes after the new layer modes in the
paint
On 08/22/2010 02:45 PM, Sven Neumann wrote:
New code in GIMP should use babl for pixel format conversion. There's no
need to introduce new API for that as we have babl which is available to
the core and plug-ins and provides a much superior API.
The short answer is: No. I won't do that.
For
On 08/15/2010 08:14 AM, David Gowers wrote:
(which, while being auto-generated, also change infrequently enough
that they *are* version-controlled),
have not been included.
Ha, and I went out of my way to keep them out of the patch... ;o)
I suggest merging these changes with the patch to
I posted an amended version of the layermode patch, which is the one
that changes the enums (not the libgimp one).
I'm sorry, looking back at the messages I left on bugzilla, it was
extremely unclear which patch is which -- thus starting the confusion.
Hopefully someone will be able to
There are still some issues that I either blissfully ignored or took the
least-cost route on:
(1) enums and gimp-composite
While the values of legacy layer mode enums are preserved,
gimp-composite.h has its own GIMP_COMPOSITE_* enums which append some
modes to the layer mode list.
I posted a new version (v3) of the layer modes patch (split in two) to
http://bugzilla.gnome.org/show_bug.cgi?id=325564
The libgimp functions and the layer mode stuff are each in a separate
patch now.
[The message I wrote there is misleading. along with the other v3
patch was just
Thanks a lot for all the input.
I have been using the matrices from
http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html *)
and thought I was doing sRGB/D65-to-Lab or sRGB/D50-to-Lab.
But as I understand now, I was actually doing sRGB-to-Lab/D65 or /D50;
while all the RGB spaces
On 08/11/2010 11:20 PM, yahvuu wrote:
Me, too, thinks that sRGB is a reasonable assumption. If you want to Do It
Right(tm),
you will have to take the image's color profile into account. Since most, if
not all
8-bit implementations of color operations are agnostic of the current color
On 08/12/2010 12:32 AM, James Cox wrote:
sRGB has only been around since 1996. I suspect that the gimp version
dates from before that, or at least before sRGB came into common use.
That would certainly explain it.
I don't think we want our color profiles to affect layer blending, so I
think
Can of worms...
A second attempt at summary and proposed action:
1. D50 vs D65 doesn't make any difference as long as Lab values aren't
communicated to the outside. (E.g. by saving to a file or by having a
Lab color picker)
2. The 'natural' conversion for sRGB seems to be D65. So I'll use
Regarding BABL: i've had a look at extensions/CIE.c and found conversion
routines
using linear light RGB with the sRGB primaries and white point -- that is
scRGB.
Everything fine here.
Now i'm not familier with BABL -- possibly i've checked at the wrong routines?
What I found was
On 08/12/2010 03:41 PM, yahvuu wrote:
[...]
So, i think GIMP should Get It Right for GEGL processing, while certain
deviations of
operations' characteristics are tolerable for 8-bit processing.
Fine with me.
Regards
Rupert
___
Gimp-developer
Disclaimer: I am not a color buff. Anybody who actually *knows* about
that stuff, please chime in.
PAL/SECAM vs sRGB
=
While writing the Lab/LCH layer mode stuff, I wondered so far why the
result is still slightly different from the current GEGL implementation
of
Hi,
while the last patch I posted* to
http://bugzilla.gnome.org/show_bug.cgi?id=325564
is of course outdated already, I think it's time to think about how to
ever get this included.
My suggestion:
(1) Completely drop the xcf enum conversions (xcf-util.*) I introduced.
They are not
On 08/09/2010 04:16 PM, Charlie De wrote:
From Rupert:
(as far as I can tell, the current Decompose Lab functions are
broken, anyway).
What makes you say that? And how severe is the problem?
Right this minute I'm writing a script with LAB Decompose...
Well, 'different' might
On 08/09/2010 05:50 PM, Charlie De wrote:
Actually, I see it, now that the script is done and the tests can be performed
without bruising my knuckles. It isn't as bad as the Color mode, but it's
there. Decomposing and recomposing an unaltered layer copy of an image
changes
the colours a
On 08/09/2010 07:42 PM, Martin Nordholts wrote:
As long as you are available to respond to feedback about the patch, it
will be included into 2.8, don't worry. It's just that it might take a
while before anyone gets around to review and test it properly.
Oh, cool.
Just, before anyone actually
On 08/08/2010 09:22 AM, Charlie De wrote:
I'm not so good at understanding patches and things... If this is accepted,
would it mean it would be available natively, without GEGL projection?
Yes, it's completely independent from GEGL.
Since LAB uses a perception-based definition of lightness,
Just uploaded a revised layer mode patch to
http://bugzilla.gnome.org/show_bug.cgi?id=325564
Good news:
- is about as fast as the legacy modes
- adds Lab Burn mode
The Lightness mode is really cool, because it effectively gives you Lab
contrast/brightness control:
- duplicate your
Hello there,
recently I got sucked somehow into supplying a small patch for GIMP (all
I ever meant to do was to report a bug...). -- and thank you to Sven,
who remained very friendly and patient, despite me getting it all wrong
the first cpuple attempts.
So now that I licked blood I wanted to
[ Ok, so I'm daring to repost my previuos mail again, which obviosly
didn't make it...]
I wrote a patch that might help fix the situation.
First, I don't consider the current Color layer mode as broken. It is
just different from what many users will expect.
What I do consider broken, though,
On 08/03/2010 10:04 PM, Charlie De wrote:
[...] For that reason I've previously proposed what to me
seems to be the cheapest solution - offer the fix as a compile option in an
incremental bug release in the stable branch.
But if someone compiles from source anyway, it's probably easier to
37 matches
Mail list logo
