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
[Gimp-developer] The old bugs in merging modes are fixed now?
I hoped that with the passage to GEGL the old bugs in the Mreging mode were fixed (i refer here to OVERLAY, that in gimp is NOT overlay but a misnamed clone of Soft Light, and to Color that do not seems work properly ) But i didn't see any news in the release notes, or in the Bugzilla reports Did i miss something, and that is already solved, or is on the to do list. Is not good for a advanced Graphic editor have similar bug regarding something basic as the correct application of Merging modes (is true that few users notice the problem in Overlay, since anyway the result should be similar to Soft Light...but similar not always identical ) If were fixed ,such good news should be reported ___ 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] The old bugs in merging modes are fixed now?
Alchemie foto\grafiche wrote: I hoped that with the passage to GEGL the old bugs in the Mreging mode were fixed (i refer here to OVERLAY, that in gimp is NOT overlay but a misnamed clone of Soft Light, and to Color that do not seems work properly ) Hi With GEGL enabled for the projection (View - Use GEGL) the layer modes Overlay and Soft Light are not identical any longer, in other words fixed in that sense. Iirc I reused the legacy algorithm verbatim for the Color mode so if the legacy code had issues the GEGL code probably will as well. We should fix Color mode before we use GEGL for the projection by default. I looked up the bug report for this: Bug 325564 – Layer mode Color doesn't work well http://bugzilla.gnome.org/show_bug.cgi?id=325564 and put it on the 2.8 milestone list. There is a closed bug report for the Overlay mode but can't find it right now. There have not yet been a release for which this could be mentioned in the release notes. Plus, as long as GEGL is not used for the projection by default this is not really that big news. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
