Andres -

>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?

It's remarkable to get your report, as we discovered this also just this week.  The problem  is in the BitBlt service routine rgbMap:from:to:.  It only affects the case that you are tallying 16-bit pixels and supplying a 32K color table.  A work-around would be to drop to a 4096-entry table for now (less accurate), or to copy your form to 32 bits and then tally into a 32K table.  If you can make up your own VM, then replace the line

	d = 0 ifTrue: [^ sourcePixel].  "no compression"
by
	d = 0 ifTrue:
		[nBitsIn = 5 ifTrue:
			["Sometimes called with 16 bits, though pixel is 15,
			but we must never return more than 15."
			^ sourcePixel bitAnd: 16r7FFF].
		nBitsIn = 8 ifTrue:
			["Sometimes called with 32 bits, though pixel is 24,
			but we must never return more than 24."
			^ sourcePixel bitAnd: 16rFFFFFF].
		^ sourcePixel].  "no compression"

This bug has been fixed in 2.4 which will be released within the next two days.

Thanks for the alert.

	- Dan