Please fix Color and/or Value transfer mode

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

I believe you're asking for

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

<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 <charliecoeli@yahoo.com> 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
>
>
>
>
>

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. I arrived at the solution by trying various scripting
approaches with ImageMagick, in my effort to find a way of reducing colour noise
without accentuating luma noise. The idea that the Lab colour space could be
used isn't new, but the "trick" is to realize that the processing of the layer
to be blended/transferred down with the Color mode should be done in RGB. So
the algorithm is simple: process the layer as needed in RGB, then use its A and
B Lab components to combine it with the L component of the layer below. That's
it, it works beautifully.

For those who use ImageMagick and can read its scripts, here it is:

convert test.tif -colorspace lab -channel r -separate test-L.tif
convert test-L.tif \( test.tif -gaussian-blur 0x2 -colorspace lab -separate \) \
-delete 1 -set colorspace lab -channel rgb -combine -colorspace rgb - | display
-


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.


I hope this is of use.

Charlie

>
>
>
>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 <charliecoeli@yahoo.com> 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

Martin,



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

Alas, all I can provide is the algorithm, I'm not a C or C++ coder.

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

I thought that it had been decided the existing GIMP Color mode was broken, so
"files relying on old behaviour" is not an issue. It wouldn't take much to make
it clear in release notes of the update that the new Color mode works better and
old files will look different. Those who rely on old functionality can refrain
from upgrading - this has always been the case with software. I find it
frustrating and specious that the "old behaviour" argument is put forward at all
when essential improvements are at stake.

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.

Once again, sorry I can't contribute code, I really wish I could.

Best,

Charlie

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

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


Music to my ears!

Good luck with the coding, your efforts are greatly appreciated.

Charlie

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

> 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? If
the thought experiment isn't convincing enough, then you can do an actual poll,
through mailing lists and forums.

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!

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.

Charlie

On Wed, Jul 28, 2010 at 4:20 PM, Charlie De <charliecoeli@yahoo.com> 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, and 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 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

It's an unjustified escalation to think of improved rendering in a new version
as breaking the XCF file format. The file format would be the same. It's only
"broken" if you make it so, if you insist on handling the new rendering through
the file format. It's worth noting, however, that XCF is not meant to be an
archival format. Granted, there may be users using it archivally, but they can
be considered idiosynchratic and catered for by appropriate warnings about fixed
functionality, not placed centre stage with upside-down development priorities.

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.

I appreciate this discussion is late in the day - the GEGL route is set, and
we're not so far from 2.8 release. But undoubtedly, new bugs will be uncovered
after the release. If at that point there are still arguments put forward in
favour of esoteric considerations, at the expense of essential fixes, then I
assure you I, as an end user, won't keep quiet about it. I'm going to challenge
you to furnish the evidence. Provide us with a sizeable body of users,
preferrably the majority, who agree with your position and are willing to forgo
timely essential fixes for the sake of mainting broken, but familiar rendering.
If you cannot provide that evidence then I will consider your position to be
willful sabotage and will make the point perfectly clear.

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.

Charlie

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

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

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

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. You're too concerned with esoteric considerations.

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

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

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

Then trust the administrators to handle the situation the way they see fit.
Whatever means are offered to handle the situation of new rendering - whether
through warnings or in some more helpful, transparent way, the admins are there
to take that on board and make decisions how to maintain their existing files.

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

If only it were only the blurring. Most of my workflow is broken because of the
broken Color mode. When processing photos it's standard procedure to execute
all sorts of helpful filters and use the Color mode to obtain the colours but
not affect the luminance.

Charlie

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

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

I beg to differ. Priorities must ultimately be set by end users. And I would
repeat that the majority of end users would favour timely fixes of essential
functionality over concerns how those fixes will render existing files. My only
point in all this is one of priorities. By all means do whatever can be done to
reduce any inconvenience of the new rendering, but don't use the compatibility
issue as a block to essential fixes. Not for 4 years!

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

Thanks for the tip, I'll look into it.

Charlie

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

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

In your list of priorities people might come up with, none described broken
essential functionality. Fixing those should be highest priority.

>From Tobias:
>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. Discussions are held and priorities are set. It's
perfectly valid for an end user to take part in that discussion.

>I don't think any serious user would be willing to throw away his work of the
>last years just because GIMP breaks backwards compatibility.


You're right about that and no-one has argued for data loss, quite the reverse.
You're presenting a straw man argument.


One thing I've learned here is that the demands of the advanced photographer
workflow in GIMP are under-represented. I do get a strong impression that one
particular argument has been overly influential, and it went something like
this: "I can see the Color mode works differently than some may expect, but that
doesn't mean it's broken. It just works different, so there's no urgency to
'correct' it."

Well, a painter or to a lesser extent a designer might be able to say that. And
even diletante photographers. But the GIMP is a high-end editor, with an
advanced feature set, targetting advanced photographers, alongside the groups
mentioned. Their needs - when functionality essential to their workflow is
broken - should be better appreciated and respected.

I think we've by now covered most of the angles. So barring any new input here,
let's wait and see what 2.8 brings. Given that the primary functionality of the
Color mode is already said to be fixed, I'm catiously optimistic a similar
situation won't arise. In addition, I can't think of anything beside transfer
modes that would affect rendering. So even if something may need urgent repair,
there's a good chance the rendering concern won't apply.

Charlie

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

>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

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" <charliecoeli@yahoo.com>
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

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

Charlie

On Sat, Jul 31, 2010 at 9:37 AM, Charlie De <charliecoeli@yahoo.com> 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 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 <sven@gimp.org> 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 <ccurtis0@gmail.com> 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

>From Alexia:
> 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.


No, certainly not just "for me". The fix should be available to all because the
feature is essential to a high quality photo processing workflow. Why is it so
essential? Look at it from a technical perspective. All the most often used
tone adjustment commands - Levels, Curves, Brightness & Contrast - work in the
HSB/HSL/HSV colour spaces. This means that as the tones are adjusted, so are
the colours, and it is difficult to achieve accurate results. Properly
functioning Color and Value transfer mode offer the user a way out of this
predicament, by separating colour and luminance.

>From Chris:
> 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.


It's generally acknowledged that what is at stake is the perceptual nature of
the way "luminance" is defined, and therein lies the soluton to how "only the
color should be transferred". And I can confirm this without reference to
Photoshop if you please. I only used Photoshop as an example of a correctly
functioning Color transfer mode, not wishing to imply GIMP should be like
Photoshop. Here is a GIMP-only explanation: I currently get around the broken
Color mode by using Decompose to separate into LAB channels, performing any
desired operations there, then Recompose back to the original. This works well,
I get a proper separation of colour and luminance. The problem is that the
solution is so unweildy, it can't be applied in all cases and is generally
burdensome in the way it works.

In more general terms, I'm happy to leave it to the developers to decide how
best the Color mode is to be fixed. I trust them to arrive at the right
solution as long as the problem is correctly understood. And I think that it
is.

Charlie

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 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 Thu, Jul 29, 2010 at 12:28 AM, Liam R E Quin <liam@holoweb.net> 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)