It's been a while since I visited 64digits, I nearly forgot all about it. lol

Some awesome stuff has happened since my last visit here. I finished ripping my DVDs, Deus Ex Human Revolution was released, etc.

Last week I fired up Game Maker for the first time in a while to develop an image file format I thought up. A long while ago, I made an image format using Game Maker where pixels of similar color would merge together to form a horizontal "streak" of a single color.

The idea was good, but my particular implementation at the time wasn't. A pixel can be nearly 17 million different colors, so the similarity threshold had to be very low for the image to be smaller in size than a bitmap, which resulted in a very streaky looking image. A strict threshold could be used to keep the same level of detail as a bitmap, but then the benefit of using streaks to define lines of a single color was outweighed by the fact that way too many of the streaks were describing just a single pixel's worth of information.

While zoning out in class last week though, the solution came to me out of the blue. It's really so simple, I don't know why I didn't think of it earlier. Instead of trying to make streaks using all the pixel's color information, split it up into channels. It's much, much easier to make streaks that don't compromise quality when the number of variations is cut from 17 million down to 256. But this approach has more than that going for it. Since the different channels have different streaks of different lengths which are combined when rendering, the image ends up having a much less streaky look even when utilizing lower thresholds.

Right now, I'm playing around with some variants on this format. In the main version, images are split into R, G, and B channels. Another variant uses HSV, which can be better or worse depending on the case. Most likely I'll merge the RGB and HSV together and just have a flag in the format that denotes whether it's RGB or HSV.

I'm toying with a third variant utilizing indexed colors instead of channels, the first implementation of which I whipped up today. Thanks to the fact that it was a quick job, there's a glitch somewhere resulting in some strange artifacting which I haven't been able to track down just yet:

Also, I need to quit being lazy and write a script to build a dynamic index of colors. Right now I'm relying on a sort of 'preset' index of 64000 colors. If I can dynamically pick 256 colors for an image, I can cut down the number of bytes per streak from 3 to 2 while still retaining good fidelity. Using 2 bytes to describe the color for up to 255 pixels is pretty awesome, though realistically it'll be a much lower number of pixels in most cases.

The biggest problem with using Game Maker for this is how slow it is. I have to make heavy use of the surface_getpixel() function, which is painfully slow. It makes converting large images to my format unbearable, so I have to stick with relatively small images. And using indexed color makes it even slower. Right now, I've got it writing a file at anywhere from 0.1 to 1 KB a second. Horribly slow, especially when you're writing an image over 200 KB. And once I implement dynamic indexes , it'll get much slower.

I may shelf the idea of indexed colors, even though it's probably the only reasonable way for me to get the size of my image format down to around GIF/JPG levels while still keeping somewhat decent quality. I've still got things I want to implement and kinks to work out with the RGB and HSV versions.