Andres,
Taking advantage of so much VM talk, would it be troublesome to support fast smallinteger shifting, like making #bitShift: hardwired as $+ and so?
It is already - #bitShift: has it's own byte code ;-)
And here's the fileout for the changed method in Color. I noticed they were slow checking them while trying to speed up Heckbert's quantization. Hehe, it works!
Great!
Right now it quantizates a 512x384x32 bit image with 630 colors down to 256 colors including building the representatives in 2.469s (200mmx). I still have to build the renderer to change all colors in the source to those quantizated by Heckbert's algorithm.
This should be pretty trivial - BitBlt uses a color map that can be set accordingly from your source depth to the right 256 colors.
-- PLEASE NOTE NEW EMAIL ADRESS!
+===== Andreas Raab ========= (andreasr@wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+
Hi.
"Raab, Andreas" wrote:
It is already - #bitShift: has it's own byte code ;-)
All right!!!
And here's the fileout for the changed method in Color. I noticed they were slow checking them while trying to speed up Heckbert's quantization.
Great!
I built an RGBSpacePartition with RGBSpaceBox es inside, very interesting. It's also noteworthy that Heckbert's paper doesn't mention the possibility that several colors are coplanar!!! Tricky, tricky...
Right now it quantizates a 512x384x32 bit image with 630 colors down to 256 colors including building the representatives in 2.469s (200mmx).
Not anymore. Now in 2.1s tops.
I still have to build the renderer to change all colors in the source to those quantizated by Heckbert's algorithm.
This should be pretty trivial - BitBlt uses a color map that can be set accordingly from your source depth to the right 256 colors.
How does this work? Does it support dithering on the way?
Andres.
I still have to build the renderer to change all colors in the source to those quantizated by Heckbert's algorithm.
This should be pretty trivial - BitBlt uses a color map that can be set accordingly from your source depth to the right 256 colors.
How does this work? Does it support dithering on the way?
I'm happy to say that this is actually documented in the class comment of BitBlt. I quote...
"When blitting from a 32 or 16 bit deep Form to one 8 bits or less, the default is truncation. This will produce very strange colors, since truncation of the high bits does not produce the nearest encoded color. Supply a 512 long colorMap, and red, green, and blue will be shifted down to 3 bits each, and mapped. The message copybits...stdColors will use the best map to the standard colors for destinations of depths 8, 4, 2 and 1. Two other sized of colorMaps are allowed, 4096 (4 bits per color) and 32786 (five bits per color)."
So to use this feature, it is necessary that each of your 32-bit (really 24-bit) colors have a unique RGB triple when truncated to 3, 4, or 5 bits per color.
If so, then build a bitmap of the right size (512, 4096 or 32768) and put i into all 4 bytes of the entry that your i-th color will map to. Then just blt it into a ColorForm of depth 8 using that as the color map, and every pixel that was color i in 32 bits will have a pixel value of i in the 8-bit form. All that remains is to supply the 256-entry color array for the colorForm. Obviously the j-th entry should be the j-th color produced by your partitioning.
If not, then this feature will not do the whole job for you. But it's so simple and fast that it may be worth figuring out how to trick it into doing what you want. One way for sure is to say you're willing to settle for 15-bit color accuracy instead of 24. If so, then just blt the 32-bit form onto a 16-bit form. This will truncate to 5 bits per color. If you then run your same algorithm it will give you 256 distinct colors in a 15-bit space. Then you KNOW you can use a 32k entry map to get those into an 8-bit form.
Hope this helps.
- Dan
Hi Dan.
I'm happy to say that this is actually documented in the class comment of BitBlt. I quote... "[etc] ... 4096 (4 bits per color) and 32786 (five bits per color)."
May I say that... I mean, this is so insignificant and still... 2^15 = 32768.
I've read your suggestions and I think I'll get it down to 15 bit, then Heckbert and then I'll have my handy 8 bit deep color form to get into a .GIF file. I was also thinking about writing simple bitmapped files, like implementing a BMP writer or something. Say, the color map... how does BitBlt do to pick the correct color in the color map? By taking pixelValue + 1 at the current position?
Andres.
I'm happy to say that this is actually documented in the class comment of BitBlt. I quote... "[etc] ... 4096 (4 bits per color) and 32786 (five bits per color)."
May I say that... I mean, this is so insignificant and still... 2^15 = 32768.
Coffee makes me reverse letters. It's even worse when I try to play the piano ;-).
- D
squeak-dev@lists.squeakfoundation.org
-
Andres Valloud -
Dan Ingalls -
Raab, Andreas