I believe you're asking for

http://bugzilla.gnome.org/show_bug.cgi?id=325564

which has been addressed when using GEGL.

Seth

On Mon, Jul 26, 2010 at 6:33 AM, Charlie De wrote:

Hello all,

I've joined up with this list to make an important suggestion for improvement.
In short, the Color and Value blending, transfer modes in GIMP do not work as
they should. The problem is compounded by the fact that there seems to be no
application on Linux where these transfer modes work correctly. In fact, it
seems all the major applications use the same or very similar algorithms. So
the problem is the same in Krita (which uses GEGL as far as I know) and in ImageMagick.

To confirm the problem, try this:

* Open an image in GIMP, preferrably one that has noticeable noise, and the noise should be coloured, not merely monochromatic. * Duplicate the image into a new layer and blur it, say by 5 points. * Set the transfer mode of the blurred layer to Color.

What should happen is that the colour component of the noise should be eliminated, but the luminance/value should remain the same. This is not the
case, the result worsens the luminance noise! If you have trouble seeing this,
zoom into the image up to 400% or try an image with more obvious noise. Also,
try increasing the blur factor.

Now by comparison, repeat the experiment in Photoshop. You won't fail to notice
that in Photoshop this works correctly. The colours are more muted, perhaps
'leaking' over colour boudaries, but the luma noise is not made worse.

The same effect is at play the other way round, if Value is used instead of Color (and it's the bottom layer that is blurred). And the same effect is also
at play if instead of layer blending, the blending is done in the Fade command
dialog.

In short, there is no correct way yet of using these transfer modes on Linux and
a proper solution is desperately needed.

By the way, I'm using GIMP 2.6.8. I appreciate that 2.7.1 is using GEGL as will
2.8, but I doubt that will in itself offer the solution, because Krita is using
GEGL and the problem there is the same.

Thank you for listening and good luck with the coding.

Charlie

On 07/27/2010 07:31 PM, Charlie De wrote:

Hello again,

Given that the GEGL solution is not yet perfect, as per the latest relevant bug report...

https://bugzilla.gnome.org/show_bug.cgi?id=624026

...I wonder if I may help with an algorithm that could be used either in GIMP internally or in GEGL.

Given how simple the solution is, I wonder if the developers would care to implement it in GIMP natively, not only in GEGL. GEGL projection is still optional and isn't multi-threaded, so there's good reason to have a working solution in the GIMP core.

Hi

If you provide a patch that improves Color mode compositing when using GEGL, I would be happy to review it.

We can't do this change in native GIMP because it would break rendering of XCF files that relies on the old behavior.

We take the opportunity to fix this when we transition to GEGL where we have done other non-compatible changes with regards to layer compositing, that's why the fix should be in the GEGL parts of GIMP.

Thanks in advance for any help,

Regards, Martin

On 07/27/2010 08:08 PM, Charlie De wrote:

On the other hand, I understand you have other good reasons to go the GEGL route. That's fine, except it will take a long time to regain the functionality GIMP already has, namely multi-threading. It's for that reason that I think relatively simple solutions in the core are still worthwhile.

First of all, GIMP doesn't do multi-threading very well, in the sense that few (any?) of the heavy filters are multi-threaded.

Second of all, why would it take long to "regain" multi-threading when we start using GEGL for real? I expect us to make use of a multi-threaded GEGL in the first GEGLifixed GIMP release.

/ Martin

On Tue, 2010-07-27 at 11:08 -0700, Charlie De wrote:

I thought that it had been decided the existing GIMP Color mode was broken, so "files relying on old behaviour" is not an issue.

Since we released stable versions with this broken behavior we now have to maintain backward compatibility to it. It is considered very important that you can open your old XCF files in a new version of GIMP and get the same result as in the version you created them in.

Sven

On Wed, Jul 28, 2010 at 4:20 PM, Charlie De wrote:

Since we released stable  versions with this broken behavior we now have to maintain backward  compatibility to it. It is considered very important that you can open your  old XCF files in a new version of GIMP and get the same result as in the  version you created them in.

I suggest that implementing the improved functionality is of much higher priority than backwards compatibility with the old.  Particularly in a project such as GIMP, where development resources are as precious as they are.

You can tackle this with a marketing "thought experiment": if you were to ask a group of GIMP users what they would prefer, speedy fixing of broken features, or insistence on backwards compatibility, which would the majority vote for?

This is an erroneous dichotomy, because a failure to preserve backwards compatibility is itself a 'broken feature' GIMP is the definitive loader of XCFs. Any other format, it is nice if it supports perfectly, but hardly needed. Its own format, it MUST support perfectly, however it achieves that. It must load any sane XCF in such a way to produce just the same result as it ever did.
Otherwise you create a situation where you are silently changing the meaning of people's XCF images. It's like you changed the symbol '2' to mean 'twice twice twice one' (that is, 8); People will still expect 2+2 to equal 4, not 16. Some people will notice that their maths comes out weird, some people won't. Regardless, it's just not reasonable to indirectly change the meaning of people's creations in this way.

Besides, the appropriate and established way of addressing backward compatibility is through the handling of old files, not by refusing to implement improvements.  Reading some of the discussions among the GIMP development team in relation to the issue of broken Color transfer mode was the first time I encountered the argument that it was preferrable to keep the broken functionality over fixing it, because a user might want to keep old rendering in the new version.  What a nonsensical argument!

Implausible, rather.

Almost all of the improvements we could look at would be much more readily coded and tested with solid GEGL integration. This is something that we do not currently have, it's more like a well-constructed Frankenstein, with some systems having an option to use GEGL, others not, and none with GEGL as the default/only rendering system.
Really solid and complete GEGL integration, IMO, would be far more of an asset to GIMP than any one other user-visible improvement, because of it's major synergistic effect on our ability to quickly write and test new image manipulation operations / combinations of operations.

Old file handling only goes so far: XCF is not only GIMP's fileformat, but represents the way GIMP conceptualizes the notion of a complex image. When basic concepts change, it is normal to not be able to map the old information 100% accurately onto the new format. (that time is not yet, though.)

Has there been a single user outside the dev team who expressed this view?

At this stage I'd prefer to avoid the argument and let the team focus on the positive task of bringing out the next version.  However, there will be bugs in new stable releases, in 2.8, 2.10 and beyond.  So the argument of how those bugs are to be dealt with and what priority backward compatibility is to have will not go away.  We might as well tackle it as we go along instead of delaying it.

My understanding is that breaking compatibility is on the table for 3.0, *and no earlier*. Because of the change of paradigm between classic GIMP and GEGL-based GIMP, GIMP 3 XCFs would naturally be quite a different beast to GIMP 2 XCFs. This makes it a natural point to break compatibility at, since users will need to learn to do quite some things differently anyway. Before then, GIMP won't work differently enough to flag to the users that hey, things may not work quite the same as you're used to.
If GIMP 2 can load GIMP 2 XCFs 'perfectly', and GIMP 3 loads GIMP 3 XCFs 'perfectly', then this is straightforward from a user point of view, no? OTOH if we change in the middle of a major version, it is not:
GIMP 2 XCFs would be loadable by, say GIMP 2.8 would load GIMP 3 XCFs. That's unfriendly behaviour and much harder to remember.

tl;dr version: There are good user-friendliness and programmer-efficiency reasons for leaving compatibility breakage until GIMP 3, and you have not presented any particularly compelling reasons for breaking compatibility earlier

Have a nice day.

David

On Tue, 2010-07-27 at 23:50 -0700, Charlie De wrote:

I suggest that implementing the improved functionality is of much higher priority than backwards compatibility with the old.

If xcf got broken a lot of people would abandon gimp - you can't screw your customers/userbase like that. And it would likely lead to even fewer resources available for development, as people who care about quality, and about usefulness, would maybe leave over it, or at least be less enthusiastic.

The way to change layer modes would probably be to introduce something new, e.g. a new set of layer modes, or a "use old layer mode colour" option that would be set by default when opening an older xcf file, perhaps with an offer to convert to new colour modes.

Having said all that... I'd wondered myself why that photoshop trick of blurring a layer in mode colour didn't work well in gimp, but I don't know that this means gimp is "wrong" here. The right answer is to work out what the behaviour should be, for each mode, and do some tests to see if the implementation matches expectations. "Be the same as some-other-program" is not, of course, a goal for GIMP. And of course it would be nice to be able to fix camera noise, especially from lower-end and older cameras, in this way!

Liam

Would it not be simplest to add a "corrected" colour mode as a new mode, keeping the old one? Just call the old one Colour (legacy)? and give the new one a new internal mode number?

There is no requirement to have back compatability, so trying to open an xcf file with this new layer mode would fail on an old version of gimp, much like any of the new features.

-Rob A>

Rob Antonishen wrote:

Would it not be simplest to add a "corrected" colour mode as a new mode, keeping the old one? Just call the old one Colour (legacy)? and give the new one a new internal mode number?

yes it is, same for non-working overlay mode.

There is no requirement to have back compatability, so trying to open an xcf file with this new layer mode would fail on an old version of gimp, much like any of the new features.

hmmm, let's see if everybody thinks this is so cool...

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On 7/28/10, David Gowers wrote:

I suggest that implementing the improved functionality is of much higher priority than backwards compatibility with the old. Particularly in a project
such as GIMP, where development resources are as precious as they are.

This is an erroneous dichotomy, because a failure to preserve backwards compatibility is itself a 'broken feature' GIMP is the definitive loader of XCFs. Any other format, it is nice if it supports perfectly, but hardly needed. Its own format, it MUST support perfectly, however it achieves that.

Which is why sins of the past could be pardoned by switching to XCF2 which is still in plans, afaik, no? Then GIMP could do things the right way.

Alexandre Prokoudine http://libregraphicsworld.org

On Thu, Jul 29, 2010 at 12:28 AM, Liam R E Quin wrote:

Having said all that... I'd wondered myself why that photoshop trick of blurring a layer in mode colour didn't work well in gimp, but I don't know that this means gimp is "wrong" here. The right answer is to work out what the behaviour should be, for each mode, and do some tests to see if the implementation matches expectations. "Be the same as some-other-program" is not, of course, a goal for GIMP. And of course it would be nice to be able to fix camera noise, especially from lower-end and older cameras, in this way!

BTW, of course this method requires a plugin, but GMIC can do this quite well (the a / b smoothness sliders in the LAB mixer can effectively smooth the coloration without effecting brightness; the denoising filters like 'anisotropic smoothing' also may be set to operate only on AB channels)

I expect it would be straightforward to implement this without breaking XCF (e.g. by keeping the existing mode as an option that's hidden unless you are editing a legacy file), so it seems to be more an issue of priorities and available resources. Note that "straightforward" doesn't translate to "quick, easy and a high priority".

I don't think there's much to be gained from further iterations of "...but it's a high priority for me" followed by "...but it's not a high priority for me". If there was, I'd keep pushing the issue of higher bit-depths :) As an alternative, people who want to use the color-layer blurring technique might want to try the wavelet denoise plugin: http://registry.gimp.org/node/4235

Regards, Ed.

On Thursday, July 29, 2010 03:34:43 Charlie De wrote:

The broken Color mode was reported 4 years ago! Had the solution been implemented natively, it would have been available to view, and would likely have evolved. There's every chance that it could now be ported to GEGL without the alpha bug to contend with.

So go fix it in gegl. I think it was decided 4 years ago what is going to happen to the layer mode bugs.

One more thing: let's not allow the energetic momentum of development be hijacked by a fear that some developers, out of an offended sense of righteousness, might leave. More will be gained by ensuring the team is motivated by a greater sense of serving happy end users.

Whaa... There is about 4 active developers on GIMP right now, plus 2 GSoC students with their projects. This is a lot. We usually hover around two and half. And nobody is in threat of leaving, because nobody seems to be arguing your side. That's lucky, because theres a lot of work to be done before 2.8. The really important stuff like SWM etc.

Your assumption that the layer mode thing is in any way as important as keeping images looking the same from one version to another is almost funny. I filed a bug about this... But I filed it because GEGL did it DIFFERENTLY. As only GIMP user for me the expected behavior of the color mode is the current one. I have several compositions and artworks that rely on it.

Your statement of suggesting people not to upgrade if they need it is cynical at best. Not everybody is an administrator of the machine they use and they cannot control what versions others they share the files have. All school and non-creative corporate environments for example, and GIMP is common there, because its near impossible to justify buying PS and companies/schools cant afford pirating.

If blurring color is so important to you there are several plug-ins that do this by splitting the image to lab and blurring the appropriate layers.

-- Alexia

On 7/29/10, Charlie De wrote:

Charlie,

I cannot help myself noticing a slight contradiction:

There are three respondents who have so far been arguing against me, three others haven't. And I'd suggest that the three of you aren't representative of
the majority of users.

and then you say:

You're minimizing a serious issue, one that makes GIMP almost unuseable for me,
forcing me to resort to external solutions like ImageMagick.

So, are we talking about majority of users or you? The two don't equal to each other, I suspect :)

Just in case, not everyone in this list is a GIMP developer. There are ways and ways to be involved in the project, so there's not much point counting opinions just because they were expressed. We all have our own ideas how GIMP could evolve, what bugs should be fixed first and so on, but as long as we do not write code, priorities are set by people who do.

By the way, since you rely on Color mode so much, maybe you would be interested in MathMap plug-in that allows creating complex node compositions, including blending modes as nodes?

Alexandre Prokoudine http://libregraphicsworld.org

On 7/29/10, Charlie De wrote:

I beg to differ. Priorities must ultimately be set by end users.

Let me just say that you fail to understand development process in real life.

Opinions of users are important, one cannot possibly doubt that. But you cannot rely on just that, because every user has his/her own priorities and rarely has any clue what under-the-hood changes it might involve.

If you ask users here and now what they want, you are likely to hear:

1. Finish single-window mode! I don't need any of that 16bit fancy stuff! Just make it usable!

2. To hell with single-window mode! I want my job done, I need high bit-depth precision and LAB!

3. (to 1 and 2) Are you bloody stupid or what? Who needs that rubbish? I want digital painting!

4. No, what GIMP really needs is CMYK!

And so on. If you tell users that they decide, what you have to do, all hell will go loose, you won't hear yourself in the screaming crowd and you won't get anything done.

Besides, tell me, do you often manage to force yourself doing something you are not interested in? In your spare time? I don't think so. People do free software development, because it's fun. If it's not fun, why do it in the first place?

Priorities are clear: finishing major work on user interface that is long overdue and proceeding with advanced functionality required for people to get their job done. It's both fun for developers and useful stuff for end-users. Everyone is happy. Except probably you :)

Alexandre Prokoudine http://libregraphicsworld.org

On 7/30/10, Charlie De wrote:

Wrong. This is open source. That implies that whoever writes the code decides.

You know it's not that simple. The GIMP is too complex, too high-end a project for whimsical involvement.

There are many ways to make yourself useful for the project. And by that I don't mean buying diapers for developers babies or whatever my sick mind can come up with :) People who *give* and take have more chances to have their wishes come true by means of basic social contract.

What you need to start with, however, is learning the state of affairs in this project. Until you understand why solution is postponed, you cannot makes a request that absolutely makes sense. Luckily you seem to end up on the road towards wisdom after all :)

Alexandre Prokoudine http://libregraphicsworld.org

Compile & and end-user. Not all en-users compile their version of Gimp. Bumping the version number in XCF and implementing the compatibility would probably be better.

----- Originele e-mail ----- Van: "Charlie De"
Aan: gimp-developer@lists.xcf.berkeley.edu Verzonden: Zaterdag 31 juli 2010 08:16:59 GMT +01:00 Amsterdam / Berlijn / Bern / Rome / Stockholm / Wenen Onderwerp: Re: [Gimp-developer] Please fix Color and/or Value transfer mode

From Alexandre:
There are many ways to make yourself useful for the project.

I'm trying to do just that.

Someone, an end user, emailed me off-list, talking about how they'd be upset with a new rendering, talking of "lost files".

Let me offer a cheap and simple solution. Release an incremental update in the stable branch, bundling a few bug fixes. The release retains the broken Color mode. Users are advised to update to take advantage of the bug fixes, and there is no compatibility issue. However, in the release notes accompanying the source, there is a new compile option, called for instance "--with-color-mode-fix". It is made clear that the option should not be used by those who may share their XCF files, because of the new rendering.

Simple, effective, problem solved.

Charlie

On Sat, Jul 31, 2010 at 9:37 AM, Charlie De wrote:

Compile & and end-user. Not all en-users compile their version of  Gimp. Bumping the version number in XCF and implementing the compatibility  would probably be better.

Of course.  But I had the impression the development cost of such a solution and the need to keep XCF unchanged were major considerations.  A compile option would avoid both issues.  It is true that not all end users will compile, but at least those who need the fix are offered a way of obtaining it.

What you are saying is that we should maintain a fork for you... I doubt thats going to happen. You can easily maintain your own patch set yourself however. Its been done before. Not a complete fork but a patch set distributed separately. GIMP Painter was such a patch set. So far some of it has been integrated to mainstream, some of it is still separate.

On Wed, 2010-07-28 at 17:34 -0700, Charlie De wrote:

It's worth noting, however, that XCF is not meant to be an archival format.

Uh, oh. Of course it is meant to be used that way. If you work on images using layers, then saving as XCF is the only way you can archive your work.

As others have pointed out already, it is of course possible to introduce a new color mode to fix the old broken one. Old XCF files would still load fine then and the problem would be fixed. But we are certainly not going to break the XCF file format.

Sven

On Thu, 2010-07-29 at 01:56 -0700, Charlie De wrote:

So go fix it in gegl. I think it was decided 4 years ago what is going to happen to the layer mode bugs.

And my point is that wasn't such a good decision precisely because it took 4 years to get it fixed. As stated, an earlier native fix would have brought the benefit to GEGL. It's disingenuous to challenge me now, 4 years later, to fix it in GEGL. If my line of thought had been followed 4 years ago, GEGL would most likely already be fixed.

It would have taken an afternoon or two to fix it. Someone just needs to spend that time and actually prepare a patch. This is not a question about GEGL or not GEGL. If you feel that it is important to get this fixed, then please submit a patch that introduces new fixed color modes.

Sven

On Sat, Jul 31, 2010 at 9:13 AM, Sven Neumann wrote:

On Thu, 2010-07-29 at 01:56 -0700, Charlie De wrote:

And my point is that wasn't such a good decision precisely because it took 4 years to get it fixed.  [...] If my line of thought had been followed 4 years ago, GEGL would most likely already be fixed.

It would have taken an afternoon or two to fix it. Someone just needs to spend that time and actually prepare a patch. This is not a question about GEGL or not GEGL. If you feel that it is important to get this fixed, then please submit a patch that introduces new fixed color modes.

It might also be nice to get a definition of what it means to be "fixed".

If I understand bugzilla correctly, this issue is bug 325564 (https://bugzilla.gnome.org/show_bug.cgi?id=325564). Martin's comments there are that changing the colorspace from HSL to CIE LCH resolve the issue but do not match Photoshop's results.

I searched for a while and could only find some speculation that Photoshop may use CIE Lab, though these people claim they figured it out and that it is custom coefficients in HSY-space: [ http://www.filterforge.com/forum/read.php?FID=8&TID=319 ].

There may be other resources available, but I found this article to be a good introduction to some of the issues involved: [ http://en.wikipedia.org/wiki/HSL_and_HSV ]. Hopefully people can read this and not say things like "only the color should be transferred" -- excluding what - brightness? luminosity? intensity? Or just admit that they want GIMP to do whatever it is that Photoshop does.

Chris

On Sat, Jul 31, 2010 at 3:13 PM, Christopher Curtis wrote:

it is custom coefficients in HSY-space:

Here's a reference to the HSY color model, since it seems uncommon, and because when searching for "gimp hsy" in Google the second result is the email I _just_ sent (!!)

http://www.x-infinity.com/files/xm/HSY.pdf

Chris