Hi,

On Fri, 2009-03-06 at 18:46 -0500, Rob Antonishen wrote:

I posted this as a bug, and was told by Sven Neumann the behaviour was intentional and to raise it here.

Thanks for bringing this discussion to the mailing-list.

The current behaviour is confusing to a user because of the following fairly typical scenario:

User wants to blur a portion of an image, but wants to save the selection for later use.

1) make selection 2) Select > Save to Channel
3) Filter > Blur > Gaussian Blur

Now the user is blurring the saved selection channel, not the layer they started on.

While I basically agree with you, I don't quite understand this example and why it is so typical. What is the user actually trying to achieve here? You say "User wants to blur a portion of an image, but wants to save the selection for later use.". How are these two related? Blurring the image does not alter the selection, so why would the user want to save the selection before blurring the selected parts of the image?

IMO it would be a much more typical scenario to use the blur filter on the selection mask to make it more fuzzy. For that use case the current behavior is ideal:

1) make selection 2) Select > Save to Channel
3) Filer > Blur > Gaussian Blur

Now this Blur was applied to the channel and it can be loaded back as a selection. Is it worth to break this workflow?

Sven

Hi!!!

On Sat, Mar 7, 2009 at 10:16 AM, Rob Antonishen wrote:

I posted this as a bug, and was told by Sven Neumann the behaviour was intentional and to raise it here.

Currently, when saving a selection to a channel, either using the UI or via the PDB, the active drawable gets changed from the working layer to the new channel.

I believe the active drawable should remain unchanged (i.e. where the selection was made).

The current behaviour is confusing to a user because of the following fairly typical scenario:

User wants to blur a portion of an image, but wants to save the selection for later use.

1) make selection 2) Select > Save to Channel
3) Filter > Blur > Gaussian Blur

Now the user is blurring the saved selection channel, not the layer they started on.

I agree, something similar to the process you describe above is more like what I want to do, and because of this annoying behaviour I don't use 'save to channel' at all ever. It's actually easier to create a new layer and fill it with foreground color, and later transfer layer alpha to selection.
While there definitely are some scenarios where I want to perform a filter on a selection, I will typically use QMask mode instead of filtering a saved selection, and IMO this is more intuitive than the workflow I see Sven has just posted about (mainly this is because QMask display is reliable, and channel display requires separate/repeated configuration to get consistent display results)

David.

Hi,

On Fri, 2009-03-06 at 20:59 -0500, Rob Antonishen wrote:

That might not have been the best example.

A guess a more useful example would be that after building a complicated selection to isolate a portion of an image (say the sky) the user wants to save that selection, then modify the entire image (say gamma correction, or colour balance, even desaturate) then load up the original selection quickly to perform another action on it.

I guess it is a question on that the point of the channels is. Most people I know who actually use them, use them as "named selections" that they can work with later. Very few that I know actually perform any editing on them directly, partially because, as David pointed out, directly editing channels is awkward and confusing, and using quickmask is much easier.

As I said already, I agree with you in all points and I am all for changing this. But I wanted you to provide a better workflow example to persuade the UI team to give OK for this change. Peter, what do you think?

Sven

Sven wrote:

As I said already, I agree with you in all points and I am all for changing this. But I wanted you to provide a better workflow example to
persuade the UI team to give OK for this change. Peter, what do you think?

Well,

what I first of all think is that the channels dialog needs to be split in two: a channels dialog and a stored-selections dialog.

that would make the concept of storing your selections a million time more comprehensible and usable. the selections dialog can stay there in the dock and channels one can become an optional one. it would not be bad to show the current (unstored) selection in the selections dialog as well.

apart from backward compatibility with scripts, this does not look like a huge amount of development effort.

back to the question:

quickmask is where selections become tangible pixels, so that is main place to modify those selection pixels.

saving a selection to channels (or better, selections) should have feedback:

- blinking the channels/selections dialog: good - showing the channels/selections dialog as the top: rather not - making in the channels dialog case the new selection/channel the the active drawable: no.

--ps

founder + principal interaction architect man + machine interface works

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

On Sat, Mar 7, 2009 at 3:24 AM, David Gowers wrote:

While there definitely are some scenarios where I want to perform a filter on a selection,  I will typically use QMask mode instead of filtering a saved selection

Speaking of which (and sorry for interrupting the thread), could somebody please fix "Qmask" message showing up in localized GIMP instead of "Quick mask" translation when you toggle quick mask with Shift+Q? Somebody (mitch?) had a go at it a while a go and even committed a fix, but it doesn't seem to work again (both 2.6.5 and trunk).

Alexandre

Hi,

On Sat, 2009-03-07 at 15:38 +0100, peter sikking wrote:

what I first of all think is that the channels dialog needs to be split in two: a channels dialog and a stored-selections dialog.

Having them in one dialog is admittedly somewhat confusing, but it is an established standard for pixel manipulation programs. I don't think we should change that. It would only waste space.

saving a selection to channels (or better, selections) should have feedback:

- blinking the channels/selections dialog: good - showing the channels/selections dialog as the top: rather not - making in the channels dialog case the new selection/channel the the active drawable: no.

We should also display a message in the status-bar telling the user that the selection has been copied along wit the name that was chosen for it.

Sven

Hi,

On Sat, 2009-03-07 at 21:48 +0300, Alexandre Prokoudine wrote:

Speaking of which (and sorry for interrupting the thread), could somebody please fix "Qmask" message showing up in localized GIMP instead of "Quick mask" translation when you toggle quick mask with Shift+Q?

Where does this message show up?

Sven

Hi,

http://bugzilla.gnome.org/show_bug.cgi?id=574418 now has a patch that implements this change.

- blinking the channels/selections dialog: good - showing the channels/selections dialog as the top: rather not - making in the channels dialog case the new selection/channel the the active drawable: no.

We should also display a message in the status-bar telling the user that the selection has been copied along wit the name that was chosen for it.

The patch linked above does implement the status-bar message, but it does not blink the channels dialog. This is because it is currently not possible to blink the dialog without raising it. If we really want to do this, we could probably change GimpDialogFactory to make this possible.

Sven

Sven wrote:

what I first of all think is that the channels dialog needs to be split in two: a channels dialog and a stored-selections dialog.

Having them in one dialog is admittedly somewhat confusing, but it is an
established standard for pixel manipulation programs.

this may look to you like we are only shuffling the furniture, but I cannot overstate how much this change is needed in the interest of usability:

really. I am not exaggerating.

a significant portion of our core user group will perceive this as we added selection management for the first time. the mind-boggling way it works now simply makes it a non-starter for them. non-starter = does not exist.

for the significant portion of our core user group who have come to terms with the current way of working this change will be a welcome speed-up of their workflow, because GIMP does not make them think anymore in this regard.

really.

I don't think we
should change that. It would only waste space.

if you want to make a usefulness/space calculation:

as I said before, channels would no longer be in the dock by default, because AFAIK this dialog would be looking for a new important job. instead there is the selections dialog in the same space (icon: the red selection). with the significant increase in usefulness that I expect, the space wasting is decreasing.

saving a selection to channels (or better, selections) should have feedback:

We should also display a message in the status-bar telling the user that
the selection has been copied along wit the name that was chosen for it.

yep. all bits help.

--ps

founder + principal interaction architect man + machine interface works

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

Hi,

On Sun, 2009-03-08 at 14:38 +0100, peter sikking wrote:

this may look to you like we are only shuffling the furniture, but I cannot overstate how much this change is needed in the interest of usability:

really. I am not exaggerating.

a significant portion of our core user group will perceive this as we added selection management for the first time. the mind-boggling way it works now simply makes it a non-starter for them. non-starter = does not exist.

for the significant portion of our core user group who have come to terms with the current way of working this change will be a welcome speed-up of their workflow, because GIMP does not make them think anymore in this regard.

I think you are missing the bigger picture here. Channels are not only about saved selections. If they were, we should indeed declare then as such. But channels are also used for simulating spot colors and as such they are much more closely related to the color components that are shown at the top of the dialog. There are more interesting things that can be done with channels. Unfortunately this is not very well covered in the GIMP documentation (the old manual by the Kylanders was better in this regard). That's why it is even more important that we keep this close to the Photoshop channels dialog. Then users can at least benefit from the documentation that exists for PS.

Sven

Sven wrote:

On Sun, 2009-03-08 at 14:38 +0100, peter sikking wrote:

this may look to you like we are only shuffling the furniture, but I cannot overstate how much this change is needed in the interest of usability:

really. I am not exaggerating.

a significant portion of our core user group will perceive this as we added selection management for the first time. the mind-boggling way it works now simply makes it a non-starter for them. non-starter = does not exist.

for the significant portion of our core user group who have come to terms with the current way of working this change will be a welcome speed-up of their workflow, because GIMP does not make them think anymore in this regard.

I think you are missing the bigger picture here. Channels are not only about saved selections. If they were, we should indeed declare then as such. But channels are also used for simulating spot colors and as such
they are much more closely related to the color components that are shown at the top of the dialog. There are more interesting things that can be done with channels. Unfortunately this is not very well covered in the GIMP documentation (the old manual by the Kylanders was better in
this regard). That's why it is even more important that we keep this close to the Photoshop channels dialog. Then users can at least benefit
from the documentation that exists for PS.

hmmm, there must be a misunderstanding here.

if you read carefully what I am proposing then you'll see that the only thing that is going to change about the channels dialog itself is that the stored selections will be outa' there. I cannot see how that will upset true channels workflows, nor their documentation.

I think the only thing that is left to argue about is whether the channels dialog should still be in the right dock by default or not. I can live with it when it stays there after the introduction of a selections dock-able dialog.

--ps

founder + principal interaction architect man + machine interface works

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

Hi.

On Sun, 2009-03-08 at 17:15 +0100, peter sikking wrote:

hmmm, there must be a misunderstanding here.

Yes, obviously there is. But it is on your side.

if you read carefully what I am proposing then you'll see that the only thing that is going to change about the channels dialog itself is that the stored selections will be outa' there.

There's no conceptual difference between channels and stored selections. And I am not talking about the red, green, blue color components that happen to be also shown in the dialog labeled Channels. Channel are a stack of masks that are projected on top of the layer stack using the colors associated with them. It happens that you can also use them as a temporary storage for the selection mask. But the actual purpose is to make the channel visible and to use it in the image projection.

If we keep channels that are created by saving the selection mask separate from other channels, then we just took away an important way to create a channel. When the user saves the selection to a channel, we don't really know if that is in order to store it for later use as a selection mask or if the user is creating a spot color channel or trying to simulate half-toning.

Sven

Sven wrote:

On Sun, 2009-03-08 at 17:15 +0100, peter sikking wrote:

hmmm, there must be a misunderstanding here.

Yes, obviously there is. But it is on your side.

if you read carefully what I am proposing then you'll see that the only thing that is going to change about the channels dialog itself is that the stored selections will be outa' there.

There's no conceptual difference between channels and stored selections.

well, we at the UI team are trying to tell the development team that over in user-space there is a big perceived difference channels and stored selections.

and I can't believe that proposing an alignment of GIMP UI with the realities of users expectations meets such a dogged resistance.

you describe to me some of the high-end usage of channels which is cool to know, but it relies in no way on the selections also being parked there. there is a free flow of pixel data possible between any layer mask and selection, so I would not know why that could also not have obvious means (like, copy and paste) in and out of channels.

--ps

founder + principal interaction architect man + machine interface works

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

Hi,

On Sun, 2009-03-08 at 21:05 +0100, peter sikking wrote:

and I can't believe that proposing an alignment of GIMP UI with the realities of users expectations meets such a dogged resistance.

There is no dogged resistance. I just had the impression that you believed that storing selections would be the only use of channels. It is more like a useful side-effect of it. Perhaps it makes sense to make it more obvious how to save and restore selections, but we also need to make sure that we are not taking away important features. Channels is really an area where GIMP is lacking. If we want to be taken seriously, then there should be much more emphasis on channels. Removing them from the default UI is not a step towards that.

Sven

Sven wrote:

On Sun, 2009-03-08 at 21:05 +0100, peter sikking wrote:

and I can't believe that proposing an alignment of GIMP UI with the realities of users expectations meets such a dogged resistance.

There is no dogged resistance. I just had the impression that you believed that storing selections would be the only use of channels.

no, my diagnosis is that it is just abuse of channels.

It
is more like a useful side-effect of it. Perhaps it makes sense to make
it more obvious how to save and restore selections, but we also need to
make sure that we are not taking away important features. Channels is really an area where GIMP is lacking. If we want to be taken seriously,
then there should be much more emphasis on channels. Removing them from
the default UI is not a step towards that.

so we were solving two different problems. You were resurrecting the channels and I was resurrecting the selections.

looking at channels: I am not the one to come up with suggestions what else channels can do. a discussion of this would be welcome.

what I can say is that "how are we going to get graphical information into channels" needs to be brought up to a level that there is for layer masks (but taking the global nature of channels into account).

I was reviewing the transport of graphical information between layers, masks, selections, channels. the weaker part seems to be the channels and also the alpha channel, I am still mesmerised that it cannot be made visible, tangible like the layer mask.

--ps

founder + principal interaction architect man + machine interface works

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

Hi,

On Wed, 2009-03-11 at 11:33 -0400, Rob Antonishen wrote:

Sven mentioned other uses, like spot colour and halftoning. I can't find any references on using gimp channels for spot colour, in fact google only finds me claims that a weakness of gimp is that it does NOT support spot colours.

If you can get your hands on the GIMP User Manual version 1.0, the book by Karin and Olof Kylander, then do that. There's pretty good coverage of this use of channels. And of course you can look at the many PS tutorials on this topic.

Sven

On Wed, Mar 11, 2009 at 10:33 AM, Rob Antonishen wrote:

Sven mentioned other uses, like spot colour and halftoning.  I can't find any references on using gimp channels for spot colour, in fact google only finds me claims that a weakness of gimp is that it does NOT support spot colours.

GIMP does offer spot channels, but there is no (easy) way to output the spot channels directly to a printer in grayscale. Nor does the channel mixer operate on the spot channels.

I use spot channels to create separations for printing. Each spot channel corresponds to a positive that will be used to create a screen (plus one channel to represent the substrate). In PS, one can turn off the RGB channel and use the visibility of the spot channels to simulate the final output on the printing press. Turning off everything except one spot channel renders that spot channel in grayscale (which makes printing the single channel very easy). Turning on two or more spot channels renders them in RGB. This is incredibly useful when setting up multicolor prints (think of a white underbase for printing a bright color on a dark substrate).

I can work around most of these things in GIMP by doing things like reloading the channel as a selection, creating a new layer and filling it with black and printing just that layer - but it can be quite cumbersome. Also, PS supplies a very badly-named function called "Apply Image" that allows you to take the contents of any given channel and apply it to the contents of any other channel using the available blending modes (multiply, screen, etc.). This is the real power behind channels.

99% of people will likely not need spot channels, but to the reaming 1% they are quite useful. Hopefully with the coming of GEGL it will become easier to do some of this pre-press separation and channel mixing.

Chris

Rob Antonishen wrote:

I think that all of the "channel" use cases should be examined before deciding how these should act.

My own experience with channels is limited to: 1) Image decomposition for masking/converting to greyscale 2) Saved selections

...
Sven mentioned other uses, like spot colour and halftoning.

I would add LAB to the list. Currently LAB implementation is via layers but it's really a colourspace.

---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---

As a casual, inexperienced user of GIMP, I would like to add my comment about saving selections.
Using a trial version of PS I tried many different things on the same photo(s). Some of them being colour fiddling, DOF manipulation, cut-and-paste, and many more.
I found the ability to save a (named) selection, (and indeed a number of different selections for the same photo) to be very useful, and in fact pretty essential.
Converting to GIMP, (because PS would bust my budget!) I was alarmed when I could not find a "selection save".
Having read through this thread, I will try to use "save to channel", but I just cannot get my head around how to retrieve the "saved" selection. Any assistance on this will be most welcome. BTW: GIMP is truly great!!!!!

I
just cannot get my head around how to retrieve the "saved" selection. Any assistance on this will be most welcome. BTW: GIMP is truly great!!!!!

You can retrieve a saved selection using the channels dialog: Go to "Windows" -> Dockable Dialogs -> Channels. Below the RGBA channels you'll find a list with your saved selections.

Hello Rob,

On Tue, Mar 17, 2009 at 11:25 AM, Rob Antonishen wrote:

I dug up a copy of this manula, and discovered a couple things after playing with channels in 2.6.4 and 2.6.1 on Ubuntu.

In the instructions, it states: Open the Channels tab and create a new channel. In the New Channel Options dialog, set this channel to 100% Fill Opacity. Click the black color swatch to access the Color Selection dialog, and choose a nice color (this will be the first plate to be printed). Name the channel “navy blue” or the like, depending
on what color you chose. Click on the OK button. Paste (right-click|Edit|Paste) the image into this channel.

It seems you can no longer paste into a channel.

In the latest SVN, you can.
It is confusing that the floating layer shows up in the layers dialog rather than the channels dialog. otherwise, things are normal. Maybe 2.6 doesn't have these fixes.

David.

On Tue, Mar 17, 2009 at 1:40 PM, Rob Antonishen wrote:

On Mon, Mar 16, 2009 at 10:15 PM, David Gowers wrote:

Hello Rob,

It seems you can no longer paste into a channel.

In the latest SVN, you can.
It is confusing that the floating layer shows up in the layers dialog rather than the channels dialog. otherwise, things are normal. Maybe 2.6 doesn't have these fixes.

David.

OK, I'm quite wrong.  I was looking to be able to use Paste Into, and have it paste directly into the active channel.

Ah, I see the problem now. There is not an 'active channel'. There is rather an 'active drawable' (and both layers and channels are classified as drawables). This has always been the case (but perhaps we can show this in a clearer way? I wonder what Peter thinks.)

So to paste into a channel you have to...

- select the channel (in the channel panel) - edit > paste (or paste into)
- select the layer panel
- hit the anchor button
- select the channel panel.

Note this is less confusing and faster when you have Anchor bound to a keyboard shortcut. Select the channel, paste, anchor. (if you wanted to change opacity or layer mode, you still have to switch to Layers dialog though - ick!)

David

Hi,

On Tue, 2009-03-17 at 07:26 -0400, Rob Antonishen wrote:

My opinion (which probably breaks some other intended behaviour) is that if the active drawable is a channel, pasting should default to a paste into that active channel

It does, of course. There's just this internal design flaw that floating selections are part of the layers stack and are shown there. The floating selection still belongs to the channel you pasted it to and it will be anchored to that channel. The fact that it is shown in the Layers dialog doesn't change that.

Mitch has been doing a lot of work on the internals of floating selections lately. The goal of this work is to fix the long-standing issue described above.

Sven