Sent: 2010-08-09 15:42:43 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 needed anymore and, quite frankly, pointless right now.
This cuts down the patch a bit and means no new files added.
(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 can tell, the current Decompose Lab functions are
broken, anyway).
(3) Once gimplibcolor updates are all settled, go about adding new layer
modes which make use of them.
(a) decide, which modes. Be conservative, don't clutter the menu
too much with modes that nobody needs. Once they are out, we
can't take them back.
(b) decide how to name them.
(c) decide how to deal with storing them (XCF version++)

What do you say?

Regards,
Rupert

* I posted a second version there, but it might not be the right place
to clutter with in-development patches.
Is there a better way to publish those? Should I setup some webspace
and host them there? That way I could publish both, incremental and
against-master patches.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 16:16:42 UTC (over 1 year ago)

From: Charlie De

Getting new layer modes fit for inclusion

permalink

>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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 16:45:00 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 have been nicer than 'broken' -

The conversion doesn't account for gamma:
http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html

As a result, the L* channel is very light (check the histogram). I have
no clue how that influences a* and b*.

Also, it uses the conversion matrix for PAL/SECAM RGB. (Maybe PAL/SECAM
has gamma 1.0? Then the missing gamma correction would be correct.)
http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html

Anyway, unless your image is in PAL/SECAM RGB, the conversion in
Decompose is incorrect.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 17:50:25 UTC (over 1 year ago)

From: Charlie De

Getting new layer modes fit for inclusion

permalink

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 little. Having two layers, top blurred, and bringing into it the
L component of the lower layer, accentuates noise somewhat, not as badly as the
Color mode. Iterating this procedure a number of times on the blurred layer,
however, soon breaks down the image, with severe colour artifacts.

Good news: the YCbCr_ITU_R709 decomposition works much better. Iteration tests
brought no breakdown. The test on an unaltered layer copy of original also
doesn't alter colours.

A commenter in the original bug report about the Color mode did say the R709
worked well in his tests.

Charlie

----- Original Message ----
> 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 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 have been nicer than 'broken' -
>
> The conversion doesn't account for gamma:
> http://www.brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html
>
> As a result, the L* channel is very light (check the histogram). I have
> no clue how that influences a* and b*.
>
> Also, it uses the conversion matrix for PAL/SECAM RGB. (Maybe PAL/SECAM
> has gamma 1.0? Then the missing gamma correction would be correct.)
> http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
>
> Anyway, unless your image is in PAL/SECAM RGB, the conversion in
> Decompose is incorrect.
>

_______________________________________________
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
>

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 17:53:44 UTC (over 1 year ago)

From: Bill Skaggs

Getting new layer modes fit for inclusion

permalink

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 a collaborative Google Docs document
and use it to work out a spec?

-- Bill

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 18:01:07 UTC (over 1 year ago)

From: Rupert Weber

Lab Decompose

permalink

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 little.

That's rather due to rounding and not a bug. Lab and 8-bit don't play
well together. But the Decompose plug-in has no other choice than to
squeeze the result into 8-bit. (It *might* be augmented by the unusual
assumption of PAL/SECAM input, but that'd be more of a coincidence.)

Other than that, decompose and recompose are consistent.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 19:36:01 UTC (over 1 year ago)

From: Martin Nordholts

Getting new layer modes fit for inclusion

permalink

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 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.

> My suggestion:
> (1) Completely drop the xcf enum conversions (xcf-util.*) I introduced.
> They are not needed anymore and, quite frankly, pointless right now.
> This cuts down the patch a bit and means no new files added.

Sounds good.

> (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 can tell, the current Decompose Lab functions are
> broken, anyway).

Having conversion routines in a separate patch is reasonable. If
Decompose is broken, a separate patch to fix it would also be good.

> (3) Once gimplibcolor updates are all settled, go about adding new layer
> modes which make use of them.
> (a) decide, which modes. Be conservative, don't clutter the menu
> too much with modes that nobody needs. Once they are out, we
> can't take them back.

CIE LCH based Hue, Saturation, Color and Lightness, right?

> (b) decide how to name them.

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 remain
as is.

> (c) decide how to deal with storing them (XCF version++)

Didn't we already say that the XCF version should be bumped?

Regards,
Martin

--

My GIMP Blog:
http://www.chromecode.com/
"Automatic tab style and removed tab title bar"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 21:08:03 UTC (over 1 year ago)

From: Charlie De

Getting new layer modes fit for inclusion

permalink

>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 remain
> as is.

"(compatibiity)" makes sense but might be a bit too long. Wouldn't "(Old)" or
"(HSB)" be better?

Charlie

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 21:17:24 UTC (over 1 year ago)

From: Martin Nordholts

Getting new layer modes fit for inclusion

permalink

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 have been loaded. The API names should remain
>> as is.
>
> "(compatibiity)" makes sense but might be a bit too long. Wouldn't "(Old)" or
> "(HSB)" be better?

I think the names needs to suggest that new files should avoid using
those layer modes.

Other alternatives:

"(compat.)"
"(legacy)"
"(obsolete)"
"(broken")
"(old)"

/ Martin

--

My GIMP Blog:
http://www.chromecode.com/
"Automatic tab style and removed tab title bar"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 22:30:47 UTC (over 1 year ago)

From: Charlie De

Getting new layer modes fit for inclusion

permalink

>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 slightly wrong connotations; "broken",
though technically correct, is too negative to be in the interface; "old"
doesn't suggest enough that the old modes are obsolete. Since these names will
only appear when old files are loaded, the more technical nature of "obsolete"
is better. Can we all agree on "(Obsolete)"?

Charlie

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-09 22:32:14 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 dives in that code, please ask me for the
most recent version, as I don't want to spam the bugzilla page with
daily updates.

>> (a) decide, which modes. Be conservative, don't clutter the menu
>
> CIE LCH based Hue, Saturation, Color and Lightness, right?

Well, yes. But what about e.g. Dodge, Burn, or Soft Light? D/B are easy
to do and make sense. SL is not so easy, don't know if it even makes sense.
But I'm also ok with sticking to those 4 obvious ones. And D/B ;=)

>> (c) decide how to deal with storing them (XCF version++)
>
> Didn't we already say that the XCF version should be bumped?

yes, I just wasn't sure how final that was. Good.

Rupert

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-10 08:11:50 UTC (over 1 year ago)

From: Martin Nordholts

Getting new layer modes fit for inclusion

permalink

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 properly.
>
> Oh, cool.
> Just, before anyone actually dives in that code, please ask me for the
> most recent version, as I don't want to spam the bugzilla page with
> daily updates.

I suggest you update the patch on, say, a weekly basis. No open source
project minds being spammed with patches :)

>
>>> (a) decide, which modes. Be conservative, don't clutter the menu
>>
>> CIE LCH based Hue, Saturation, Color and Lightness, right?
>
> Well, yes. But what about e.g. Dodge, Burn, or Soft Light? D/B are easy
> to do and make sense. SL is not so easy, don't know if it even makes sense.
> But I'm also ok with sticking to those 4 obvious ones. And D/B ;=)

I don't get, we already have working Dodge, Burn and Soft Light, don't we?

/ Martin

--

My GIMP Blog:
http://www.chromecode.com/
"Automatic tab style and removed tab title bar"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-22 14:45:36 UTC (over 1 year ago)

From: Sven Neumann

Getting new layer modes fit for inclusion

permalink

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 can tell, the current Decompose Lab functions are
> broken, anyway).
> (3) Once gimplibcolor updates are all settled, go about adding new layer
> modes which make use of them.
> (a) decide, which modes. Be conservative, don't clutter the menu
> too much with modes that nobody needs. Once they are out, we
> can't take them back.
> (b) decide how to name them.
> (c) decide how to deal with storing them (XCF version++)

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. If your
optimized routines turn out to outperform the CIE Lab sRGB
conversions that are in babl right now, then your code should be added
to babl.

Sven

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 02:52:11 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 the long answer see further down below. (Sorry if this post becomes
a bit longish)

First about the current state of affairs:
I posted the last update to the patch to
http://bugzilla.gnome.org/attachment.cgi?bugid=325564

From my point of view, it is now done.

Some performance numbers, comparing redraw times of legacy modes to the
new LCH modes and to current GEGL LCH modes:
(Tested with a very large picture to get measurable numbers; still these
are ca. numbers, obtained with a stop watch)

Mode | Legacy | New LCH | GEGL/babl
-------------+--------+---------+----------
Hue | 3.6 | 6.4 | 396
Saturation | 4.6 | 6.2 | 405
Color | 4.7 | 4.1 | 431
Value/Lightn.| 3.5 | 4.1 | 416

So I'm in the ball park of the legacy modes, Color is even a little
faster. Compared to current GEGL/babl the new modes are about 60 to 100
times faster. (Yes, no typo)

As to accuracy, these are the round-trip pixel errors for Lab and LCH
conversions:
Error after round-trip [in 8bit RGB space]:
L*a*b* L*C*H*
0: 16561783 ( 98.716%) 0: 16527659 ( 98.513%)
1: 214941 ( 1.281%) 1: 248244 ( 1.480%)
2: 492 ( 0.003%) 2: 1313 ( 0.008%)
3: 0 ( 0.000%) 3: 0 ( 0.000%)

The worst we get are off-by-two errors. You won't notice without
diff'ing two layers.
If you don't just stack no-op layers on top of each other, out-of-gamut
errors will be *far* greater than these.

So, as I already said, I consider the patch done now.

Things I will still be glad to change:
- Location/name of new file, name of exported functions, etc.
- Any bug fixes, of course.
- The open issues I had mentioned earlier (file formats,
GIMP_COMPOSITE_BLEND et al.)

Things I won't change:
- Optimization. I currently see no further optimization potential
without uglifying the code.
- As to putting the conversion outside the loop: Yes it can be done,
but even if it is done, it doesn't belong in this patch.
The current implementation in gimp_composite_generic.c is symmetric
to the existing layer modes. So any such un-looping would be a
general change to that file, not specific to the new layer modes.
- Inlining: Brutally inlining everything can be done and gives some
12%-15% performance increase. -- But I don't want to get my hands
dirty with that.. :o)

And then there is babl.
I feel very bad about that request. Because I expect it to be the first
step in a relatively short sequence of if-we-do-that-why-don't-we's that
will end with these modes not getting in but rather be added to the GEGL
agenda.
As that is effectively what you are asking me to do: work on the GEGL
modes instead (or duplicate them, which would be even sillier).
But that is not what I signed up for. The idea was to get something done
and usable now. Not something that will be great in some uncertain future.

When this is done I will be glad to take a look at babl and see if the
conversions can somehow be integrated. But I don't expect that to be a
trivial task.

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.

Regards

Rupert

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 04:20:05 UTC (over 1 year ago)

From: David Gowers

Getting new layer modes fit for inclusion

permalink

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 superior API.
>
> The short answer is: No. I won't do that.
> For the long answer see further down below. (Sorry if this post becomes
> a bit longish)
>
> First about the current state of affairs:
> I posted the last update to the patch to
>        http://bugzilla.gnome.org/attachment.cgi?bugid=325564
>
>  From my point of view, it is now done.
>
> Some performance numbers, comparing redraw times of legacy modes to the
> new LCH modes and to current GEGL LCH modes:
> (Tested with a very large picture to get measurable numbers; still these
> are ca. numbers, obtained with a stop watch)
>
> Mode         | Legacy | New LCH | GEGL/babl
> -------------+--------+---------+----------
> Hue          |  3.6   |   6.4   |   396
> Saturation   |  4.6   |   6.2   |   405
> Color        |  4.7   |   4.1   |   431
> Value/Lightn.|  3.5   |   4.1   |   416
>
> So I'm in the ball park of the legacy modes, Color is even a little
> faster. Compared to current GEGL/babl the new modes are about 60 to 100
> times faster. (Yes, no typo)

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 pixel count,
and should convert that number of pixels. It doesn't have any heavy
architecture or processing, aside from what may be in each individual
converter function

looking at your code in gimpcolorspace.c, making that code work with
BABL looks like it's pretty much a case of cut+paste, modify the way
the input is referred to, add some registration code.

(getting your layer mode code to USE that, is a different issue, and I
agree that would be non-trivial, although you might get significant
speed gains from it because of greatly reduced function call overhead
-- probably about as much as you describe for inlining below.)

>
> As to accuracy, these are the round-trip pixel errors for Lab and LCH
> conversions:
> Error after round-trip [in 8bit RGB space]:
>  L*a*b*                          L*C*H*
>  0:   16561783 (  98.716%)      0:   16527659 (  98.513%)
>  1:     214941 (   1.281%)      1:     248244 (   1.480%)
>  2:        492 (   0.003%)      2:       1313 (   0.008%)
>  3:          0 (   0.000%)       3:          0 (   0.000%)
>
> The worst we get are off-by-two errors. You won't notice without
> diff'ing two layers.
> If you don't just stack no-op layers on top of each other, out-of-gamut
> errors will be *far* greater than these.
>
> So, as I already said, I consider the patch done now.
>
> Things I will still be glad to change:
> - Location/name of new file, name of exported functions, etc.
> - Any bug fixes, of course.
> - The open issues I had mentioned earlier (file formats,
>   GIMP_COMPOSITE_BLEND et al.)
>
> Things I won't change:
> - Optimization. I currently see no further optimization potential
>   without uglifying the code.
>   - As to putting the conversion outside the loop: Yes it can be done,
>     but even if it is done, it doesn't belong in this patch.
>     The current implementation in gimp_composite_generic.c is symmetric
>     to the existing layer modes. So any such un-looping would be a
>     general change to that file, not specific to the new layer modes.
>   - Inlining: Brutally inlining everything can be done and gives some
>     12%-15% performance increase. -- But I don't want to get my hands
>     dirty with that.. :o)
>
> And then there is babl.
> I feel very bad about that request. Because I expect it to be the first
> step in a relatively short sequence of if-we-do-that-why-don't-we's that
> will end with these modes not getting in but rather be added to the GEGL
> agenda.
> As that is effectively what you are asking me to do: work on the GEGL
> modes instead (or duplicate them, which would be even sillier).

GEGL modes are something else. I believe what Sven was suggesting is
to implement your conversion code in a BABL extension, and use that to
do color conversion in the layer modes; Not to use GEGL for that whole
thing.

That said...

> But that is not what I signed up for. The idea was to get something done
> and usable now. Not something that will be great in some uncertain future.
>
> When this is done I will be glad to take a look at babl and see if the
> conversions can somehow be integrated. But I don't expect that to be a
> trivial task.
>
> 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.

I absolutely agree that this patch should be applied promptly.
It implements much-wanted functionality in an effective and efficient way.
Separating the new color conversions into their own file in
app/composite/ is a smart idea, it will make later BABL migration
easy.

I only have one thing to criticize about this patch: It adds a single
whitespace error :)

[at the end of app/composite/gimp-lab-lch.c, there is an extra
newline. Whoever commits it can easily amend the commit before pushing
it, though, so basically a non-issue]

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 07:38:55 UTC (over 1 year ago)

From: Martin Nordholts

Getting new layer modes fit for inclusion

permalink

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.
>
> The short answer is: No. I won't do that.
> For the long answer see further down below. (Sorry if this post becomes
> a bit longish)

Hi Rupert

Thanks a lot for your hard work, it is much appreciated. Personally I am
fine with not having your new conversion routines ported to babl yet, we
can do that later.

It is my firm belief however that it is too early to apply the patch.
There are usability aspects that needs to be taken care of first, that
has been mentioned before.

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 variants of the
same layer mode always available, where one is broken and one works, is
simply not good enough.

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).

* Add an "(obsolete)" suffix to the legacy ones (only shown in
the UI, not in the API)

* Remove the "(LCH)" suffix in your new layer modes (only
in the UI, not in the API)

Disclaimer:
I haven't reviewed your latest patch so there might be things we need to
address there too.

Best regards,
Martin

--

My GIMP Blog:
http://www.chromecode.com/
"Automatic tab style and removed tab title bar"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 10:09:19 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 variants of the
> same layer mode always available, where one is broken and one works, is
> simply not good enough.
>
> 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).
>
> * Add an "(obsolete)" suffix to the legacy ones (only shown in
> the UI, not in the API)
>
> * Remove the "(LCH)" suffix in your new layer modes (only
> in the UI, not in the API)
>

Yes, I almost forgot about that. I always considered the names so far as
working titles only.

What you suggest seems reasonable to me. (And the current GEGL modes
suggest that dropping the old modes is the intended route, anyway).

If that's how we do it, I'll need a little help, as I have no UI/Gtk
experience. Or maybe at least a pointer where to look at / which way to
go. I could imagine having two prebuilt menus which are swapped vs.
dynamically adding removing items. -- The toolbox dropdown for the
painting mode should probably never change.
(And if someone says, "hey that's easy, I'll do that in a couple of
minutes", please, don't let me stop you :) )

Rupert

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 10:58:51 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 pixel count,
> and should convert that number of pixels. It doesn't have any heavy
> architecture or processing, aside from what may be in each individual
> converter function
>
> looking at your code in gimpcolorspace.c, making that code work with
> BABL looks like it's pretty much a case of cut+paste, modify the way
> the input is referred to, add some registration code.
>
> (getting your layer mode code to USE that, is a different issue, and I
> agree that would be non-trivial, although you might get significant
> speed gains from it because of greatly reduced function call overhead
> -- probably about as much as you describe for inlining below.)

As I indicated, I'll be happy to make the babl integration of those
conversions my next little project, but I also expect a bunch of
questions to come up in the process (color management comes to mind).

On the other hand I see bablification of gimp_composite_* as part of a
general overhaul of that code, not limited to the LCH layer modes. And
that raises the question if that makes sense or if that time wouldn't be
better spent on the GEGL modes.

> I only have one thing to criticize about this patch: It adds a single
> whitespace error :)

Ha, I believe 'single' is a new positive record for me... :o)

Regards

Rupert

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 11:51:21 UTC (over 1 year ago)

From: Øyvind Kolås

Getting new layer modes fit for inclusion

permalink

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
>> accepts a source and a destination pointer, along with a pixel count,
>> and should convert that number of pixels. It doesn't have any heavy
>> architecture or processing, aside from what may be in each individual
>> converter function
>>
>> looking at your code in gimpcolorspace.c, making that code work with
>> BABL looks like it's pretty much a case of cut+paste, modify the way
>> the input is referred to, add some registration code.
>>
>> (getting your layer mode code to USE that, is a different issue, and I
>> agree that would be non-trivial, although you might get significant
>> speed gains from it because of greatly reduced function call overhead
>> -- probably about as much as you describe for inlining below.)
>
> As I indicated, I'll be happy to make the babl integration of those
> conversions my next little project, but I also expect a bunch of
> questions to come up in the process (color management comes to mind).

Color management does not have much to do with this, since the pixels
are already assumed to be in a well defined pixel format and color
space. Babl is nothing more than a collection of conversion functions,
meta data about the color spaces and data types used and the ability
to assess the conversion speed and quality of these conversions at
runtime. Thus as long as the claim as to what pixel format a buffer is
in is correct, use of babl is correctly color managed.

/Øyvind K.

--
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 12:21:02 UTC (over 1 year ago)

From: Øyvind Kolås

Getting new layer modes fit for inclusion

permalink

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 superior API.
>
> The short answer is: No. I won't do that.
> For the long answer see further down below. (Sorry if this post becomes
> a bit longish)
>
> First about the current state of affairs:
> I posted the last update to the patch to
>        http://bugzilla.gnome.org/attachment.cgi?bugid=325564
>
>  From my point of view, it is now done.
>
> Some performance numbers, comparing redraw times of legacy modes to the
> new LCH modes and to current GEGL LCH modes:
> (Tested with a very large picture to get measurable numbers; still these
> are ca. numbers, obtained with a stop watch)
>
> Mode         | Legacy | New LCH | GEGL/babl
> -------------+--------+---------+----------
> Hue          |  3.6   |   6.4   |   396
> Saturation   |  4.6   |   6.2   |   405
> Color        |  4.7   |   4.1   |   431
> Value/Lightn.|  3.5   |   4.1   |   416
>
> So I'm in the ball park of the legacy modes, Color is even a little
> faster. Compared to current GEGL/babl the new modes are about 60 to 100
> times faster. (Yes, no typo)

Due to the hacky way it is implemented, to enable using the GEGL code
paths alongside the legacy code paths without breaking the legacy code
paths. Additional conversions back and forth between 8bit and 32bit
float are needed, and the processing is not done in non-optimal
amounts.

> As to accuracy, these are the round-trip pixel errors for Lab and LCH
> conversions:
> Error after round-trip [in 8bit RGB space]:
>  L*a*b*                          L*C*H*
>  0:   16561783 (  98.716%)      0:   16527659 (  98.513%)
>  1:     214941 (   1.281%)      1:     248244 (   1.480%)
>  2:        492 (   0.003%)      2:       1313 (   0.008%)
>  3:          0 (   0.000%)       3:          0 (   0.000%)
>
> The worst we get are off-by-two errors. You won't notice without
> diff'ing two layers.
> If you don't just stack no-op layers on top of each other, out-of-gamut
> errors will be *far* greater than these.

Such an error should be unacceptable, the conversion code for CIE Lab
in babl are symmetric.

> So, as I already said, I consider the patch done now.
> And then there is babl.
> I feel very bad about that request. Because I expect it to be the first
> step in a relatively short sequence of if-we-do-that-why-don't-we's that
> will end with these modes not getting in but rather be added to the GEGL
> agenda.
> As that is effectively what you are asking me to do: work on the GEGL
> modes instead (or duplicate them, which would be even sillier).
> But that is not what I signed up for. The idea was to get something done
> and usable now. Not something that will be great in some uncertain future.
>
> When this is done I will be glad to take a look at babl and see if the
> conversions can somehow be integrated. But I don't expect that to be a
> trivial task.
>
> 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.

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.

If you add your conversion code to babl as well it will be picked
instead of the existing conversion, if it is both symmetric and faster
than the existing implementations.

/Øyvind K.

--
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 17:06:23 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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/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 say, it's the same
as in babl.
But I don't see that code being called from anywhere within GIMP. Why is
it even there?
It seems we can reduce by one copy then. ;)

> If you add your conversion code to babl as well it will be picked
> instead of the existing conversion, if it is both symmetric and faster
> than the existing implementations.

But it isn't fully symmetric. For the intended purpose, i.e. conversion
from/to 8bit RGB, that's not a problem. For a more general purpose
routine, it might be.
So while the integer conversions might be portable to babl in some way
shape or form, it won't be a simple 1:1 copy/paste.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 17:14:10 UTC (over 1 year ago)

From: Martin Nordholts

Getting new layer modes fit for inclusion

permalink

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, I'll need a little help, as I have no UI/Gtk
> experience.

I imagine the solution to be along the lines of:

1. Adding a new function to app/core/gimpimage.c
called gimp_image_uses_obsolete_layer_modes()
2. Add a with_obsolete_modes boolean parameter to
gimp_paint_mode_menu_new()
3. Create two variants of the paint mode menu, one with and
one without the obsolete modes, in gimp_layer_tree_view_init()
4. Show the correct version in of the paint mode menu in
gimp_layer_tree_view_set_image() based on return result of
gimp_image_uses_obsolete_layer_modes()

An additonal comment:

* Add the obsolete layer modes after the new layer modes in the
paint mode menu, your latest patch has the old ones before the
new ones, but the new ones are the most relevant

/ Martin

--

My GIMP Blog:
http://www.chromecode.com/
"Automatic tab style and removed tab title bar"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 17:30:43 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 pixel by pixel (=1Mio calls) to the integer
conversions.
babl still comes out 35x slower.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 18:22:07 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 mode menu, your latest patch has the old ones before the
> new ones, but the new ones are the most relevant
Agreed.

Rupert

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 19:19:27 UTC (over 1 year ago)

From: Øyvind Kolås

Getting new layer modes fit for inclusion

permalink

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 as one buffer (=one function call) vs.
> passing the same buffer pixel by pixel (=1Mio calls) to the integer
> conversions.
> babl still comes out 35x slower.

This is expected since there are no additional fast paths in babl for
the specific conversion you probably used. At the moment babl will
have to do quite a bit of internal work going via double precision
floats and manually permuting components.

The purpose of babl is to provide an API that provides correct color
conversions and allows accelerating these with extensions that are
conformance tested and performance ranked at runtime. Your integer
code could be added as such an extension and will be chosen
automatically if it is good enough (or if the environment variable
BABL_TOLERANCE is set to for instance 0.02 or higher, indicating that
babl shouldnt be as strict about which fast paths are permitted.)

Fast conversions added to babl do not only benefit the conversion of
the implemented source/target pixelformats since babl can also string
together such conversions in a chain).

/Øyvind K.
--

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 22:59:52 UTC (over 1 year ago)

From: Sven Neumann

Getting new layer modes fit for inclusion

permalink

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 say, it's the same
> as in babl.
> But I don't see that code being called from anywhere within GIMP. Why is
> it even there?

It is used by the RGB->Indexed conversion in core/gimpimage-convert.c

Sven

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 23:11:23 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 23:11:41 UTC (over 1 year ago)

From: Sven Neumann

Getting new layer modes fit for inclusion

permalink

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 will hurt us pretty badly. We will have to
maintain that API for a couple of releases and I would really like to
avoid that. Plug-ins will start to use it and that code will pretty soon
have to be converted to use babl then.

Instead of adding more pixel conversion routines to libgimpcolor, all of
libgimpcolor should be deprecated as soon as possible and all users
should be converted to use babl instead. Otherwise we will stick with
our legacy APIs forever.

Unfortunately I can't access bugzilla.gnome.org at the moment (seems to
be a temporary server problem), so I can't review your patch in detail.
I really don't want to stand in the way of this patch, but I strongly
suggest that we go the road of deprecating libgimpcolor asap instead of
extending it further.

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.

Sven

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-24 23:45:22 UTC (over 1 year ago)

From: Sven Neumann

Getting new layer modes fit for inclusion

permalink

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 conversion code.
> >
> > I'm surprised to find that code in app/base. As you say, it's the same
> > as in babl.
> > But I don't see that code being called from anywhere within GIMP. Why is
> > it even there?
>
> It is used by the RGB->Indexed conversion in core/gimpimage-convert.c

Oh, and also by the SIOX algorithm in base/siox.c

Sven

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-25 01:53:02 UTC (over 1 year ago)

From: David Gowers

Getting new layer modes fit for inclusion

permalink

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 patch is that it adds new public API to
> libgimpcolor.
Actually, AFAICS the latest version of the patch does not.
It adds the API in it's own file in app/composite/ , which as I noted,
should make adopting it to babl painless, and doesn't expose it to
plugins.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-26 02:12:05 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 babl is out of the question because it is just way too slow.
Leaves improving babl, which I will be glad to do (or attempt) next. I
just don't expect that to be a quickie. Some questions already came up
and I'm sure there will be more. The algorithms will probably have to be
twiddled with, maybe just a few more bits precision, maybe some floating
point/integer/LUT combination -- I just don't know yet.
Once that's done, all current Lab conversions in GIMP can easily be
ported to babl.
If it turns out I'm wrong and it's much easier and quicker than I
anticipate -- fantastic. Throw those conversion right back out and it's
babl all the way.
If I'm not, then it's a feature that could have been.

Regards

Rupert

PS: As David already noted, the last patch doesn't have the conversions
in libgimpcolor anymore -- so no additional API.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-28 20:03:50 UTC (over 1 year ago)

From: Geert Jordaens

Getting new layer modes fit for inclusion

permalink

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 buffers. A converter function just
>>> accepts a source and a destination pointer, along with a pixel count,
>>> and should convert that number of pixels. It doesn't have any heavy
>>> architecture or processing, aside from what may be in each individual
>>> converter function
>>>
>>> looking at your code in gimpcolorspace.c, making that code work with
>>> BABL looks like it's pretty much a case of cut+paste, modify the way
>>> the input is referred to, add some registration code.
>>>
>>> (getting your layer mode code to USE that, is a different issue, and I
>>> agree that would be non-trivial, although you might get significant
>>> speed gains from it because of greatly reduced function call overhead
>>> -- probably about as much as you describe for inlining below.)
>> As I indicated, I'll be happy to make the babl integration of those
>> conversions my next little project, but I also expect a bunch of
>> questions to come up in the process (color management comes to mind).
> Color management does not have much to do with this, since the pixels
> are already assumed to be in a well defined pixel format and color
> space. Babl is nothing more than a collection of conversion functions,
> meta data about the color spaces and data types used and the ability
> to assess the conversion speed and quality of these conversions at
> runtime. Thus as long as the claim as to what pixel format a buffer is
> in is correct, use of babl is correctly color managed.
>
> /Øyvind K.
Well how well defined is the format that babl receives and sends back.

According to the web page at :
http://www.gimp.org/release-notes/gimp-2.4-cm.html.
The intent is to work in Gimp using the sRGB color space, however one
can ignore this.
On the other side there babl is supposed to work in scRGB
(http://www.gegl.org/babl).

Maybe I didn't look hard enough but I didn't find a real conversion from
sRGB(8bit) to scRGB(16bit),
neigther in GIMP nor in babl as described in
*http://www.colour.org/tc8-05/Docs/colorspace/61966-2-2NPa.pdf.*

In the babl extensions a CIE model is present, it takes as e reference
white D65 while more common would be the reference white E
(http://www.brucelindbloom.com). I assume that the sRGB/scRGB have
reference white D50.

Has anyone an idea what is the reference white for the RGB color model
in BABL or GIMP?
Are the reference white and the chromaticity coordinates not missing in
the BABL model?

Geert

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-30 20:19:21 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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
activate the legacy modes is easy: Whenever an image is loaded that uses
them.

But when to deactivate?
- As soon as there is no layer left using legacy modes? (I.e. you
couldn't switch modes back and forth. Once switched away from legacy
modes, the menu item would be gone.)
- When closing the image or switching to another image that doesn't have
legacy modes. I.e. changing the active image will change the dropdown.
- When closing the last image that uses legacy modes. I.e. you could
activate legacy modes for all images by keeping a foot-in-the-door image
open.
- Only when closing GIMP.

While I could think of use-cases for all of them, I think it boils down
to how strongly we would want to discourage from using the legacy modes.

Is it decided that GEGL will not support the legacy modes, or should
they be implemented in GEGL as well to retain backward compatability?

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-30 20:25:38 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 about 4x slower; probably due
to the increased size (x32) of lookup tables. So that would definitely
need more work.

Rupert

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-30 20:58:38 UTC (over 1 year ago)

From: Sven Neumann

Getting new layer modes fit for inclusion

permalink

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-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-08-30 21:26:09 UTC (over 1 year ago)

From: Martin Nordholts

Getting new layer modes fit for inclusion

permalink

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, but have question. Deciding when to
> activate the legacy modes is easy: Whenever an image is loaded that uses
> them.
>
> But when to deactivate?
> - As soon as there is no layer left using legacy modes? (I.e. you
> couldn't switch modes back and forth. Once switched away from legacy
> modes, the menu item would be gone.)
> - When closing the image or switching to another image that doesn't have
> legacy modes. I.e. changing the active image will change the dropdown.
> - When closing the last image that uses legacy modes. I.e. you could
> activate legacy modes for all images by keeping a foot-in-the-door image
> open.
> - Only when closing GIMP.
>
> While I could think of use-cases for all of them, I think it boils down
> to how strongly we would want to discourage from using the legacy modes.

I think you could add a gboolean was_loaded_with_obsolete_modes to
GimpImage, set it when an image is loaded, and then check that boolean
in gimp_layer_tree_view_set_image(). So whenever an image that was
loaded with obsolete layer modes present becomes the active image, we
show the obsolete modes in the menu.

Slightly different from my initial solution proposal in other words.

/ Martin

> 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 in the pixel or 'nothing'. Right
the result is the unmodified pixel, as in the SVG 1.2 compositing model.
In legacy GIMP compositing, the result is 'nothing' (except when the
layer is the bottom-most layer...).

I'm fine with using our legacy compositing model, as long as there
exists a consistent compositing model without special cases to describe
it. I will try to come up with such a compositing model unless someone
else gives it a go before me.

/ Martin

--

My GIMP Blog:
http://www.chromecode.com/
"Automatic tab style and removed tab title bar"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-01 02:37:55 UTC (over 1 year ago)

From: Rupert Weber

Getting new layer modes fit for inclusion

permalink

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 in the pixel or 'nothing'. Right
> the result is the unmodified pixel, as in the SVG 1.2 compositing model.
> In legacy GIMP compositing, the result is 'nothing' (except when the
> layer is the bottom-most layer...).
>
> I'm fine with using our legacy compositing model, as long as there
> exists a consistent compositing model without special cases to describe
> it. I will try to come up with such a compositing model unless someone
> else gives it a go before me.

I hadn't noticed that yet: All non-GEGL modes now actually use deleted
content for compositing, so that could probably be called broken. (Paint
something on bottom layer that has effect on top layer's compositing,
then delete content in bottom layer to get checkerboard. There are
changes in alpha, but the deleted drawing still shows through)

But if what you wrote was an answer to my questions, it was much more
than I bargained for. ;)

I just meant if GEGL should also implement the current HSV-based color
layer modes for (then) old files, or if GEGL will stay with just
supporting the LCH modes.

Rupert

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-01 07:28:33 UTC (over 1 year ago)

From: Martin Nordholts

Getting new layer modes fit for inclusion

permalink

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 should also implement the current HSV-based color
> layer modes for (then) old files, or if GEGL will stay with just
> supporting the LCH modes.

Sorry, I got carried away :)

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 need the legacy color modes in GIMP.

If we end up using the SVG 1.2 compositing model, we have decided we
won't be compatible. But if we change to use our legacy compositing
model in GEGL too, then for simplicity we should also make sure to
render legacy files with GEGL like the legacy rendering engine does it,
i.e. implement all layer modes.

Right now, the Overlay layer mode actually renders differently in GEGL
than in legacy, so we would also have to introduce an "(obsolete)"
version of Overlay. (The legacy Overlay is exactly identical to legacy
Soft Light, but the GEGL Overlay is different from the GEGL Soft Light.)

/ Martin

--

My GIMP Blog:
http://www.chromecode.com/
"Automatic tab style and removed tab title bar"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-01 12:12:43 UTC (over 1 year ago)

From: Øyvind Kolås

Getting new layer modes fit for inclusion

permalink

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 need the legacy color modes in GIMP.
--
> Right now, the Overlay layer mode actually renders differently in GEGL
> than in legacy, so we would also have to introduce an "(obsolete)"
> version of Overlay. (The legacy Overlay is exactly identical to legacy
> Soft Light, but the GEGL Overlay is different from the GEGL Soft Light.)

GEGL will do compositing in linear light RGB, while GIMP will do
compositing in sRGB (unless profiles are attached to the image, then
it will do compositing in that random space). The results of GEGL
compositing when GIMP is not lying to GEGL about the pixel format of
the pixels will in most cases result in slightly different results.

/Øyvind K.
--

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-01 16:37:24 UTC (over 1 year ago)

From: Martin Nordholts

Getting new layer modes fit for inclusion

permalink

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 incompatibilities are OK, in
>> which case we don't need the legacy color modes in GIMP.
> --
>> Right now, the Overlay layer mode actually renders differently in GEGL
>> than in legacy, so we would also have to introduce an "(obsolete)"
>> version of Overlay. (The legacy Overlay is exactly identical to legacy
>> Soft Light, but the GEGL Overlay is different from the GEGL Soft Light.)
>
> GEGL will do compositing in linear light RGB, while GIMP will do
> compositing in sRGB

Yes you're right, and personally I think this is fine, as long as we do
full and proper color management in GIMP 3.0.

/ Martin

--

My GIMP Blog:
http://www.chromecode.com/
"Automatic tab style and removed tab title bar"
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer