Hi all,

peter sikking schrieb:
> I like the innovative nature of the idea.

it would not be without a hint of irony if, after 40+ years of digital image 
GIMP were the first to finally introduce the concept of a background color ;-)
And i'm not aware of a raster file format which features that concept.
Let's see if it's any good.

> - I would like to see some more thinking on how this influences the
>    simplest case: importing an image without any transparency.

the secondary workflow gets simplified:

importing e.g. a JPG creates a GIMP document with one layer
and the image background color set to opaque white.
Any modification other than making the background color
transparent preserves the image projection's property
of being fully opaque. Thus on export, the projection can be
converted to JPEG format without asking the "flatten?" question
(which actually asks wether to fill transparency with a bg color).

For file formats which support transparency, e.g. PNG, import initializes
the image background color to neutral, say transparent white.
For a cycle of import and export this doesn't introduce any change:
- if the PNG was fully opaque before, the imported bottom layer will
  be fully opaque, thus covering the background color.
- if the PNG has transparent pixels, the projection will have them, too.
  The image bg color does not introduce any change as it is fully
In both cases the "flatten or merge layers?" question becomes obsolete.

As a side-effect, the automatically chosen image bg color gives
a non-intrusive hint about the imported file's transparency capabilities.
(That's another reason why GIMP should not try to be smart in choosing
the image bg color, e.g. from image content. The first reason beeing that
this can't be done reliably, e.g. trying to recall the image bg color of
an exported JPG on re-import)

> - I would like to see some more thinking on how this is related to
>    the background color in the color chooser. coupled/decoupled?

in short: decoupled, definitely.

An explicit image background color actually questions the very
existence of a color named "background" as part of tool state.
Having several colors available for instant access is undoubtedly
very handy in the sense of a core mini-palette. Labelling the second color
staticly as "background" - although being a good mnemonic - is somehow
a remainder of evolution from the days of non-alpha, single-layer images.

This shows up in the case of the eraser tool. Cleary it should erase
to background color. But what is the background color of a layer?
Currently, the answer depends on layer state - wether it has an alpha
channel or not. This can be unified according to the rationale that
"layers are just transparent sheets" in order to prevent mode errors.
Then the answer is to erase to transparency, on the alpha channel.
Consequently, the eraser doesn't require a background color as part of
tool state anymore (and which other tool does?).

The benefit of an image bg color in that context is that the bottom layer
doesn't need to be special-cased: a newly created GIMP image consists of
a transparent layer and an opaque white bg color by default.

The other important tool which utilizes the toolbox bg color is the "fill tool".
>From my experience here, the tool box's bg color serves more as a lay-by for
smooth interplay of multiple tools than actually as a background color.
Even when working on a single layer, i tend to change the bg color quite
often; YMMV. Anyway, binding the 'CTRL+.' shortcut to the image bg color
will limit it's usefulness.

Another "tool" which accesses the tool box's background color is export.
The cases where the export process needs to eliminate transparency
will probably still arise, though much less often - e.g. exporting an XCF
with transparent bg color to JPEG. This could just utilize the RGB part
of the image bg color. Might not be very intuitive, though, as it's
difficult to visualize the difference between transparent white and,
say, transparent black for the image bg color. Any help appreciated...

In any case, the color should not be taken from the tool box's bg color.
Export is a file-level operation and should ideally be independent of
workspace state like the selection mask, current tool, current brush
.. and current tool colors. If the upcoming export mechanism can't take
the color from the image bg color, it should explicitly ask for it, IMHO.

In summary, an image bg color is independent of the concept of a tool bg color,
with the former living in the layer dialog and the latter inside the tool box.
The tool bg color is worth being questioned as the background notion is 
here, without associated tool semantics. Of course, any changes to the tool box
must be examined from a much wider perspective. Just wanted to point out
that an image bg color might be one piece of the puzzle.


Gimp-developer mailing list

Reply via email to