[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] Script-fu primitive wishlist: islands, integrals/sums, and data files
On Fri, 2008-10-31 at 19:27 -0400, Kevin Cozens wrote: David Gowers wrote: One is finding islands in an image [snip] Another is integrals: zero, first and second moments, or alternatively, integrals/sums of channel intensity, x- and y-weighted intensity, and x^2, y^2 and xy-weighted intensity. As you stated, the above two features could be implemented in Scheme but they would probably be too slow in actual use. Indeed, just tried, they're quite slow. When I can't bear it any longer, I'll see about a C plugin. Finally, opening and storing data files. See section 6.6 of the R5RS. Working with external files is handled via the use of pipes. Thanks, got it working. And Saul, text is all I need, can't speak for others. I don't suppose there's a script-fu interface to the file browser for setting the file name... One more question: I can't seem to access procedures in my scripts from the console. That is, if I define some procedures in files in .gimp-2.4/scripts/foo, the console doesn't know they exist. Is there a way to access those procedures from the console? Cheers, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ 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
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] merging new Xcursor plug-in
Hi! I'm writing X11 Mouse Cursor plug-in which enable GIMP to import and export a Xcursor file. Current release is here. http://registry.gimp.org/node/10764 I have implemented almost everything which I think is necessary and it is ready for being merged in GIMP itself. So, if I write a patch to include this plug-in in the svn tree of GIMP and throw it to bugzilla, will you accept it? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-fu primitive wishlist: islands, integrals/sums, and data files
Quoting Adam C Powell IV [EMAIL PROTECTED]: I don't suppose there's a script-fu interface to the file browser for setting the file name... The registration parameters (SF-FILE) get evaluated when Script-fu is loaded (or scripts are Refreshed) and dialog boxes for file browsing otherwise use the last values with which the function was invoked. (In other words, I don't believe it possible to set the filename.) Thanks, got it working. And Saul, text is all I need, can't speak for others. I don't think that Script-fu needs the functionality to access binary files (nor that 'read-byte' and 'write-byte' would be the best approach); however, it does seem that the TinyScheme interpreter should provide such support. One more question: I can't seem to access procedures in my scripts from the console. That is, if I define some procedures in files in .gimp-2.4/scripts/foo, the console doesn't know they exist. Is there a way to access those procedures from the console? Filenames in the 'scripts' folder must have the extension .scm or they are ignored by Script-fu. If you rename your file to foo.scm, all functions defined within it should be available in the console. ___ 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
[Gimp-developer] Snapping options should be remembered across sessions
Hi, As requested to discuss it on list rather than on bgo... It would be quite useful to be able using same snapping options (snapping to guides, grid, canvas border, active path) across sessions, preferably by defining defaults via Edit - Preferences - Image Windows/Appearance like UI. I'm not sure which tab exactly it could be. Probably inside Image Windows group or after Default Grid. 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
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] Snapping options should be remembered across sessions
Hi, On Sun, Nov 2, 2008 at 4:59 AM, Alexandre Prokoudine [EMAIL PROTECTED] wrote: Hi, As requested to discuss it on list rather than on bgo... It would be quite useful to be able using same snapping options (snapping to guides, grid, canvas border, active path) across sessions, preferably by defining defaults via Edit - Preferences - Image Windows/Appearance like UI. What exactly are you trying to propose here that is not included in the functionality of Edit - Preferences - Image Windows/Appearance itself? Are you trying to say 'remember the options that a particular image has, across sessions'? I'm baffled. -- 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 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] Snapping options should be remembered across sessions
Hi, On Sun, Nov 2, 2008 at 8:22 AM, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On Sun, Nov 2, 2008 at 12:36 AM, David Gowers wrote: It would be quite useful to be able using same snapping options (snapping to guides, grid, canvas border, active path) across sessions, preferably by defining defaults via Edit - Preferences - Image Windows/Appearance like UI. What exactly are you trying to propose here that is not included in the functionality of Edit - Preferences - Image Windows/Appearance itself? David, if you take time to actually read what is written above, you'll see that it says snapping options, not Show rulers or Show layer boundary. Believe me, there *is* a difference :) Oh, I thought we had that already. Apparently not. 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: 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
