Hi saulgoode,

On Tue, Apr 28, 2009 at 12:29 PM,
<saulgo...@flashingtwelve.brickfilms.com> wrote:
> Perhaps I am misunderstanding this proposal, but the ramifications
> seem to be more confusing than the present method. And while I realize
> that GIMP does not make any guarantees about retaining the colors of
> transparent pixels, its current behavior is quite useful for editing
> files destined for applications which employ the alpha channel in
> unconventional ways. It also offers a few other atypical benefits, but
> mainly it is consistent and easy to comprehend what is happening.
> Some questions:

I don't understand some of your following objections (or I think they
are based on false premises)

The eraser currently does change color values, in the case of layers
without alpha (it's like using paintbrush or pencil with the
background color). Yahvuu's proposition would make sure it never
changed color values because there would be no layers without alpha.
Thus, several of the things you brought up have no relation to the
proposition (because they could not possibly occur through
implementing this proposition)

> If a PNG is loaded as a layer, should the "image background color" be
> updated to the PNG file's background color? or should it remain what
> it was originally? If a JPEG is loaded as a layer, should the "image
> background color" be set to white?
Good questions!
It's pretty clear to me, that if the PNG provided a background color,
we should keep it; otherwise, we should assign our own. It looks like
my proposed 'image has an alpha-channel' flag is needed here to avoid
occasionally changing the meaning of pictures.

There is no right or wrong behaviour for JPEGs imo, since they are
completely opaque and predicting a good BG color automatically would
be more troublesome than it is worth.

I think 50% grey (#bababa) is a better default BG color for when a
default is needed.

> Should gradients be using the "image background color" or the "second
> color in a color slot history"?
I think, given a slot history such as I described, it would be helpful
to provide the ability to 'virtually point at' any of the 5 slots
(considering 1 = current, 5 = oldest) and deprecate the notion of
'background color' (or even precisely 'foreground color') from
gradients; automatically convert references to BGcolor into slot #2,
yes. The 'slots-based' history would serve the same purpose in terms
of gradients -- allow quick building of gradients -- just that it
would be even more flexible and quite often more quick :)

Gimp-developer mailing list

Reply via email to