[Bf-committers] Re: image editor / draw alpha

Branan Riley branan at gmail.com
Wed Jun 14 02:37:42 CEST 2006


Actually, I just had an idea for this...

If the RGB scales are set to 0, and the RGB biases are all set to 0,
then a black background could be drawn first, then the biases could be
set to 1, and blending enabled. This would let the alpha be drawn as
all white blended onto the black background. Kinda slow, but it avoids
endianness issues, and even five-year-old hardware could probably
handle it OK.

I'll go ahead and write the patch, and if it gets decided that there's
a better way to do it, no harm done.

On 6/13/06, Branan Riley <branan at gmail.com> wrote:
> I'm running Gentoo Linux x86-64 on a Pentium 4, so endianness is
> probably the issue. I don't think testing for the Mac OS define would
> work, since there are also Intel-based macs. Does anyoen know the
> right define to check for to distinguish endianness?
>
> On 6/13/06, Brecht Van Lommel <brechtvanlommel at pandora.be> wrote:
> >
> > Hi,
> >
> > Branan Riley wrote:
> > > The problem is the draw alpha option, to show what the alpha looks
> > > like. It's using a single 32-bit value for the display of the alpha,
> > > which is actually all four components, not just the alpha.
> > >
> > > I did a test with an image, and it's definately using all four
> > > channels. I'm getting drastically different values based on the color,
> > > not just on the alpha.
> >
> > I can't reproduce that here (Mac OS X, PPC, ATI).
> >
> > > Here's the offending code segment...
> > >
> > > static void sima_draw_alpha_pixels(float x1, float y1, int rectx, int
> > > recty, unsigned int *recti)
> > > {
> > >
> > >    /* swap bytes, so alpha is most significant one, then just draw it
> > > as luminance int */
> > >    glPixelStorei(GL_UNPACK_SWAP_BYTES, 1);
> > >    glaDrawPixelsSafe(x1, y1, rectx, recty, rectx, GL_LUMINANCE,
> > > GL_UNSIGNED_INT, recti);
> > >    glPixelStorei(GL_UNPACK_SWAP_BYTES, 0);
> > > }
> > This might be an endianness issue. The trick used here is to make
> > alpha the most significant byte, so that after rounding the RGB part
> > will just be ignored. On big endian alpha is the least significant byte,
> > so it needs to be swapped. On little endian the swap is not needed.
> >
> > So I guess you're using Intel or another little endian processor, and
> > Ton tested this on his Mac OS X PPC?
> >
> > Brecht.
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> > http://projects.blender.org/mailman/listinfo/bf-committers
> >
>


More information about the Bf-committers mailing list