At a loss

One of the hardest things to do when reducing a high colour image down to VERY few colours is actually picking those colours. My original line remap code just used a histogram of most popular colours, took the top 4 and remapped each line to a palette of those. That's great for some images (lower colour source) but for high colour images with a lot of detail in it tends to lose a lot.

I'm now investigating original and modified diversity algorithms. Pretty simple code and it seems to sometimes produce an image that with dithering would turn out really nice. Other times it's nowhere near as good as that original most popular method.

I suppose I can leave all methods in the code and allow multiple passes, outputting an image for each and let the user decide. I'd also imagine most of these routines will produce a lot better result once a) dithering and b) PMG/mid scanline colours are added.


Pete

Quantification

I was pondering adding some auto line based A8 conversion to my app using the already written colour remapping when I saw Quantizator over on AtariAge forum so I thought there was no point, then last night I got bored of working on what I was doing so thought I'd just drop it in anyway. Turned out to be pretty easy to get the basics going, an hour of coding (plus some time for a blatant bug that took me ages to catch) and I'd got a 4 colour per line remapper.

It's not amazing so far and doesn't quite produce results that are as good as quantizator. I'm presuming that uses a method to find top used colours that are different hues whereas mine is a simple "most used" formula atm. I've also got no dithering to help spread colour matching errors.

Here's an example with a fairly simple C64 image.

Original


Converted


I think I'll continue messing with it as it's taken less time than I thought and add better colour choosing, F-S dithering/error spreading, PMGs for extra colour, maybe and/or mid-scanline colour changing.


Pete

The Colour of Magic

After adding colour matching to the app based on code I've written many times over the past couple of decades, stuff I've found on the web etc and then tweaking it a bit and thinking I was done, I ended up spending more and more time on colour.

An argument on a certain forum over which machine had a better palette, the Atari 800 or the Atari ST got me geared up to add some more functionality to the app. Simple things like the fact that none of the high end image apps seem able to remap to a fixed palette of anything over 256 colours because that's the most sensible maximum size for a fixed palette, it having one byte per pixel. A 512 colour palette would need 2 bytes per pixel (without bit packing) which is 16 bits which means you may as well write some raw RGB values in that pixels data instead. All that meant there didn't seem to be a standard image app that would remap to the ST's palette (9bit 333RGB = 512 colours). Also despite what one member (and I use that term with more than one sense) thinks just masking off bits of a 24bpp image doesn't have the desired result.

After faffing with all of that and posting remapped images in all kinds of formats and palettes and APAC 256 colour Atari 800 versions I thought I was done with colour. Wrong again :) The matter of picking complementary colours whilst designing a game came up as just having a shade of colour a bit "off" can ruin the look of a perfectly well done image. Soooo I've now added some more colour conversion functions: RGB to XYZ, XYZ to CIE-L*ab, CIE-L*ab to CIE-L*CH, some others, and all the functions to convert back. CIE-L*CH seems to be the one to use for automatically finding complementary colours so now the functions are all there I'll be able to fiddle with some kind of gui colour picker thing in that colourspace..

No more colour now! Different code!! :)


Pete

Merry Christmas

Or very nearly. 6 mins to go and I've just fixed a bug in my colour remapping. Originally I think it was a bug with VB.NET because it was doing really weird things, I edited the code, it seemed to fix it but there was no reason for it to have done so, so I changed it back and it still worked. It wasn't quite working though as evidenced by "bugs" in an output APAC image. I've changed the matching "distance" algorithm slightly and that's all fixed now :)

I'm going to add HLS colourspace stuff at some point (when xmas is out the way) because despite it now remapping correctly it's not picking colours that are perceptibly close just mathematically. HLS should fix that or at least allow me to add a bit of weighting to the conversion.


3 mins to go...


Pete

Conversions

So, I've been adding colour stuff to the app for the last few days.

I've done colour matching so you can load in an image and match it to a chosen palette (a8,c64 etc). The image you load can be any bit depth because it's matching an existing palette. So if for example you load a 24bpp image and match it to an A8 palette, you'll end up with an image with max 256 colours, all A8 ones. It's kind of up to the artist to make sure they don't use too many but there will be some colour reduction added soon.

I've also added APAC conversion which works from the colour matching, gets the A8 palette "index" number which equates to the colour/lum (4 bits of each) which it then splits onto 2 lines, gets the next pixel (I don't do any averaging across pixels atm, just fixed offset samples) does the same stuff and packs it with the previous one into a byte.

I also recently added image to char conversion + optimisation (same char removal/remapping) ready for all the level/tile editor/software sprite grabbing etc.


Pete

Getting there.

Just as the original Exploding Fist was a bunch of nothing till it was nearly all designed/coded (he never tested his code, just wrote it then ran it when it was pretty much all finished) so the A8 version is currently a lot of partially done (in some cases finished) parts.

Once the current rewrite of the PC app for editing all the game data (backgrounds, sprite grabber, sprite animator, collision editor) is done, there is A8 code waiting for it all to be dropped into. Sooo, as soon as that data is ready there should be a demoable Exploding Fist :)


Pete

Prince of Pain-in-the-assia

As there seems to be a lot of chat, graphics editing and other shenanigans going on on the AA forum (not least of which by myself) about doing C64/Atari800 Prince of Persia I decided to have a look at repacking the DOS sprites. As they've got a bit of anti-alias colour in them I can actually make them smaller than the originals (they'll be 4 colour on these versions) and with some bit packing, smaller still..

Now to write the depacker!! I'm going to do the C64 one first (cuz it's easier). It'll check width and height to see what number/layout of hardware sprites are needed, set those up at the correct X/Y positions on screen and then depack the data into them. I need to build masking into the routine which makes it even more arsey and it's at times like these I hate 6502 and it's lack of registers.

The A8 version will no doubt be a bigger bitch as it has to do the software spriting/masking/setting PMG positions etc at the same time. YUK!


Pete