There were some important improvements to the RGB to HAM8 conversion algorithm. Pictures produced by the new version have less artefacts and are more detailed.
- Colorspace conversion algorithm is now much more precise. Earlier version was crude and resulted in some nasty artefacts. For example choosing SET colour from 6-bit RGB base palette (just 4 shades per component!) was almost always choosing darker shade. It was a temporary hack to eliminate some other artefacts. The new method is still not perfect. If the picked colour is lighter than the original it sometimes produces a few much too light pixels.
- Error calculation used to choose operation (SET, Modify Red, Modify Green, Modify Blue) is modified to use weighted sum based on sensitivity of the human eye to each of the primary colours: 2*error_red+3*error_green+1*error_blue. A human eye has the highest sensitivity to green and the lowest to blue. It also eliminated much of the artefacts at the edges of the each object. Most of the ugly areas of more of less random colours at the edges are now just a mild blue-violet glows which are much less noticeable. There were also some less important bugs in this algorithm.
Base image (Kołobrzeg, Poland, july 2012)
ham_convert v0.3
ham_convert v0.4 (color hack enabled)
Update (8.11.2013): final version is ready.
Just a small update: weighted error calculation was made optional. This new method improves detail preservation but there are a few situations where the older one causes less disturbing artefacts like trees with a blue sky in the back or small blue details.
Newer versions can be found here.
Get it here:
ham_convert_0.4.jar
Initial version announcement from 2013/09/18 recovered from archive.org:
I’ve been recently developing a freeware java-based image converter that converts bitmaps to HAM8-like screen mode available on old Commodore Amiga computers (Amiga 1200 and 4000). It’s a very early version but the resulting image looks quite OK. There’s a room for further optimizations as the current conversion algorithm is rather primitive. For example it uses fixed 64-color base palette (RGB 2:2:2). Palette calculation will be added in the future. IFF saving is yet not implemented. Output is PNG-only. I took the picture in Mielno, Poland in early June 2013.
Base image
HAM8 mode v0.1
HAM8 mode v0.2
HAM8 mode v0.3
Get it here:
ham_convert_0.3.jar
Hi there,
For an open source project, I got into HAM-encoding, too. Since you’re getting very good results, I’m interested in the source code. Is it available? How do you generate your base palette? How do you choose between index, red-hold, green-hold and blue-hold?
Kind regards,
Josua Schmid
I have sent the source code to your email address.
That’s great! Thank you very much! I’ll let you know, when my implementation is ready.
Your code helped me to try some things which let me decide not to use a HAM-mechanism for my project. Istead of that I’ll use pure addition in a cyclic group of 255 values for each color. Slow transitions are more important for me than adequate hits.
Here are my first tries for HAM7 based on your code. I’think that the base palette is not choosen well for 7 bits. But the result seems to be ok:
http://jsfiddle.net/6LXEP/7/
And here are my tries of the pure addition method. You’ll see much artefacts on hard transitions but almost none on smooth ones:
http://jsfiddle.net/6LXEP/9/
You temporarily need to disable the “same origin policy” in your browser, because the pictures are loaded externally. In Chrome that would be “chrome –disable-web-security”
Looks promising. I think it should be called ham8 because ham7 was an obscure mode that almost nobody used. Like ham5 it had one of the two have control bits locked so you can only select set or modify-blue.
I’m also working on an open source project for an image viewer for Amiga OS that saves as IFF-ILBM and PNG formats. For nostalgia I’d like to also be able to save as HAM6/HAM8. Your HAM conversion program works the best of several I have tried.
My graphics program is written in C but I can use the Java as a reference. The difficult parts are error correction for the index values to reduce artifacts and accurately and quickly producing a color palette that works well.