Re: [Gimp-developer] Icons for layer modes

2009-10-26 Thread Patrick Horgan




yahvuu wrote:

  David Gowers wrote:
  
  
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.)

  
  
stretching the idea a bit further, the previews could be arranged as a table:
http://yahvuu.files.wordpress.com/2009/08/blendmodes-popup-array1.png

... just brainstorming..
  

Someone's getting a book out of this discussion, and when you do, I'll
buy it.

Patrick


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-26 Thread yahvuu
Ilya Zakharevich wrote:
> 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).
[..]
> 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.

that sounds a pretty much like the "Curves" plots i did in (fifth column):
http://yahvuu.files.wordpress.com/2009/09/table-contrast-2100b.png
An explanation is is available at [1].


> 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?

"a picture says more than a hundred words" springs to mind. I think it's pretty
much impossible to meet the requirements for useful layer mode icons, though:
http://lists.xcf.berkeley.edu/lists/gimp-developer/2009-October/023432.html


greetings,
yahvuu

[1] http://yahvuu.wordpress.com/2009/09/27/blendmodes1/#curves

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-26 Thread yahvuu
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...

Ilya, if you're aiming for any other goal besides insulting the developers
you should thoroughly adjust your posting habits.

In case you're not fully aware of the situation:
improving a program ultimatively means patching the code. Just talking about
how things should be instead of doing things is thus already dangerously close
to telling others what to do. Talking is cheap, they say. Also do note that
suggesting improvements is likely to implicitely criticize other people's
prior work. There's more than enough reason to be as polite as possible.
In general, the best channel to suggest UI improvements is the UI brainstorm:
http://gimp-brainstorm.blogspot.com/



> Layer modes is a very simple and intuitive concept.  The only thing
> missing is documentation 

well, if layer modes and their usage were as simple and intuitive
as you claim: why then is documentation necessary at all?
People's intuition seems to differ widely.



> (I'm going to address it in more details when
> the waves from my previous posts would subdue...).

This mailing list is not about making waves. Sad you have to be told.
Documentation improvements, however are shurely welcome over at gimp-docs.
Feel free to use the following template at will:

#   hi gimp-documenters,
#
#   i'd like to do the following changes to the layer modes section of the 
manual:
#1. xxx
#2. yyy
#
#   To me, this seems like a big improvement.
#   What you do think? A patch is welcome?
#...



> Hope this helps,

your strewn-in insults are anything but helpful.



> 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)?

what i consider as the 'intuitive' part of the current layer mode interface is
using the scrollwheel to select a different mode within the current group.
For example, if the current mode is 'screen' you can scroll up and down to
adjust for more or less brightening (for some sense of brightening).

The current interface is quite limited with regards to the number of layer modes
it can host. Currently, there are 15 'RGB' modes (the 'f(a,b)' type) and it is 
already
a cognitive burden to memorize their names. Now for more fine-grained control of
blending characteristics even more blend modes are necessary. However, a 
drop-down
list of 50 blend modes to choose from would not be acceptable. So in effect, 
the current
interface is limited to rather coarse adjustments of blending characteristics.


greetings,
yahvuu

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-26 Thread yahvuu
David Gowers wrote:
> 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.)

stretching the idea a bit further, the previews could be arranged as a table:
http://yahvuu.files.wordpress.com/2009/08/blendmodes-popup-array1.png

... just brainstorming..


greetings,
yahvuu

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-25 Thread Ilya Zakharevich
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.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-24 Thread Ilya Zakharevich
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)...

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-23 Thread David Gowers
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.)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-23 Thread Ilya Zakharevich
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)?

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-21 Thread yahvuu
Ilya Zakharevich wrote:
> 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.
> 
> The problem with your proposal is 2-fold:
> [..]

naa, don't worry, this wasn't meant as a proposal to replace layer modes.
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:
it is both limited and mostly non-intuitive. Developing a proper successor for
layer modes remains an open challenge.


regards,
yahvuu

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-21 Thread Ilya Zakharevich
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...]

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-05 Thread peter sikking
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
>> s 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



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-05 Thread yahvuu
peter sikking 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.


> first, I know now why our Darken section is one Shorter that our
> Lighten one: we are missing "subtractive" (that needs a name not
> s 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.


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.

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

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'...

Under GEGL, this technique of using a blend mode twice in conjunction
with an inverted blend layer should probably provided by a macro?!?


... well, and if go with such macros, 'dodge' is just the complement
of 'burn', which is a shortcut for inverting both the input layers
as well as the result. But this clearly goes too far against the
history of image editors. Just thinking aloud...


greetings,
yahvuu(i'll try to stick with the nick name, easier for everbody)


[1] 
https://lists.xcf.berkeley.edu/lists/gimp-developer/2008-November/021116.html


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-04 Thread peter sikking

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
s 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





smime.p7s
Description: S/MIME cryptographic signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-04 Thread peter sikking

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





smime.p7s
Description: S/MIME cryptographic signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-03 Thread peter sikking
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



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Icons for layer modes

2009-10-03 Thread photocomix

>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 (via www.gimpusers.com)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-03 Thread peter sikking
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



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-03 Thread yahvuu
hi,

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. 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 :-)

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.


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?


greetings,
peter


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-03 Thread yahvuu
hi,

peter sikking 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.

In my regard, blending is a complex adjustment rather than the choice of one 
discrete mode.
What is currently called layer modes can be seen as factory presets of a future 
blend tool.
A dedicated tool which allows on-canvas adjustment of blending characteristics 
will presumably
work best.

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.

But that's a loong way to go, especially if the adjustments shall be 
artistically
relevant ones. So the question is what to do right now?
The current set of layer modes seems rather arbitrary to me.



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...



> [..] 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.


thanks for the encouraging comments,
yahvuu



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-02 Thread peter sikking
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



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-02 Thread Patrick Horgan
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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-02 Thread peter sikking

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





smime.p7s
Description: S/MIME cryptographic signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-02 Thread SHIRAKAWA Akira
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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-02 Thread Martin Nordholts
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

-- 

My GIMP Blog:
http://www.chromecode.com/

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-02 Thread SHIRAKAWA Akira
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.

-- 
SHIRAKAWA Akira
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-02 Thread peter sikking

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





smime.p7s
Description: S/MIME cryptographic signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-01 Thread SHIRAKAWA Akira
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.

-- 
SHIRAKAWA Akira
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-01 Thread peter sikking
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



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-01 Thread Martin Nordholts
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

-- 

My GIMP Blog:
http://www.chromecode.com/

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Icons for layer modes

2009-10-01 Thread peter sikking
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



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Icons for layer modes

2009-10-01 Thread yahvuu
Hi all,

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


At a glance, it can be seen which group a layer mode belongs to:
- darken: only blueish and greenish colors
- brighten:   only yellow/red and green
- contrastboth red and blue

At a second glance, the neutral value (if existent) for the top layer
can be read out, that is a horizontal green line in the icon:
- green line at top: n = 255   e.g. burn
-"   at middle:  n = 127   e.g. hardlight
-"   at bottom:  n = 0 e.g. screen

Complementary pairs like dodge/burn show up as icons rotated by 180 degrees
with inverted color code, i.e. swapped red<->blue colors.

(dissolve and the 'channel modes' color, saturation, hue and value are of
 a different kind)

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

and a preliminary patch is also available:
http://sites.google.com/site/yahvuu/stuff/layermode-icons-preliminary.tar.bz2


makes sense to anyone?

greetings,
peter



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer