Re: texture alpha: premultiplied or not?

[Roger H. <rog...@mi...>]

On 11 May, 2007, at 17:23, James W. Walker wrote:

>
> On May 11, 2007, at 4:27 AM, Roger Holmes wrote:
>
>>
>> On 11 May, 2007, at 00:08, James Walker wrote:
>>
>>> Back in 2004, there was some discussion here about the fact that the
>>> Interactive Renderer essentially assumes that ARGB textures use
>>> premultiplied alpha, and questioning whether it ought to be an
>>> option.
>>> Yesterday I changed the OpenGL renderer to assume non-premultiplied
>>> alpha, but now I'm wondering if that was too rash.
>>>
>>> The QD3D manual doesn't seem to give any hint whether alpha  
>>> should be
>>> premultiplied or not.  I believe there was a claim in 2004 that
>>> QuickDraw 3D did use premultiplied alpha, but I can't confirm that
>>> today.  When I loaded an ARGB texture test in Classic Geom Test, the
>>> result doesn't agree with either of our renderers.
>>
>> You mean the interactive renderers in Quesa and QuckDraw3D are
>> different?
>
> Right.  At least on the one machine where I made the comparison.
>
>>>
>>> If you'd like to check it yourself, my test model is here:
>>> <ftp://ftp.frameforge3d.com/misc/texture-argbT.3dmf.zip>.  It
>>> contains 2
>>> flat TriMeshes.  One is opaque and gray, another has an ARGB texture
>>> whose background has alpha = 0, color = white, intended for use as
>>> non-premultiplied.  The opaque TriMesh looks transparent in Classic,
>>> which I don't understand at all.
>>
>> Er, maybe I'm being thick (as usual), but alpha==0 means transparent,
>> alpha ==1.0 (or 0xFF) means opaque. What's to not understand?
>
> The fact that this particular TriMesh had no transparency color
> attribute and no texture, but looked translucent in Classic.

I have opened your model on my latest product using Quesa and on an  
old G4 running OS9 and QuickDraw3D.

On the OLD machine with QuickDraw3D I see two surfaces, an opaque  
grey one and in front of it a patterned one. With the interactive  
renderer there is no transparency in either, but with the Microspot  
Renderer the white parts of the patterned surface do not appear i.e.  
they are transparent. Possibly the NuBus accelerator card and/or  
LightWorks supported transparency.

With Quesa I do not see the grey surface at all, it does not even  
affect the bounding box, which it would if it were transparent. Maybe  
my program deletes it for some reason, it does go through and deletes  
certain objects just after reading a file for backward compatibility  
with old version which left invisible junk in the file, like empty  
groups. The interactive renderer again shows the white pixels and  
once again with the Microspot renderer they are transparent.

For this file it seems that the interactive renderer is compatible  
across QD3D and Quesa, as is the Microspot renderer (not surprisingly  
as its the same source code).






>
>>
>>>
>>> Anyway, in the previous discussion, it was suggested that the
>>> premultipled flag could be set with an object property on the
>>> renderer,
>>> or a new style object.  It occurs to me now that it might make
>>> sense to
>>> set it at the level of individual textures... maybe a new pixel type
>>> constant like kQ3PixelTypeARGB32Premultiplied, maybe an object
>>> property
>>> or custom element.
>>
>> Sounds like a good idea to me, data can be imported into my programs
>> so if you are going to support two types of alpha data, then the type
>> needs to be bound to the data, how else could I render an image with
>> a mixture of pre-multiplied and non pre-multiplied textures on many
>> objects, pixmap markers, foreground and background images.
>>
>> When was the concept of pre-multiplied alpha invented? After
>> QuickDraw3D?
>
> I think the idea of premultiplied alpha goes back to about 1984.
> When did QD3D come out, about 1994?

That sounds about right, though the Metafile format was discussed  
quite a while before they told us they were developing any code. Not  
that is relevant here. If pre-multiplied goes back that far then  
Apple might or might not have used it. No help to us, but there is a  
clue in that the interactive renderer does not support Alpha, so it  
seems unlikely that they would want to divide back by the alpha to  
get the correct colour for displaying as opaque, especially in the  
case of dividing by zero.

Roger.