Re: [Gimp-developer] Background color property for GIMP images
On Thu, 30 Apr 2009 11:01:08 +0930 David Gowers 00a...@gmail.com 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. -- Jon Senior j...@restlesslemon.co.uk ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi Jon! On Thu, Apr 30, 2009 at 4:35 PM, Jon Senior j...@restlesslemon.co.uk wrote: On Thu, 30 Apr 2009 11:01:08 +0930 David Gowers 00a...@gmail.com 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
Re: [Gimp-developer] Background color property for GIMP images
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Thu, Apr 30, 2009 at 9:13 PM, yahvuu yah...@gmail.com wrote: Hi David, here's a mockup idea on your proposal; might or might not help to identify the current-previous 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, left-right+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 attachment: toolbox-color-mockup.png___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Thu, Apr 30, 2009 at 10:36 PM, Rob Antonishen
rob.antonis...@gmail.com 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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi all, David Gowers schrieb: 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. yep. Me too regards this as research, exploring and checking potential solutions. This is very different from trying to push a certain feature, requesting 'GIMP should work like this or that'. Decision time comes when the pros and cons are known and somebody is actually interested in implementing an idea. For UI design, the possibilities are endless and i just have no sound base to think about paint tools and color swatches, so i can contribute very little but noise here. So far for my personal things ;) 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? OSD layout. some permutations with the gradient tool in mind. As it's now on the list, here's for everybody to see: http://www.picturepush.com/public/1664460 ... just a spontaneous thought greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi all, 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) conclusion there: GIMP's equivalent for the PNG bg color is Preferences-Display-Transparency greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hello, On Wed, Apr 29, 2009 at 11:17 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi all, peter sikking schrieb: and I do not really follow what you wrote in there. I do have the feeling we draw different conclusions. indeed, obviously we draw different conclusions from the very same specs. Here's my take on why png bKGD is complementary to any (future) element of XCF: The background color given by bKGD will typically be used to fill unused screen space around the image this intention is really different vom any XCF intent , as well as any transparent pixels within the image. transparent XCFs are meant to be transparent, wether or not they are specified with the help of a bg-color-layer. (Thus, bKGD is valid and useful even when the image does not use transparency.) GIMP bg-color-layer is redundant when the bottom layer is opaque Viewers that have a specific background against which to present the image (such as Web browsers) should ignore the bKGD chunk giving presentation hints for viewers is outside the scope of XCF, no part of it is optional when it gets rendered. bg-color-layer and png bKGD are about what will the image consumers see. I think that doesn't really match png bKGD: in the common web use-case, the png bKGD gets intentionally ignored by the browser, so the consumers never see it. This use-case is in turn why most(?) image viewers and GIMP also do ignore png bKGB: to gauge transparency. greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
2009/4/29 peter sikking pe...@mmiworks.net 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. -- Filipe Soares Dilly dilly.carbonmade.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi all, peter sikking schrieb: 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. i think the gradient tool would work equally well if the swatches were named left - right. When i want a red-yellow gradient on a blue background, i even have to override my background color. I'd like to add that a 'background' can only be defined in artistic terms. (I learned that when 'foreground select' tool came along: i already have a fg color, what's that for?!?...) some medium level observations: [..] total agreement here (leaving the PNG corner case aside) greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Thu, Apr 30, 2009 at 12:49 AM, Filipe Soares Dilly fil...@gmail.com wrote: 2009/4/29 peter sikking pe...@mmiworks.net 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
David Gowers wrote: On Thu, Apr 30, 2009 at 12:49 AM, Filipe Soares Dilly fil...@gmail.com 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi saulgoode, On Tue, Apr 28, 2009 at 7:00 PM, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting David Gowers 00a...@gmail.com: 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi, Sparr schrieb: 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. thank you, that's interesting to learn. However, when examining the consequences for the PNG plugin, the PNG behaviour turns out to be completely different to the proposed XCF bg color. This background color thingy touches on so many topics, that i'd like to prepend that it's intended purpose is to avoid special-casing for a unified image model which equips all layers with alpha channels. The GIMP background color acts much like a semi-layer at the bottom of the image which is always filled with a fixed color. You can't paint on it, only change that color. (In a way, the one desired anomaly - the eraser should not punch holes into the default document - just gets shifted from the background layer to the image bottom and is thereby made explicit.) In effect, the user is provided a prominent place to state that she wants to fill any transparency in the image projection with a fixed color. This explicit information in turn simplifies the export process a bit. The PNG format's background color behaviour is very different from that concept: 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. which means that the PNG format makes a non-binding suggestion for the image's environment. The proposed XCF bg color, in contrast, aims to define the image pixels. And it is compulsory to evaluate the bg color when such an XCF file gets rendered. So introducing a bg color for GIMP images doesn't neccessarily imply any changes for the PNG plugin: - if the XCF bg color is opaque, the resulting PNG must be opaque, too. The PNG bg color doesn't help with this, the user however is free to attach it. - if the XCF bg color is transparent, the projection may contain transparent pixels, which in turn are converted to transparent PNG pixels. Here too, the PNG bg color is independent from the action. GIMP's equivalent for the PNG bg color is Preferences-Display-Transparency. I think it's best to provide a color chooser inside the PNG plugin and possibly initialize that from the display preferences. greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Quoting David Gowers 00a...@gmail.com: 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? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi, David Gowers schrieb: Hi saulgoode, On Tue, Apr 28, 2009 at 12:29 PM, saulgo...@flashingtwelve.brickfilms.com wrote: 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. i have to disagree. The PNG background color semantics are very different from the proposed XCF bg color. In fact, PNG provides a presentation hint for the image's environment, rather than specifying the image's colors. I have recently posted my analysis somewhere upstream on this thread. My conclusion is that importing as layers is independent from the image background color. It should not modify this color. I think 50% grey (#bababa) is a better default BG color for when a default is needed. no opinion on that from my side. I chose white solely to match the current default image's color. greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi, David Gowers schrieb: 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. Yep. Just in case this rooted a misunderstanding, i'd like to add that the eraser is totally independent from the proposed image background color. This applies to the other paint tools as well. That fact that the eraser always works on alpha alone is implied by b). greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
Hi, David Gowers schrieb: On Mon, Apr 27, 2009 at 2:20 AM, yahvuu yah...@gmail.com 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 err, that's why i used 'copy' in the key sequence... Still not that nice to type. Anyhow, i'd be interested in the larger picture of that workflow: - you're working in the 'stone quarry' of an aquired bitmap here? - would it help to first cut out the 'fossil' as a whole and to segment it later on? .. this probably just shows i haven't understood what you're doing.. greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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 -- GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Sun, Apr 26, 2009 at 8:01 AM, yahvuu yah...@gmail.com 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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 :) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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
Re: [Gimp-developer] Background color property for GIMP images
Hello yahvuu, On Sun, Apr 26, 2009 at 9:31 PM, yahvuu yah...@gmail.com 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
Re: [Gimp-developer] Background color property for GIMP images
Hi, David Gowers schrieb: 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.. A set of good rationales is IMO: GIMP is an XCF editor. It can't be a perfect PNG, TIFF, GIF,.. editor at the same time - at least not with a good UI. That means, the complexities of export should not show up during editing. Getting the the most out of a certain file format is an essential difficulty, which deserves a dedicated UI of it's own. It is non-negotiable that GIMP allows the user to export optimal files. And a lot of excellent work has been done to provide this functionality. Allowing access to all the nitty-gritty details doesn't rule out to provide a bird's eye view on export which concentrates on the central trade-offs (typically size vs. quality) for users who don't care. Concretely, the export process must provide a way to remove the alpha channels. The best way to present this i could think of yet, is to do this as a chain of operations, resembling a GEGL branch on top of the image. For the PNG example, this would be something like: write to bla.png ^ | convert to PNG ^ | fill transparency with image bg color ^ | merge layers Such an 'export branch' can be autocreated with sensible defaults, (many times as soon as on import time). Besides other benefits, these defaults will just be good enough most of the time. greetings, peter (of course the better part of the rationales is stolen from the UI team, any flaws are my own) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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) in terms of the model under discussion, this is a shortcut for cut fill. I wonder, doesn't CTRL+C.V do the trick? greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
On Mon, Apr 27, 2009 at 2:20 AM, yahvuu yah...@gmail.com 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Background color property for GIMP images
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
