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

From: Rupert Weber

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

On Tuesday, August 03, 2010 23:04:09 Charlie De wrote:

From: Rupert Weber

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

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

From: Martin Nordholts :
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

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