On 09/01/2010 12:12 PM, Øyvind Kolås wrote:
> On Wed, Sep 1, 2010 at 6:35 AM, Martin Nordholts 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 some incom
On Wed, Sep 1, 2010 at 6:35 AM, Martin Nordholts 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 some incompatibilities are OK, in
> which case we don't nee
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
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 r
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 doin
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
___
Gimp-develop
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 abou
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, but have question. Deciding when to
activat
On 24-08-10 11:51, Øyvind Kolås wrote:
On Tue, Aug 24, 2010 at 9:58 AM, Rupert Weber 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 b
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 existin
On Wed, Aug 25, 2010 at 6:41 AM, Sven Neumann wrote:
> 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
On Tue, 2010-08-24 at 22:59 +0200, Sven Neumann wrote:
> 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 conv
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/24/2010 10:59 PM, Sven Neumann wrote:
> It is used by the RGB->Indexed conversion in core/gimpimage-convert.c
Yes, you're right. No clue what I grep'd for before.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.X
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
On Tue, Aug 24, 2010 at 4:30 PM, Rupert Weber 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 to babl a
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/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 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 h
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 app/base
On Tue, Aug 24, 2010 at 1:52 AM, Rupert Weber 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 provides a much su
On Tue, Aug 24, 2010 at 9:58 AM, Rupert Weber 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 function just
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 wit
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 02:52 AM, Rupert Weber 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 provides a much superior API
On Tue, Aug 24, 2010 at 10:22 AM, Rupert Weber 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 provides a much s
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 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
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
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 actual
>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"
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
>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
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 feedba
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
From: Rupert Weber
> 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
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, 'differen
>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
___
Gim
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 n
39 matches
Mail list logo
