Re: [Gimp-developer] Discussion on transparency
Other effects aside, I am all for preserving the RGB values of each pixel, regardless of it's alpha value. If there is garbage in there, once the mask has the alpha channel, it can be selected by color and one can cut away the previously transparent areas quite easily. Also, the nominations copy from alpha channel and move to alpha channel sound clear enough, while layer's alpha channel by it is own was very obscure to me when I met it first time. Regards, JS -- On Friday 28 November 2003 16:30, [EMAIL PROTECTED] wrote: There's been some controversial discussion in bug #127930 http://bugzilla.gnome.org/show_bug.cgi?id=127930. Raphaël proposes a discussion in this mailing list if we're not convinced about it. Well, I'm not. Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Discussion on transparency
On Monday 01 December 2003 19:00, David Neary wrote: (...) And Alpha channel to Layer Mask is unclear? If there is an action of copy alpha to mask and one other of move alpha to mask, then alpha to mask, IMO, is not clear. Actually I dislike the way they are spelled right now (/me run yesterday's compile from the GIMP) hmm..there they are, under initialize layer mask to: Layer's alpha channel and Transfer Layer Alpha Channel Yes...definetly seems like copy layer's alpha channel will be easier to understand at first sight. Transfer or move are both good. Cheers, Dave. -- Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Discussion on transparency
Joao S. O. Bueno wrote: Other effects aside, I am all for preserving the RGB values of each pixel, regardless of it's alpha value. If there is garbage in there, once the mask has the alpha channel Agreed. I am of the opinion that modifying the alpha channel should never modify RGB data. If we consider pixels with alpha 0 as undefined, then that isn't a hard fast rule. Also, the nominations copy from alpha channel and move to alpha channel sound clear enough, while layer's alpha channel by it is own was very obscure to me when I met it first time. And Alpha channel to Layer Mask is unclear? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Discussion on transparency
There's been some controversial discussion in bug #127930 http://bugzilla.gnome.org/show_bug.cgi?id=127930. Raphaël proposes a discussion in this mailing list if we're not convinced about it. Well, I'm not. I couldn't agree more that the content of totally transparent pixels is undefined. However I hardly see how reviving fully transparent pixels could confuse users. The manual should just state clearly in big bold letters that the RGB value of a fully transparent pixel is undefined, and so one can expect anything arising from the exposition of previously transparent areas. This approach was even taken by the PNG specification, which specifies to maintain the full RGB data even for pixels with zero alpha value (there's even an entry in the Rationale section aimed to explain the reasons). The manual could also mention that in the current version the RGB value in fully transparent pixels is kept intact with whatever was there before assuming that it was initialized, that if it is not initialized at all then the pixel could contain anything, that some filters could silently alter the RGB data of the pixel, and that this behaviour could change in future versions. The proposal given by Raphaël in bug #128118 http://bugzilla.gnome.org/show_bug.cgi?id=128118 does not allow the possibility of increasing the opacity, so it's not valid as a way to edit the alpha channel, which was the intention in bug #127930. The only solution that I could perhaps admit discussing is the same applied in bug #127930 but instead of just setting all the pixels in the alpha channel to alpha 255, do the equivalent of applying the threshold alpha filter with a value of zero, i.e. keep zeros as zeros and set all the nonzero values to 255, which sounds more in accordance with Raphaël's ideas. There's another problem that Raphaël mentions in bug #127930: There are other problems related to the consistency of the user interface: in the menu for creating the mask, the new option to transfer the alpha channel is the only one that has a side effect and this is not obvious to the user. Putting this option in a separate group may solve this problem, but in any case I don't like the fact that it mixes different concepts. I agree with him here; leaving this option just as it is results confusing because that option is the only one which modifies the alpha channel. My initial proposal aimed at solving this issue by using a different wording for the options, but it was rejected: to use Copy Alpha to Mask (or Copy from Alpha channel) instead of the previous Layer's Alpha Channel, and call the new one Move Alpha to Mask (or Move from Alpha channel). The rationale was that the strong opposition between the words Copy and Move, the only word that changes between the two sentences, would make it evident that the latter could have destructive side effects. OTOH most users are familiar with the fact that if they *move* a file from A to B and then delete it from B, they lose the file. This was also mentioned by Raphaël as a drawback (what if the user discards the mask?, he argued), but I don't see a problem here. Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
