Peter (yahvuu) wrote:

there's one solution i haven't seen yet:

assign a background color to GIMP images. Not a layer, just a single color.
This way, the eraser can always work on alpha, and all layers consistently can have an alpha channel.

I like the innovative nature of the idea.

but,

I am not sure about how general purpose this idea is.

- I would like to see some more thinking on how this influences the simplest case: importing an image without any transparency. how would that look like without introducing complication. simple things (in users' eyes) have to remain simple in the UI.

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

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Hello yahvuu,

On Sun, Apr 26, 2009 at 9:31 PM, yahvuu 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

On Mon, Apr 27, 2009 at 2:20 AM, yahvuu wrote:

Hi all,

David Gowers schrieb:

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)

Did I really write that "(as the layer)"? I meant "(as fuzzy/foreground-selection then stops working 'correctly' on that part of the layer)

in terms of the model under discussion, this is a shortcut for cut & fill. I wonder, doesn't "CTRL+C.V" do the trick?

No, think about it, once you have 'Cut' something the selection is gone. All that would achieve is to fill the entire layer with a color

yahvuu wrote:

And i'm not aware of a raster file format which features that concept.

PNG. http://www.w3.org/TR/PNG/#11bKGD

HTH, Michael

On Sun, Apr 26, 2009 at 8:01 AM, yahvuu wrote:

peter sikking schrieb:

I like the innovative nature of the idea.

And i'm not aware of a raster file format which features that concept.

I just want to point out that PNG supports a background color (and the GIMP plugin to save PNG offers an option to save the current brush background color as the image background color), and being the only format to do so we should probably consider its specified functions and suggested behavior as potential starting points for GIMP's handling of such.

4.2.4.1. bKGD Background color

The bKGD chunk specifies a default background color to present the image against. Note that viewers are not bound to honor this chunk; a viewer can choose to use a different background.

For color type 3 (indexed color), the bKGD chunk contains:

Palette index: 1 byte

The value is the palette index of the color to be used as background.

For color types 0 and 4 (grayscale, with or without alpha), bKGD contains:

Gray: 2 bytes, range 0 .. (2^bitdepth)-1

(If the image bit depth is less than 16, the least significant bits are used and the others are 0.) The value is the gray level to be used as background.

For color types 2 and 6 (truecolor, with or without alpha), bKGD contains:

Red: 2 bytes, range 0 .. (2^bitdepth)-1 Green: 2 bytes, range 0 .. (2^bitdepth)-1 Blue: 2 bytes, range 0 .. (2^bitdepth)-1

(If the image bit depth is less than 16, the least significant bits are used and the others are 0.) This is the RGB color to be used as background.

When present, the bKGD chunk must precede the first IDAT chunk, and must follow the PLTE chunk, if any.

See Recommendations for Decoders: Background color.

=========================================

10.7. Background color

The background color given by bKGD will typically be used to fill unused screen space around the image, as well as any transparent pixels within the image. (Thus, bKGD is valid and useful even when the image does not use transparency.) If no bKGD chunk is present, the viewer will need to make its own decision about a suitable background color.

Viewers that have a specific background against which to present the image (such as Web browsers) should ignore the bKGD chunk, in effect overriding bKGD with their preferred background color or background image.

The background color given by bKGD is not to be considered transparent, even if it happens to match the color given by tRNS (or, in the case of an indexed-color image, refers to a palette index that is marked as transparent by tRNS). Otherwise one would have to imagine something "behind the background" to composite against. The background color is either used as background or ignored; it is not an intermediate layer between the PNG image and some other background.

Indeed, it will be common that bKGD and tRNS specify the same color, since then a decoder that does not implement transparency processing will give the intended display, at least when no partially-transparent pixels are present.

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:

Currently, erasing on a layer having an alpha channel only affects the alpha channel, the color values remain the same. If a special case were to be created such that transparent erasures (alpha < 1/256) result in changes to color values, what then is to happen when color depths are increased such that the minimum non-zero alpha becomes 1/65556 (16-bit per color), or even lower (32-bit or floating point)? Erasures of an 8-bit PNG image using these higher color depths will reveal not the original image, but instead some unassociated color and this might cause some problematic "fringing".

If erasing is to be changed such that color channels are painted, is this to be offered as a tool option which can be disabled? And if erasures are done with an tool opacity less than 100%, would the option be provided to decide whether the color channels are painted at 100% background or instead blend with the underlying color at the tool's opacity level? or would using the tool's transparency level make more sense?

If the eraser's color is to blend with the existing color channels, should blend modes be enabled for the eraser tool?

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? Maybe every layer should be assigned its own background color?

Should gradients be using the "image background color" or the "second color in a color slot history"?

I don't mean to stomp on the idea of an image background color completely but I do think some of the deeper consequences need to be addressed in detail, and the options being presented to, and removed from, the user weighed.

Hi saulgoode,

On Tue, Apr 28, 2009 at 12:29 PM, 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 :)

David

Quoting David Gowers :

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.

I don't understand the last sentence (perhaps I don't understand Yahvuu's proposition correctly). If color values are never changed, the only place that erasures would result in an "image background color" (being revealed) is on the bottommost layer. Is that what is being proposed?

If so, then I would consider the lack of consistency in the tool's behavior across layers to be a problem.

If it is not so, what determines whether or not erasure results in the RGB part of the "image background color" being blended with the layer contents?

Hi saulgoode,

On Tue, Apr 28, 2009 at 7:00 PM, wrote:

Quoting David Gowers :

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.

I don't understand the last sentence (perhaps I don't understand Yahvuu's proposition correctly). If color values are never changed, the only place that erasures would result in an "image background color" (being revealed) is on the bottommost layer. Is that what is being proposed?

No, because your reasoning is oversimplified. The above situation could occur, but it depends on the image content. Some images would have transparent areas even on the bottom layer (this is common in web graphics and icons)

If so, then I would consider the lack of consistency in the tool's behavior across layers to be a problem.

Is there an inconsistency to be had? It will behave just the same as before, really. Only it will never ever change the colors on any layer, because it will never encounter a layer without alpha that requires it to paint with BG color instead.

If it is not so, what determines whether or not erasure results in the RGB part of the "image background color" being blended with the layer contents?

The alpha channel of the respective layers. Erasure never results in the image background color being blended with the layer contents. The effect on the layer contents is only a change in alpha channel, just like it currently is provided your layer has an alpha channel.

Yahvuu's proposition is essentially a) have a 'virtual layer' always at the bottom of the stack, filled with a color and
b) make all layers have an alpha channel

Nothing more. It does have some ramifications to certain functions (like Cut and Float) but none really to Eraser (just that the eraser code can be simplified. most likely)

David

guys,

here is sort of a review of what has been discussed here:

To take this top-down: I can only see this change as an UI improvement if it means getting rid of the bg color swatch. Only then we can reach the goal of less user thinking, instead of more.

but some crucial things depend on the bg color. the gradient tool being the big show-stopper for me. the tool needs a redesign, but up to then the fg->bg type of interaction looks to be the most (universally) usable to me.

also I really would like to know the number of plugins that use fg+bg in their functionality.

so a no-go on this count for me, really.

some medium level observations:

- there is still an added level of complexity for photo editing use where the bottom layer is naturally the opaque picture, where further edits and layer are piled upon. this is really a heavy minus point. high-end photo editing is one of the pillars of GIMP, according to our vision.

- all layers are transparent foils is something I see as and improvement. UI conceptional they could be always there, in actual file/memory implementation: on-demand.

- a new file consisting of a white bg-color-layer plus a first transparent layer is something I could live with as a concept. neutral on this one, the gain is somewhere else.

- so the bg-color-layer can have a color or be transparent. since this is how the image is made and evaluated in GIMP, this should set the export intent (for png for instance). for formats that do not have transparency (jpg) we are still in the same pickle: if the bg-color-layer is set to transparent, then what?

- png bKGD. looks to me it should be honoured on import (as file creating import, that is), no extra dialogs please. I tend to say it should not be used (by default) on export. a set bg-color-layer should be merged into the pixels. but then there is roundtrip safeness... import png as layer: what happens today? honour by merging to layer pixels?

- default bg-color-layer: white. a new GIMP document is solid white.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Wed, Apr 29, 2009 at 5:37 PM, peter sikking wrote:

guys,

here is sort of a review of what has been discussed here:

To take this top-down: I can only see this change as an UI improvement if it means getting rid of the bg color swatch.

How is one supposed to paint on mask without bg/fg color swatch?

Alexandre

Alexandre Prokoudine wrote:

On Wed, Apr 29, 2009 at 5:37 PM, peter sikking wrote:

guys,

here is sort of a review of what has been discussed here:

To take this top-down: I can only see this change as an UI improvement if it means getting rid of the bg color swatch.

How is one supposed to paint on mask without bg/fg color swatch?

ehm, fg would be there.

you mean painting on layer mask/selection?

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

peter (yahvuu) wrote:

peter sikking schrieb:

- png bKGD. looks to me it should be honoured on import (as file creating import, that is), no extra dialogs please. I tend to say it should not be used (by default) on export. a set bg-color-layer should be merged into the pixels. but then there is roundtrip safeness... import png as layer: what happens today? honour by merging to layer pixels?

i can't follow here. Was my analysis flawed? (https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-April/022178.html )

and I do not really follow what you wrote in there. I do have the feeling we draw different conclusions.

to clarify what I write:

import (creates new GIMP document window): bg-color-layer should be set to png bKGD.

import (creates new layer): png bKGD should be merged with image pixels.

conclusion there:
GIMP's equivalent for the PNG bg color is Preferences->Display-

Transparency

I cannot agree with this. completely different intent. bg-color-layer and png bKGD are about what will the image consumers see. Preferences->Display->Transparency is about how do GIMP users gauge transparency.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

Hello,
On Wed, Apr 29, 2009 at 11:17 PM, Alexandre Prokoudine wrote:

On Wed, Apr 29, 2009 at 5:37 PM, peter sikking wrote:

guys,

here is sort of a review of what has been discussed here:

To take this top-down: I can only see this change as an UI improvement if it means getting rid of the bg color swatch.

How is one supposed to paint on mask without bg/fg color swatch?

That's not included in yahvuu's proposal, but I proposed something that could neatly solve that, and address gradient issues: replace the FG/BG color concept with FG + cycleable 4-long color history. In this situation, you could still press a single key to swap between two colors (you would be swapping the previous color with the current color). Pressing it multiple times could cycle further back (in both cases you could get a simple OSD -- see MyPaint for example.). 'previous color in the color history' still can have roughly the same usage, we would just not be giving that color special treatment by labelling it 'BG'. The 'FG to BG' gradients still make sense in this context,
they could just become 'Current to old color' (and usage patterns should be virtually identical.)

Peter's done a good job synthesizing the 'BGcolor' with the requirement to specify whether alpha channel is desired in any exported/flattened image, and also notices similar problems to you.

The problems brought up by both of you, Alexandre and Peter, are addressed neatly by my proposal above. Perhaps it needs a mockup.. I feel it fits very well into yahvuu's proposition, turning its weakpoints into strong points.

Something that hasn't been brought up, BTW: Flatten Image vs Merge Visible layers. Not exactly the same, but would become closer to each other if Peter's description was implemented. Maybe we need to attempt to rationalize that.

The behaviour of Sample Merged seems fairly obvious here, but I'm bringing it up also, just in case.

David

2009/4/29 peter sikking

guys,

here is sort of a review of what has been discussed here:

To take this top-down: I can only see this change as an UI improvement if it means getting rid of the bg color swatch. Only then we can reach the goal of less user thinking, instead of more.

but some crucial things depend on the bg color. the gradient tool being the big show-stopper for me. the tool needs a redesign, but up to then the fg->bg type of interaction looks to be the most (universally) usable to me.

Unless you make a ease and nice way of swathing (or alternating) colors, I'm against it.
When you are painting (making a digital painting or painting on a mask...) in the current version you just hit "X" to alternate between bg / fg colors. Its just ease that way.

But I really like the bg color and the idea of "always transparent" new layers.

Just my two cents. =)
Thanks for your efforts.

On Thu, Apr 30, 2009 at 12:49 AM, Filipe Soares Dilly wrote:

2009/4/29 peter sikking

but some crucial things depend on the bg color. the gradient tool being the big show-stopper for me. the tool needs a redesign, but up to then the fg->bg type of interaction looks to be the most (universally) usable to me.

Unless you make a ease and nice way of swathing (or alternating) colors, I'm against it.
When you are painting (making a digital painting or painting on a mask...) in the current version you just hit "X" to alternate between bg / fg colors. Its just ease that way.

I've already made a proposal that thoroughly addresses this twice in this thread. It is based on a system MyPaint (http://mypaint.intilinux.com) uses, so I've already tried a very similar system and found it very effective.

It's simply a 5-slot color history, with X selecting from it (when a color is 'chosen', it goes into slot #1 in the history (slot #1 == FG/ actual painting color), the old color moves into slot #2, and the rest of the items are moved back if needed. Just standard history operation.)

X could work almost unchanged (just, pressing X multiple times in quick succession would move back through the 5-slot color history, rather than just swapping the two newest slots. So your current usage of X would be unchanged, but you could use it to switch between more than 2 colors)

So far, no one has given any feedback on the idea, or indeed any acknowledgement of it. This disappoints me, as it really does fit neatly into the 'holes' of yahvuu's proposal and would make those areas even more effective than GIMP currently is before implementing yahvuu's proposal alone.

In case people have read it and simply not understood what I meant, I'll provide an animated GIF,
and perhaps submit a derivation of the GIF to gimp-brainstorm.blogspot.com

http://img.photobucket.com/albums/v449/neota/alphazero/animation.gif

I'm not sure whether or not Yahvuu was alluding to my proposal when he says

i think the gradient tool would work equally well if the swatches were named "left" -> "right".

If we maintain a strict visual order (eg. newest at right -- see my GIF above), this could work better than naming it 'current' -> 'previous'

David

David Gowers wrote:

On Thu, Apr 30, 2009 at 12:49 AM, Filipe Soares Dilly wrote:

Unless you make a ease and nice way of swathing (or alternating) colors, I'm against it.
When you are painting (making a digital painting or painting on a mask...) in the current version you just hit "X" to alternate between bg / fg colors. Its just ease that way.

I've already made a proposal that thoroughly addresses this twice in this thread.

I certainly like your proposal, but interaction design is not performed by taking the best bits of different programs and mashing it together. Just because it works well in MyPaint does not mean it will work well in GIMP (although I can not yet see why it wouldn't). Before we know it works well someone needs to make an interaction design analysis of how well this will work in GIMP. Since I am not trained in this I'm waiting for the IxD guys do comment.

- Martin

Moin,

On Wed, Apr 29, 2009 at 15:37, peter sikking wrote:

To take this top-down: I can only see this change as an UI improvement if it means getting rid of the bg color swatch. Only then we can reach the goal of less user thinking, instead of more.

One thing I use the bg color swatch for is to fast switch between black and white. Eminently if I work with masks I have a finger on the X to switch. If the bg color swatch will be remove I need a new way to swith fast between different colors.

Regards, Tobias

On Thu, 30 Apr 2009 11:01:08 +0930 David Gowers wrote:

X could work almost unchanged (just, pressing X multiple times in quick succession would move back through the 5-slot color history, rather than just swapping the two newest slots. So your current usage of X would be unchanged, but you could use it to switch between more than 2 colors)

So far, no one has given any feedback on the idea, or indeed any acknowledgement of it. This disappoints me, as it really does fit neatly into the 'holes' of yahvuu's proposal and would make those areas even more effective than GIMP currently is before implementing yahvuu's proposal alone.

I didn't understand it at first, and believed that the idea was that 'x' would cycle through the colours in a palette. Meaning that the user would press 'x' once to change to a new colour and another four times to go back to the original. Looking at your animated gif it all makes a lot more sense, although I suspect that the timings will be critical. I would also (as a user) want some method of adjusting or "loading" those five colours, either via 5 swatches in the tool box, or a single "choose colours" dialog.

If we maintain a strict visual order (eg. newest at right -- see my GIF above), this could work better than naming it 'current' -> 'previous'

It does also resolve a question that was floating around in my head as to what the "new" non-background colour would be called. The gradient tool is an obvious example of one where the foreground/background naming convention is strong, and easy to understand. This might require that the "choose colours" dialog allows a method for swapping the colour order, because having to do it using only 'x' could get annoying when arranging two colours for use in a gradient.

I guess some third-party plug-ins rely on fg/bg values. For instance, FX Foundry -> Convert color temperature. That's for compatibility. And there should be a way to a provide an interaction between script-fu and user selectable colors.

With respect, Alexander Rabtchevich

Hi Jon!

On Thu, Apr 30, 2009 at 4:35 PM, Jon Senior wrote:

On Thu, 30 Apr 2009 11:01:08 +0930 David Gowers wrote:

X could work almost unchanged (just, pressing X multiple times in quick succession would move back through the 5-slot color history, rather than just swapping the two newest slots. So your current usage of X would be unchanged, but you could use it to switch between more than 2 colors)

So far, no one has given any feedback on the idea, or indeed any acknowledgement of it. This disappoints me, as it really does fit neatly into the 'holes' of yahvuu's proposal and would make those areas even more effective than GIMP currently is before implementing yahvuu's proposal alone.

I didn't understand it at first, and believed that the idea was that 'x' would cycle through the colours in a palette. Meaning that the user would press 'x' once to change to a new colour and another four times to go back to the original. Looking at your animated gif it all makes a lot more sense, although I suspect that the timings will be critical. I would also (as a user) want some method of adjusting or "loading" those five colours, either via 5 swatches in the tool box, or a single "choose colours" dialog.

Thanks for the feedback ! :)

I envision that you would just choose colors whenever you want, and that new color would enter slot #1, and push back the other items (knocking the item in the old slot #5 out).

This is how it works in MyPaint, and it's pretty effective. However, this may take some consideration as to when to adjust the color history, as the color selection dialog of GIMP allows you to tweak colors continuously, with no clear indication of when you're 'done' selecting a color.
I guess we'd store a copy of the color which was in slot #1 before changing it, and then adjust the history (slots 2,3,4 -> slots 3,4,5; stored color -> slot 2; new color = slot 1) after a certain time delay(1.5 seconds?). In this way slot 1 would always be current, while avoiding overpopulating the history with minor tweaks of a single color.

In the case of clicking to sample colors from gradients, the history ought to update each time the user releases the left mouse button. (Note: my understanding is that there is a distinct lack of users who are aware they can left-click to sample colors from gradients, sadly.)

In the case where the popup dialog, or palettes, or eyedropping, or drag-n-dropping colors, is used, no delay is necessary (because the user is explicitly specifying when the color is 'ready'; the meaning of their actions is entirely unambiguous.)

If you wanted to fill all 5 slots with 5 specific colors from the image, you'd just ctrl+click 5 times (assuming you're currently using a paint tool), or click one after another on 5 colors in your palette, or one of the other methods I mention above (that currently only effect the FG color). Simple. With that, I believe there is no need to edit anything other than a single color (slot #1, the current color)

On a related note: The popup color editing dialogs have color history (A ColorNotebook?)
(for example, doubleclick on a palette color) This is slightly different in nature to the kind of history I'm suggesting -- the popup history list is like a list of 'colors I like' (10 long; colors are only added explicitly with the '>' button), whereas my history list of course is of 'colors I'm using right now (or recently)'.
These two lists would not interact in any way, due to their fundamentally different application.

It's important to depict these two color histories in a differing way, so that there is no confusion between the two types of history (semi-permanent vs transient)

If we maintain a strict visual order (eg. newest at right -- see my GIF above), this could work better than naming it 'current' -> 'previous'

It does also resolve a question that was floating around in my head as to what the "new" non-background colour would be called. The gradient tool is an obvious example of one where the foreground/background naming convention is strong, and easy to understand. This might require that the "choose colours" dialog allows a method for swapping the colour order, because having to do it using only 'x' could get annoying when arranging two colours for use in a gradient.

Again, a maximum of two eyedroppings/ your method of choice should easily arrange the color history appropriately.

Also, my experience with MyPaint is that needed keypresses are few -- remember, you would only have to press X a maximum of 8 times to get any two colors to the front.
The '8' example comes from if you want slots #5, #4 transferred to #2, #1. You press X four times to select #5, and wait a short time (1.5s?); then press X another four times to select #4 (which became #5 after your previous selection).
the history looked like this (letters represent colors rather than slots) "ABCDE" and after the first step it looks like "BCDEA", after the second step it looks like "CDEAB" (ie. the content of slots #5, #4 moved into slots #2, #1)

If you still believe any more editing machinery than what I describe above is necessary, please elucidate.

Thanks.

David

I just ran through my scripts.

In the .scm files distributed with gimp, there were: 38 files containing gimp-context-set-foreground 65 files containing gimp-context-set-background

looking at the scripts I have installed in my home directory, there were: 49 files containing gimp-context-set-foreground 29 files containing gimp-context-set-background

This is my no means a thorough assessment. Perhaps the individual operating the gimp plugin registry could grep all the plugin files and give a better count of the third party scripts using these calls.

-Rob A>

I guess some third-party plug-ins rely on fg/bg values. For instance, FX Foundry -> Convert color temperature. That's for compatibility. And there should be a way to a provide an interaction between script-fu and user selectable colors.

With respect, Alexander Rabtchevich

On Thu, Apr 30, 2009 at 9:13 PM, yahvuu wrote:

Hi David,

here's a mockup idea on your proposal; might or might not help to identify the currentprevious color pair... just brainstorming.

I hope you're not bothered i'm sending private mail - it's just i can't contribute anything generally useful on the topic, much along the lines of what Martin said.

When Martin said that, I thought "that just means it's inappropriate for us to make the decisions. It doesn't mean we shouldn't do research -- in fact, I'm sure Peter Sikking would appreciate it."

Hence, I've CCed this to the list.

All i know (or imagine to know ;) is that the only tool which requires the background metaphor is the eraser, including the 'selection erasers' delete and cut. I don't even see a conflict with bg-color-layer, despite that's where i started to question the bg color swatch..

So from my point of view, everything is open for the tool box, be it mypaint style, or even mypaint+bg color, color swatch plugins, leftright+bg color, you name it.

I've looked at your image, and I'm not sure what it's supposed to be. A layout for the OSD? or a toolbox status display? Or something else?

When you say 'toolbox' I'm also not sure whether you mean the optional colors display at the top of the toolbox, or the 'Colors' dockable (or both)

Have you looked at MyPaint? It doesn't *have* a status display :) It allows you to edit the current color (via a shortcuttable menu item) and move through the color history; that's the only time you see the color history, via the Onscreen Display. The OSD I mocked up before is pretty close to what MyPaint's OSD looks like, though.

I've created a mockup of my own idea of a toolbox status display. It's based on the old color display (I think we should try to take the same amount of space as before).. It's attached. I believe it makes the current + immediately previous color obvious, while clearly prioritizing the current color, and showing the other indication. I left the 'reset' and 'swap' icons there, because they still make some sense.

In the OSD I mocked up, the current + previous color are always the rightmost color , and the color immediately next to it. So IMO no further indication is needed in the OSD.

many thanks for taking the time for discussion and all the great work on GIMP,

Thanks for starting this thread that so much interesting discussion has come out of :)

David

On Thu, Apr 30, 2009 at 10:36 PM, Rob Antonishen wrote:

I just ran through my scripts.

In the .scm files distributed with gimp, there were: 38 files containing gimp-context-set-foreground 65 files containing gimp-context-set-background

The ones I have looked at, mainly set background and then do a edit-fill with BG or a drawable-fill.

looking at the scripts I have installed in my home directory, there were: 49 files containing gimp-context-set-foreground 29 files containing gimp-context-set-background

This is my no means a thorough assessment.  Perhaps the individual operating the gimp plugin registry could grep all the plugin files and give a better count of the third party scripts using these calls.

There is no question of removing either of the above PDB functions, AFAICS. It's just a matter of what to do to emulate the old FG / BG behaviour. In the case of my proposition, FG would remain (as slot #1 -- 'current') and BG would map to slot #2 ('immediately previous'). However, one side effect is that setting FG could change BG (through the normal history cycling mechanism). Erk.

David

another round of review:

OK, first the 5-slot color history:

So far, no one has given any feedback on the idea, or indeed any acknowledgement of it. This disappoints me

Sorry, I had to think about it more before stepping in to this, doing that yesterday would have been too fast.

I see we need to maintain the following iron compatibility, with tools, scripts and users:

- there needs to be a foreground color and an alternate, call them fg and alt, and they always need to have a value.

- swapping fg and alt is very important. the magic-X is holy for usability sake. in the heat of painting it can be pressed with a surprising high frequency, so giving any meaning to clicking X twice is not possible.

- the color of fg can be changed (color selector, eyedropper). this cannot change the value of alt.

- assigning the default black + white to fg and alt needs to stay. way to much meaning behind that, mask painting for instance.

disappointing conclusion: there is not much we can change about the current fg + bg, except renaming it to fg + alt, and fiddle with how it is used for instance in Edit->Fill with ..., or for creating new layers. The 5-slot color history can only work for fg, alt is not part of that (drag and drop of colors from history to alt could work, however). fg+history need another key-press than X to cycle through.

the whole 5-slot color history (plus a pop-up with a lot of more (49?) older history) can be packed in the current fg/bg color dockable. toolbox: no, I do not think so.

yesterday I said:

I can only see this change as an UI improvement if it means getting rid of the bg color swatch. Only then we can reach the goal of less user thinking, instead of more.

hmmm, bg (call it alt) is not going to go away; getting the bg color disconnected from file flattening during export is ruined by edge cases;
and the layers always having an alpha: actually, why is that not simply so today?

However,
this may take some consideration as to when to adjust the color history, as the color selection dialog of GIMP allows you to tweak colors continuously, with no clear indication of when you're 'done' selecting a color.

ouch. that is a spanner in the works.

png bKGD: I would say at this point: we stick to how GIMP opens those pngs now, as new doc or as layer (unless there is a horrible bug in it). Saving: I say again: avoid using this by default.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Thu, Apr 30, 2009 at 11:56 PM, peter sikking wrote:

OK, first the 5-slot color history:

So far, no one has given any feedback on the idea, or indeed any acknowledgement of it. This disappoints me

Sorry, I had to think about it more before stepping in to this, doing that yesterday would have been too fast.

127> I see we need to maintain the following iron compatibility,

with tools, scripts and users:

- there needs to be a foreground color and an alternate,   call them fg and alt, and they always need to have a value.

- swapping fg and alt is very important. the magic-X is   holy for usability sake. in the heat of painting it can   be pressed with a surprising high frequency, so giving   any meaning to clicking X twice is not possible.

Yes (although, in case there is any confusion: it's impossible to swap colors while painting.
Oddly, it's NOT impossible for colors to change during painting (do something like, open a gimp-python console and run "import time;time.sleep (10.0);gimp.set_foreground(127,255,0)" and start painting (hold the mouse button down) for about 15 seconds -- the color will change and glitching occurs (brush apparently becomes a square block of similar size when you are painting the second color) )

- the color of fg can be changed (color selector, eyedropper).   this cannot change the value of alt.

Yeah ;(

- assigning the default black + white to fg and alt needs to stay.   way to much meaning behind that, mask painting for instance.

disappointing conclusion: there is not much we can change about the current fg + bg, except renaming it to fg + alt, and fiddle with how it is used for instance in Edit->Fill with ..., or for creating new layers. The 5-slot color history can only work for fg, alt is not part of that (drag and drop of colors from history to alt could work, however). fg+history need another key-press than X to cycle through.

Hmm, this idea deserves some consideration. FG+history. I do really think we need to reduce the role of alt/BG/whatever we call it -- visually I mean -- since it's mainly used for corner cases and thus has less importance. I think we could benefit somewhat from changing the toolbox color status display to look like this:

FFFFFF FFFFFF
rBBBBx

where F=FG B=BG and r/x = reset/swap (A variation on the design I posted earlier related to color history)

This has also the advantage of making the FG area a better click target.

the whole 5-slot color history (plus a pop-up with a lot of more (49?) older history) can be packed in the current fg/bg color dockable toolbox: no, I do not think so.

I admit I'm out of touch there -- I never have that little status display enabled :)
Anyway if BG/alt is required, then there's no reason to make any such modification, yes.

yesterday I said:

I can only see this change as an UI improvement if it means getting rid of the bg color swatch. Only then we can reach the goal of less user thinking, instead of more.

hmmm, bg (call it alt) is not going to go away; getting the bg color disconnected from file flattening during export is ruined by edge cases;
and the layers always having an alpha: actually, why is that not simply so today?

I thought it was simply a matter of efficiency, alpha channel inflating layer memory requirements by 33% minimum (RGB) up to 100% maximum (GRAY / INDEXED)

David