#15244 - DekuTree64 - Mon Jan 19, 2004 7:59 pm
Hey everyone, just thought I'd share what I've been working on the past few days. It's a tool to quantize/dither a 24-bit bitmap to use several smaller palettes for 16-color tile mode. You can set the size/number of palettes for it to use.
It's based on the algorithms discussed in the color quantization thread in the graphics section a while back, so I didn't do that much thinking on the matter, just putting it together.
You can see some comparisons at http://www.angelfire.com/wizard/deku/program/quither/example.html, although the palettes are screwed up by the program I used to save them as GIFs, so if you want to try them out on a real GBA, I made a zip of the bitmaps at http://www.angelfire.com/wizard/deku/program/quither/example.zip. The first image is the Smash Bros box art that was tested in the other thread (mine doesn't look quite as good though...), and the other 2 are pictures I've drawn, one of them sized down to GBA screen size and the other still nice and big.
If you don't want to wait for all those images to load, just download the program at http://www.angelfire.com/wizard/deku/program/quither/quither.zip, and convert some yourself, because it's much smaller (20KB, as opposed to 540 for the zip).
It's still a little slow though, but the source is included so feel free to optimize it if you see any pointless wastes of time, or try better quantization methods. Currently it uses an octree, which is why it's so slow.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#15254 - Miked0801 - Tue Jan 20, 2004 2:30 am
Pretty Cool! How quick do you think you could add 8-bit .bmp support to it as I believe a lot of people will create 8-bit images and want to convert them to 16-16?
Mike
#15257 - tepples - Tue Jan 20, 2004 3:39 am
Converting a photorealistic image to 256-color indexed is a form of lossy compression. Converting to 16x15 is lossy as well. In general, two lossy steps in a row are a Bad Thing. If you're not trying to convert line art, best is to scan the image in 24-bit, manipulate it in 24-bit, then convert it from 24-bit to 16x15.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15258 - Miked0801 - Tue Jan 20, 2004 3:56 am
Except when converting pre-exisiting 8-bit images to save space - or when the art is originally drawn 8-bit. Truth is, I can modify the code to support 8-bit if I needed to anyways. I just though other people might find 8-bit support handy.
#15302 - DekuTree64 - Tue Jan 20, 2004 5:39 pm
8-bit support added. I also did away with that irritating "dimensions must be multiples of 8" message, now it just chops off any extra from the edges.
Thanks for the point, Mike.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#15308 - Miked0801 - Tue Jan 20, 2004 7:31 pm
Actually, that warnings is nice - if the art isn't aligned, I'd like to know about it and edit it - not have a tool silently take care of the issue. :)
Great tool. I'm getting the latest now and giving it a run :)
#15324 - DekuTree64 - Tue Jan 20, 2004 8:58 pm
Hmm, true. I'll put the warning back in so you know if it's happening.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#15334 - Miked0801 - Tue Jan 20, 2004 11:17 pm
Oops. You broke 24-bit support :) Stuff that worked ysterday crashes it now :)
#15336 - DekuTree64 - Wed Jan 21, 2004 12:13 am
Crap.
Well, it's fixed now. Forgot that changing from bm.bmWidth to bm.bmWidthBytes meant I didn't have to multiply by 3 anymore.
Thanks a bunch for your bug reports, hope it's fully functional now^_^
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#15341 - Miked0801 - Wed Jan 21, 2004 1:44 am
Excellent. 24-bit works again :)
#17527 - DekuTree64 - Tue Mar 09, 2004 10:31 pm
Update: Raw GBA data output added, main function split into a bunch of logical sections, so source is hopefully a little bit more readable now, Windows LoadImage function replaced with my own bitmap loader, so source is now portable.
Get it at http://www.angelfire.com/wizard/deku/program/quither/quither.zip
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#17529 - Lupin - Tue Mar 09, 2004 10:45 pm
nice hand drawing :)
I wonder why you chose splash screen type images for the test because no one is going to convert splash screens to 16 colors i would guess (the 16 color mode is good for sprite gfx, right?)
I never used the 16 color mode, converting 16 bit images or 24 bit images to 8 bit ones is way more interesting to me.
#17534 - Miked0801 - Tue Mar 09, 2004 11:18 pm
| Code: |
no one is going to convert splash screens to 16 colors
|
I will :)
Dropping from 8-bit to 16/16 with this utility doesn't hurt image quality (much) and halves ROM space usage. A good trade.
BTW, there may be a bug with it as it stands - occasionally the first color ramp (darkest) is getting full red and green color entries in towards the middle of the ramp (after a bunch of black or near blacks.) If I can get an example of this around NDA, I'll post an image for you to see what I'm talking about. Probably nothing, but who knows.
#17537 - Lupin - Tue Mar 09, 2004 11:31 pm
you cut off my "i would guess" :)
Well, i am interested in high quality image output, because that's what most commercial roms prefer rather than rom size (just take a look at splinter cell, i don't think the images there are 16 colors... i really like that game and all its fancy colors :P)
#17548 - tepples - Wed Mar 10, 2004 3:09 am
Not everybody has the luxury of 8 MB of space. Some people have to fit their programs into RAM so that they can multiboot.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.