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 processing, 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 transparent. 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 arbitrary 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. greetings, peter _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
