Re: pre-multiplied alpha in filter effects, again

On Mon, 12 Jul 1999, Fredrik Lundh wrote:

> Christian Brunschen <cb@df.lth.se> wrote:
> > Regardless of how good accuracy you might have in your premultiplied RGB
> > values - ie, even if they get stored as 80-bit IEEE floating-point - there
> > is one case where it is impossible to recreate the non-premultiplied RGB
> > values, if you only have the premultiplied ones and the Alpha value. I am
> > talking, of course, of the case when Alpha = 0, ie, the pixel in question 
> > is fully transparent.
> 
> it's not "fully transparent" -- it simply doesn't "exist".

I offer that this may or may not be the intent of the image. I might well
draw a colourful image and provide with it an Alpha channel that left
parts of the image invisible - so that I could, by changing the Alpha
channel, reveal parts of the image that were previously invisible. In this
case, the fully-transparent pixels most certainly _do_ exist.

> and non-existent pixels inside the image are no
> different than the infinite number of pixels outside
> the image rectangle...

I beg to differ.

If we consider the case where we start with some unmarked drawing surface,
and then place marks on it, then only those parts of the surface where we
have placed marks indeed 'exist', and we can remove all or parts of the
unmarked surface surrounding the markings, and we still have 

> 
> > One simply can't divide the premultiplied RGB values
> > (which are all zero due to premultiplication) by the Alpha value (also
> > zero) and expect to retreive the original pixel value.
> 
>     "Thus, for all practical purposes, a trans-
>     parent pixel ceases to exist conceptually.
>     This is profound because suddenly images
>     change from rectangular items to shaped
>     objects with partial transparencies. This
>     is largely what humans mean by a visual
>     object."
> 
> (from "Alpha and the history of digital compositing"
> by Alvy Ray Smith (1)).

I would still offer that the author of an image may well have an intent
other than that. I would argue that there are two cases that are possible
for a pixel with an Alpha value of zero: 

1) the pixel also has well-defined RGB values, which just happen to be
   invisible

2) the pixel has undefined RGB values

> > Remember, PNG stores non-premultiplied Alpha.
> 
> yeah, but other future image sources might not
> be able to provide premultiplied pixels...

True - already, the case where the image source is, say a <text></text>,
is such a case - it leaves a number of pixels simply 'unpainted', which
would place them in the category of 'undefined-RGB' zero-Alpha pixels. 

I would propose that, conceptually, pixels generated by reading a PNG
image would fall into case 1) above, by virtue of supplying
non-premultiplied pixels. A <text></text>, or another <svg></svg> which
did not touch every pixel within its rectangle, would leave its untouched
pixels to fall into case 2). 

It might be interesting to allow svg graphics to generate pixels in
case 1), by drawing with a defined colour, and Alpha = 0, in part of the
image if desired...

> > Of course, this is only one possible solution, but I do dare suggest that
> > the problem,and thus the question, should be taken into consideration.
> 
> sure, but maybe the best way to deal with pixels that
> don't exist is to treat them as they don't exist -- or in
> other words, if you're filling empty regions in an image,
> you must explicitly specify what to fill them with.

I'm beginning to realize that even using non-premultiplied does not solve
the problem - since zero-Alpha pixels may have either one of two different
'meanings'. Perhaps the only 'solution' is to tag the 'hidden' colour (if
any) onto each zero-Alpha pixel. This would allow recovery of colour from
a pixel with well-defined RGB values but Alpha = 0; it would also allow
detection of pixels which are 'not there', and selecting some sort of
default colour for those.

The problem of 'what do I get from non-premultiplying a pixel with
Alpha=0 ?' exists in the spec today, regardless of the discussion above;
and that should be fixed no matter what.

I would also offer that it would be quite counterintuitive to people who
work with PNG images if they lose the colour information in their 'hidden'
pixels, when passing the image through the SVG image filters. 

> 
> </F>
> 
> 1) available as technote #7 from
> ftp://ftp.research.microsoft.com/Users/alvy/
> make sure to read technotes #4 and #6 too!

I will do that, thanks.



Best regards

// Christian Brunschen

Received on Tuesday, 13 July 1999 04:16:14 UTC