Re: [Gimp-developer] Introduction / Color layer modes
Rupert, that's wonderful news on a Sunday morning! Thank you so much for your effort. 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? 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. Thanks again, Charlie - Original Message From: Rupert Weber g...@leguanease.org To: gimp-developer@lists.XCF.Berkeley.EDU Sent: Sun, August 8, 2010 5:12:03 AM Subject: 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 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
Re: [Gimp-developer] Introduction / Color layer modes
From: Martin Nordholts ense...@gmail.com : Since this is the second time you mention this, I feel I have to step in and say that I think it is a really bad idea. We want to improve the usability of GIMP, and forcing users to use a configure flag to make GIMP work like they want is not a step forward. This is a feature addition, and thus won't be added to GIMP 2.6. But as long as someone is working on the patch, it is very likely that this will end up in GIMP 2.8. And users will not have to use configure flags and compile GIMP themselves to make use of the new feature. Martin, an important fix isn't a feature addition, and early provision of the fix by whatever means doesn't amount to forcing. But I'm repeating myself as you've noted, so thanks to all for your valuable work and good luck with coding for 2.8. A new approach is needed, I'll see what I can do. Best, Charlie ___ 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 Tue, 2010-08-03 at 18:46 +0200, Rupert Weber wrote: 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. Without having looked at the patch (yet), I think that bumping the version in case that the new modes are being used is the right thing to do. Sure you can do something with the file in an old version, but the behavior is undefined and unexpected and it would IMO be better to require that the user uses a version that is new enough to handle the new modes. Sven ___ 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
From: Rupert Weber g...@leguanease.org I wrote a patch that might help fix the situation. Thanks so much for working on this! I'm one of the people who'd greatly appreciate the fix. In fact, your effort is more than I dared hope for, I was resigned to the idea that the GEGL route was the only option right now. My main concern regarding compatibility is that it doesn't cause a delay in the release of the update. 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. Those who want a better compatibility solution can then work on it for the next release. Thanks again and good luck with continued coding. :-) Charlie ___ 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 Tuesday, August 03, 2010 23:04:09 Charlie De wrote: From: Rupert Weber g...@leguanease.org I wrote a patch that might help fix the situation. Thanks so much for working on this! I'm one of the people who'd greatly appreciate the fix. In fact, your effort is more than I dared hope for, I was resigned to the idea that the GEGL route was the only option right now. It is the gegl route + some backwards compatibility for the old engine making it suitable for 2.8. My main concern regarding compatibility is that it doesn't cause a delay in the release of the update. You are really lucky if this gets in 2.8. I think theres no chance this will be back-ported/applied to 2.6 series. --Alexia ___ 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. Hi, Since this is the second time you mention this, I feel I have to step in and say that I think it is a really bad idea. We want to improve the usability of GIMP, and forcing users to use a configure flag to make GIMP work like they want is not a step forward. This is a feature addition, and thus won't be added to GIMP 2.6. But as long as someone is working on the patch, it is very likely that this will end up in GIMP 2.8. And users will not have to use configure flags and compile GIMP themselves to make use of the new feature. It should be pretty easy for whoever is interested to backport the patch to GIMP 2.6 of course, but it won't go upstream. 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
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
