Icons for layer modes

[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
- contrast    both 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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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:

<http://yahvuu.files.wordpress.com/2009/09/table-brightness-1600.png>

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

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


> <http://yahvuu.files.wordpress.com/2009/09/table-brightness-1600.png>
>
> 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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[peter sikking]

Martin Nordholts wrote:

>> <http://yahvuu.files.wordpress.com/2009/09/table-brightness-1600.png>
>>
>> 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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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





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

[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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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





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

[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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Batangisip]

>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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[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





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

[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
<http://yahvuu.files.wordpress.com/2009/09/table-brightness-1600.png>
again, and look for really different heat maps (you know yahvuu, they
are good for that) and math formulas with discontinuities."

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

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

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

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

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

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

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

     --ps

         founder + principal interaction architect
             man + machine interface works

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





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

[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
> soooo close to our Subtract).

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

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


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@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer