pre-multiplied alpha in filter effects, again

Hello again,

I just came to think of one strong point against pre-multiplied-alpha
pixels.

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. 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.

So? Most filters operate on premultiplied RGB values anyway. 

True - but two important ones don't.

Now suppose I have a filter something like


--- begin example ---

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG July 1999//EN"
"http://www.w3.org/Graphics/SVG/svg-19990706.dtd">

<filter id="offsetAndFlattenAlpha">

<feOffset in="SourceGraphic"
 dx="3" dy="2" nodeid="offsetImage" />

<feComponentTransfer in="offsetImage"
 nodeid="alphaFlattenedImage">

   <feFuncA type="linear" slope="0.5" intercept="0.25">

</feComponentTransfer>

<feMerge>
  <feMergeNode in="alphaFlattenedImage" />
</feMerge>

</filter>


<image href="http://foo.bar/image.png"
 filter:url(#offsetAndFlattenAlpha)">
   <desc>
   This image will be offset by (3, 2), and have its alpha channel
   'flattened' from a range between [0.0 .. 1.0] to [0.25 .. 0.75]
   </desc>
</image>

</svg>

--- end example ---


What this filter does is:

1) in the node 'offsetImage', it offsets the input graphic 3 pixels
   horizontally and 2 pixels vertically 

2) then, in node 'alphaFlattenedImage', it remaps the Alpha values of the
   image linearly from [0.0 .. 1.0] to [0.25 .. 0.75].


Reading the spec, the feOffset filter node (offsetImage) wants, and
generates, premultiplied-alpha samples. So far so good.

But the feComponentTransfer node (alphaFlattenedImage) gets to work on
un-premultiplied samples. If there are any samples that have zero alpha
after the feOffset node 'offsetImage', then their RGB values, for the
purpose of the feComponentTransfer node 'alphaFlattenedImage' is
undefined. Not only that, but if there were any pixels in the original
image which had zero Alpha, whatever RGB information was available for
them has been lost. (Remember, PNG stores non-premultiplied Alpha.)


Now, one solution is to keep the non-premultiplied pixels around along
with the premultiplied ones, if Alpha happens to be zero. But if we're
already keeping non-premultiplied pixels with us, why not just keep all of
them and premultiply as needed instead? 

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.

Best regards

// Christian Brunschen

Received on Monday, 12 July 1999 12:31:48 UTC