On Thu, Dec 01, 2005 at 01:19:41AM +0900, Carsten Haitzler said:
> the problem is tif's use pre-multiplied alpha (ie rgb is multipled BY the
> alpha
> value when stored) instead of non-premul (as imlib2's internals, png's argb
> etc. use). that means imlib2 is missing the "de-multiply" on load code. it has
> the multiple on save. it's a bug. :)
Hurrah! (sort of)
*insert blinding flash of realisation*
Doh!
I've just realised what was going on. I was mislead by the fact that it
was so dark and therefore though that it couldn't be the alpha_factor
because if it multiplied on save then it must divide on load.
But if the alpha is 146 then 146/2.550 is going to be less than 1 and
dividing by it is the same as multiplying.
Patch attached.
Cheers for the help.
Simon
--- loader_tiff.c 2005-11-30 16:36:58.000000000 +0000
+++ loaders/loader_tiff.c 2005-11-30 16:40:14.000000000 +0000
@@ -83,7 +83,7 @@
uint32 *pixel, pixel_value;
int i, j, dy, rast_offset;
DATA32 *buffer_pixel, *buffer = img->image->data;
-
+ double alpha_factor;
image_width = img->image->w;
image_height = img->image->h;
@@ -102,10 +102,11 @@
for (j = 0; j < w; j++)
{
pixel_value = (*(pixel++));
+ alpha_factor = ((double) TIFFGetA(pixel_value) / 255.0);
(*(buffer_pixel++)) =
(TIFFGetA(pixel_value) << 24) |
- (TIFFGetR(pixel_value) << 16) | (TIFFGetG(pixel_value) << 8) |
- TIFFGetB(pixel_value);
+ ((TIFFGetR(pixel_value)/alpha_factor) << 16) |
((TIFFGetG(pixel_value)/alpha_factor) << 8) |
+ (TIFFGetB(pixel_value)/alpha_factor);
}
}
