All the legacy blending modes are funny, not just overlay. All of them need to be fixed.

Blending modes are arbitrary artistic things and there is no correct overlay formula. GIMP doesn't necessarily have to use the one in Wikipedia. Here's an interesting and thorough post in the GIMP developer list on this topic:
https://mail.gnome.org/archives/gimp-developer-list/2012-July/msg00201.html

To start making new layer modes, somebody has to come up with a list of modes that are actually needed. And somebody has to come up with a way to include both legacy and new layer modes in the GUI (I think that was already covered in IRC).

On Mon, Nov 12, 2012 at 12:56 PM, Paul Geraskin wrote:

Hi all again!

I did a fix for Gimp 2.9 Overlay Mode. Can you check it?

https://bugzilla.gnome.org/**show_bug.cgi?id=673501- issue https://bugzilla.gnome.org/**attachment.cgi?id=228551- my patch

The Overlay mode fully compatible with Krita, Photoshop, ORA, Painter.

The formula was taken from here: http://en.wikipedia.org/wiki/** Blend_modes

Mitch said that it's possible to set "New Overlay" and remain "Legecy Overlay". And he said to talk to GEGL guys about this to get the implementation of new Overlay mode to Gimp 2.9/2.10.

Can you review my patch and implement it into the 2.9/2.10 release?

Also, you can experiment with my psd file for testing: http://dl.dropbox.com/u/**26887202/blender/ee.png http://dl.dropbox.com/u/**26887202/blender/ee.psd

Thanks. ______________________________**_________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/**mailman/listinfo/gimp-**developer-list

On 11/12/2012 06:55 PM, Ville Sokk wrote:

All the legacy blending modes are funny, not just overlay. All of them need to be fixed.

Blending modes are arbitrary artistic things and there is no correct overlay formula. GIMP doesn't necessarily have to use the one in Wikipedia. Here's an interesting and thorough post in the GIMP developer list on this topic:
https://mail.gnome.org/archives/gimp-developer-list/2012-July/msg00201.html

To start making new layer modes, somebody has to come up with a list of modes that are actually needed. And somebody has to come up with a way to include both legacy and new layer modes in the GUI (I think that was already covered in IRC).

Just wondering if the blend modes couldn't be implemented with specialized plugins. There would be uses for this in photography and/or astrophotography (exposure blend, averaging...).After all it's just a formula with the RGB values for the layer and the composite image below, isn't it? (at least this is how the current ones are described).

On Mon, 2012-11-12 at 22:16 +0100, Ofnuts wrote:

On 11/12/2012 06:55 PM, Ville Sokk wrote:

All the legacy blending modes are funny, not just overlay. All of them need to be fixed.

Blending modes are arbitrary artistic things and there is no correct overlay formula. GIMP doesn't necessarily have to use the one in Wikipedia. Here's an interesting and thorough post in the GIMP developer list on this topic:
https://mail.gnome.org/archives/gimp-developer-list/2012-July/msg00201.html

To start making new layer modes, somebody has to come up with a list of modes that are actually needed. And somebody has to come up with a way to include both legacy and new layer modes in the GUI (I think that was already covered in IRC).

Just wondering if the blend modes couldn't be implemented with specialized plugins. There would be uses for this in photography and/or astrophotography (exposure blend, averaging...).After all it's just a formula with the RGB values for the layer and the composite image below, isn't it? (at least this is how the current ones are described).

They are gegl ops, so this is already possible. There is just no UI to set them, and I'm not sure if there should be.

--mitch

On Tue, 2012-11-13 at 10:43 +0400, Paul Geraskin wrote:

If it's possible, so this is will be my feature request. How difficult it to make this like a plugin/addon? You will save million artists and there will be more interest to Gimp, really.

We are in unstable development here. When 2.10 is done, artists will be able to choose proper modes from the menu.

All i need is to Override "gfloat comp" in the gimpoperationoverlaymode.c .

Like my patch does: https://bugzilla.gnome.org/attachment.cgi?id=228551

On 13.11.2012 01:42, Michael Natterer wrote:

They are gegl ops, so this is already possible. There is just no UI to set them, and I'm not sure if there should be. --mitch _______________________________________________ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Tue, Nov 13, 2012 at 3:47 PM, Paul Geraskin wrote:

Good! I will wait for that. Interesting when do you plan to release the Gimp 2.10? I hope it will be faster than 2.8. :)

The best way to ensure that is to contribute :)

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, 2012-11-13 at 15:47 +0400, Paul Geraskin wrote:

Good! I will wait for that. Interesting when do you plan to release the Gimp 2.10?

As usual, when it's done :)

I hope it will be faster than 2.8. :)

The only way to speed that up is contributing :)

On 13.11.2012 11:27, Michael Natterer wrote:

On Tue, 2012-11-13 at 10:43 +0400, Paul Geraskin wrote:

We are in unstable development here. When 2.10 is done, artists will be able to choose proper modes from the menu.

I agree with Paul on the overlay mode. The patch is excellent, and it makes importing files from Photo$hop more consistent. I think it should be the default. Just my two cents.

On Tue, Nov 13, 2012 at 8:25 AM, Michael Natterer wrote:

On Tue, 2012-11-13 at 15:47 +0400, Paul Geraskin wrote:

Good! I will wait for that. Interesting when do you plan to release the Gimp 2.10?

As usual, when it's done :)

I hope it will be faster than 2.8. :)

The only way to speed that up is contributing :)

On 13.11.2012 11:27, Michael Natterer wrote:

On Tue, 2012-11-13 at 10:43 +0400, Paul Geraskin wrote:

We are in unstable development here. When 2.10 is done, artists will be able to choose proper modes from the menu.

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Jeff Maples (grapnell@gmail.com) wrote:

I agree with Paul on the overlay mode. The patch is excellent, and it makes importing files from Photo$hop more consistent. I think it should be the default. Just my two cents.

The problem with the approach Paul took in the bug report is, that it breaks compatibility: Existing Artwork stored in XCF files will change apperance depending on the Gimp version.

We can't have that.

However, this does not prevent us from implementing a "proper" overlay mode. We just need to keep the old (arguably buggy) blending mode around and introduce a *new* one with the proper implementation. Then we change labels in the UI.

That'd be the way to go forward with this issue.

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Tue, Nov 13, 2012 at 7:14 PM, Simon Budig wrote:

However, this does not prevent us from implementing a "proper" overlay mode. We just need to keep the old (arguably buggy) blending mode around and introduce a *new* one with the proper implementation. Then we change labels in the UI.

I would suggest to detect XCF version and for files with legacy blending modes rename the mode to "Legacy Overlay" and suggest resaving, while using just "Overlay" for all new files.

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre Prokoudine (alexandre.prokoudine@gmail.com) wrote:

I would suggest to detect XCF version and for files with legacy blending modes rename the mode to "Legacy Overlay" and suggest resaving, while using just "Overlay" for all new files.

There is no need to fiddle around with the XCF version. The layer mode basically is an enum. We simply keep the old enum value (and the "buggy" legacy overlay implementation) around and assign a new one to the fixed "Overlay". Then we hide the "Legacy Overlay" in the menu (unless it is used).

This however needs to be done. Just exchanging the math in the overlay operation won't cut it.

Bye,
Simon

simon@budig.de              http://simon.budig.de/

Paul Geraskin (paul_geraskin@mail.ru) wrote:

Is it possible to implement it right now? It seems your solution is pretty simple.

Dive into the code and give it a shot. If you need guidance around the code feel free to ask on IRC.

Bye, Simon

simon@budig.de              http://simon.budig.de/

On Tue, 2012-11-13 at 16:27 +0100, Simon Budig wrote:

Alexandre Prokoudine (alexandre.prokoudine@gmail.com) wrote:

I would suggest to detect XCF version and for files with legacy blending modes rename the mode to "Legacy Overlay" and suggest resaving, while using just "Overlay" for all new files.

There is no need to fiddle around with the XCF version. The layer mode basically is an enum. We simply keep the old enum value (and the "buggy" legacy overlay implementation) around and assign a new one to the fixed "Overlay". Then we hide the "Legacy Overlay" in the menu (unless it is used).

The problem is much bigger. Almost *all* of our layer modes will be "Legacy", and the new modes will operate in linear light. Just adding a hack for overlay is not going to fix the root problem.

--mitch

This however needs to be done. Just exchanging the math in the overlay operation won't cut it.

Bye,
Simon

El 13/11/12 14:37, Michael Natterer escribi:

The problem is much bigger. Almost *all* of our layer modes will be "Legacy", and the new modes will operate in linear light. Just adding a hack for overlay is not going to fix the root problem.

--mitch

Apart from the different overlay formula and all being blended in linear light, is there any other layer mode that changes? I was thinking about the simplest way to tackle this problem, and if those are the only differences this might work:

If the file was created with 2.8 or earlier, show a warning and offer opening the file anyway or using the legacy mode. If the user chooses legacy:
- Promote the file to high bit depth. - open it normally (afaik this would convert the colorspace to the working space and linearize every layer) - add a gamma correction operation to all the layers applying the sRGB TRC (1D LUTs?)
- blend
- Linearize the composite prior the last color-management op.

- Regarding the Overlay operation: Just replace it using the soft light mode instead. Correct me if I'm wrong, but in GIMP 2.8 and previous versions both modes seem to provide the same result.

Probably applying gamma correction to inputs that were linearized from a gamma corrected source sounds redundant, but this is supposed to be a legacy mode, a compatibility layer, so the reduced efficiency would be probably justified.

If this is possible, switching from legacy to the new native linear blending would mean just bypassing the gamma correction nodes.

I'm not a coder and I don't know anything about the GIMP/GEGL internals, so I tried using the logic I'd use with a compositing software. If this is a stupid oversimplification you're entitled to make me STFU :-)

Gez

Hi,

I remember when using 2.7 and GEGL view (?) was available for testing, Overlay worked as expected.

Legacy Overlay looks like Soft Light, but GEGL Overlay looks like Overlay.

n-pigeon

Ups, my e-mail browser folded responses :D

sorry for repeating what already was written ^^'

On Tue, Nov 13, 2012 at 9:14 PM, Paul Geraskin wrote:

I had some experience in converting sRGB to linear RGB. When I coded in GLSL. I have taken this code from blender GLSL shader. The main idea is: convert all inputs to linear RGB, then make formula calculation, then convert output to sRGB.

The methods from blender GLSL shader (it works per channel):

in GIMP and GEGL code pixel format conversion between well defined standard color models and pixel formats is the responsibility of babl, http://gegl.org/babl/

Converting from 8bits per component sRGB to 32 bit floating point with the same RGB primaries as sRGB but with a linear gamma ramp is done like this:

babl_process (babl_format ("R'G'B'A u8"), babl_format ("RGBA float"), source_buffer, destination_buffer, n_pixels);

Other predefined babl_formats of interest could be "RaGaBaA half" which is 16bit floats in linear light with premultiplied alpha. Or "Y' u8" which is 8bit grayscale like you'd find in a grayscale JPG or PNG.

You can extend babls vocabulary of data types and pixel formats at runtime as well as register optimized fast-paths, that can be combined for pairs of formats without their own fast paths (possible conversions are precision and performance profiled at runtime).

/yvind K.

@hodefoting

On Wed, Nov 14, 2012 at 3:29 AM, yvind Kols wrote:

babl_process (babl_format ("R'G'B'A u8"), babl_format ("RGBA float"), source_buffer, destination_buffer, n_pixels);

I should have looked up the header or some actual code first, the first argument of babl_process is a babl-fish for the conversion that can be cached, more correct code could be:

const Babl *fish = babl_fish (babl_format ("R'G'B'A u8"), babl_format ("RGBA float"));
..
babl_process (fish, source_buffer, destination_buffer, pixel_count);

@hodefoting

On Wed, 2012-11-14 at 11:57 +0400, Paul Geraskin wrote:

Hi again.

I talked to Krita developer "Boud" by IRC and he said many interesting things about linear RGB.
He said that there is no need to convert to Linear RGB. Krita does not convert anything. It only mixes layers.

I suggest you trust what the gimp developers say about what needs and needs not to be done in gimp code.

So everything is simplier. You just need to implement my patch and make "New Overlay"/"Legacy Overlay"
for new/old XCF formats.

No, it is exactly as i said.

--mitch

Entire talk:
[11:36] mifth: yes
[11:38] i have a tlkt to gimp devs about Overlay mode. There is a question: do you convert to Linear RGB layers before mixing and then to sRGB/RGB16 after mixing?
[11:38] talk*
[11:39] no -- krita users can create their images in linear rgb and work in that mode if they want, but otherwise, everything is done in the current colorspace
[11:39] i mean in Krita of course
[11:40] this is different from gegl, which, afaik, always works with 32 bit floating point linear rgb [11:41]==thorwil[~thorwil@79.251.116.204] has joined#krita [11:42] For eaxmple i created an image RGB8 in Krita. Then i did some layers with different modes. Does Krita convert RGB8 to Liner RGB to mix layers?
[11:43] no -- if you have layers in different color models, krita will convert those layers to the image model before composition [11:45] Gimp devs say that they should convert to liner RGB before mixing layers? Are they right? [11:45] i'll post some their posts now [11:45] I'm on the mailing list :-0) [11:45]==LukasT[~zil00064@213.95.68.61] has joined#krita [11:45] aha cool
[11:46] what do you think about that talk? [11:46] it's something that one can debate... the thing is, that yets, there are advantages. But artists often don't want the way linear rgb works, it confuses them
[11:46] it affects the way layers are blended together, and they are used to the non-linear system
[11:46] so krita gives people a choice: choose to work in linear rgb, or not
[11:48]==home[~home@unaffiliated/home] has joined#krita [11:48] interesting..
[11:48] it also means you can easily experiment with the differences in krita :-)
[11:49] where can be switching to linear in Krita? [11:49] I've just updated Krita.org to the latest version of Joomla and it's plugins. It should all work fine, but if anyone comes across anything weird, I'd appreciate hearing about it! [11:49]==MrBeast[~foo@pD9508D90.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
[11:50] Bugsbane: ok!
[11:50] mifth: image/convert image type, select an scRGB profile. [11:50] boud: other question: Is it ok to mix layers with different modes without convertion to linear RGB? [11:51] yes, in krita it is
[11:51] cool
[11:51] but afaik, krita is the only application that allows you to have layers of different color models [11:51] thank you for talking
[11:51] i'll post it to Gimp mailing list [11:52] you're welcome
[11:52] oyvind kolas (pippin) knows how krita works, btw, but he thinks we're doing it wrong by allowing the user that flexibility

On 13.11.2012 21:37, Michael Natterer wrote:

The problem is much bigger. Almost *all* of our layer modes will be "Legacy", and the new modes will operate in linear light. Just adding a hack for overlay is not going to fix the root problem.

--mitch

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Wed, Nov 14, 2012 at 11:57 AM, Paul Geraskin wrote:

Hi again.

I talked to Krita developer "Boud" by IRC and he said many interesting things about linear RGB.
He said that there is no need to convert to Linear RGB.

This is true for Krita, this isn't true for GIMP and GEGL.

GEGL _always_ works in linear light RGBA.

Alexandre Prokoudine http://libregraphicsworld.org

On Wed, 2012-11-14 at 12:21 +0400, Alexandre Prokoudine wrote:

On Wed, Nov 14, 2012 at 11:57 AM, Paul Geraskin wrote:

Hi again.

I talked to Krita developer "Boud" by IRC and he said many interesting things about linear RGB.
He said that there is no need to convert to Linear RGB.

This is true for Krita, this isn't true for GIMP and GEGL.

GEGL _always_ works in linear light RGBA.

Actually, it doesn't. Each GEGL operation specifies its input and output color space, and GEGL makes sure the data is correctly converted when calling the op.

--mitch

Am 13.11.2012 18:37, schrieb Michael Natterer:

The problem is much bigger. Almost *all* of our layer modes will be "Legacy", and the new modes will operate in linear light. Just adding a hack for overlay is not going to fix the root problem.

are you referring to technical concerns or rather to UI design challenges?

I think the solution that was designed to update the color transfer blend modes (#325564) is sustainable here, too:

Old modes have '(legacy)' appended in layer mode menu and don't show in menu unless an XCF with one of them is openend. They never show in paint menu.

Working with a legacy XCF thus offers some 40 blend modes, which can naturally be displayed in two columns, side by side. This is important in order to enable manual replacing of the old blend modes on a layer-by-layer basis.

The legacy modes are CPU hogs, because they need to apply gamma to both inputs and de-gamma the output. I see no way around that.

When a legacy XCF gets openend, an automatic conversion to the new blend modes can be offered, informing the user that the color appearance might change. This needs to be undoable. The notification should be non-intrusive, probably similar to Firefoxen's door hangers[1]. I believe a lot of the rationales also apply to GIMP. However, this needs to be in line with general GIMP UI (peter?).

Writing legacy XCF is clearly an export.

@Gez: i believe this is mostly in line with your proposal, only that i'd like to avoid a modal pop-up on opening the legacy XCF.

best regards, yahvuu

[1] http://people.mozilla.com/~faaborg/files/20090821-notification/newNotification-i1.png https://bugzilla.mozilla.org/show_bug.cgi?id=398776#c5 http://people.mozilla.com/~faaborg/files/20111102-fiveYears/notification-guidelines-full.png

El 14/11/12 09:32, yahvuu escribi:

Am 13.11.2012 18:37, schrieb Michael Natterer:

The problem is much bigger. Almost *all* of our layer modes will be "Legacy", and the new modes will operate in linear light. Just adding a hack for overlay is not going to fix the root problem.

are you referring to technical concerns or rather to UI design challenges?

I think the solution that was designed to update the color transfer blend modes (#325564) is sustainable here, too:

Old modes have '(legacy)' appended in layer mode menu and don't show in menu unless an XCF with one of them is openend. They never show in paint menu.

Working with a legacy XCF thus offers some 40 blend modes, which can naturally be displayed in two columns, side by side. This is important in order to enable manual replacing of the old blend modes on a layer-by-layer basis.

The legacy modes are CPU hogs, because they need to apply gamma to both inputs and de-gamma the output. I see no way around that.

When a legacy XCF gets openend, an automatic conversion to the new blend modes can be offered, informing the user that the color appearance might change. This needs to be undoable. The notification should be non-intrusive, probably similar to Firefoxen's door hangers[1]. I believe a lot of the rationales also apply to GIMP. However, this needs to be in line with general GIMP UI (peter?).

Writing legacy XCF is clearly an export.

@Gez: i believe this is mostly in line with your proposal, only that i'd like to avoid a modal pop-up on opening the legacy XCF.

I think that a checkbox in the layers panel would be more elegant and less of a clutter than adding "legacy blending modes" to the available blending modes.
I was thinking about adding it along with the lock buttons. A checkbox labeled "legacy mode" that adds the needed gamma correction nodes to all the layers and replaces the new overlay for soft-light is all that we need. I can't see a reason for having legacy blending modes co-existing with native. The legacy mode should be only for compatibility. Users should always use the native mode and only use legacy for the very specific cases when old files need to be opened and their appearance has to match with other old files.
For artistic purposes, the appearance of the old blending modes should be replicated using different tools (probably adjustment layers in the future. The non-destructive workflow proposed by Peter should provide all the needed tools for that).
Duplicating the number of blending modes available adding the old ones is cumbersome and seems quite pointless.

There's an extra use case where legacy mode could be useful, and it's working for web mockups. As far as I could see, and the last time I asked pippin about this he said the same, since web browsers blend RGBA images in gamma-corrected space, it's necessary to design web mockups with gamma-corrected alpha overs to match the web appearance. Currently only alpha-overs are affected, but the web is getting blending modes soon in CSS, and apparently they will be also blended in sRGB space.

For that specific case using the legacy mode would be mandatory. But again, it doesn't have to co-exist with native. It's switching to a mode where everything has to work in the old way (except overlay probably. I'm not sure what overlay formula will be used in web browsers).

So, summarizing: - There's no real need to make new and legacy co-exist. Those seem more like exclusive "modes".
- The new mode should be default, and the legacy mode an alternative. - The current and future web seem to blend RGBA in nonlinear space, so having a mode for that could be needed (and in such case the term "legacy" isn't entirely accurate).

Regarding the modal popup: this is a very special situation. The user has to decide wether to use the native mode or the legacy for the imported file. Making that step transparent could mean leaving that important difference unnoticed.

Kind regards, Gez.

Am 14.11.2012 13:32, schrieb yahvuu:

Writing legacy XCF is clearly an export.

oops, i meant: "Writing XCF compatible with older GIMP versions is clearly an export".

(That is, a composition with legacy blend modes can just be saved as any other composition. Only when backwards compatibility is requested, the export conversion is necessary.)

Elsewhere, please read "legacy XCF" as "XCF with at least one legacy blend mode".

sorry, yahvuu

Paul Geraskin (paul_geraskin@mail.ru) wrote:

If you have read the article.. it happens only if you use gaussian blur filter which makes some color calculations with alpha.

Please take a deep breath, relax a little and don't jump to conclusions.

This article is exactly about the blending problem which of course involve a lot of alpha stuff, since blending without alpha channel is basically meaningless.

You're currently not helping getting things done. You apparently did not fully grasp the problems we're facing. Your isolated fix is not a solution unfortunately.

Bye,
Simon

simon@budig.de              http://simon.budig.de/

Am 14.11.2012 14:50, schrieb Guillermo Espertino (Gez):

I think that a checkbox in the layers panel would be more elegant and less of a clutter than adding "legacy blending modes" to the available blending modes.

Ahh, i see, so we're not so much inline as i previously thought :)

A bit of visual clutter: yes. But i'm confident that this first shot can be improved: http://yahvuu.files.wordpress.com/2009/08/legacy-blend.png *)

In contrast: yet another checkbox adds yet another application state that the user has to memorize.

I was thinking about adding it along with the lock buttons. A checkbox labeled "legacy mode" that adds the needed gamma correction nodes to all the layers and replaces the new overlay for soft-light is all that we need. I can't see a reason for having legacy blending modes co-existing with native.

A good reason for co-existence is that all the new blending goodness will be available when touching up/building upon prior work.

A global switch between old/new blending characteristics might also turn into conflicts with future developments. With co-existance, we're on the safe side in that regard.

In the latter case, we're only talking about when the legacy modes show up in the UI. With a global switch, we would be be putting constraints on the composition.

The legacy mode should be only for compatibility. Users should always use the native mode and only use legacy for the very specific cases when old files need to be opened and their appearance has to match with other old files.

here we agree

For artistic purposes, the appearance of the old blending modes should be replicated using different tools (probably adjustment layers in the future. The non-destructive workflow proposed by Peter should provide all the needed tools for that).

i believe so, too

There's an extra use case where legacy mode could be useful, and it's working for web mockups. As far as I could see, and the last time I asked pippin about this he said the same, since web browsers blend RGBA images in gamma-corrected space, it's necessary to design web mockups with gamma-corrected alpha overs to match the web appearance. Currently only alpha-overs are affected, but the web is getting blending modes soon in CSS, and apparently they will be also blended in sRGB space.

uhh, and "graphical elements of web pages" are covered by the product vision. So we're not only talking about "legacy blend modes" but also about "web blend modes".

This needs more thinking, but i'm already convinced that a global "web mode" switch would play in the same league as an "8bit mode" switch. Possibly, we could use a "web modes..." switch in the _blend mode list_ to toggle the visibility of the additional blend modes.

best regards, yahvuu

*) multiply mode indeed stays the same in linear light and "sRGB light". The others probably don't. The color transfer modes change to CIE LCH as per #325564.

El 14/11/12 12:43, yahvuu escribi:

I was thinking about adding it along with the lock buttons. A checkbox labeled "legacy mode" that adds the needed gamma correction nodes to all the layers and replaces the new overlay for soft-light is all that we need. I can't see a reason for having legacy blending modes co-existing with native.

A good reason for co-existence is that all the new blending goodness will be available when touching up/building upon prior work.

A global switch between old/new blending characteristics might also turn into conflicts with future developments. With co-existance, we're on the safe side in that regard.

In the latter case, we're only talking about when the legacy modes show up in the UI. With a global switch, we would be be putting constraints on the composition.

I guess we can put this issue in simpler terms and see if we agree: - Linear is the way blending should be done. The most basic compositing operation, which is the porter-duff alpha over works better in linear space. it's extremely easy to see this just blending a couple of saturated colors. The semi-transparent pixels tend to add a dark fringe if you blend them in non-linear.
- Legacy is legacy. For some reason which no longer applies blending was done in non-linear space. There is no other reason for using non-linear blending other than:
a) support legacy GIMP
b) support applications that still use blending in non-linear space. Web browsers, for instance.
- This brings two problems:
a) How to deal with old GIMP files
b) How to provide a reliable web workflow without packing the UI with duplicated menus.

I think that making linear and non-linear blending coexist is the worst thing that can be done, because it creates a complexity which is not really necessary.
It's not putting constraints on the composition. You can use any technical errors as creative tools, but making the UI of the "proper" tools because of that is a mistake. It's like asking to keep a buggy filter as an alternative "because I like how it looks". Other tools should be provided to re-create the intended look, not keeping things that don't work as they should. And blending in nonlinear space probably falls in the latter.

After thinking about it for a moment, I can't imagine a better way to address this problem other than adding a special "mode" that makes all blends non-linear, but considering the need of a web-safe workflow, it probably shouldn't be named "legacy", but something more accurate like "Allow blending in non-linear space"

And if it's possible, only when that switch is selected, then show the alternative "old overlay", which only makes sense for legacy.

Gez.

On 11/14/2012 07:00 PM, Guillermo Espertino (Gez) wrote:

After thinking about it for a moment, I can't imagine a better way to address this problem other than adding a special "mode" that makes all blends non-linear, but considering the need of a web-safe workflow, it probably shouldn't be named "legacy", but something more accurate like "Allow blending in non-linear space"

And if it's possible, only when that switch is selected, then show the alternative "old overlay", which only makes sense for legacy.

Use legacy mode when the image is iprocessed in 8-bit? (which could be on e of the technical reasons for the non-linear blending anyway)

El 14/11/12 23:18, Ofnuts escribi:

Use legacy mode when the image is iprocessed in 8-bit? (which could be on e of the technical reasons for the non-linear blending anyway)

That's interesting, and iirc it was one of the first proposals. The problem with that, in my opinion, is how to communicate to the user the difference and what bitdepth to use as default. If a default session of GIMP starts in 8 bpc int... Should the blending behave as the old GIMP? I don't think so. But perhaps the solution is indeed a new mode there, among the other bit depth modes.

What about a new mode, a "legacy/web mode" which is 8 bpc int, with nonlinear blending but it's NOT the default bitdepth? The rest of the modes should be linear to ensure the best quality, and probably the current 8bpc mode should be replaced by a 16bit int mode with a conversion to 8bpc in the end (to make sure all the color operations, blendings and filters provide good quality results, even in 8bpc).

I'm not sure about the technical viability of this proposal, but from a user point of view the impact in the UI would be minimum (just an extra mode in the precision menu).
The legacy files would open using that mode, and in that mode the blending should be done in non-linear space, and the layers UI would show the same modes, but they will work as in legacy. If the overlay mode uses the new formula, the imported legacy files could get the overlays converted to soft-light.
The same mode would work for web design.

If that's possible from the technical side it sounds like a pretty elegant way to address these needs, and meanwhile it would keep the rest of GIMP working at the best quality for the creative work.

Gez.

Hi again,

Am 14.11.2012 19:00, schrieb Guillermo Espertino (Gez):

b) support applications that still use blending in non-linear space. Web browsers, for instance.

how much support for 'web type' blending modes does GIMP really need?

GIMP is not a HTML editor, this has been clearly pointed out in [1]. The focus is rather on creating bitmaps for web use. But does this imply a verbatim preview of how the bitmaps would be rendered in multi-layered html pages?

If it is just for judging how far a alpha-based drop shadow will reach, probably a preview during export-for-web would be sufficient.

Besides, web browser color management in combination with blend modes sounds like an invitation for trouble -- supposedly, no two browsers will do it the same. For GIMP this means that there is probably no single 'right' way to preview web graphics anyway. Which hints at leaving web-specific stuff to specialized export-for-web functionality and keeping it separate from the composition itself.

best regards, yahvuu

[1] http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg20547.html

On Fri, Nov 16, 2012 at 12:30 AM, yahvuu wrote:

Besides, web browser color management in combination with blend modes sounds like an invitation for trouble -- supposedly, no two browsers will do it the same.

https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Nov 16, 2012 at 12:34 AM, Alexandre Prokoudine wrote:

On Fri, Nov 16, 2012 at 12:30 AM, yahvuu wrote:

Besides, web browser color management in combination with blend modes sounds like an invitation for trouble -- supposedly, no two browsers will do it the same.

https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html

The official URL, however, will be http://www.w3.org/TR/compositing/

Alexandre Prokoudine http://libregraphicsworld.org

2012/11/15 yahvuu :

Hi again,

Am 14.11.2012 19:00, schrieb Guillermo Espertino (Gez):

b) support applications that still use blending in non-linear space. Web browsers, for instance.

how much support for 'web type' blending modes does GIMP really need?

It when you're making design mockups and when you're preparing the assets for a design for the web.
But after reading further and, if I got it right, I found that there is a property in the specs that allows to choose the space for blending, and the newer blending and filter specs default to linear. The old ones, however, default to sRGB blending (SVG filters for instance) unless you explicitly change it to linear.

Apparently we're in a transition period and everything points to linear for the future, so it's quite possible that blending in sRGB ends up as "legacy" anyway.

On Thu, 2012-11-15 at 21:30 +0100, yahvuu wrote:

Hi again,

Am 14.11.2012 19:00, schrieb Guillermo Espertino (Gez):

b) support applications that still use blending in non-linear space. Web browsers, for instance.

how much support for 'web type' blending modes does GIMP really need?

This Web thing will never take off, it's just a momentary... er... wait :)

GIMP is not a HTML editor, this has been clearly pointed out in [1].

The W3C compositing spec applies to images as well as text. One could combine separate images as layers in a Web application.

supposedly, no two browsers will do it the same.

Supposed by whom? The purpose of HTML 5, and of specifications like Compositing, is *precisely* so that all the major browsers work the same way.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

[oops, resending from the right mail account, sorry]

On Thu, 2012-11-15 at 21:30 +0100, yahvuu wrote:

Hi again,

Am 14.11.2012 19:00, schrieb Guillermo Espertino (Gez):

b) support applications that still use blending in non-linear space. Web browsers, for instance.

how much support for 'web type' blending modes does GIMP really need?

This Web thing will never take off, it's just a momentary... er... wait :)

GIMP is not a HTML editor, this has been clearly pointed out in [1].

The W3C compositing spec applies to images as well as text. One could combine separate images as layers in a Web application.

supposedly, no two browsers will do it the same.

Supposed by whom? The purpose of HTML 5, and of specifications like Compositing, is *precisely* so that all the major browsers work the same way.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On Wed, Nov 14, 2012 at 8:57 AM, Paul Geraskin wrote:

[11:46] so krita gives people a choice: choose to work in linear rgb, or not
[11:48] == home [~home@unaffiliated/home] has joined #krita [11:48] interesting..
[11:48] it also means you can easily experiment with the differences in krita :-)
[11:49] where can be switching to linear in Krita? [11:49] I've just updated Krita.org to the latest version of Joomla and it's plugins. It should all work fine, but if anyone comes across anything weird, I'd appreciate hearing about it! [11:49] == MrBeast [~foo@pD9508D90.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
[11:50] Bugsbane: ok!
[11:50] mifth: image/convert image type, select an scRGB profile. [11:50] boud: other question: Is it ok to mix layers with different modes without convertion to linear RGB? [11:51] yes, in krita it is
[11:51] cool
[11:51] but afaik, krita is the only application that allows you to have layers of different color models [11:51] thank you for talking
[11:51] i'll post it to Gimp mailing list [11:52] you're welcome
[11:52] oyvind kolas (pippin) knows how krita works, btw, but he thinks we're doing it wrong by allowing the user that flexibility

The user will have the same flexibility in the GIMP/GEGL model, In this model there is no working-space operations are happening, neither global nor local per layer. In GEGL each GeglBuffer / layer might have a different color model or precision for it's storage, It is the operation that specifies the color space it is happening in. Which means that sRGB based compositing or linear compositing is best done with separate GEGL operations (and on the GIMP side layer-modes that needs to be dealt well with wrt legacy/non-linear to avoid UI explosion.).

/yvind K.
--
@hodefoting

Am 16.11.2012 00:24, schrieb Liam R E Quin:

On Thu, 2012-11-15 at 21:30 +0100, yahvuu wrote:

how much support for 'web type' blending modes does GIMP really need?

This Web thing will never take off, it's just a momentary... er... wait :)

Or: "The Internet? Is that thing still around?" :)

GIMP does not have support for photoshop softlight mode. GIMP does not have support for SVG softlight mode. GIMP does not even have a ticket open for that. Does GIMP really need specific support for the 'web-softlight in sRGB' blending mode?

GIMP is not a HTML editor, this has been clearly pointed out in [1].

The W3C compositing spec applies to images as well as text. One could combine separate images as layers in a Web application.

That is exactly my point: combining separate image layers for a web page is the job of the Web application (or browser). It is not GIMP's job.

As long as no common web image format is multi-layered, GIMP does not strictly need to support web-specific blending modes. And even in that case, the necessary support might be considered as export functionality. Functionality, which should be kept separate from the composition's features (aka list of native GIMP blending modes).

supposedly, no two browsers will do it the same.

Supposed by whom? The purpose of HTML 5, and of specifications like Compositing, is *precisely* so that all the major browsers work the same way.

Please pardon my scepticism. I really do hope that it will work out as intended. But optimists are just pessimists without experience, they say :) I mean, color management did not enter the world of browsers _that_ smoothly. And the related pitfalls do have impact on GIMP.

What is the state of discussion in W3C? Is it already settled that compositing will be performed in sRGB? Does a migration plan towards blending in linear light exist? Or is it ruled out explicitly for the future?

best regards, yahvuu

Am 15.11.2012 23:28, schrieb gespertino@gmail.com:

But after reading further and, if I got it right, I found that there is a property in the specs that allows to choose the space for blending, and the newer blending and filter specs default to linear. The old ones, however, default to sRGB blending (SVG filters for instance) unless you explicitly change it to linear.

Can you help me out on that? I couldn't find it in the links provided by Alexandre.

best regards, yahvuu

On Fri, 2012-11-16 at 13:33 +0100, yahvuu wrote:

What is the state of discussion in W3C? Is it already settled that compositing will be performed in sRGB? Does a migration plan towards blending in linear light exist? Or is it ruled out explicitly for the future?

The compositing spec is a working draft, still open to change.

Change most often comes from (1) implementation experience, and (2) comments from people.

W3C Consensus-based Process requires the Working Group to respond to, and try to address, all outside comments before a specification moves forward towards being a "Recommendation". So, if you have strong feelings and expertise in this area, please do comment.

See the "Status" section of the document on www.w3.org/TR/ for instructions on sending comments, as it varies fo each specification.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

Hi all,

A couple different lines of discussion are in this thread, the correct way to implement Overlay in regular sRGB, the effect of linear gamma blending with respect to changing w3 standards, how to deal with legacy blend modes after the switch to linear light image editing.

An implicit assumption seems to be that linear light blending is *always* more correct than blending in the regular sRGB color space. While Normal blending requires linear light to be radiometrically correct (to work like real light works), I'm not so sure about the Overlay blend mode.

Overlay doesn't really have a physical counterpart, does it? And doesn't the Overlay blend mode have a mathematically built-in assumption that the color space being used is reasonably close to being perceptually uniform? Consider the following:

The Overlay blend mode has an inflection point at 0.50 on a scale from 0 to 1, where you switch from Multiply to Screen. People refer to the the Overlay inflection point as "50% gray". But the phrase "50% gray" is misleading. It sounds like "middle gray" but it isn't. "50% gray" is always R=G=B=127, regardless of the gamma/tone rsponse curve of the RGB color space in which the blending is being done.

In the sRGB color space, "50% gray" is very close to "middle gray", but only because sRGB is almost perceptually uniform. "Middle gray" itself is an ambiguous phrase, but it never means "50% gray". It might mean:

Lab values of L=50, a=b=0 (sRGB: R=G=B=119) 18% gray (sRGB: R=G=B=118)
13% (really 12.9%) gray (sRGB: R=G=B=99) 12% gray (sRGB: R=G=B=97)

Below are corresponding Lab->RGB values if the image is in the regular sRGB color space:
0->0
10->27
20->48
30->70
40->94
50->119
Overlay inflection point is when R=G=B=127, which is when Lab L=53, very close to Lab middle gray - all values below are multiplied, all values above are screened.
53->127
60->144
70->171
80->198
90->226
100->255

Now consider the Lab to RGB values for linear light sRGB: 0->0
10->3
20->8
30->16
40->29
50->47
53->54
60->71
70->103
Overlay inflection point is when R=G=B=127, which is when Lab L=76, half-way between middle gray and max white - all values below are multiplied, all values above are screened. 80->144
90->194
100->100

Four uses for Overlay blend mode (any other uses?):

1. To increase mid-tone contrast while compressing shadows and highlights. 2. When creating a gaussian glow
3. When doing high pass sharpening.
4. When using a "50% gray" layer for dodging/burning

Focusing on the first use, when an image is overlayed over itself in the regular sRGB color space, the effect is *exactly* the same as applying a more or less symetric S-curve which increases mid-tone contrast and compresses shadows and highlights. This is usually what people want to have happen. I can provide the curves values if anyone is interested.

But because the Overlay inflection point is defined as 0.5, or R=G=B=127 (regardless of the color space gamma/tone response curve), in a *linear light* color space Overlay blending an image with itself produces a very different outcome. In a linear light color space the shadows are crushed to 0, the midtones are shifted down toward the shadows, and the highlights aren't compressed much at all. This not particularly useful result is at odds with probably all the reasons why we might want to use Overlay blend mode.

It seems to me that instead of "50% gray" a more reasonable inflection point for the overlay mode in digital image editing (at least in linear light) would be Lab (50,0,0) to preserve the effect of stretching midtones and compressing shadows and highlights. I suspect the formulas for Multiply and Screen could use some tweaking, too, to accomodate linear light blending.

Sorry this post is so long! Elle

http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography

On Fri, Nov 16, 2012 at 8:33 PM, Elle Stone wrote:

Hi all,

A couple different lines of discussion are in this thread, the correct way to implement Overlay in regular sRGB, the effect of linear gamma blending with respect to changing w3 standards, how to deal with legacy blend modes after the switch to linear light image editing.

It seems to me that instead of "50% gray" a more reasonable inflection point for the overlay mode in digital image editing (at least in linear light) would be Lab (50,0,0) to preserve the effect of stretching midtones and compressing shadows and highlights. I suspect the formulas for Multiply and Screen could use some tweaking, too, to accomodate linear light blending.

Critically evaluating what is the reasonable color space to use for various operations is indeed something that we need to do. For many operations - like blurs, various warps and transforms linear makes most sense. And for operations that will work better in a more perceptual space I think as Elle states here - that using CIE Lab (or something very similar) is likely to be a better choice than sticking with sRGB gamma curves for the non-linearity.

/yvind K.

The future is already here. It's just not very evenly distributed
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/

On Thu, Nov 15, 2012 at 9:30 PM, yahvuu wrote:

Am 14.11.2012 19:00, schrieb Guillermo Espertino (Gez):

b) support applications that still use blending in non-linear space. Web browsers, for instance.

how much support for 'web type' blending modes does GIMP really need?

GIMP is not a HTML editor, this has been clearly pointed out in [1]. The focus is rather on creating bitmaps for web use. But does this imply a verbatim preview of how the bitmaps would be rendered in multi-layered html pages?

If it is just for judging how far a alpha-based drop shadow will reach, probably a preview during export-for-web would be sufficient.

I think most use cases that needs sRGB based compositing, for web preview purposes etc. will be covered by offering just "normal" with non-linear compositing, the rest of the legacy modes could be more or less fully hidden from the UI when creating new projects.

/

Hi Elle,

Am 16.11.2012 20:33, schrieb Elle Stone:

An implicit assumption seems to be that linear light blending is *always* more correct than blending in the regular sRGB color space. While Normal blending requires linear light to be radiometrically correct (to work like real light works), I'm not so sure about the Overlay blend mode.

I'd rather like to put it like that:

Normal mode blending has proven to better suit artistic needs when applied in a linear light color space. For other blend mode formulas, like overlay, this may not be the case. Some may 'shine' in linear light, others may become pretty useless. It's a matter of experimentation to find that out.

GIMP's focus is on artistic needs. Whether a blend mode is useful or not, can only a judged from an artistical point of view. If you want to model physical reality with GIMP means, be careful to check whether the actually implemented math is suitable for your case.

Of course, it is not by accident that certain formulas which model the physics of light do turn out to be useful in GIMP. But i believe it is misleading to think of blend modes in terms of correct or incorrect.

Overlay doesn't really have a physical counterpart, does it? And doesn't the Overlay blend mode have a mathematically built-in assumption that the color space being used is reasonably close to being perceptually uniform?

No physical counterpart, no built-in assumptions. From looking at the formula, i suppose it is simply the result of an experiment like "Can we combine multiply and screen in one blend mode?"

Overlay turned out to to have some useful characteristics for image manipulation, which is why it 'survived'.

The Overlay blend mode has an inflection point at 0.50 on a scale from 0 to 1, where you switch from Multiply to Screen. People refer to the the Overlay inflection point as "50% gray". But the phrase "50% gray" is misleading. It sounds like "middle gray" but it isn't. "50% gray" is always R=G=B=127, regardless of the gamma/tone rsponse curve of the RGB color space in which the blending is being done.

In the sRGB color space, "50% gray" is very close to "middle gray", but only because sRGB is almost perceptually uniform. "Middle gray" itself is an ambiguous phrase,

Within the context of separable blendmodes *), i suggest to use the range 0 to 1 and simply look at the RGB triples. It is clear that R=G=B=0.5 in sRGB results in a different gray than R=G=B=0.5 in geglRGB.

Blend mode formulas will produce the same numbers regardless of the color space. But these numbers will be interpreted differently depending on the color space. In turn, the perceived characterics of a blend mode will change with the color space.

This effect is neither good nor bad per se -- we need to find out what is useful and what is not.

Some blend modes like overlay and soft light have a neutral value when the top layer is at R=G=B=0.5. If i got you right, you are putting your finger on the fact that this neutral value will look different in geglRGB than it did in sRGB.

Four uses for Overlay blend mode (any other uses?):

a) Painting with overlay mode can be useful for cleaning up masks. For example, painting with black turns the darker half of the tone range into pitch black while preserving the highlights. On a mask, this means cleaning up the outside range without touching the borders too much.

b) blending two images

1. To increase mid-tone contrast while compressing shadows and highlights. 2. When creating a gaussian glow
3. When doing high pass sharpening.
4. When using a "50% gray" layer for dodging/burning

Focusing on the first use, when an image is overlayed over itself in the regular sRGB color space, the effect is *exactly* the same as applying a more or less symetric S-curve which increases mid-tone contrast and compresses shadows and highlights. This is usually what people want to have happen. I can provide the curves values if anyone is interested.

yep, duplicating a layer and using any of the separable blend modes is equivalent to appling a curve. I consider this technique by far inferior to curves, because it
a) bloats the layer dialog
b) does not allow fine-tuning of the effect

But because the Overlay inflection point is defined as 0.5, or R=G=B=127 (regardless of the color space gamma/tone response curve), in a *linear light* color space Overlay blending an image with itself produces a very different outcome. In a linear light color space the shadows are crushed to 0, the midtones are shifted down toward the shadows, and the highlights aren't compressed much at all. This not particularly useful result is at odds with probably all the reasons why we might want to use Overlay blend mode.

Actually, the 'overlay over itself' technique is equivalent to applying an S-curve regardless of the color space. It is just that in linear light, such an S-curve does not result in the same effect as perceived in the sRGB case.

This will, of course, also surface when using the curves tool. A possible remedy might be to use logarithmic scales there. It has also been suggested to use Lab color space as default for curves.

It seems to me that instead of "50% gray" a more reasonable inflection point for the overlay mode in digital image editing (at least in linear light) would be Lab (50,0,0) to preserve the effect of stretching midtones and compressing shadows and highlights. I suspect the formulas for Multiply and Screen could use some tweaking, too, to accomodate linear light blending.

A good reason to tweak the layer modes (or to keep the compatiblity modes around) would be if they perform badly when blending two *different* layers.

As said, the 'blend by itself' technique is more of an oddity, which is completely superseeded by the curves tool.

best regads, yahvuu

*) 'Separable blendmodes' include overlay, dodge and burn etc, but exclude dissolve, color, hue. The term nicely describes that the blend mode formula is applied separately to each of R,G,B. It is taken from http://www.w3.org/TR/compositing/

On Sat, 2012-11-17 at 13:57 +0100, yahvuu wrote: [...]

GIMP's focus is on artistic needs. Whether a blend mode is useful or not, can only a judged from an artistical point of view. If you want to model physical reality with GIMP means, be careful to check whether the actually implemented math is suitable for your case.

Come on, how many artists do you know who will have enough of a background in mathematics and physics to have a hope of doing that?

You might as well tell a bunch of engineering students that they need to consider the interaction between the sthetics of composition and socio-political emotive responses.

The overlap is non-zero, some do have a hope, but it's not OK to make it into a barrier.

Of course, it is not by accident that certain formulas which model the physics of light do turn out to be useful in GIMP. But i believe it is misleading to think of blend modes in terms of correct or incorrect.

Here we agree :-)

Best,

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On 11/17/2012 08:38 AM, Liam R E Quin wrote:

GIMP's focus is on artistic needs. Whether a blend mode is useful or not, can only a judged from an artistical point of view. If you want to model physical reality with GIMP means, be careful to check whether the actually implemented math is suitable for your case.

Come on, how many artists do you know who will have enough of a background in mathematics and physics to have a hope of doing that?

You might as well tell a bunch of engineering students that they need to consider the interaction between the sthetics of composition and socio-political emotive responses.

The overlap is non-zero, some do have a hope, but it's not OK to make it into a barrier.

I think Yahvuu's suggestion is accurate; your implication of his meaning is a bit off the mark. The way an artistic individual could decide about the "actually implemented math" is by experience, not analysis. Which blend mode "looks best", to the artist, is meaningful.

-- BUrnie

Am 16.11.2012 18:12, schrieb Liam R E Quin:

W3C Consensus-based Process requires the Working Group to respond to, and try to address, all outside comments before a specification moves forward towards being a "Recommendation". So, if you have strong feelings and expertise in this area, please do comment.

no expertise and no strong feelings. In particular, no intention to discredit anybody's work or to sound disrespectful. My apologies if this came out wrong.

See the "Status" section of the document on www.w3.org/TR/

Thanks to your link i have searched the archives a bit and have learned that 1) there are color-interpolation and color-interpolation-filters properties 2) these have been in SVG for a long time

It is not clear to me in what scope CSS compositing will use these properties. However, if i go by example of the Filter Effects Draft[1] --which both explicitly targets CSS and references the color interpolation properties-- this makes my original concerns look unfounded. When the rendering color space is explicitly specified, there may be differing browser capabilities to deal with, but it is hard to imagine any adverse impact on GIMP.

best regards, yahvuu

[1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#color-interpolation-filters

Am 15.11.2012 23:28, schrieb gespertino@gmail.com:

Apparently we're in a transition period and everything points to linear for the future, so it's quite possible that blending in sRGB ends up as "legacy" anyway.

another take on the topic:

The need for more experimentation/evaluation has been pointed out, so what about using an interim version for experimentation, and discuss the final approach again when more experience is available?

In that case, i'd propose:

- compatibility modes are named like "Normal (NL)" - these are only selectable from the layers dialog - the blend modes pop-up has a button to show/hide non-linear modes - non-linear modes are displayed in a second column with short-name "(NL)", e.g. like http://yahvuu.files.wordpress.com/2009/08/legacy-blend2.png - selection via mouse-wheel does not change the column - no need for fancy notifications when opening XCFs which contain non-linear blend modes - a script can convert all modes between linearnon-linear in one fell swoop

just thinking aloud, yahvuu

On Sun, 2012-11-18 at 12:30 +0100, yahvuu wrote:

Am 16.11.2012 18:12, schrieb Liam R E Quin:

W3C Consensus-based Process requires the Working Group to respond to, and try to address, all outside comments before a specification moves forward towards being a "Recommendation". So, if you have strong feelings and expertise in this area, please do comment.

no expertise and no strong feelings. In particular, no intention to discredit anybody's work or to sound disrespectful. My apologies if this came out wrong.

No need to apologise - the reason why we (W3C) put out working drafts is that we make mistakes, or write specs that don't include some community or other because we don't know about them.

Liam

See the "Status" section of the document on www.w3.org/TR/

Thanks to your link i have searched the archives a bit and have learned that 1) there are color-interpolation and color-interpolation-filters properties 2) these have been in SVG for a long time

It is not clear to me in what scope CSS compositing will use these properties.

Again, feel free to post a comment requesting that the draft be made clearer.

However, if i go by example of the Filter Effects Draft[1] --which both explicitly targets CSS and references the color interpolation properties-- this makes my original concerns look unfounded. When the rendering color space is explicitly specified, there may be differing browser capabilities to deal with, but it is hard to imagine any adverse impact on GIMP.

The only thing I see is that GIMP should be able to reproduce the specified compositing effect accurately. Long term, I expect all browsers to behave pretty much identically, to the extent this makes sense in different hardware and operating environments. Certainly that's the goal and the reason for the spec.

Best,

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
The barefoot typographer - http://www.holoweb.net/~liam/