peter (yahvuu) wrote:

first: let me say that there is some real innovative stuff in this post, it is surely intriguing me.

here's an idea how icons for layer modes could look like: http://yahvuu.files.wordpress.com/2009/10/layermode-sshot-proposed.png

The icons provide a color-coded overview of how blending affect brightness:
- blue: reduced brightness
- green: neutral, brightness unchanged - red: increased brightness

Technically, these are diagrams where the x-axis is the bottom layer brightness
and the y-axis denotes the top layer brightness. The brightness difference caused
by the blending operation is then color-coded as described above. The full explanation is available at: http://yahvuu.wordpress.com/2009/09/27/blendmodes1/#brightness_diff

I oscillate here all the time between great and fail.

I could go into smaller stuff like the use of (SGA!) color (UI theme colors must be taken into account) but there is a much bigger interaction-design-fish to fry:

to have a reason to add these icons to GIMP, they really have to add something for usability, not just be different enough icons that happen to be similar in their group. what the icons have to deliver is additional _user_insight_ into the modes, in addition to the name of the mode. also this insight must _feel_ to be true, it must match users' experience.

this is the ultimate arbiter and this plan needs work before it makes a chance of getting there. I actually doubt that icons can be made that pass the criteria above and not involve user-thinking of "OK, a vertical ramp was overlaid with a horizontal one and..."

the current model for the use of modes is that users gather experience through trying modes and evaluating results. the regrouping we done after 2.6 is helping out in that regard, having alternatives in the same group.

in that light this is also an interesting contribution:

the reason for re-grouping is explained here: http://yahvuu.files.wordpress.com/2009/10/layermode-grouping.png

one of the first things it shows is what is working in Martin Nordholts reordering (marked 2.7.1 in the pic above): that we have sections in the menu that are described by their first item: lighten(-only), darken(-only), overlay, difference.

what the new proposal points out is:

a) grain merge is in the wrong group, should be in overlay b) normal mode is should be in overlay group, is strongest of all c) dissolve is, ehm, special (btw: the icon of dissolve shown here really works according to the benchmark of insight _and_ feels correct)

I say:

a) yes I see the point, let fix that b) I am not sure and would like to know how users feel about this. I really do not like that suddenly everything is ordered strong-to-soft, the other groups are is soft-to-strong c) we are stuck with it (are we?) and it depends on b) if it need to be moved around.

btw, here:

there is a grab bag of modes never seen in GIMP. do we want to (artistic need, not compatibility) and can (effort) add some of them?

wait! am I proposing bloat? >^}

--ps

founder + principal interaction architect man + machine interface works

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

On 10/01/2009 06:40 PM, peter sikking wrote:

peter (yahvuu) wrote:

first: let me say that there is some real innovative stuff in this post, it is surely intriguing me.

I can only agree, really nice work yahvuu

there is a grab bag of modes never seen in GIMP. do we want to (artistic need, not compatibility) and can (effort) add some of them?

Effort-wise it is not a problem to add more layer modes, but I have for a long time felt that layer modes is just a primitive and naive way to achieve some kind of non-destructiveness.

Assuming the introduction of GEGL will be severely crippled if done within the limits of GIMP 2.x backwards compatibility and that we decide to go for GIMP 3.x, wouldn't it be interesting to try to get rid of the layer mode concept as it is now and instead couple it more with the rest of the non-destructiveness GEGL will provide? Or are people too used to the concept of layer modes that it would be suicide to make them less prominent?

BR, Martin

Martin Nordholts wrote:

there is a grab bag of modes never seen in GIMP. do we want to (artistic need, not compatibility) and can (effort) add some of them?

Effort-wise it is not a problem to add more layer modes, but I have for a long time felt that layer modes is just a primitive and naive way to achieve some kind of non-destructiveness.

that is a good bit of reality-check. are we just just catching up with somebody else's legacy issues?

well, I used to think that adjustment layers was "just a primitive and naive way to achieve some kind of non-destructiveness."

so '90s. >^}

but now I see that

- doing a (non-destructive) operation on a layer with a selection - paint (non-destructive) with a certain mode/tool/plugin (later) on a layer
- applying an adjustment layer (non-destructive) with a layer mask

can achieve exactly the same results and each of them is completely valid, simply depending on what each user finds more logical in the spur of the moment.

Assuming the introduction of GEGL will be severely crippled if done within the limits of GIMP 2.x backwards compatibility and that we decide to go for GIMP 3.x, wouldn't it be interesting to try to get rid of the layer mode concept as it is now and instead couple it more with the rest of the non-destructiveness GEGL will provide? Or are people too used to the concept of layer modes that it would be suicide to make them less prominent?

I think applying layer modes to layers with either 'found image' material or users' own painting is a way of working that can be the most comfortable for a lot of cases and users. removing it seems rather impossible.

as I said: only artistic need (not one-upmanship) should be a reason add one or more layer modes to our arsenal.

maybe there are simply zero arguments to add modes...

meanwhile, can the overlay thing be repaired file-backward-compatible?

--ps

founder + principal interaction architect man + machine interface works

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

Martin Nordholts wrote:
[cut]

Or are people too used to the concept of layer modes that it would be suicide to make them less prominent?

First of all, my field is digital painting/drawing [1], not photography retouching, so we may have different views on this.

I rarely use layer modes except for the Overlay one which I use quite often [2], but I've seen many people using them extensively, mostly for artistic work, in order to create effects and tricks of all sorts.

I personally have never thought of layer modes as way to obtain primitive non-destructiveness, but as one to obtain some effects that would be otherwise long/tricky/impossible to do or to have more control on them compared to filters/plug-ins.

Will GEGL be able to do the same (or even more advanced ones) layer operations as layer modes currently allow?

If yes, then I have no problem in removing the layer mode concept, as probably won't the majority of people who uses them now.

If not/maybe not, then I think they will definitely need to remain.

***

[1] By the way, many people would find nice to see more digital-artist oriented features such as a mixing brush for example, of which there's a third party GIMP source code patch here:

http://sourceforge.jp/projects/gimp-painter/releases/

[2] I use paint modes more, especially Multiply, as it's so useful. Off-topic note: paint modes would be much more useful if there was a "sample merged" option for painting tools too, so that they will pick up colors from lower layers.

Akira wrote:

[1] By the way, many people would find nice to see more digital-artist oriented features such as a mixing brush for example, of which there's a
third party GIMP source code patch here:

http://sourceforge.jp/projects/gimp-painter/releases/

I remember and checked: we discussed this in july 2008.

even our brush mistress Alexia Death chipped in: GIMP is an image manipulation program (including "wild brushwork over collages of found images") but not a paint-from-scratch app.

so I am sorry. no additions solely for digital-artists.

--ps

founder + principal interaction architect man + machine interface works

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

peter sikking wrote:

so I am sorry. no additions solely for digital-artists.

Many people (and really I mean many) use Photoshop or GIMP, the closest open source equivalent program, for "paint-for-scratch" work even though they're really not suited for this job. This is because almost all specialized programs (included the famous Corel Painter) fail in so many aspects of raster image processing/editing that their advantages in artistic use are quickly overshadowed by them.

GIMP may be headed to other directions, but I believe there is a strong demand for such features which cannot be ignored, as demonstrated for example by this mixing brush source code patch I linked in my previous post or Ramon Miranda's Gimp Paint Studio resource collection.

Perhaps a more advanced brush engine in the future can overcome the current limitations without expressly introducing digital-artist-only features? Not really a question, just a hope.

On 10/01/2009 07:46 PM, peter sikking wrote:

meanwhile, can the overlay thing be repaired file-backward-compatible?

If you refer to the Overlay layer mode being different when using GEGL compositing compared to legacy compositing, then yes I'm sure it's repairable, and we don't have much choice but to fix it somehow. Probably by having a "legacy compositing mode" also when using GEGL. Making GIMP 2.6 XCF files not openable in GIMP 2.8 isn't an alternative.

BR,
Martin

Martin Renold wrote:
[cut]

But those
brush modes would "copy" the composited image into the current layer and brighten it there. The result would look on the screen as if you had flattened the image first. If I understood you correctly, this is exactly what you proposed in your footnote?

Yes, I meant exactly this!
Of course it would be an optional setting.

David was somewhat enthusiastic about this, but I'm still wondering whether this would not result in some major annoyances, compared to layer modes?

I still think layer modes (or layer operations) have their place, especially if they involve pre-made resources (for example the Overlay layer mode I wrote about in my previous post in my case is used mainly to apply subtle textures to areas painted on lower layers, for example paper/canvas texture).

When you make invisible a layer below the one you used to brighten the image, you would see the (faint) image structure from the hidden layer because some of it was copied while brightening. Would this be no big issue?

Now that I think about it, you're right, this could be a problem depending on the situation.

Would it be important to also be able to manipulate (eg. brighten) the current layer only, in the way that brush modes work right now in GIMP?

I think it would be important/useful to be able to affect only a limited set of layers. I think that layer groups/trees, which will be implemented in the 2.8 version of GIMP will add this capability (if a priority system based on layer position within the tree will be implemented. By the way, this is where GEGL is heading, from what I know).

I understand if you're more interested in GIMP than in MyPaint, but I am still interested whether this would be compatible with your workflow...

It appears it would be. Some issues would have to be sorted out though. By the way, this side-discussion started because on Photoshop CS4 I can use different painting modes even on totally transparent areas (if there is nothing in the background, then the brush behaves as if the painting mode is "Normal"), while GIMP does not.

And, have you already used a software that offers such a feature?

I can't try it again right now, because the trial period has expired and for some reasons it doesn't work anymore (it should, but without the file save features), but if I remember well Paint Tool SAI is a very good software for illustration/painting/drawing which handles layers and layer modes better than other programs:

http://www.systemax.jp/en/sai/

I think layer modes here work on a hierarchy tree structure. Try it if you can.

bye,
Martin

[1] http://www.davidrevoy.com/temp/mypaint-request/ [2] http://forum.intilinux.com/mypaint-development-and-suggestions/layer-blending-mode/

Thanks,
SHIRAKAWA Akira

Martin Nordholts wrote:

On 10/01/2009 07:46 PM, peter sikking wrote:

meanwhile, can the overlay thing be repaired file-backward- compatible?

If you refer to the Overlay layer mode being different when using GEGL compositing compared to legacy compositing, then yes I'm sure it's repairable, and we don't have much choice but to fix it somehow. Probably by having a "legacy compositing mode" also when using GEGL. Making GIMP 2.6 XCF files not openable in GIMP 2.8 isn't an alternative.

what I mean is that right now (2.6) when overlay is chosen, soft light is executed.

I think we should have in 2.8 a working overlay mode (also for legacy compositing). I think the following plan can technically work and is usable:

- overlay gets repaired and assigned new mode enumeration number

- when any old gimp file is opened and an old overlay mode is encountered,
soft light is substituted as the layer mode, also in the UI. this sub does not mark the gimp file as dirty (changed).

this means old files display the same as before.

--ps

founder + principal interaction architect man + machine interface works

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

peter sikking wrote:

Akira wrote:

[1] By the way, many people would find nice to see more digital-artist oriented features such as a mixing brush for example, of which there's a third party GIMP source code patch here:

http://sourceforge.jp/projects/gimp-painter/releases/

I remember and checked: we discussed this in july 2008.

even our brush mistress Alexia Death chipped in: GIMP is an image manipulation program (including "wild brushwork over collages of found images") but not a paint-from-scratch app.

so I am sorry. no additions solely for digital-artists.

Hope that gets revisited sometime--art's what I use GIMP for.

Patrick

Akira wrote:

peter sikking wrote:

so I am sorry. no additions solely for digital-artists.

Many people (and really I mean many) use Photoshop or GIMP, the closest open source equivalent program, for "paint-for-scratch" work even though they're really not suited for this job. This is because almost all specialized programs (included the famous Corel Painter) fail in so many aspects of raster image processing/editing that their advantages in artistic use are quickly overshadowed by them.

well, another way of saying that is that these specialised paint programs need improvements for you paint-from-scratch guys, their core audience.

in the discussion where the GIMP team formulated what they are, it was explicitly mentioned that GIMP is not an app like Painter.

GIMP may be headed to other directions, but I believe there is a strong demand for such features which cannot be ignored, as demonstrated for example by this mixing brush source code patch I linked in my previous post or Ramon Miranda's Gimp Paint Studio resource collection.

Perhaps a more advanced brush engine in the future can overcome the current limitations without expressly introducing digital-artist- only features? Not really a question, just a hope.

let's put it this way, that GIMP still works out for you paint-from- scratch
guys is a side effect of what the GIMP team decided what they want to achieve. GIMP needs a better general-purpose paint system, Alexia is on the job (I also help out there) and you will also win at the end.

the stress in "no additions solely for digital-artists" is on _solely_. if an addition that you are craving for can be proven to be a paint improvement in general, or can be morphed into something that is a paint improvement in general (as seen through the eyes of our core users) then I say let's do it.

part of that is also that I can imagine adding it without adding bloat (like adding another tool in the toolbox), integration is crucial.

I think the GPS brushes are an example of that. As far as I know we are including them. All I have to say about it is: please take only the sub-set of brushes that are truly general-purpose, in the sense that the person who reviews them can see each of these used in a thousand different ways, depending on the paint settings they are used with.

--ps

founder + principal interaction architect man + machine interface works

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

peter (yahvuu) wrote:

peter sikking wrote:

to have a reason to add these icons to GIMP, they really have to add something for usability, not just be different enough icons that happen to be similar in their group. what the icons have to deliver is additional _user_insight_ into the modes, in addition to the name of the mode. also this insight must _feel_ to be true, it must match users' experience.

OK, i can't imagine that it's possible to visualize the subtle difference
in _feeling_ between, say hardlight and grain merge.

actually you are doing all right in the difference department, but I started
seeing disinformation in the feel-true department. I think you can have a
shot at trying to fix that.

Surprisingly enough, the
'brightness diff' plots turned out to be so characteristic that i soon started
to identify blend modes by their plots instead of by their names. But then,
i've probably been looking at too many such diagrams lately :-)

don't forget you have an engineering background and can do the math. I expect the majority of our core users to simply use this by feeling and build up a wealth of experience that that can retrieve by using the names of the modes.

i guess that litmus test can be used in the opposite direction as well:
if it is impossible to create suitable icons for layer modes, then they probably should not be presented as a drop-down list.

no that is not true.

what you run into is the very limited possibilities to express something (usable) in an icon of this size vs. the incredible richness that language has. I do admit that these mode labels have their legacy issues,
nothing to be done about that.

I wonder if the criteria are different for preset selection, e.g. for the curves tool. Here, any visual hint of distinction seems like an improvement
over pure textual choices like 'curves 2009-08-01' or 'curves 2009-08-02'.
Even if there's no correspondence with the 'feeling' of a certain curve.
Or is this case within the same category as general icons?

I have discussed ages ago with Mitch what is needed on the levels/ curves/etc.
(remembered) presets.

for the automatically created presets what is needed to help selecting is not only date + time, but also the the result: the thumbnail of the layer _after_ applying this levels/curves/etc. to it. this gives two orthogonal ways to identify an automatically created preset.

for the presets that users saved + named, the richness of language is enough and no icon is needed.

--ps

founder + principal interaction architect man + machine interface works

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

so I am sorry. no additions solely for digital-artists.

I am afraid that you undervalue creativity of who use gimp for photo or image editing

I explain better, even if the goal may be different (as photo-retouch differs from use gimp to paint) the tool used are often the same

So as who use gimp for paint may also take advantage of filters and tools developed with the goal of photo editing...who use gimp to retouch or edit, (in other words the group that you focus as the main users )may well benefit of improvement of brush tool...because they use same tools

In this case as example i will not exclude the utility of a mix brush for restore digital or scannered images

photocomix wrote:

so I am sorry. no additions solely for digital-artists.

I am afraid that you undervalue creativity of who use gimp for photo or image
editing

I explain better, even if the goal may be different (as photo- retouch differs
from use gimp to paint) the tool used are often the same

So as who use gimp for paint may also take advantage of filters and tools
developed with the goal of photo editing...who use gimp to retouch or edit,
(in other words the group that you focus as the main users )may well benefit of improvement of brush tool...because they use same tools

In this case as example i will not exclude the utility of a mix brush for
restore digital or scannered images

you see, now we are talking. by taking the debate to how a certain addition can really improve the productivity or creativity of our core groups, how painting can be made better in general, there is much better chance of getting somebody to listen and to get it integrated, one day.

--ps

founder + principal interaction architect man + machine interface works

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

peter (yahvuu) wrote:

Martin Nordholts wrote:

[..] I have
for a long time felt that layer modes is just a primitive and naive way to achieve some kind of non-destructiveness.

yes, the evil plan which spun off my posting is to get rid of the layer mode concept.

funny enough I had realised before your mail rolled in that that is impossible, for the following reason:

the layer mode controls the mathematical operation used compositing of that layer. there is no _reasonable_ way (right now) to achieve the same results in a different way. here the fundamentals of what it does prove it to be unique.

peter sikking wrote:

maybe there are simply zero arguments to add modes...

each new mode adds one finer step for adjustment of blending characteristics.

If i want to darken a layer by itself, the curves tool allows nearly infinite
different characteristics of darkening. If i want to darken a layer by another one, there are a total of 3(!) characteristics available: 'darken only', 'multiply' and 'burn'. Of course, there won't ever be enough layer modes, which is one reason why they have to die long- term...

no, your analogy is wrong.

layer mode sets the mathematical operation.

- if you want control over the strength, that is what layer opacity is for - if you want fine control over the characteristics curve, use curves on the layer
- if you want to mask where what is used, use the layer mask

your thought of creating a 'tool' that could make this more hands-on is intriguing though. give it a shot.

[..] but now I see that

[..] applying an adjustment layer [..] [..] is completely valid, [..]

i'd like to take the same line:
if a layer is just a transparent sheet, and a composition is just a projection of a stack of sheets, then it's most natural to insert (photographic) filters in between. Say, a colorizing red glas or a freaky effect lens, in general: an adjustment layer.

note that in the future a adjustment layer will be shown to be the natural choice when the same adjustment needs to be made on several (composited) layers. if it is one layer that needs an adjustment 'just doing it' on the layer itself will be the natural way.

keep coming with the evil plans, there are helping us.

--ps

founder + principal interaction architect man + machine interface works

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

so after writing in my last mail:

layer mode sets the mathematical operation

and seeing that the user requests for layer modes are not exactly streaming in, I was thinking during cooking: "I should have a look at

again, and look for really different heat maps (you know yahvuu, they are good for that) and math formulas with discontinuities."

actually a question for peter (yahvuu): how complete is this overview? (I think "negation is looking for a mate, purely on symmetry grounds) lots of insights how current modes work, btw.

so after an entertaining hour of map spotting, what have I learned?

first, I know now why our Darken section is one Shorter that our Lighten one: we are missing "subtractive" (that needs a name not soooo close to our Subtract).

then looking for interesting heat maps, with the overview much reduced (@18%) to find the really different modes.

well, "vividlight" looks interesting and different. then there are quite a few modes that don't do much or not that different from what we have.

"freeze, heat, reflect & glow" seem to come as one package. but then "glow" seems to really 'do what it says on the tin' and may be a worthy addition just on its own.

that's it really what I could fish out: "subtractive", "vividlight" + "glow"

--ps

founder + principal interaction architect man + machine interface works

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

yahvuu wrote:

actually a question for peter (yahvuu): how complete is this overview?

most notably, the porter-duff modes are not listed. I'll have a look to make the overview as complete as possible.

I am interested in that. modes are like a box of chocolates, you'll never know what you gonna get.

first, I know now why our Darken section is one Shorter that our

Lighten one: we are missing "subtractive" (that needs a name not soooo close to our Subtract).

yeah, in photoshop, the names are: 'subtractive' => 'linear burn'
'additive' => 'linear dodge'
which is a lot better.

It's still not perfect though, as the most prominent property of burn/dodge
is the capability to increase the local contrast -- which is not featured
by their 'linear' counterparts. But at least the confusion of 'subtractive'
not actually using a subtraction term in the formula is avoided.

well, we cannot rename addition (and it is a clear name at that), and linear burn is really not where I would like to go.

After a look at the math (thanks for that) and a bit of brainstorming with nonsense names like "addition against all odds" or "orchestral addition in the dark" I arrived at something that does work: "Dark addition" (because it is an addition, shifted full range towards black).

Actually, i think the old 'subtract' mode should be removed, when 'subtractive' gets added: just invert the blend layer and you get the old 'subtract' mode back.

no no no. everything stays there and keeps its name. file and user backward compatibility is needed here. that sounds very 'developer', and I fight a lot of these battles on the other side, but in this case it is true.

Along the same lines, what is the right to exist for 'divide'? - it's just 'dogde' with an inverted blend layer.

it is a straightforward mathematical mode, maybe used to prepare a mask for further use. it is part of the difference group that provides all kinds of mind-bending (inverting) stuff. after moving grain merge out I am happy to leave that group as-is.

An accepted pair of this type is grain extract/merge, for which useful techniques exist [1], but also for dodge/divide?!? If so, possibly the rest of the modes are candidates for 'mode bloat', too, say a new mode: 'multiply with inverted blend layer'...

avoiding mode bloat is a good one. but please do not mix up the different reasons why modes are there right now. Like having a set of 'layer math' or simply results oriented (burn, lighten only). you see there are some very subtle reasons to add a new mode or not.

I had some more fun with the heat maps in

and I think I start to understand the algorithm-aesthetics better. as you pointed out, the lighten and darken groups are exclusively red or blue, which means that something like freeze/reflect do not fit there. then our overlay group modes have equal areas of red and blue in it. this makes heat/glow a better candidate then the two rows above or the one below them.

then again there is no artistic value in that...

--ps

founder + principal interaction architect man + machine interface works

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

On 2009-10-03, yahvuu wrote:

Using an analogy, the current situation for blending is like not having the curves tool, but only preset curves to choose from. And indeed there's a relation between curves and blending, for each RGB blend mode can be described as a set of 256 curves, at least within 8bit-accuracy.

"A curve" is a function of one variable. "A layer mode" is a function of two variables ("value" of a current level, and "value" of the composite of levels below it; here "value" is, typically, the level of R/G/B considered separately).

[Here I assume Porter-Duff semantic of layer modes, so transparency is handled "automatically" when a function of 2 variables is given. Otherwise (as with Dissolve) it is two functions of 4 variables: given levels and transparency of this level, and those of the composite below, one gets new level and new transparency.]

The problem with your proposal is 2-fold:

1) "Invert" is just a particular case of an "apply-curve"; let's remove this redundant misfeature;

1') Likewise for "levels".

2) More seriously: a graph is a convenient down-to-earth representation of a function of one variable. It allows a simple intuitive concept of direct manipulation.

I never saw a similar in convenience UI to directly manipulate a function of two variables.

Hope this helps, Ilya

P.S. When GIMP has a JIT compiler present, there would be no significant problem in representing "a layer mode" as "a programming language CODE" implementing a function of two variables. [Note similarity with how shaders in OpenGL work...]

On 2009-10-21, yahvuu wrote:

The analogy was given to show why the the current interface to blending (i.e. choosing among a discrete set of layer modes) is a poor one:

And my message was intended to show why the current interface is a very good one...

it is both limited and mostly non-intuitive.

IMO, "non-intuitive" is 100% fault of GIMP developers. The current documentation is plain insulting...

Layer modes is a very simple and intuitive concept. The only thing missing is documentation (I'm going to address it in more details when the waves from my previous posts would subdue...).

Hope this helps, Ilya

P.S. WRT "limited": what *exactly* do you want to do which follows the semantic of layer modes ("a function of two variables" applied to pixels), and you cannot do now (AND would not be able to do when "decent groupsing" is allowed)?

On Sat, Oct 24, 2009 at 9:48 AM, Ilya Zakharevich wrote:

On 2009-10-21, yahvuu wrote:

The analogy was given to show why the the current interface to blending (i.e. choosing among a discrete set of layer modes) is a poor one:

And my message was intended to show why the current interface is a very good one...

it is both limited and mostly non-intuitive.

IMO, "non-intuitive" is 100% fault of GIMP developers.  The current documentation is plain insulting...

At this point I support banning you from this list for your repeated insults and self-righteous attitude towards people who are freely volunteering their time and effort.

Further, insulting people who have very little to do with the subject is even worse (GIMP documentation is managed by different people, there is very little overlap between GIMP docs development and GIMP development)

Layer modes is a very simple and intuitive concept.  The only thing missing is documentation (I'm going to address it in more details when the waves from my previous posts would subdue...)

The documentation of layer modes is outstandingly clear and thorough -- this is largely due to 'scb' and later 'j.h's excellent work, as you can see in the comments.

http://git.gnome.org/cgit/gimp-help-2/tree/src/concepts/layer-modes.xml

The only thing I would change about that documentation if I knew how, is make the images showing the effect of specific layer modes change to the base image on mouse-over so you can easier discern the exact effect.

Rather than better documentation, I believe better visualization is the path to improvement of user understanding: Using the layer thumbnails (and GEGL cache?) to build a 'preview' composited thumbnail for each mode and show it (next to the text or as a tooltip) would help the user to understand at a glance the general working of a layer mode they are considering. The composite thumbnails could be generated on-demand and otherwise in idle time (so the person who knows exactly which layer mode they need would not be impacted -- they could select layer mode just as fast as before, and if they did need the thumbnails, they'd only need to wait a fraction of a second longer.)

On 2009-10-01, yahvuu wrote:

Technically, these are diagrams where the x-axis is the bottom layer brightness and the y-axis denotes the top layer brightness. The brightness difference caused by the blending operation is then color-coded as described above. The full explanation is available at: http://yahvuu.wordpress.com/2009/09/27/blendmodes1/#brightness_diff

Yet another idea: for most of "puzzling" layer modes the mode is just a function F of two variables: "level in current layer", and "level L in composite of layers below" (here "level" is the value of a particular channel). So for each value of "level in current layer", one gets a *curve* applied to the "composite of layers below" (essentially, I consider the effect of the mode when the current level is a solid color).

Moreover, for most of the modes, F is linear in "level in current channel" (or piecewise-linear on [0..128] and [128..255]). So in this variable, knowing F for very few values allows one to "reconstruct" F for the rest of the values. And it is not mentally hard to consider simultaneously 3 graphs of 3 functions: F(20, L), F(128, L), F(245, L).

So what about the following icon: take some background color in good contrast with all gray20, gray128, and gray245. On this back, plot the graph of F(20,L) in gray20, etc. One gets an icon with 3 graphs.

For me, it is going to be a much better visualization than "a color-coded graph of a function of 2 variables". But it is quite probable that I'm not representative enough. What do you think?

Yours, Ilya

P.S. One could also combine both icons (maybe even one layered on top of another)...

On 2009-10-24, Ilya Zakharevich wrote:

So what about the following icon: take some background color in good contrast with all gray20, gray128, and gray245. On this background, plot the graph of F(20,L) in gray20, etc. One gets an icon with 3 graphs.

Forgot to explain why values 20 and 245 (gray128 is more or less self-explanatory: it is a "neutral" [= "no-change to what is below it"] color for a lot of modes, and plotting a diagonal gray128 graph for these modes is a major hint)...

A lot of modes involve clamping of levels outside [0..255] range. As a result, graphs describing the effect of white and black are the same for a lot of modes.

For example, "hard light" and "grain merge" modes give the same effect when the top level has only black, gray128, and white. To disambiguate, one should better replace black and white by similar near-white and near-black grays.

Thinking about it more: maybe the graphs would look more distinguishable if near-white and near-black are in fact 2/3 of the way between gray128 and white/or/black. Then the plots would correspond to gray40, gray128, gray215.

Ilya

P.S. Another visual aid: scanning internet for recipes of image manipulation, it looks like people do not realize that instead of combining two copies of a layer in "Multiply" mode, one could as easy use (non-destructive) gamma=0.5.

So one may want to plot on the same graph ALSO the curve equivalent to combining image with itself. Then one needs to have 5 contrasting colors: background, 1 for effect-of-duplication, gray40, gray128, gray205.