Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On Sat, Feb 24, 2001 at 06:16:13PM +0100, [EMAIL PROTECTED] wrote: > COW is indeed a good thing. However I assume you address the mentioned > memory overhead with your answer and I'm not sure how you would avoid > it with copy-on-write. You're completely right. It was a thinko on my part, I have been starting at assoc/ non-assoc alpha channels for too long and forgotten that the storage is inline and thus not amenable to COW. Sorry everyone. Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On 23 Feb, Nick Lamb wrote: >> Does this mean that you agree to ditching all the special code >> for the 3 and 1 byte case as well? I'd really love to see this >> changes although as already stated this might introduce a bit >> memory overhead in case the user didn't use the alpha channel >> at all. > If we can get back COW during 1.3 this overhead is zero (all new > channels / layers etc. can be created as COW tiles with the > apppropriate contents -- huge speedup). COW is indeed a good thing. However I assume you address the mentioned memory overhead with your answer and I'm not sure how you would avoid it with copy-on-write. The 3 byte will be always problematic because we always step over memory boundaries which is a huge loss in performance on any modern architecture. However restructuring the code to have a special function for each of the possible cases could be a cure to the branchprediction smashing distinguish in the source of the performance critical functions. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On Friday, 23 Feb 2001, Nick Lamb wrote: > If we can get back COW during 1.3 this overhead is zero (all new > channels / layers etc. can be created as COW tiles with the > apppropriate contents -- huge speedup). > > I believe COW was lost because there were problems making it stable > with all the spaghetti in 1.1.x, but presumably as we wipe out the > worst of the spaghetti we should be able to bring it back, no? I thought 1.2.x shipped with COW still enabled? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On Fri, Feb 23, 2001 at 06:30:53PM +0100, [EMAIL PROTECTED] wrote: > Does this mean that you agree to ditching all the special code > for the 3 and 1 byte case as well? I'd really love to see this > changes although as already stated this might introduce a bit > memory overhead in case the user didn't use the alpha channel > at all. If we can get back COW during 1.3 this overhead is zero (all new channels / layers etc. can be created as COW tiles with the apppropriate contents -- huge speedup). I believe COW was lost because there were problems making it stable with all the spaghetti in 1.1.x, but presumably as we wipe out the worst of the spaghetti we should be able to bring it back, no? Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On 22 Feb, Sven Neumann wrote: > We'll face one problem if we decide to make alpha the default for all > images: A lot of fileformats do not understand alpha and you actually > don't want to save the alpha channel with the image at all if you > never touched it. One way to solve this would be to introduce a > function to check if the image's alpha channel is empty. This hint > could be set from the already existing tile-row hints without too > much overhead. As you said. For one we can use some special dirty flag for the Alpha channel and for the case of the non-alpha fileformats we simply do the same as now: Flatten image. Does this mean that you agree to ditching all the special code for the 3 and 1 byte case as well? I'd really love to see this changes although as already stated this might introduce a bit memory overhead in case the user didn't use the alpha channel at all. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
Hi, Jens Lautenbacher <[EMAIL PROTECTED]> writes: > Let's just think of your casual user who never understood nor even > heard of layers or that gimp has something like this. He just want's > to edit a single layer, and starts to clear a selection, or use the > eraser. In my opinion such a complete newbie wouldn't be surprised by > having the eraser/clers selection act like really clearing the image > i.e. removing parts of it completely. Maybe he would think what the > hell is this checherboard, but would very quickly become accustomed to > it. The behaviour of having the eraser effectively drawing in the bg > color isn't that much more intuitive. I agree to Jens points here. Having the eraser draw with the background color is a special case which does not make the user interface simpler and certainly messes up the code. We'll face one problem if we decide to make alpha the default for all images: A lot of fileformats do not understand alpha and you actually don't want to save the alpha channel with the image at all if you never touched it. One way to solve this would be to introduce a function to check if the image's alpha channel is empty. This hint could be set from the already existing tile-row hints without too much overhead. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
[EMAIL PROTECTED] (Raphael Quinet) writes: > I think that confusing the first category of users (those who do not > think in terms of layers) would be worse. Many users are still using > the Gimp as they would use xv, Windows Paint or other simple tools: > they do not care about layers and they do not even know what they > mean. I have witnessed this when I observed several of my colleagues > using the Gimp. Although the concept of layers is powerful and simple > to understand, this is simply not necessary for many users (not > professionals, just casual users -- and this is the majority). I still voute for always having alpha. Let's for the moment forget about the fact that changing something in a new version will frustrate users who know and expect a certain old behaviour. this is always the case for any user visible change of the modus operandi. Let's just think of your casual user who never understood nor even heard of layers or that gimp has something like this. He just want's to edit a single layer, and starts to clear a selection, or use the eraser. In my opinion such a complete newbie wouldn't be surprised by having the eraser/clers selection act like really clearing the image i.e. removing parts of it completely. Maybe he would think what the hell is this checherboard, but would very quickly become accustomed to it. The behaviour of having the eraser effectively drawing in the bg color isn't that much more intuitive. I think the people which would be bitten most by changing stuff like I propose would be old but still clueless gimp users. jtl ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On Thu, 22 Feb 2001, Seth Burgess <[EMAIL PROTECTED]> wrote: > I know you're trying to make a point, but I'd actually > agree with that assessment too, if for slightly > different reasons. The user has no way of knowing > what shade of gray they are about to place on the > image. I don't think this is used anywhere near as > commonly as layers/transparency, so isn't perceived as > such a big problem. But it should get some attention > as well. [...] It is even worse when you are working with indexed images (yes, there are people who are working with GIF images) because you can use only a limited set of colors and many tools do not work as expected. In fact, the support for indexed images in the Gimp is not very good, but in some cases it is better to live with the limitations of the indexed mode than converting to RGB and then back to indexed. For example, some games require a fixed palette, or sometimes you need to assign a specific index value to some pixels. I don't think that converting everything to RGB automatically is a good solution. It is not the solution for indexed images and not for grayscale images either. Now, about the alpha channel... When I posted my first message in this thread, I vaguely remembered what we discussed last year and I though that always adding an alpha channel would be the best solution. However, I re-read the discussion from last year and I saw that at that time I proposed to add an alpha channel as soon as a second layer is added, but not before. You can read the old thread with the subject ``Is "Add alpha channel" really necessary?'' on this page: http://lists.xcf.berkeley.edu/lists/gimp-developer/2000-May/date.html I think that it makes more sense to add an alpha channel when a second layer is created, not before (but I could change my mind again :-). Basically, we have to choose the lesser of two evils: 1) Adding an alpha channel to all images (even with a single layer) will confuse some users who think of their images as "flat" things (no layers, no transparency). They would see that the new version of the Gimp adds transparent areas when they use the eraser or when they cut a selection. And then they would be told to flatten their image before saving it, because the file format they are using did not support transparency. 2) Adding an alpha channel as soon as a second layer is added will confuse some users when they see that adding a layer causes the eraser or the cut operation to behave differently on the background layer (actually, they would behave in the same way as in all other layers, but not as they did before when the image was flat). I don't think that the second case is a real problem. These users already know about about layers and transparency, and they will expect all layers to behave in the same way. I think that the current situation is worse, because the background layer behaves differently from all other layers until you explicitely use "Add Alpha Channel". If you read the discussion from last year, you will see that I was surprised to discover that some users used the following solution when they did not understand why the background layer was behaving differently: they duplicated the background layer, then deleted the original one. For them, it was faster (two mouse clicks) and (surprisingly) more intuitive than finding "Add Alpha Channel" in some menu. I think that confusing the first category of users (those who do not think in terms of layers) would be worse. Many users are still using the Gimp as they would use xv, Windows Paint or other simple tools: they do not care about layers and they do not even know what they mean. I have witnessed this when I observed several of my colleagues using the Gimp. Although the concept of layers is powerful and simple to understand, this is simply not necessary for many users (not professionals, just casual users -- and this is the majority). -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
Zach, I know you're trying to make a point, but I'd actually agree with that assessment too, if for slightly different reasons. The user has no way of knowing what shade of gray they are about to place on the image. I don't think this is used anywhere near as commonly as layers/transparency, so isn't perceived as such a big problem. But it should get some attention as well. In this case, changing the toolbar when that image is active is a possibility, if grayscale editing is still a goal. Also, the color selectors would have to change depending on the mode, so you're introducing the same problem in a different spot. I think what it comes down to is that modes increase the load on the user of the tool. If they have to exist, there should always be a clear indicator of the current mode. Where possible, I'd like to see them go away. Seth > If that is the case, I have noticed another flaw. > When I am working > in the grayscale image mode, and I use the > paintbrush to try and draw > a color on the image, it comes out in gray!! This is > clearly wrong > behavior. You would not expect a tool to have two > different modes of > operation depending on the image you are drawing on! > Obviously, all > images should be color. > > Zach > -- > [EMAIL PROTECTED] Zachary Beane > http://www.xach.com/ > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On Thu, Feb 22, 2001 at 04:23:27PM +0100, Jens Lautenbacher wrote: > Seth Burgess <[EMAIL PROTECTED]> writes: > > > Well, I strongly dislike having an eraser tool that > > behaves differently based on a property of an image > > you can't even see. It really stinks. > > > > What I'd prefer to see is a "replace color" paint tool > > that can handle bgs or any other layer the way eraser > > works now on a bg layer. > > > > Keeping the user experience the same between versions > > is not a good thing when the user experience sucks. > > > > Seth > > I second this. We have too long stayed with this behaviour. I doubt > that there a too many people using gimp for (and _only_ for) one layer > images. If I once grokked the idea of layers, the current behaviour as > it is strikes me as unintuitive even when working on single layer > images. If that is the case, I have noticed another flaw. When I am working in the grayscale image mode, and I use the paintbrush to try and draw a color on the image, it comes out in gray!! This is clearly wrong behavior. You would not expect a tool to have two different modes of operation depending on the image you are drawing on! Obviously, all images should be color. Zach -- [EMAIL PROTECTED] Zachary Beane http://www.xach.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
Seth Burgess <[EMAIL PROTECTED]> writes: > Well, I strongly dislike having an eraser tool that > behaves differently based on a property of an image > you can't even see. It really stinks. > > What I'd prefer to see is a "replace color" paint tool > that can handle bgs or any other layer the way eraser > works now on a bg layer. > > Keeping the user experience the same between versions > is not a good thing when the user experience sucks. > > Seth I second this. We have too long stayed with this behaviour. I doubt that there a too many people using gimp for (and _only_ for) one layer images. If I once grokked the idea of layers, the current behaviour as it is strikes me as unintuitive even when working on single layer images. jtl ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
Well, I strongly dislike having an eraser tool that behaves differently based on a property of an image you can't even see. It really stinks. What I'd prefer to see is a "replace color" paint tool that can handle bgs or any other layer the way eraser works now on a bg layer. Keeping the user experience the same between versions is not a good thing when the user experience sucks. Seth --- Zachary Beane <[EMAIL PROTECTED]> wrote: > On Thu, Feb 22, 2001 at 01:42:06PM +0100, Jens > Lautenbacher wrote: > [snip] > > > > I'd vote for always having an alpha layer. seems > to be cleaner > > conceptually. > > I'd vote AGAINST this. Imagine if you use GIMP > without any layer > functionality, and suddenly you find that cut & > erase change to do > different things in version 1.4, and the only way to > get them back to > normal (for you) is through a strange hack involving > multi-colored > layers. > > I do like the idea of implicit alpha on the > operations Sven > mentioned... > > Zach > -- > [EMAIL PROTECTED] Zachary Beane > http://www.xach.com/ > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On Thu, Feb 22, 2001 at 01:42:06PM +0100, Jens Lautenbacher wrote: [snip] > > I'd vote for always having an alpha layer. seems to be cleaner > conceptually. I'd vote AGAINST this. Imagine if you use GIMP without any layer functionality, and suddenly you find that cut & erase change to do different things in version 1.4, and the only way to get them back to normal (for you) is through a strange hack involving multi-colored layers. I do like the idea of implicit alpha on the operations Sven mentioned... Zach -- [EMAIL PROTECTED] Zachary Beane http://www.xach.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On 22 Feb, Jens Lautenbacher wrote: > what remains in this case is that things like clear selection (on the > bg layer) suddenly start to behave differently, depending if there's a > layer above the background layer or not. Ick. > I'd vote for always having an alpha layer. seems to be cleaner > conceptually. Always having an Alphachannel would allow us some nifty optimsations in the GIMP. Although this takes more memory on some images (4 instead of 3 resp. 2 instead of 1 byte per pixel) the code would be much simpler, many if's in the source which trash the branch prediction of any processor would go away and the pixels would in most cases directly be on cache boundary even speeding the thing more. And for real graphics one needs an alphachannel anyways so what's the deal? -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
Sven Neumann <[EMAIL PROTECTED]> writes: > > Yes. But I don't think we should always add the alpha channel. Just > do it automatically as soon as there is more than a single layer in > the image. > what remains in this case is that things like clear selection (on the bg layer) suddenly start to behave differently, depending if there's a layer above the background layer or not. Ick. I'd vote for always having an alpha layer. seems to be cleaner conceptually. jtl . ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
Hi, [EMAIL PROTECTED] (Raphael Quinet) writes: > Several months ago, there was a discussion about RGB vs RGBA images, > and why the background layer was "special" and required the option > "Add Alpha Channel". For some obscure reason the same discussion came up again yesterday when Mitch and me started to work on the framework necessary to redo the layers dialog. The fact that the background is special cased adds a lot of ugliness to the code and provides no real advantage. Our conclusion was that The GIMP should probably automatically add an alpha channel if: - the user creates a second layer in the same image - the user adds a mask - the user changes the layers opacity from 100% - ... [ more cases we forgot to consider ] > Consider the following cases, which should all produce a file with > transparency, if the File->Save plug-ins were working as the user > would expect: > - Create a new image, use Image->Canvas Size to increase the size of > the canvas (some transparent areas appear), then save as PNG. IIRC, changing the Canvas Size does not alter the saved result at all since most file plug-ins save the current layer, not the whole image. I don't see why the user would expect an alpha channel here. > - Create a new image, use the Move tool to move a part of the layer > out of the canvas, then save the result as TGA or TIFF. Same reasons apply here. > - Create a new image, use the Opacity slider in the L,C&P dialog to > make it partially transparent, then save as PNG. Correct, see my notes above. > Wouldn't this be another reason to get rid of the default RGB-only > background layer? Yes. But I don't think we should always add the alpha channel. Just do it automatically as soon as there is more than a single layer in the image. > Also, the file plug-ins would have to be modified to check if the > alpha channel is empty or not before saving the image. This could be > another option in the user preferences: "automatically strip an empty > alpha channel when saving an image" (default would be ON). There could > be another option, similar to the one used in the "Clear Alpha" script: > "minimum value needed to declare an alpha channel non-empty" (default > would be around 10%, or maybe 0). IMHO unnecessary since the user can always use Flatten to get rid of the alpha channel before saving. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB vs RGBA - why Add Alpha Channel?
On Tue, 20 Feb 2001, Sven Neumann <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Raphael Quinet) writes: [...] > > Consider the following cases, which should all produce a file with > > transparency, if the File->Save plug-ins were working as the user > > would expect: > > - Create a new image, use Image->Canvas Size to increase the size of > > the canvas (some transparent areas appear), then save as PNG. > > IIRC, changing the Canvas Size does not alter the saved result at all > since most file plug-ins save the current layer, not the whole image. > I don't see why the user would expect an alpha channel here. Because most new users would expect this to happen. When you are familiar with the insides of the Gimp, you know that "saving an image" actually means "saving the current layer" if and only if you selected a single-layer image format (e.g., PNG, JPEG, TGA, ... but not XCF). But this goes against the principle of least surprise and most users who are not familiar with the insides of the Gimp consider this as a bug. For example, take a look at bug #23610: it is clear that the user expected that resizing the canvas of his 800x654 PNG image to 800x600 would result in an image that is 800x600. Instead, he got an image that was identical to the original one. Granted, we all know that the current version of the Gimp behaves like that, because only the current layer was saved, ignoring the settings that are associated with the image but not with the layer. We all know that he should have used the Crop tool or flattened the image or (if the PNG image had some transparent parts) merged the image with a new transparent layer that had the same size as the canvas. But the behavior that he observed is not very intuitive. If the canvas size is different from the layer size (in a single-layer image), it would be better to trigger the Export dialog and ask the user if he/she wants to: - save only the current layer, - flatten the image first, or - clip the image (merge the current layer with a transparent layer that has the same size as the canvas, which is useful if there are some transparent areas that should be preserved). That would solve the problems like the one described in #23610. It would work when the layer is larger or smaller than the canvas. > > - Create a new image, use the Move tool to move a part of the layer > > out of the canvas, then save the result as TGA or TIFF. > > Same reasons apply here. Same comments as above. But in addition, this gets very interesting when you save as PNG, because PNG takes the layer offset into account but ignores the canvas size. Try the test case (2a) in bug #51114. This will give you the most surprising results: an image that has the correct offset but the wrong size. Again, the results can easily be explained if you know how the Gimp works internally and what options are supported by the PNG format. But I do not think that anybody would really expect the results that you get by following the steps described in (2a). Compare the saved file with the image as it was before saving it. Link to the bug report: http://bugzilla.gnome.org/show_bug.cgi?id=51114 > > - Create a new image, use the Opacity slider in the L,C&P dialog to > > make it partially transparent, then save as PNG. > > Correct, see my notes above. > > > Wouldn't this be another reason to get rid of the default RGB-only > > background layer? > > Yes. But I don't think we should always add the alpha channel. Just > do it automatically as soon as there is more than a single layer in > the image. Yes, that would be a solution. As a matter of fact, I went back to the archives of this mailing list and I saw a discussion that I initiated in May 2000, with the subject ``Is "Add alpha channel" really necessary?''. The conclusion was that the alpha channel should be added automatically. And Gary Osgood said: "I imagine Mitch is coding it already, ;)". However, if you look at the messages that were posted on the 16th of May, you will see that my opinion was that the alpha channel should be added as soon as a second layer is created, while Gary thought that it would be better to keep the background layer "special" until the user clicks on the up/down arrows to move another layer below the background layer. When I posted my first message today (before re-reading this old thread), I thought that it would be better to always add an alpha channel to all images. But the arguments that I posted last year convinced me that I was right at that time. ;-) > > Also, the file plug-ins would have to be modified to check if the > > alpha channel is empty or not before saving the image. This could be > > another option in the user preferences: "automatically strip an empty > > alpha channel when saving an image" (default would be ON). There could > > be another option, similar to the one used in the "Clear Alpha" script: > > "minimum value needed to declare an alpha channel non-empty" (de
