Re: Canvas size, background, and channels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 20.08.2010 08:52, Chris Mohler wrote:
> On Thu, Aug 19, 2010 at 10:53 PM,
> <saulgoode@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>  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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux