Re: [Gimp-developer] Update on LCH layer modes
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 region of it, and painting over with a HSV value-increased version of same color. Ideally, this would possibly change Hue or Chromaticity, but shouldn't change Lightness significantly. Looking at the LCH color selector, L rises ~2 points for each paint application in my example. Unfortunately, that's not fixable but a result of the too small gamut of the sRGB working space. Combining the lightness of #2a7e23 with hue/saturation of #11e500 results in (linear) sRGB values which are negative for red and blue. Clipping those to 0-255 yields the result you observed (the color becomes lighter than it should be). Whenever you observe this misbehavior, at least one of the resulting RGB components should be at 0 or 255 -- otherwise it really would be a bug. The only fix is to use a larger working space, like scRGB. Regards Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
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 previous explanation of gamma mismatch... But if GIMP is feeding non-linear sRGB to GEGL, isn't that the right reason for GEGL to treat it as what it is? The discussion in the link you sent seems to support that. Of course, for all the RGB layer modes (i.e. everything but Hue/Sat/Color/Value) backwards compatibility makes it a different story. Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
On 13.09.2010 15:28, Rupert Weber wrote: On 09/13/2010 01:05 PM, yahvuu wrote: btw, the red returned from the current GEGL implementation is too dark: [..] I am proposing the attached tiny patch to correct that 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 previous explanation of gamma mismatch... For the record, the relevant thread is here: https://lists.xcf.berkeley.edu/lists/gimp-developer/2008-November/021182.html regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
On 12.09.2010 11:37, Rupert Weber wrote: 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 implementation. Especially when composing e.g. in Color mode onto a white layer, results differ. A red onto white will become yellow (which isn't necessarily worse than the red from floating point, as it seems to be closer to correct lightness -- but it's different.) btw, the red returned from the current GEGL implementation is too dark: the projection eventually converts to linear light RGB u8 [1] and these values get fed directly to the screen, which in contrast expects gamma-corrected values -- that is, at least when color management is turned off. By numbers: sRGB 1 0 0 red (color mode) over sRGB 1 1 1 white gives LCH(ab) (D65): LCH 53.24 104.55 40 red LCH 100 0 % white the result color is certainly out of gamut: LCH 100 104.55 40 super-bright red = RGB 3.110.450.21 linear light [2] = R'G'B' 1.640.700.50 gamma-encoded [2] with the GEGL projection enabled, GIMP currently delivers (1.0 0.450.21) * 255 = 255 115 55 using proper gamma handling the result, truncated to sRGB, will be: (1.0 0.700.50) * 255 = 255 179 128 hopefully i'm not needlessly complicating things, yahvuu [1] to quick'n'dirty test the gamma-correct conversion, gegl/gimp-gegl-utils.c:61 can be modified to: case 3: return babl_format (R'G'B' u8); /* former (RGB u8) */ case 4: return babl_format (R'G'B'A u8); /* former (RGBA u8) */ [2] babl clamps the results of LCH-RGB conversions to the [0 ..1] interval: extensions/CIE.c:1286 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
On 09/13/2010 01:05 PM, yahvuu wrote: btw, the red returned from the current GEGL implementation is too dark: the projection eventually converts to linear light RGB u8 [1] and these values get fed directly to the screen, which in contrast expects gamma-corrected values -- that is, at least when color management is turned off. [...] hopefully i'm not needlessly complicating things, yahvuu The way I understand it is that GEGL intentionally uses the non-gamma-corrected pixels in order to render like the current modes. (As Øyvind had explained somewhere earlier on the list). But for the LCH layer modes that is just wrong without being necessary, as there are no legacy LCH modes, and Lab/LCH is whole different thing from doing RGB arithmetic anyway. I am proposing the attached tiny patch to correct that (Actually I believe someone else described that solution here on the list somewhere, but I maybe confusing it with Øyvind's post). Handling other modes is an opp and thus completely invisible to me ;o) There is a very interesting article about operations on non-linear RGB which I think I found linked on bugzilla: http://www.4p8.com/eric.brasseur/gamma.html Rupert 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 sRGB gamma. --- app/gegl/gimpoperationpointlayermode.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/app/gegl/gimpoperationpointlayermode.c b/app/gegl/gimpoperationpointlayermode.c index 1b59155..a6d145f 100644 --- a/app/gegl/gimpoperationpointlayermode.c +++ b/app/gegl/gimpoperationpointlayermode.c @@ -192,10 +192,10 @@ gimp_operation_point_layer_mode_get_new_color_lchab (GimpLayerModeEffects blend float in_lchab[3]; float lay_lchab[3]; float new_lchab[3]; - Babl *ragabaa_to_lchab = babl_fish (babl_format (RaGaBaA float), + Babl *ragabaa_to_lchab = babl_fish (babl_format (R'aG'aB'aA float), babl_format (CIE LCH(ab) float)); Babl *lchab_to_ragabaa = babl_fish (babl_format (CIE LCH(ab) float), - babl_format (RaGaBaA float)); + babl_format (R'aG'aB'aA float)); babl_process (ragabaa_to_lchab, (void*)in, (void*)in_lchab, 1); babl_process (ragabaa_to_lchab, (void*)lay, (void*)lay_lchab, 1); -- 1.7.0.4 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
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 implementation. Especially when composing e.g. in Color mode onto a white layer, results differ. A red onto white will become yellow (which isn't necessarily worse than the red from floating point, as it seems to be closer to correct lightness -- but it's different.) The problem is that I have to clip twice in integer mode: once from Lab to XYZ, then again from XYZ to RGB. Widening the lab-to-xyz LUT solved the problem for red, but created strange color bandings for blue, so it probably leads to integer overflow somewhere. In other words: I'll have to work on the lab-to-rgb conversions... Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
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 given that there are so many questions not even asked yet, let alone answered, I'm pretty sure that it won't be in 2010. Regards Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
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 old HSV/HSL modes. Is it supposed to? A reminder of Martin's suggestions: I think the names needs to suggest that new files should avoid using those layer modes. Other alternatives: (compat.) (legacy) (obsolete) (broken) (old) I'd consider legacy/obsolete/old defendable. 'old' is nice for its shortness, 'legacy' doesn't sound as negative. The old modes aren't broken (just different and maybe less useful) and 'compat.' is, well, somehow ugly. But I'll let you guys bang each others' heads over that. ;) Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Update on LCH layer modes
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 are loaded from an XCF. I haven't addressed anything else in the patch yet (except very minor changes / comments), specifically compositing onto nothing (which I consider definitely buggy now) and babl. But both are actually not specific to the LCH layer modes. About hiding the old layermodes: (This was my first contact with gtk et al., so I hope what I came up with isn't completely braindead) After pursuing some dead-end roads, this is what I finally did: - added 'was_loaded_with_obsolete_modes' to GimpImage (looks a bit lonely there -- I feel like I missed the right place to add the flag) - in gimp_layer_tree_view_init(), create two paint_mode_menus, one 'default' and one 'obsolete'. Connect signal handler / help data to both of them. - instead of gimp_item_tree_view_add_options(), call a modified gimp_item_tree_view_add_options_mul(), which takes a list of options to add to an hbox. (only first one is shown). This saves us passing up a pointer to the hbox and breaking up encapsulation. - in gimp_layer_tree_view_set_image(), show/hide the menus as apropriate and always set paint_mode_menu to the current menu so any other code automatically references the current menu only. One other thing, also not specific to LCH modes, but somewhere in the same orbit: The Soft Light/Overlay 'situation' -- shouldn't we take the opportunity of bumping up the XCF version to finally fix that, too? I'd volunteer for the grunt-work, if only I knew which one needs to be changed and to what. Regards Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on LCH layer modes
Hi, On Mon, 2010-09-06 at 17:42 +0200, Rupert Weber wrote: 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 are loaded from an XCF. 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. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
