bugGNUstep - Bugs: bug #22247, Pre-multiplied alpha values for...

Group
 
 

bug #22247: Pre-multiplied alpha values for bitmaps

Submitter:  Fred Kiefer <FredKiefer>
Submitted:  Thu 07 Feb 2008 08:57:59 AM UTC
   
 
Category:  Backend Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 12 May 2008 10:57:53 AM UTC, comment #4: 

Closed this bug as the original problem is gone now.
The bug report is still great for further reverences, but these will still work for closed bugs.

Fred Kiefer <FredKiefer>
Group Member
Wed 12 Mar 2008 01:54:34 AM UTC, comment #3: 

Added a conversion to pre-multiplied in the draw method of NSBitmapImageRep. This does not catch all cases, but most.

I failed to find a way of removing the obsolete division of alpha and later multiplication in the render_alpha drawing path. I am still sure that duplicate efforts happen here, but the code is still to complex for me to understand. Perhaps I could split the render_alpha methods up in two cases one for pre-multiplied input and another for unpre-multiplied, but this is to much effort for now and I give up.

Not sure, whether I should close this bug report now or leave it open...

Fred Kiefer <FredKiefer>
Group Member
Mon 10 Mar 2008 09:19:31 AM UTC, comment #2: 

Moved the unpre-multiplication in the art backend one step down. The code was already there for one format (RGB, 8 bit without clipping) and is now used in all cases.
A next step would be to remove this unpre-multiply completely and adopt the image processing code to cope with pre-multiplied colours. This should be faster as this was the whole idea behind pre-multiplying.

Another thing that is still needed is the conversion of all bitmaps into the pre-multiplied format, which is now consistently expected by all backends.

And just for the record: I checked JPEG cannot handle transparency, so there is nothing to do here and although GIF handles transparency it allows only alpha values of 0 and 255, so no pre-multiplication is needed there.

The othe formats and the windows backecd still need to be checked.

Fred Kiefer <FredKiefer>
Group Member
Fri 08 Feb 2008 10:53:30 PM UTC, comment #1: 

The first part of this change, mostly in gui, is done now. For TIFF and PNG images we now set the format correctly.
For the art backend I added a hack to convert all bitmaps to non-pre-multiplied format before using them. We could add a similar hack to the other backends to change all bitmaps to the pre-multiplied form. Or even better change all bitmaps when we create them to this form.
Currently it still seems better to me to pass the image format down to the drawing code and let that handle all different formats, or use a conversion.

Fred Kiefer <FredKiefer>
Group Member
Thu 07 Feb 2008 08:57:59 AM UTC, original submission:  

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

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.



Fred Kiefer <FredKiefer>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-05-12 FredKiefer StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2008-02-08 FredKiefer StatusNone In Progress

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code