Re: [Gimp-developer] Better grouping of layer modes
Hi Joao On Wed, Nov 5, 2008 at 12:15 PM, Joao S. O. Bueno [EMAIL PROTECTED] 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
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. -- View this message in context: http://www.nabble.com/Better-grouping-of-layer-modes-tp20279130p20324960.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Hi vabijou, On Wed, Nov 5, 2008 at 2:21 AM, vabijou2 [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
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 signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
On Tuesday 04 November 2008, David Gowers wrote: Hi vabijou, On Wed, Nov 5, 2008 at 2:21 AM, vabijou2 [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
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 As with almost all feature requests it can certainly be done, someone just have to sit down and think a bit and then write the code for it. In this case that someone is not me I'm afraid. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Martin Nordholts wrote: 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. 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). After doing the rearrangements we end up with the following groups. Things to note is that Addition does not have a counterpart, and that Divide is a bit of an outsider in its group when looking at the blending formulas. If no one objects, the grouping at the end of this mail is what I will commit. / Martin Normal Dissolve Lighten Only Screen Dodge Addition Darken Only Multiply Burn Overlay Soft light Hard light Difference Subtract Grain extract Grain merge Divide Hue Saturation Color Value ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Martin Nordholts wrote: Martin Nordholts wrote: After doing the rearrangements we end up with the following groups. Things to note is that Addition does not have a counterpart, and that Divide is a bit of an outsider in its group when looking at the blending formulas. If no one objects, the grouping at the end of this mail is what I will commit. Commited now to trunk, rev 27540: 2008-11-03 Martin Nordholts [EMAIL PROTECTED] * app/widgets/gimpwidgets-constructors.c (gimp_paint_mode_menu_new): Arrange layer modes into more logical and useful groups. / Martin Normal Dissolve Lighten Only Screen Dodge Addition Darken Only Multiply Burn Overlay Soft light Hard light Difference Subtract Grain extract Grain merge Divide Hue Saturation Color Value ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
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 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 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, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
David Gowers wrote: 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 Oh, what does BR stand for? I've read that several times and still none the wiser :) Or you could just convert to to CIE Lab alpha double on the fly in process() just as I currently convert to and from HSV/HSL on the fly. Best Regards, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Hi, On Sun, Nov 2, 2008 at 6:46 PM, Martin Nordholts [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Better grouping of layer modes
Hi
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.
The darker and lighter modes have been internally sorted based on how
much they tend to affect the image, see end of mail.
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.
BR,
Martin
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
Index: app/widgets/gimpwidgets-constructors.c
===
--- app/widgets/gimpwidgets-constructors.c (revision 27508)
+++ app/widgets/gimpwidgets-constructors.c (working copy)
@@ -107,23 +107,24 @@ gimp_paint_mode_menu_new (gboolean with_
GIMP_NORMAL_MODE,
GIMP_DISSOLVE_MODE,
- GIMP_MULTIPLY_MODE,
- GIMP_DIVIDE_MODE,
+ GIMP_LIGHTEN_ONLY_MODE,
GIMP_SCREEN_MODE,
- GIMP_OVERLAY_MODE,
-
GIMP_DODGE_MODE,
+ GIMP_ADDITION_MODE,
+ GIMP_DIVIDE_MODE,
+
+ GIMP_DARKEN_ONLY_MODE,
+ GIMP_MULTIPLY_MODE,
GIMP_BURN_MODE,
- GIMP_HARDLIGHT_MODE,
+ GIMP_SUBTRACT_MODE,
+
+ GIMP_OVERLAY_MODE,
GIMP_SOFTLIGHT_MODE,
- GIMP_GRAIN_EXTRACT_MODE,
- GIMP_GRAIN_MERGE_MODE,
+ GIMP_HARDLIGHT_MODE,
GIMP_DIFFERENCE_MODE,
- GIMP_ADDITION_MODE,
- GIMP_SUBTRACT_MODE,
- GIMP_DARKEN_ONLY_MODE,
- GIMP_LIGHTEN_ONLY_MODE,
+ GIMP_GRAIN_MERGE_MODE,
+ GIMP_GRAIN_EXTRACT_MODE,
GIMP_HUE_MODE,
GIMP_SATURATION_MODE,
@@ -133,11 +134,13 @@ gimp_paint_mode_menu_new (gboolean with_
gimp_int_store_insert_separator_after (GIMP_INT_STORE (store),
GIMP_DISSOLVE_MODE, -1);
gimp_int_store_insert_separator_after (GIMP_INT_STORE (store),
- GIMP_OVERLAY_MODE, -1);
+ GIMP_DIVIDE_MODE, -1);
+ gimp_int_store_insert_separator_after (GIMP_INT_STORE (store),
+ GIMP_SUBTRACT_MODE, -1);
gimp_int_store_insert_separator_after (GIMP_INT_STORE (store),
- GIMP_GRAIN_MERGE_MODE, -1);
+ GIMP_HARDLIGHT_MODE, -1);
gimp_int_store_insert_separator_after (GIMP_INT_STORE (store),
- GIMP_LIGHTEN_ONLY_MODE, -1);
+ GIMP_GRAIN_EXTRACT_MODE, -1);
if (with_behind_mode)
{
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
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. - Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Hi, On Sat, Nov 1, 2008 at 11:06 PM, Martin Nordholts [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
David Gowers wrote: Hi, On Sat, Nov 1, 2008 at 11:06 PM, Martin Nordholts [EMAIL PROTECTED] 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. 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). 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. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Better grouping of layer modes
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Alchemie foto\grafiche wrote: 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? With Symmetric I assume you mean commutative. In my opinion, commutative properties (as well as the blending formulas) of layer modes are better highlighted in user the manual. Marking out commutative layer modes in the combo box would be too noisy. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
On Sun, Nov 2, 2008 at 12:02 AM, Martin Nordholts [EMAIL PROTECTED] wrote: David Gowers wrote: Hi, On Sat, Nov 1, 2008 at 11:06 PM, Martin Nordholts [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
David Gowers wrote: On Sun, Nov 2, 2008 at 12:02 AM, Martin Nordholts [EMAIL PROTECTED] wrote: 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.. 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. In the former case you are correct, Divide cancels Multiply. I.e. putting a copy of a Multiply layer on top of itself with the Divide layer modes yields no change at all to the end composite (in absence of rounding and clamping). 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. 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? BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
Hi, On Sun, Nov 2, 2008 at 9:34 AM, Martin Nordholts [EMAIL PROTECTED] 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 #90 makes the image brighter and yellower, Grain extracting the same bright yellow makes the image darker and more blue. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
