RSS/Atom feed Twitter
Site is read-only, email is disabled

Discussion on transparency

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

4 of 4 messages available
Toggle history

Please log in to manage your subscriptions.

Discussion on transparency usr352@wanadoo.es 28 Nov 19:30
Discussion on transparency Joao S. O. Bueno 29 Nov 13:30
  Discussion on transparency David Neary 01 Dec 22:00
   Discussion on transparency Joao S. O. Bueno 01 Dec 22:49
usr352@wanadoo.es
2003-11-28 19:30:00 UTC (over 20 years ago)

Discussion on transparency

There's been some controversial discussion in bug #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 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

Joao S. O. Bueno
2003-11-29 13:30:40 UTC (over 20 years ago)

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, usr352@wanadoo.es wrote:

There's been some controversial discussion in bug #127930 . Raphaël
proposes a discussion in this mailing list if we're not convinced about it. Well, I'm not.

Pedro Gimeno

David Neary
2003-12-01 22:00:10 UTC (over 20 years ago)

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.

Joao S. O. Bueno
2003-12-01 22:49:28 UTC (over 20 years ago)

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.