Hi, saulgoode@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx schrieb: > 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. GIMP should absolutely support to create any desired constellation of alpha/layers/... required for foreign file formats. The goal of the 'all layers have alpha' model is to separate these concerns from image editing - they are better adressed at export time. (and the image bg color proposal is an appendix to that model) I'll take an extreme example, trying to make myself clear: say a certain file format plugin XY supports to save text objects which are less capable than GIMP's text objects. One solution would be to introduce a compatibility mode for GIMP's text objects. But very few users want to be asked 'GIMP text or XY format text?' every time they create text. Clearly, it's better to convert the text objects on export. I see this example as an analogy for the alpha/non-alpha question for layers. XCF does support alpha, and yet it would sometimes be useful to downgrade to non-alpha, with export in mind (in your case even oftentimes). But the distinction alpha 'yes or no?' gets in the way when editing the image. Always. It should be resolved on export. I really hope that any workflows that become inconvenient under the 'always alpha' model can be served in alternative ways. For smooth exporting alone, it may be sufficient to opaquely fill the layers and never touch the alpha. > > 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? No, for the proposed model, the eraser should solely work on the alpha channel. An eraser which modifies the RGB color is in effect a brush tool. > Should gradients be using the "image background color" or the "second > color in a color slot history"? definitely not the image background color. All tool colors must be provided by the tool box. greetings, peter _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
