BitBlt oddity

Andres Valloud sqrmax at cvtci.com.ar
Fri Apr 9 09:17:46 UTC 1999


Hi.

While doing color reduction with BitBlt's colorMap facility, I stumbled with
something. The thing is that the original method I was using was first to
quantizate, then for each color of the source find the closest quantizated color
and then doing pixelValueAt:put: to a color form with the proper color map. If a
color map is provided (calculated), then BitBlt can do this for you. But I don't
know why the BitBlt version comes out blueish compared to the old method. And
hey, they both quantizate the colors the same way, and the closest colors are
determined in the same way. So... am I building the color map ok?

I'm using a bitmap of length 32k to generate the color map. First I ask BitBlt
for a tallyPixelValue bitmap. Of this one, I think that each index of that
bitmap, starting at 1, refers to the color being first index - 1 and then, of
that, the first 5 bits are the blue ones, the next 5 bits are the green ones and
then last 5 are the red ones. With all that taken in consideration, I build the
color map with 0 at unused colors, and when there's not a zero in the pixel 
value tally, I put in the same index of the color map (taking care to subtract
one to get the real color intended) the closest color index - 1 of my
quantizated color list to the tally's index - 1 thought of as a 5 bit color
triplet, and then I store such index (real index less one so that the first
color is color zero). When I have the color map, I just use the Form paint
combination rule to get the source 32k colors into the destination of up to 256
colors, being a color form, with the color list being the quantizated color list
I used. I do exactly the same for the pixelValueAt:put:, but by hand for each
pixel. 

The BitBlt'ed version invariably comes out grossly blueish, especially
almost-white colors. I've tried to dig up where does BitBlt does the color map
translation in BitBltSimulation, but I really got lost in there. Where should I
take a look next? Checking for fencepost errors by introducing off by one errors
on purpose doesn't correct the blueishness. The quantization phase is the same
for both methods, ie generated the same quantizated color list. The same code is
used to determine which is the closest quantizated color (one is RGB vs. RGB and
the other is RGB vs. 5 bit triplet, changing order of colors in the triplet
makes things worse).

Andres.





More information about the Squeak-dev mailing list