Conversion of 24bit RGB Image to HAM6

[DanScott]

Anyone have a good and quick algorithm for this? ideally one that can uses a fixed 16 colour base palette

[DanScott]

or 12bit 0x0RGB format to HAM6 too would also be ideal

[alpine9000]

Simplest algorithm, ignoring dithering, just process each line, walking from left to right picking which pixel is the closest perceived distance to the original pixel from either a colour in the palette, or the previous pixel with HAM offset.

I played with HAM conversions here (including a converter with dithering)

https://github.com/alpine9000/amiga_..._ham/README.md

[sandruzzo]

Just an idea: what about Dynamic Low-res were you can have 32colors for each line?

[Thomas Richter]

Originally Posted by DanScott

Anyone have a good and quick algorithm for this? ideally one that can uses a fixed 16 colour base palette

If the palette is fixed, then this sounds a bit like an application of a Viterbi algorithm to me. Walk the line from left to right, and for each pixel consider four possible alternatives: Pick a color from the palette, or modify red, or green, or blue. Record for each selection the error in terms of color, label the edges of a decision tree with them, continue to the right edge, then backtrace the path with the least possible error. You'll find a lot on google on Viterbi. If the palette is not fixed, a heuristic would be to first select a suitable palette by the k-means algorithm, and then continue from the above. It is then not necessarily the ideal palette, but it should work out.

[DanScott]

Originally Posted by sandruzzo

Just an idea: what about Dynamic Low-res were you can have 32colors for each line?

Not suitable for the use case

[DanScott]

Originally Posted by Thomas Richter

If the palette is fixed, then this sounds a bit like an application of a Viterbi algorithm to me. Walk the line from left to right, and for each pixel consider four possible alternatives: Pick a color from the palette, or modify red, or green, or blue. Record for each selection the error in terms of color, label the edges of a decision tree with them, continue to the right edge, then backtrace the path with the least possible error. You'll find a lot on google on Viterbi. If the palette is not fixed, a heuristic would be to first select a suitable palette by the k-means algorithm, and then continue from the above. It is then not necessarily the ideal palette, but it should work out.

This sounds like a good way... perhaps too slow for what I need... I need to be able to precalculate something like 320x256 image in a couple of seconds.. but I will at least have a try Thanks for the info

[DanScott]

Originally Posted by alpine9000

Simplest algorithm, ignoring dithering, just process each line, walking from left to right picking which pixel is the closest perceived distance to the original pixel from either a colour in the palette, or the previous pixel with HAM offset.

I played with HAM conversions here (including a converter with dithering)

https://github.com/alpine9000/amiga_..._ham/README.md

Thanks, wil try this too... is their a method for weighting distance on colour perception ? (ie.. green error is more perceivable than red, which is more than blue.. i believe it some where around 35:50:15 in terms of percentage for R:G:B)

[chb]

The wikipedia page on color distance has some useful formulas: https://en.wikipedia.org/wiki/Color_difference

If you cannot afford the square root or a table lookup for it, 3*delta_R + 4*delta_G +2*delta_B gives a cheap approximation.

[alpine9000]

Originally Posted by chb

The wikipedia page on color distance has some useful formulas: https://en.wikipedia.org/wiki/Color_difference

If you cannot afford the square root or a table lookup for it, 3*delta_R + 4*delta_G +2*delta_B gives a cheap approximation.

This is the approximation I used.

[meynaf]

I used 2R, 3G, 1B approximation for my ham8 renderer and it gave good quality and speed.

If you want to convert to ham (regardless if this is ham6 or ham8) you have two ways of doing.

The fast way uses static decision method : instead of computing which pixel type you use, this depends on the pixel position. Of course quality is low but it might be enough, depending on the use case.

The slow way uses adaptative decision. You compute error for fixed, red, green, blue pixel types.
To find out the closest fixed pixel, making 16 computations (64 for ham8 !) is too slow so you can use a 12-bit approximation to read the closest index in a 4096-entry table. You're then left with 4 error level comparisons.

[Bruce Abbott]

Originally Posted by DanScott

I need to be able to precalculate something like 320x256 image in a couple of seconds..

Why? And why are you converting 24 bit to HAM anyway?

[britelite]

Originally Posted by Bruce Abbott

Why? And why are you converting 24 bit to HAM anyway?

Wild guess, generating graphics for an intro/demo at runtime

[DanScott]

Originally Posted by Bruce Abbott

Why? And why are you converting 24 bit to HAM anyway?

Because I want to

[PeterK]

Originally Posted by meynaf

To find out the closest fixed pixel, making 16 computations (64 for ham8 !) is too slow so you can use a 12-bit approximation to read the closest index in a 4096-entry table. You're then left with 4 error level comparisons.

No, you just need to order all the base colors regularly in the color cube and then don't have to compare all the distances to find the closest color, but you can simply calculate the closest base color from the position of the desired color in the cube. Unfortunately, for HAM6 it's a bit unfavorable for dividing the space of the cube into 16 blocks. You could use 4 levels for green, 2 for red and 2 for blue. In my icon.library I have only 8 regularly base colors, because I also need to preserve the 4 system + 4 MWB colors. For HAM8 I use 48 base colors, which are squeezed between and around the system, MWB and mouse pointer colors and are mapped. The other colors are also used, but they need, of course, a distance comparison each. I'm using a pre-calculated 512 word table with (((delta)^4)>>16 +(delta)^2 + 7)/8. The ^4 component is a panalty for runaways. Of course, you won't need to calculate roots, because they would not change the order of the fake distances.

You can find all code for ARGB to HAM6/8 conversion in my source code, but I have to warn you, since it's merged with conditional compilation together with TCdraw an all my other versions and spread over several locations with many dependencies and references. It's very hard to read and understand my confusing code. You will probably not need to care for any alpha channel or transparency, nor to take system, MWB or mouse pointer colors into account. Look for "HAM8imagedrawing" in my source if you are courageously enough to fight with complex chaos.

[thellier]

Use my prog it give excellent results
http://aminet.net/package/gfx/conv/DatatypeToHam
Sadly it use lots of RAM so run it with WinUAE

[meynaf]

Originally Posted by PeterK

No, you just need to order all the base colors regularly in the color cube and then don't have to compare all the distances to find the closest color, but you can simply calculate the closest base color from the position of the desired color in the cube. Unfortunately, for HAM6 it's a bit unfavorable for dividing the space of the cube into 16 blocks. You could use 4 levels for green, 2 for red and 2 for blue. In my icon.library I have only 8 regularly base colors, because I also need to preserve the 4 system + 4 MWB colors. For HAM8 I use 48 base colors, which are squeezed between and around the system, MWB and mouse pointer colors and are mapped. The other colors are also used, but they need, of course, a distance comparison each. I'm using a pre-calculated 512 word table with (((delta)^4)>>16 +(delta)^2 + 7)/8. The ^4 component is a panalty for runaways. Of course, you won't need to calculate roots, because they would not change the order of the fake distances.

That means the colors are regularly spaced which isn't the best option for quality, or you need more comparisons to support the extra ones. With my simple LUT i could use any palette without speed penalty.

Originally Posted by PeterK

You can find all code for ARGB to HAM6/8 conversion in my source code, but I have to warn you, since it's merged with conditional compilation together with TCdraw an all my other versions and spread over several locations with many dependencies and references. It's very hard to read and understand my confusing code. You will probably not need to care for any alpha channel or transparency, nor to take system, MWB or mouse pointer colors into account. Look for "HAM8imagedrawing" in my source if you are courageously enough to fight with complex chaos.

No thanks.
But you can find my aga picture viewer from this page if you want to perform speed and quality comparisons.

[PeterK]

Originally Posted by meynaf

That means the colors are regularly spaced which isn't the best option for quality, or you need more comparisons to support the extra ones. With my simple LUT i could use any palette without speed penalty.

It depends on what you need. For my HAM icons I would need a different optimal palette for each, but I have dozens of them on the same screen with just one palette. So the best compromise is a regularly color space allocation. You can check out my HAM demo ADF files or look at the screenshots.

http://eab.abime.net/showthread.php?t=64079

Thanks, I have no doubts about the quality and speed of your picture viewer and I know it, although I mostly use TrueColor screens. HAM is just for fun.