Hello yahvuu, On Sun, Apr 26, 2009 at 9:31 PM, yahvuu <yahvuu@xxxxxxxxx> wrote: > 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. Yes, this is certainly an interesting idea, worth trying, and I agree it has potential to address quite a few problems. > > 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) > This all sounds pretty good to me > >> - 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. See MyPaint -- it provides a 5-slot color history. You'll need to try it to see how it works. (the 'previous color' action swaps between the 2 most recent.. but it pops up all 5 visibly, and pressing it quickly multiple times moves further back. >From my experience, this works much better than having FG and BG color and swapping them as needed. MyPaint is a dedicated painting app, I think we could really learn from it here; the way it handles color history is comfortable, discoverable, and non-intrusive. > 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. Totally agree, it's always seemed a bit odd to me. > > 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?). I see where you're going with this. One bump I see is things like "Cut" and "Float" -- quite often I want them to fill the source area with a solid color rather than with transparency. When this doesn't happen, it's awkward (as the layer) > > 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... What happens when we want to save a 24bit png with no alpha from a single layered image? how is this detected? The current distinction between layers with and without alpha channel allows the user to make that clear.. Hmm. In that case, it probably makes a lot of sense to assign a 'has alpha channel?' property to each image (rather than layer). This would allow us to eliminate the choice between 'merge visible layers' and 'flatten image' in the Export process. > > 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 terms of exporting, I definitely agree completely with this 'BGcolor associated with image' idea. > > > 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. Well, I agree there is not much quality justification for the tool bg color. The behaviour of Cut and Float is one point to examine. Of course we would, through removing tool bg color, make the interface less familiar to Photoshop users, but as this is an interface simplification, I count it as a positive. Some thought on how to assure scripting compatibility between before image bg is introduced and after is probably also needed. In summary, I really think we should both add an image BG color and remove the tool BG color (as only two commands really require it, to me, this indicates it is those commands which need rethinking.) Thanks for taking the time to write about this with such thoroughness and clarity. David _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
