Martin wrote:

The layer mode combo box contains groups of layer modes. I fail to see the logic behind the current grouping and instead propose a new grouping. The new groups are:

* Different alpha compositing methods * Modes that always gives a brighter result * Modes that always give a darker result * Overlay-like modes
* Modes that can give completely different colors * Modes based on HSV/HSL.

grouping modes with similar results will help comparing and goal-driven experimenting.

The darker and lighter modes have been internally sorted based on how much they tend to affect the image, see end of mail.

is it then a coincidence you got implicitly almost every of these groups labelled up by their first item (Lighten, Darken, Overlay, Difference)? it is a good thing this is happening.

it is also good that as a result it is easier to guess what the opposite of multiply is (screen). one thing that jars is that it becomes clear that divide has no opposite/complementary mode.

Attached to this mail is a patch that does this regrouping so you can try how it feels. Does anyone have any problems with me commiting that?
If not I will commit it to trunk within a few days.

the only thing I would change is to swap the order of Grain merge and Grain extract. simply because it is explained as a workflow in that order in the manual.

New groups:

Normal
Dissolve

Lighten Only
Screen
Dodge
Addition
Divide

Darken Only
Multiply
Burn
Subtract

Overlay
Soft light
Hard light

Difference
Grain merge
Grain extract

Hue
Saturation
Color
Value

--ps

founder + principal interaction architect man + machine interface works

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

Hi,

On Sat, Nov 1, 2008 at 11:06 PM, Martin Nordholts wrote:

peter sikking wrote:

Martin wrote:

The darker and lighter modes have been internally sorted based on how much they tend to affect the image, see end of mail.

is it then a coincidence you got implicitly almost every of these groups labelled up by their first item (Lighten, Darken, Overlay, Difference)? it is a good thing this is happening.

No it was not a coincidence, I deliberatly put Lighten, Darken and Overlay at the top of their groups to make them act like "labels". Difference was more or less a coincidence though, but you're right in that it makes a nice label as well since you can end up with completely Different colors when using modes in that group.

the only thing I would change is to swap the order of Grain merge and Grain extract. simply because it is explained as a workflow in that order in the manual.

Good point, I will swap those.

Actually, I didn't understand why you grouped them with Difference (even given your explanation of 'can produce completely different colors'); I would have grouped them with Overlay, since they both provide darkening ( on one side of 128) and lightening (on the other side of 128),

In general I like these new groupings a lot, particularly the positional correlation (add/sub, dodge/burn) I'm a bit puzzled as to why Multiply is paired thusly with Screen -- Divide is closer to being the opposite of Multiply IMO (from a visual inspection div(mul(x)) and mul(div(x)) are closer to the original x than scr(mul(x)) or mul(scr(x)) )

David

grouping. The new groups are:

* Different alpha compositing methods * Modes that always gives a brighter result * Modes that always give a darker result * Overlay-like modes
* Modes that can give completely different colors * Modes based on HSV/HSL.

there are 2 more generic categories Symmetrical and Asymmetrical

To know that a mode is asymmetrical is useful, because then swapping layers positions open new options

Maybe is possible prefix a symbol as a double arrow to the Symmetrical modes Names?

Unisciti alla community di Io fotografo e video, il nuovo corso di fotografia di Gazzetta dello sport: http://www.flickr.com/groups/iofotografoevideo

On Sun, Nov 2, 2008 at 12:02 AM, Martin Nordholts wrote:

David Gowers wrote:

Hi,

On Sat, Nov 1, 2008 at 11:06 PM, Martin Nordholts wrote:

Actually, I didn't understand why you grouped them with Difference (even given your explanation of 'can produce completely different colors'); I would have grouped them with Overlay, since they both provide darkening ( on one side of 128) and lightening (on the other side of 128),

I had them grouped with Overlay for a while but ended up putting them under Difference since Grain Extract can look very similar to Difference. And from an aesthetic point of view it looks better to have 3 and 3-groups than 5 and 1-groups.

I'm a bit puzzled as to why Multiply is paired thusly with Screen -- Divide is closer to being the opposite of Multiply IMO (from a visual inspection div(mul(x)) and mul(div(x)) are closer to the original x than scr(mul(x)) or mul(scr(x)) )

One have to differentiate between mathematical similarities of the blending formulas and the effect the modes have on the colours we perceive. From this point of view Multiply pairs better when Screen than with Divide.

No, that's what I was saying -- from VISUAL inspection.I didn'c check the numbers, just how it looked when I painted in div mode then multiply mode with same color, etc..

Actually from this point of view Divide and Subtract should probably be moved to the Difference category. They can produce completely new colours as well. Addition doesn't really have a counterpart (Addition is Linear Dodge in PS and GIMP has no Linear Burn counterpart).

Linear Burn is exactly a reversed Subtract, yes? that is, result = dest - (1-src)
rather than
result = dest - src
?

The problem with introducing Linear Burn to GIMP is the name; what should it be called? One alternative would of course be to call Addition Linear Dodge instead.

I like that. For layer mode usage. (for painting, the current Subtract behaviour is more symmetric with Add than Linear Burn would be.)

I think it would be wise to plan for eventually having the layer modes list something like the toolbox tools currently are: a large set, with each item individually hideable (and new ones installable -- though they would have to be visually differentiated so the user knew they might not load in a 'baseline' GIMP install). Perhaps the disabled ones could be left in an 'others' "submenu" to leave them accessible while reducing their interaction speed cost.

So, we could consider which ones would be the least valuable, and let that inform the sorting.
For example:

* Color mode is markedly inferior to PS Color mode (because it uses HSL, rather than LAB colorspace, the transference is not only of color data but some intensity data.). It's important to include some Color mode, however if we can get Color mode working in LAB space, we should probably show that by default and hide old style Color mode. * Also consider doing the same with Hue and Saturation, using a polar transform of LAB (ie. LCH),
hue transfers only the angle, saturation transfers only the radius.

Personally, only about 7 of the layer modes have any use to me: normal dissolve difference multiply divide grainMerge grainExtract

Hi,
On Sun, Nov 2, 2008 at 9:34 AM, Martin Nordholts wrote:

I understand what you mean now. We are not doing the same kind of paring though. You are pairing layer modes that are cancelling each other out while I am paring layer modes that give opposite effects on lightness. To convince yourself of that Multiply pairs with Screen in the latter case, create an image with two layers, one with a vertical black-to-white gradient and the other with a horizontal black-to-white gradient (so that all possible combinations of channel intensities are blended). Then examine the result of having the top layer first set to Multiply and then to Screen.

Yes, I see what you mean. Overall effect rather than mathematical relation.

Linear Burn is exactly a reversed Subtract, yes? that is, result = dest - (1-src)
rather than
result = dest - src
?

Yes exactly, Linear Burn is

result = dest - (1 - src) = dest + src - 1

* Color mode is markedly inferior to PS Color mode (because it uses HSL, rather than LAB colorspace, the transference is not only of color data but some intensity data.). It's important to include some Color mode, however if we can get Color mode working in LAB space, we should probably show that by default and hide old style Color mode.

I agree, the current Color mode and friends can give pretty unexpected results. Personally I don't think I will put much effort in that in the near future though.

I'm assuming that the separate layer modes will eventually separate into their own files for reasons of speed, in which case this is trivial to implement; request LAB color as the input format, apply normal blending to A and B channels, leave L channel unchanged from dest. I would certainly be willing to do that when the time comes.

Personally, only about 7 of the layer modes have any use to me: normal dissolve difference multiply divide grainMerge grainExtract

Interesting, what do you use Grain extract and Grain merge for?

Colorized shading/lighting. The nice thing about grain merge and extract is they have a very regular effect on intensity, which means it is comfortable to eg. paint using Grain Merge on a Grain Merge-moded layer.
If you start with a layer filled with color #808080 which is neutral: Say you have colors #606060 and #a0a0a0, painting with one of those will lighten the layer by 32; if you swap colors you will be darkening the image by 32. Providing layer opacity == 100%, that will result in a literal change of 32 to the underlying image. That predictable symmetry helps.

Also, you may have noticed, Grain merge creates complimentary colorings; eg Grain merging bright yellow #ffff90 makes the image brighter and yellower, Grain extracting the same bright yellow makes the image darker and more blue.

Hi,
On Sun, Nov 2, 2008 at 6:46 PM, Martin Nordholts wrote:

David Gowers wrote:

I'm assuming that the separate layer modes will eventually separate into their own files for reasons of speed, in which case this is

I meant separate operations, here.

trivial to implement; request LAB color as the input format, apply normal blending to A and B channels, leave L channel unchanged from dest. I would certainly be willing to do that when the time comes.

I have ported almost all (only Soft light pending) layer modes to a GEGL operation. It is yet unclear if this will be eventually used or if it will more serve as a reference implementation, but in any case would improvements to how Color behaves best be written against this file:

http://svn.gnome.org/viewvc/gimp/trunk/app/gegl/gimpoperationpointlayermode.c?view=markup

Yes, I've looked at that. It might be possible to implement Color mode there... If prepare () is called at the time I hope it is, then I can set format to 'CIE Lab alpha double' (the only implemented LAB format in BABL) as needed when COLOR mode is in use. This would achieve a correct result.

As you can see the whole thing is very readable and patchable. If you in GIMP trunk do View -> Use GEGL then the above GEGL operation is used for compositing the projection. Once the port is complete I will write a mail to this list explaining some important differences between this op and the legacy layer mode compositing.

BR,

Oh, what does BR stand for? I've read that several times and still none the wiser :)

David

peter sikking wrote:

the only thing I would change is to swap the order of Grain merge and Grain extract. simply because it is explained as a workflow in that order in the manual.

I would also like to see a dynamically updated list at the top of the list that shows the last 3-5 used blend modes under a heading of "Recent:". This may be outside the scope of the OP's original suggestion, but for many users there are a select few modes that are used frequently, and having to dig through a long list slows things down.

Hi vabijou,

On Wed, Nov 5, 2008 at 2:21 AM, vabijou2 wrote:

peter sikking wrote:

the only thing I would change is to swap the order of Grain merge and Grain extract. simply because it is explained as a workflow in that order in the manual.

I would also like to see a dynamically updated list at the top of the list that shows the last 3-5 used blend modes under a heading of "Recent:". This may be outside the scope of the OP's original suggestion, but for many users there are a select few modes that are used frequently, and having to dig through a long list slows things down.

I am such a user, and I say: This is a change I do not want, it would reduce my working speed further.
This is because of the way recently-accessed lists work -- the most recent is at the top. This means unless I am constantly selecting *the* most recent (instead of eg. 2nd most recent), where I have to click to achieve the same result changes, because my choice reorders the list.

In conjunction with locking functionality (so that your later choices no longer change the order or content of the recent-list), this could be effective. I would honestly like similar locking functionality for the recent-filters-list .. the constant disordering is just so confusing and slow that I usually find it faster to select from the original menu path.. which defeats the purpose.

David

On Wednesday 05 November 2008, David Gowers wrote:

I am such a user, and I say: This is a change I do not want, it would reduce my working speed further.
This is because of the way recently-accessed lists work -- the most recent is at the top. This means unless I am constantly selecting *the* most recent (instead of eg. 2nd most recent), where I have to click to achieve the same result changes, because my choice reorders the list.

How about weighted sorting for some uppermost 2-5 flexible entries? Using a certain layer mode adds weight to that mode, and each mode loses some weight again for each action. I think that that's more or less how desktop environments manage their most used applications.

Do you think that would be less annoying?

Another problem (imho) would simply be the added length to that list, which is longer than what feels good to me now already.

Daniel

On Tuesday 04 November 2008, David Gowers wrote:

Hi vabijou,

On Wed, Nov 5, 2008 at 2:21 AM, vabijou2 wrote:

peter sikking wrote:

the only thing I would change is to swap the order of Grain merge and Grain extract. simply because it is explained as a workflow in that order in the manual.

I would also like to see a dynamically updated list at the top of the list that shows the last 3-5 used blend modes under a heading of "Recent:". This may be outside the scope of the OP's original suggestion, but for many users there are a select few modes that are used frequently, and having to dig through a long list slows things down.

I am such a user, and I say: This is a change I do not want, it would reduce my working speed further.
This is because of the way recently-accessed lists work -- the most recent is at the top. This means unless I am constantly selecting *the* most recent (instead of eg. 2nd most recent), where I have to click to achieve the same result changes, because my choice reorders the list.

In conjunction with locking functionality (so that your later choices no longer change the order or content of the recent-list), this could be effective. I would honestly like similar locking functionality for the recent-filters-list .. the constant disordering is just so confusing and slow that I usually find it faster to select from the original menu path.. which defeats the purpose.

David,
as far as filters are concerned, I'd strongly, and that means __strongly__, suggest you to use keyboard shrotcuts to get to your filters. Yes, stopping ytour work to configure keyboard shortcuts is a major pita, and that is why most people don? do it in any software, even knowing it is possible. However, GIMP has setup a unique feature that was once available to all GTK+ applications:
dynamic keyboard shortcuts.
Just enable these once in preferences, and you will never again have to selct a single filter in the thrid menu level more than once. The tooltip on the edit->preferences->interface option that enable these shortcuts is self explanatory.

As for layer combination modes...Martin, is there any clean way of allowiyng setting keyboard shortcuts to layer combiantion modes? That ? be a nice feature to have.

js
->

David

On Wed, Nov 5, 2008 at 4:45 AM, Joao S. O. Bueno wrote:

As for layer combination modes...Martin, is there any clean way of allowiyng setting keyboard shortcuts to layer combiantion modes?

Or mapping to a USB HID device's action. E.g. using Griffin PowerMate's wheel to scroll through modes

Alexandre

Hi,

On Wed, 2008-11-05 at 05:07 +0300, Alexandre Prokoudine wrote:

On Wed, Nov 5, 2008 at 4:45 AM, Joao S. O. Bueno wrote:

As for layer combination modes...Martin, is there any clean way of allowiyng setting keyboard shortcuts to layer combiantion modes?

Or mapping to a USB HID device's action. E.g. using Griffin PowerMate's wheel to scroll through modes

What about using your mouse scroll-wheel? You can already do that (for all combo-boxes, in all GTK+ applications).

Sven

Hi,

On Wed, 2008-11-05 at 05:07 +0300, Alexandre Prokoudine wrote:

As for layer combination modes...Martin, is there any clean way of allowiyng setting keyboard shortcuts to layer combiantion modes?

Or mapping to a USB HID device's action. E.g. using Griffin PowerMate's wheel to scroll through modes

You can already configure your USB device to do that. The layer modes can be changed by Input controllers.

Sven

Hi Joao

On Wed, Nov 5, 2008 at 12:15 PM, Joao S. O. Bueno wrote:

David,
as far as filters are concerned, I'd strongly, and that means __strongly__, suggest you to use keyboard shrotcuts to get to your filters.

This is definitely important. I'm working on it. It takes time to arrange keyboard shortcuts efficiently; I have a color-coded SVG of a keyboard with every important function arranged nearby. Mapping them to keys takes a lot of thought.

Yes, stopping ytour work to configure keyboard shortcuts is a major pita, and that is why most people don? do it in any software, even knowing it is possible. However, GIMP has setup a unique feature that was once available to all GTK+ applications:
dynamic keyboard shortcuts.

I've tried dynamic keyboard shortcuts, and in my experience they result in the same effect as the filters recently-used menu. You assign them on one image, then go to another image and find they are wrong. Or you use the wrong one, or accidentally reassign a really important shortcut (like Undo.). IME, the limit of dynamic shortcuts is the ability of the user to remember them.. my limit seems to be about 1.