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 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] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] new layer modes patch posted
On 08/15/2010 08:14 AM, David Gowers wrote: (which, while being auto-generated, also change infrequently enough that they *are* version-controlled), have not been included. Ha, and I went out of my way to keep them out of the patch... ;o) I suggest merging these changes with the patch to libgimp, since that is the one that introduces the new enums. Actually, it's the layer mode patch. The libgimp patch only introduces the new conversion functions, not the enums. I'll attach the amended patch to bug #325564. Thanks ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new layer modes patch posted
I posted an amended version of the layermode patch, which is the one that changes the enums (not the libgimp one). I'm sorry, looking back at the messages I left on bugzilla, it was extremely unclear which patch is which -- thus starting the confusion. Hopefully someone will be able to successfully wade through that mess... BTW -- is there any way to edit existing messages on bugzilla? I didn't find anything. Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] layer modes - open questions
There are still some issues that I either blissfully ignored or took the least-cost route on: (1) enums and gimp-composite While the values of legacy layer mode enums are preserved, gimp-composite.h has its own GIMP_COMPOSITE_* enums which append some modes to the layer mode list. (GIMP_COMPOSITE_BLEND, _SHADE, _SWAP,...). Those additional enums have their values changed. Is that a problem? (I can't even find any place they are used) (2) file import/export For import of psp, psd and xjt I simply assumed the new modes would be more appropriate than the old ones. For exporting, I just mapped the new modes along with the old ones. But I don't know what would be correct for those file formats/programs. (3) paint-funcs layer modes Is the layer mode code in app/paint-funcs ever used? If so, the code would have to be amended accordingly. Right now, I just mapped the new modes to the old functions. I think that's about it. Regards Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] new layer modes patch posted
I posted a new version (v3) of the layer modes patch (split in two) to http://bugzilla.gnome.org/show_bug.cgi?id=325564 The libgimp functions and the layer mode stuff are each in a separate patch now. [The message I wrote there is misleading. along with the other v3 patch was just supposed to mean that it accompanies the first patch. There is no third patch missing.] Additionally, I also posted a patch for the Decompose plug-in to http://bugzilla.gnome.org/show_bug.cgi?id=626944 (that one builds on top of the libgimp patch) Regards Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
Thanks a lot for all the input. I have been using the matrices from http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html *) and thought I was doing sRGB/D65-to-Lab or sRGB/D50-to-Lab. But as I understand now, I was actually doing sRGB-to-Lab/D65 or /D50; while all the RGB spaces like AdobeRGB or sRGB have their own fixed implicit reference white. Correct? *) This is where the matrix used by babl and the Decompose plug-in is listed as PAL/SECAM) It all almost seemed to make sense. Then I read the wiki on sRGB where it says that sRGB has an illuminant white point D65, an encoding ambient wp of D50, and a typical ambient wp of D50. Then my head exploded and I decided to keep this strictly on need-to-know... So, summing it all up, I am not doing anything wrong when I do the conversion from sRGB to Lab/D65? - to be like Photoshop: D50 - to be more right: D65 As to babl and the Decompose plug-in: They should be updated to use sRGB conversion? Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
On 08/11/2010 11:20 PM, yahvuu wrote: Me, too, thinks that sRGB is a reasonable assumption. If you want to Do It Right(tm), you will have to take the image's color profile into account. Since most, if not all 8-bit implementations of color operations are agnostic of the current color space, however, i think it's valid to postpone full color space support until GEGLized processing takes over. I agree. But I considered adding a reserved parameter to the functions, so we have the option to later add color management support without breaking binary compatibility of 3rd party plug-ins. As far as layer modes are concerned, you are actually free to choose. If i understand correctly, you're on a chase for the 'best' 'color' layer mode anyway (where 'best' refers to some subjective quality). Well, yes for now. But the conversion routines go into the colorspace lib and may be used by plug-ins for who knows what. (like the Decompose/Compose plug-in.) Then it might become relevant. (Then again, nobody complained so far and probably nobody would ever notice if we did it Right(tm)...) Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
On 08/12/2010 12:32 AM, James Cox wrote: sRGB has only been around since 1996. I suspect that the gimp version dates from before that, or at least before sRGB came into common use. That would certainly explain it. I don't think we want our color profiles to affect layer blending, so I think it is best that we choose a single color space and stick with it. I was wondering about that. Right now, that's the behavior. But if you had two identical images differing only in color profile, should the same action (say, increase contrast by 30%) deliver (a) the same visual result (gamut permitting), or (b) the same RGB values? Wouldn't (a) be preferable, even if it is different from current behavior? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
Can of worms... A second attempt at summary and proposed action: 1. D50 vs D65 doesn't make any difference as long as Lab values aren't communicated to the outside. (E.g. by saving to a file or by having a Lab color picker) 2. The 'natural' conversion for sRGB seems to be D65. So I'll use that. [ Any plug-in that wants something different than D65 will just have to do its own conversion for now. ] 3. To keep the door open for a later implementation of full color profile support, I'll add a reserved parameter to all Lab functions that either accept or return RGB values. (The layer modes could then still choose not to use that and stick with default sRGB / D65) Sounds reasonable? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
Regarding BABL: i've had a look at extensions/CIE.c and found conversion routines using linear light RGB with the sRGB primaries and white point -- that is scRGB. Everything fine here. Now i'm not familier with BABL -- possibly i've checked at the wrong routines? What I found was conv_rgbF_xyzF() in extensions/gggl-lies.c But I'm just as unfamiliar with babl, so I might be the one who looked at the wrong place. Regarding the Decompose plug-in: yes, that seems to use the PAL stuff. However, i'd be surprised if that makes a really big difference. What's more important, is that i couldn't find any routine which respects the gamma curve defined by sRGB. Yes, it's just not there. I suppose that's why results show a very bright L channel. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
On 08/12/2010 03:41 PM, yahvuu wrote: [...] So, i think GIMP should Get It Right for GEGL processing, while certain deviations of operations' characteristics are tolerable for 8-bit processing. Fine with me. Regards Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
Disclaimer: I am not a color buff. Anybody who actually *knows* about that stuff, please chime in. PAL/SECAM vs sRGB = While writing the Lab/LCH layer mode stuff, I wondered so far why the result is still slightly different from the current GEGL implementation of Color/Hue/Saturation/Value modes. Now after taking a quick peek at the babl source, it seems that GEGL/babl assumes a PAL/SECAM RGB space as source (just like the Decompose plug-in.) Considering that two different implementations use PAL/SECAM, I am wondering if there is a good reason for it and I just don't understand; or if maybe they just either copied from each other or happened to reference the same (limited) resource? After all, accurate color conversion information isn't abundant and was probably less so when that code was written. So far I'd say it's a bug -- barring actual color management the most reasonable assumption seems to be sRGB. D50 vs D65 == Another question during transformation to Lab is, which illuminant or reference white to use. That part, I don't quite understand yet. Does that depend on the source data, or simply on how the monitor is calibrated? I'll be grateful for any enlightenment. Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Getting new layer modes fit for inclusion
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
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
Re: [Gimp-developer] Lab Decompose
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
Re: [Gimp-developer] Getting new layer modes fit for inclusion
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
Re: [Gimp-developer] Introduction / Color layer modes
On 08/08/2010 09:22 AM, Charlie De wrote: I'm not so good at understanding patches and things... If this is accepted, would it mean it would be available natively, without GEGL projection? Yes, it's completely independent from GEGL. Since LAB uses a perception-based definition of lightness, this would effectively solve the Color mode problem, the two being two sides of the same coin. What this means is that it makes a fix for our present predicament easier to release: as a completely new mode, the LAB Lightness would avoid the compatibility issue that a fixed Color mode would present. Why didn't I think of this during the discussion? So I would urge all concerned to initially focus on this new mode, and please consider an early release. While the Color and Lightness/Value modes are the reverse of each other and can thus theoretically replace each other by swapping layers, I don't see the Lightness mode being released any sooner than the new Color mode. It's both of them or none. I'd really love to see this (well, once it's done, of course) go into 2.8. Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Introduction / Color layer modes
Just uploaded a revised layer mode patch to http://bugzilla.gnome.org/show_bug.cgi?id=325564 Good news: - is about as fast as the legacy modes - adds Lab Burn mode The Lightness mode is really cool, because it effectively gives you Lab contrast/brightness control: - duplicate your layer (or make new from visible) - set top layer to 'Lightness (Lab)' - Use normal Curves, Levels, or whatever you prefer. next thing I'll do is rework the integer math routines, so they don't require intermediate 64bit ints -- and run faster. Cheers Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Introduction / Color layer modes
Hello there, recently I got sucked somehow into supplying a small patch for GIMP (all I ever meant to do was to report a bug...). -- and thank you to Sven, who remained very friendly and patient, despite me getting it all wrong the first cpuple attempts. So now that I licked blood I wanted to get involved a bit more. I took the Color layer mode issue as a good way to get to know the code a bit. I posted a first patch with new layer modes to http://bugzilla.gnome.org/show_bug.cgi?id=325564 That patch is nowhere ready for inclusion, but good enough to take a look at. [ I had already written quite a bit about the patch to this list from a different (GMX) account, but it seems it didn't get through. -- So before reposting that again, I'll first see if this comes through...] Cheers, Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Introduction / Color layer modes
[ Ok, so I'm daring to repost my previuos mail again, which obviosly didn't make it...] I wrote a patch that might help fix the situation. First, I don't consider the current Color layer mode as broken. It is just different from what many users will expect. What I do consider broken, though, is that currently using GEGL delivers completely different results from 'classic' mode. The current Color mode uses HSL, the hue/saturation/value modes use HSV. GEGL uses LCH for all those modes. That means if you open an XCF file, it is not clear how to render it, as you don't know if they were created with GEGL view or not. (Which is why I would not consider http://bugzilla.gnome.org/show_bug.cgi?id=325564 FIXED, rather it went from somewhat unexpected behaviour to broken) The patch introduces four new layer layer modes for Color/Hue/Saturation/Lightness, all using LCH/Lab space. (The result is slighly different from current GEGL though, I don't know why, yet.) About how to store in XCF: The obviuos choice seems to be to bump up the version to 3, which is what the patch currently does if one of the new modes is used. That might not be good, though: - Older versions will simply refuse to open the file. - With e.g. 2.6.8, you can still open a file with the new modes, it's just that the display will be a mess until you've set valid layer modes. While this won't allow you to render the image correctly, you can still *access* it, which might be valuable. I attached the patch to the abovementioned bugreport. I'd be glad to hear what you think, Cheers Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Introduction / Color layer modes
On 08/03/2010 10:04 PM, Charlie De wrote: [...] For that reason I've previously proposed what to me seems to be the cheapest solution - offer the fix as a compile option in an incremental bug release in the stable branch. But if someone compiles from source anyway, it's probably easier to just apply the patch (well maybe not this one, but once it's halfway done). Martin made a remark on bugzilla: Don't change the name of the legacy enums, that just complicates the patch. While I'd spontaneously agree with that, I am only now starting to realize what a bad decision it was, along with reordering them which is much worse still: I hadn't considered plug-ins at all. 'neutralizing' the enums for XCF is pretty pointless if all existing plug-ins break. Of course we could do it for plug-ins, as well, but then it should be *all* enums... ouch. So it's back to original order and naming for the legacy enums. But I'm still torn on XCF. I'd really dislike going back to writing enums to files -- but objectively, there isn't much of a point to keep it up. Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
