On 09/01/2010 12:12 PM, Øyvind Kolås wrote:
On Wed, Sep 1, 2010 at 6:35 AM, Martin Nordholtsense...@gmail.com wrote:
My point was that we either decide that GEGL should render just like
legacy, in which case we would need to implement both kinds of color
layer modes in GEGL, or we decide that
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
On 09/01/2010 02:37 AM, Rupert Weber wrote:
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
I just meant if GEGL
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 Mon, 2010-08-30 at 20:25 +0200, Rupert Weber wrote:
so I've played around with babl a bit, and quite a few questions came
up. Is there a separate babl mailing list?
gegl-developer is the place for discussing babl things.
Sven
___
On 08/30/2010 08:19 PM, Rupert Weber wrote:
On 08/24/2010 07:46 AM, Martin Nordholts wrote:
* Only show the legacy color modes when an image that already
uses them is the active image (we either show all four, even
if an image only uses one).
Haven't got around doing that, yet,
On 24-08-10 11:51, Øyvind Kolås wrote:
On Tue, Aug 24, 2010 at 9:58 AM, Rupert Weberg...@leguanease.org wrote:
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
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 Tue, Aug 24, 2010 at 9:58 AM, Rupert Weber g...@leguanease.org wrote:
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
On Tue, Aug 24, 2010 at 1:52 AM, Rupert Weber g...@leguanease.org wrote:
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
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 10:09 AM, Rupert Weber wrote:
On 08/24/2010 07:46 AM, Martin Nordholts wrote:
I suggest we:
* Only show the legacy color modes when an image that already
uses them is the active image (we either show all four, even
if an image only uses one).
If that's how we do it,
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 Tue, Aug 24, 2010 at 4:30 PM, Rupert Weber g...@leguanease.org wrote:
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
On Tue, 2010-08-24 at 17:06 +0200, Rupert Weber wrote:
I suspect that the code is already triply duplicated now then, the
original GIMP CIE Lab code in app/base/cpercep.c , it's copy in
babl/ectensions/CIE.c and your conversion code.
I'm surprised to find that code in app/base. As you
Hi,
On Tue, 2010-08-24 at 02:52 +0200, Rupert Weber wrote:
The patch is here. Now, and it works. The conversions add 17k of code.
Once GEGL takes over, they'll simply removed again. No one gets hurt.
Well, the problem with your patch is that it adds new public API to
libgimpcolor. And that
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 Tue, Aug 24, 2010 at 10:22 AM, Rupert Weber g...@leguanease.org wrote:
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
On Mon, 2010-08-09 at 15:42 +0200, Rupert Weber wrote:
(2) Separate out the actual conversion routines in gimplibcolor as
a standalone patch.
Maybe change the Decompose plug-in to use those, so we at least
have something to make use of the new conversions.
(as far as I
On 08/09/2010 10:32 PM, Rupert Weber wrote:
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
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
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...
Charlie
___
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
...@leguanease.org
To: gimp-developer@lists.XCF.Berkeley.EDU
Sent: Mon, August 9, 2010 4:45:00 PM
Subject: Re: [Gimp-developer] Getting new layer modes fit for inclusion
On 08/09/2010 04:16 PM, Charlie De wrote:
From Rupert:
(as far as I can tell, the current Decompose Lab functions
Given that decisions made about layer modes will have consequences
for years to come, it strikes me that there is an urgent need for a
formal specification of what is to be done. A natural place to write
one would be the wiki, but since that isn't functioning, maybe it
would be possible to create
On 08/09/2010 03:42 PM, Rupert Weber wrote:
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.
Hi,
As long as you are available to respond to feedback
From Martin:
I think the displayed names should be like above, and the API names
should have a LCH prefix or suffix. I think the old ones should have
display names with (compatibility) appended, and only be shown when an
XCF that uses these modes have been loaded. The API names should
On 08/09/2010 09:08 PM, Charlie De wrote:
From Martin:
I think the displayed names should be like above, and the API names
should have a LCH prefix or suffix. I think the old ones should have
display names with (compatibility) appended, and only be shown when an
XCF that uses these modes
From Martin:
I think the names needs to suggest that new files should avoid using
those layer modes.
Other alternatives:
(compat.)
(legacy)
(obsolete)
(broken)
(old)
Good point! Then (obsolete) is best. The abbreviation of compat. to be
avoided; legacy is too figurative, has
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
33 matches
Mail list logo
