Quoting Chris Mohler :

Is this a bug? (or a feature ;)

1. Create new RGB image 2. Add channel
3. Increase canvas size
4. Edges of channel are now filled 100% solid, regardless of BG color

I expected:

4. Edges of channel are now filled with % based on BG or possibly FG color (or 0% fill)

Or am I missing something?

Imagine you've made a selection around an object and then saved that selection to a channel for later use (for example, a model's face). If increasing the canvas size filled the "edges" of the canvas with anything but black, then your saved selection would no longer be limited to the original object (e.g., the model's face), but would also include the edges. It seems more reasonable to me that saved selections should not be changed if the canvas size changes.

On 08/19/2010 11:12 PM, Chris Mohler wrote:

Is this a bug? (or a feature ;)

1. Create new RGB image 2. Add channel
3. Increase canvas size
4. Edges of channel are now filled 100% solid, regardless of BG color

I expected:

4. Edges of channel are now filled with % based on BG or possibly FG color (or 0% fill)

I would expect it to be filled with what it was filled with when you created it, as if it would have no bounds but extend into infinity

IMO that nicely fits into automatically managed layer (and channel) boundaries scheduled for GIMP 3.0.

/ Martin

Hi,

On 20.08.2010 08:52, Chris Mohler wrote:

On Thu, Aug 19, 2010 at 10:53 PM, wrote:

Imagine you've made a selection around an object and then saved that selection to a channel for later use (for example, a model's face). If increasing the canvas size filled the "edges" of the canvas with anything but black, then your saved selection would no longer be limited to the original object (e.g., the model's face), but would also include the edges. It seems more reasonable to me that saved selections should not be changed if the canvas size changes.

(forgot to reply-all)

That's pretty much the same (and opposite) problem I'm facing. Imagine you're storing image data for output in the channels. 100% solid = 100% output. Now, increase the canvas size and there's a solid border of output. I must delete it to prevent it from printing.

I think the 'infinite fill' behaviour as described by Martin will solve this problem, too. If you start by filling with 0% (whithout an active selection), then expanding the canvas will just reveal more of that 0%-filled infinite plane.

IMO, storing selections is but a secondary function of spot channels - their primary function is output to press. But I'm coming from a print background, so perhaps I'm biased ;)

IMO, the channels dialog in its traditional form is fundamentally broken from a conceptual point of view: anything that can be stored as a grayscale bitmap has been dumped in there, regardless of the corresponding concepts.

What is currently being called a 'channel'?

1) Color components, like R,G,B

These are what every pixel in every layer consists of.

Here, a 'channel' is a representation of one color component of a single layer's pixels. For example, the red component of all pixels of a certain layer can be treated as a grayscale bitmap.

Alpha is a color component in that sense, too.

(Multi-band images have additional color components. It has already been decided that 'spot colors' will not be considered as such additional color components.)

2) Spot channels aka plates for the wet press

These are additional grayscale bitmaps which are unrelated to the rest of the image. Interpretation is completely up to the user.

In contrast to 1), these 'channels' don't give a different view on the image's pixels but provide new, 'other' pixels which allocate additional memory.

3) Stored selections

Since selections are defined as per-pixel values of 'membership', they can be represented as grayscale bitmaps, too. Hence they get stored as 'channels'.

The conceptual difference to the 'channel' types 1) and 2) is that selections are inherently multi-colored (to avoid the term multi-channel) -- they apply to all the R,G,B components of a pixel. It would make perfect sense to have 'colored' selections which treat the pixel components individually -- but they are simply not practical.

Following the concept of a fuzzy stencil, a selection could allow 50% tool action for red, 75% action for green and 0% for blue -- and all that within a circular area. If that sounds strange, think of the R,G,B pixel layout on your TFT screen -- the described effect could be achieved by proper rasterization of a physical stencil.

So a selection is conceptually a multi-color stencil which -- for practical reasons -- has all R,G,B values bound to the same value for each pixel.

Now, it has been proven very beneficial to allow manipulation (and interaction) of all these different entities via their grayscale representation. But that surely doesn't imply to stuff everything into a single dialog -- which falsely suggests similarity of quite different concepts.

rant finished, yahvuu

On 8/20/10, Martin Nordholts wrote:

IMO that nicely fits into automatically managed layer (and channel) boundaries scheduled for GIMP 3.0.

Will it also make layer mask move along with the layer it is attached to?

Alexandre Prokoudine http://libregraphicsworld.org

On 08/20/2010 08:22 PM, Alexandre Prokoudine wrote:

On 8/20/10, Martin Nordholts wrote:

IMO that nicely fits into automatically managed layer (and channel) boundaries scheduled for GIMP 3.0.

Will it also make layer mask move along with the layer it is attached to?

Hi Alexandre

No, automatically managed layer boundaries has nothing to do with that.

But it is still a change we should do.

/ Martin