Re: Compositing and alpha

[BALATON Zoltan]

Hello,

On Mon, 5 Aug 2002, Alexander Malmberg wrote:
> Recently I've implemented better compositing support in back-art,
> including most operators in the non-compositerect case. There's a pretty
> picture of it all at:
>
> http://w1.423.telia.com/~u42308495/alex/backart/backart_composite.png

Great! Is this generated by code that is calling private functions in the
art backend or by using DPS/OpenStep functions? In the latter case it
would be nice if you could make this test available. I could use it to
check ghostscript for bugs or could run it on OPENSTEP 4.2 for reference.

> (For those who care, back-art and, thus, this picture are using
> pre-multiplied alpha. Sover-compositing the results of the composite on
> a black background would look like in the picture even with
> non-premultiplied alpha, so you can pretend that that's the case.)

AFAIK Ghostscript also uses premultiplied alpha.

> The results are correct, as far as I can tell. Anyway, a few questions:
>
> 1.
> Currently, when you render with alpha in back-art, the stuff you render
> gets blended over the stuff that's already there. Another way of dealing
> with alpha would be to simply replace when drawing, including the alpha
> buffer. Some DPS docs I've found seem to imply this. ...

My experience also shows this. Tests on OS 4.2 and ghostscript show that
drawing with alpha does not blend, but overwrites color and alpha.

> ... I'm not sure what
> mosx does. What should GNUstep do?

I'm not sure about MacOS X either, but Quartz docs at
http://developer.apple.com/techpubs/macosx/CoreTechnologies/graphics/Quartz2D/drawingwithquartz2d/qcolor/Using_Transparency.html
imply that Quartz does blend when drawing with alpha. I think to preserve
compatibility GNUstep should behave like OS 4.2 when using DPS functions
and implement MacOS X behaviour in the Quartz like interface.

> Eg.:
>
> PSsetalpha(1);
> PSsetrgbcolor(1,0,0);
> PSrectfill(0,0,100,100);
> PSsetalpha(0.5);
> PSsetrgbcolor(0,0,1);
> PSrectfill(25,25,50,50);
>
> Should the middle rectangle be a 50/50 blend of red and blue with alpha
> 1, or all blue with alpha 0.5?

I've tested this on ghostscript and OS 4.2. Ghostscript generated a 50%
blend of blue and black (like premultiplied alpha), the results of OS 4.2
can be found here: http://goliat.eik.bme.hu/~balaton/gnustep/testalpha.tiff
On screen it looked similar to the ghostscript result, but color values
are very different. I have no explanation, but would be interested if
somebody has one. (Probably some color correction or halftoning might
happened as my screen depth is 16 bpp.)

> 3.
> The docs I have say that compositerect with the normal operators should
> work like a composite from a window filled with the current color. This
> isn't currently implemented, and implementing it would be a fair amount
> of (straightforward but boring) work. Does mosx have something
> equivalent? Will the 'final' GNUstep backend interface? It would be a
> useful feature if drawing with alpha doesn't blend, but I hope we will,
> and then there's no big use for it.

It is implemented in the gslib backend and supposed to behave like you
described, but I haven't really tested it yet. You could implement it as a
blending rectfill, so I cannot see why this would be hard with back-art.

> 4.
> What's the initial contents of a window? Currently I'm assuming that
> it's all opaque since this lets me optimize handling of completely
> opaque windows (ie. basically all on-screen windows).

This is the case with ghostscript and OS 4.2. The initial alpha value is
1.0. I don't know about MacOS X.

> 5.
> Is DPSimage supposed to do a plain blit of color and alpha data to a
> window, or blend the image (an Sover composite, in practice)?

I only know about the postscript operator, not the function called
DPSimage in gsc based backends that may be different. In postscript the
image operator does not handle alpha at all. There is a different operator
called alphaimage that according to tests just blits color and alpha
values to the window. On OS 4.2 NSDrawBitmap seems to call one of these
operators depending on the hasAlpha parameter and does not perform any
compositing (in reality it calls an undocumented operator called
nextimage, but the observed behaviour is the same). GNUstep on the other
hand expects NSDrawBitmap to do compositing, thus in the gslib backend I
currently do an Sover compositing for images with alpha. This is
incompatible with OS 4.2, but consistent with the current GNUstep usage.

Regards,
BALATON Zoltan