[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #22247] Pre-multiplied alpha values for bitmaps

From: Fred Kiefer
Subject: [bug #22247] Pre-multiplied alpha values for bitmaps
Date: Thu, 07 Feb 2008 08:58:00 +0000
User-agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.7 (like Gecko) SUSE


                 Summary: Pre-multiplied alpha values for bitmaps
                 Project: GNUstep
            Submitted by: FredKiefer
            Submitted on: Donnerstag 07.02.2008 um 08:57
                Category: Backend
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: FredKiefer
             Open/Closed: Open
         Discussion Lock: Any



For bitmap data with an alpha chanle there are two ways to store the colour
values for each pixel, either the basic value (for example r 255, g 0, b 0, a
128 for a half transparent red) or pre-multiplied with the alpha value (in our
case this gives r 128, g 0, b 0, a 128). The later is easier for correct
colour operations and is the format that the specification requires.

The different GNUstep backends expect different sorts of bitmap data. Xlib
and cairo expect pre-multiplied alpha whereas art expects non-pre-multiplied
values. This leads to different results when one or the other format is given.

Our TIFF loader returns either format, depending on the stored TIFF data, the
PNG loader always returns non-pre-multiplied bitmaps. That way some TIFFs and
all PNG with alpha chanel get displayed wrongly in the cairo and xlib backend
and soem TIFFs in the art backend.
I did not look into the other loadable bitmap formats nor into the winlib

To resolve this we first need to stored the format with each loaded and
generated bitmap, this is now possible with a 10.4 extension of NSBitmapRep
(NSAlphaNonpremultipliedBitmapFormat). Next we will need to extend the bitmap
value conversions to handle this case (-colorAtX:Y:, -setColor:atX:Y:) and
perhaps write a generic converter.
The final step will then be to implement the correct handling of all possible
formats in the backends. Here I see the biggest problem in the art backend.
For the other backends I would just suggest to convert all formats into the
pre-multiplied form, but for art it would be nice to implement the blit code
to work directly with the pre-multiplied values.


Reply to this item at:


  Nachricht geschickt von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]