A.D.A. Amiga Demoscene Archive

Dear Amiga users

I remembered when Amiga 500 ruled the world, IBM PC has presented the new weapon in their arsenal - VGA graphics card .
while Amiga could display 4096 colours out of palette 4096 in Ham mode, VGA could display 256 but from palette of 260000colours. It resulted in emerging of various GIF scans which we Amiganias tried to convert to HAM6 mode, but with very poor result due to lack of colours. Converting 18bit palette to 12bit resulted usually with terrible banding, which could not be reduced with dithering because in theory HAM do not allow dithering. In theory because this limitation was finally broken in HAM_convert. You can find it here:

http://mrsebe.bplaced.net/blog/wordpress/?p=662

By utilising fancy programming and the best of graphics converting algorythms this is probably the best quality HAM converter, but it can do much more, together with Dynamic_Hires mode and C64 modes.

Generally its better to try it for yourself. It is still in Work in Progress stage, so it lacks Amiga format output but the algorythms are there and working great.
If you know where we could find the information how to implement those formats, such information would be welcomed.

If you could help, suggest and inspire please write to author - mrsebe@gmail.com

Enjoy

Ok, I'm gonna go out on a limb and be the sceptic again. How exactly are these limitations "finally broken"? Are there any good examples there of how this tool actually performs for HAM6?

Hello, I'm the author of this program. I wrote it just for fun and it's not a serious tool (it doesn't even have the iff output yet). DynamicHires is very buggy and changes all 16 colors every line instead of 7 and I don't have a time to fix it (too much coding at work).
Dithering in HAM6 was added because one of the testers suggested that it might be interesting. I think that it causes more color fringing because of more frequent rapid color changes. In this mode the first step is converting the input image to 12-bit RGB with dithering, and then to HAM6. Color fringing was reduced by using a weighted error formula based on sensitivity of the human eye to each of the primary colours: 3*error_red+4*error_green+2*error_blue. Modify_green is just used more often than modify_blue.

Cool. :) I'm a bit sceptical to the dithering part as well. Still suspect that "sliced HAM" is the best possible HAM option for OCS.

Farfar and I had a similar plan for the Oldskool Graphics compo at Revision 2011, though in the end (time pressure and a demo to make as well) we just converted it to a plain HAM picture using ADPro.

Farfar came up with this very nice portrait (original 24-bit image on the left, HAM image on the right):



It took some experimentation to make the smooth gradients look good everywhere. Adding more sparkles helped, as this increased the local variation in intensity.

I tried converting the image with Ham_convert (with Floyd-Steinberg dithering), with this result:



It seems to reduce the errors on some of the edges compared to the ADPro conversion, while ADPro does a better job at dithering (especially visible on the purple hair). I also tried the other dithering methods available in Ham_convert with similar results (Floyd-Steinberg looked best in my eyes).

Angry Retired Bastard: The main limitation of HAM mode is that you can only change one subcolour RGB at time or use 16 colours. On PC GIFs were using 24bit and direct conversion to 12bit would generate terrible banding without dithering. You can use hamconvert to turn on and off dithering to see the difference yourself.
In case of dithering it was believed that you have to change more subcolours every pixel, so for so long many converters did not use dithering at all in HAM mode. Some believed that dithering is not possible at all in ham mode, because of this limitations.
Blueberry: Floydsteinberg works the best with digitised pictures. In your picture hamconvert using Jarvis dithering was the best IMHO and better than ADPro.
In pixel art. situation i think the best would be the hand made correction after correction to fix most obvious errors.

Ham_convert with Jarvis dithering:



It definitely improves upon the artifacts on the forearm compared to the F/S version.

In the end, I guess it comes down to a matter of taste. The pure HAM version is further from the original and more noisy, especially on the edges, whereas the Ham_convert version can be a bit splotchy in places (though mainly where the original is fairly smooth to begin with).

Is it possible to make Ham_convert output the image in a form which is displayable (perhaps with some manual work) on an Amiga? The HAM bitmap plus one palette per scanline or some such?

I'm quite busy but I will implement it soon or later. It's not supported yet.
Edit (1.04.2015): IFF saving was added in 0.9 (supports HAM6 and HAM8). Probably still needs more testing.

The latest version supports IFF output in HAM mode.

Blueberry: Its mathematical conversion which always will be more or less visible in case of pixel graphics, however if you spent some time on hand postprocessing you can easily remove a lot of noise especially in flat areas.

As for other modes please take a look how 1226colours look in Hires mode

http://www.imagebam.com/image/ec96dc399825150

There is a new version of HAM_Convert 0.95

Besides old features like
1. psychovisual colour converter
2. Floyd Steinberg dithering with Brightness correction to simulate all subcolours
There is now:
A new higher quality (and much slower) palette generator for ham6, 16 and 32and EHB-color ocs modes. It uses multiple iterations to make palette more diverse and eliminate colors that are too similar. It was designed mainly with ham6 in mind but can be used in other modes. Possible modes: 0 (legacy), 1 (safest) – 5 (most aggressive). Mode 0 is a fast single-iteration mode present in previous versions that is better suited for slower computers. Multi-iteration modes: 1-safest that doesn’t look great but always gives acceptable results with no side-effects. Other modes eliminate some very similar colors from a bigger palette to make palette more diverse and make room for colors of smaller details that wouldn’t normally appear in the palette. Mode 5 is the most aggressive and should be used with caution because it eliminates more colors than other mores and it can make the resulting picture look unnatural.

To see how great quality HAM6 can be on Amiga download few examples when i converted true colour Slayer pixel art. to Amiga IFF using this program and irfanview for resizing.

http://www46.zippyshare.com/v/lcUIehAI/file.html

At the end I must write that i have seen recently few really nice demos which has really bad quality ham graphics probably due to use strange converters. So Amigians you can use better converter now.

As far as i can see the probably best result for pixel artist would be to create some nice pixel art. in true colour on PC, then convert them to ham6 and then manually correct dither noise in IFF file.
HAM6 is tricky because it all depends on proper choosing main 16 colour palette.

Interesting this, I actually have had a HAM converter as a suggested Computer Science project for students on my webpage for ages sadly no one seemed as excited about it as I was ;-). Even used HAM as an exam question in a computer architecture exam a couple of years back. Will have a look at this more carefully but indeed very cool that you are doing this.

bonkers: HAM mode is an example of (first in history of electronics) hardware graphics (texture) compresssion!!!!!
You are right giving it for an exam to the students, however this is not an easy theme. The constrains of it make it very difficult to use, but it you can win over them you will get what Amiga was famous of back in those good old days.
Amazing one of the kind low bandwidth color system.

Compression? :D

In that case the vic20 also had hardware graphics compression, as it could display 16 color graphics with way less memory consumption than 4 bits per pixel ;)

Well, you cant have on VIC20 every single pixel in different colour, dont you?

Generally Its clear on some computers certain techniques were used to optimise memory usage, however as for HAM take a look here

https://en.wikipedia.org/wiki/Hold-And-Modify

HAM can be considered a lossy compression technique; under HAM6 mode the playfield is encoded in half the memory normally required for a 12-bit color space.

Yes, HAM can be considered a lossy compression technique in the same way as the graphics modes in most 8 bit machines can be considered a lossy compression.

Of course you can, but with limitations, just like with the HAM mode :)

What you are trying to start is the disccussion when exactly starts the boldness :D

I think there is the difference between 16 fixed colours and true 12bit RGB color space.
Amiga HAM mode can display this whole RGB palette using only 6bit. Yes with limitations, but we are still operating on the same RGB palette. That is why it can be considered lossy compression, while VIC is not.
I believe if we would used therem "lossy RGB compression", there would be no confusion.

The VIC can display the whole 16 colors using only 2 bits. Yes with limitations, but we are still operating on the same 16 color palette. That is why it can be considered lossy compression, while HAM is not ;)

If the Amiga actually had a true 12 bit mode (without limitations), and you could use HAM as a way to represent the data and afterwards manipulate it on a per-pixel basis, then I would agree that it could be called hardware compression. But as it stands now, it's just a limited graphics mode, just like the graphics modes on various 8bit machines.

VIC does not operate on RGB palette, but on fixed palette (which is not RGB, but chroma, hue and other analog composite stuff looking different on PAL and on NTSC version), that is why it is not considered as compression.

HAM mode changes RGB data that is why it is compression and you could use HAM as a way to represent the RGB data and afterwards manipulate it on a per-pixel basis, but with limitations.
You do not understand it because you want to represent RGB data lossless and losslessly manipulate it on per pixel basis.
HAM is not lossless compression, it is lossy compression just in the same way DXTC (s3TC) texture compression is, that is why the HAM output is looking similar to 12bit RGB input and every single pixel can have different RGB value,
Of course you can try to create and use your own word meaning, and continue this silly disscussion, but I bet you have a demo to create.

Fach out

Right, so there can't be compression involved in indexed modes, right on! :D


Right back at you ;)

AT HIS MOMENT YOU ARE BEHAVING LIKE TROLL, putting in my mouth words I have never used. In fact i have said few posts above something exactly different:
[quote=FachenIts clear on some computers certain techniques were used to optimise memory usage,[/quote]

I am doing a lot to explain exactly what I have in mind, but You are totally omit an integral parts of what i wrote and twist my words, behaving like you do not want to understand.
Are you having fun?
Ok, then go to Wikipedia and tell them that you know better.

Yes, I am. I do find your comments quite amusing :)

Anyway, why can't the bitplane+colorram modes be considered compression but HAM-mode can? That HAM operates in an RGB-space doesn't matter.

EDIT: As both are ways to represent more color data with less memoryconsumption

Yes, both are ways to represent more color data with less memoryconsumption, however there is the difference in what is the exact meaning of commpression. Output must look like input (at least perceptually).

Using indexed 16 colour palette you just cant have representation of RGB palette no matter what kind of dithering you use. Some RGB colours would have to be replaced by completelly different ones, as they have no representation in indexed palette.
The difference in what you are looking for is how much different the output can be to be considered lossy compression. It seems for you only sky is the limit, while i find it problematic to call a lossy compression something which has totally different colours than input.

HAM_convert can also convert RGB input to indexed ZX spectrum or C64 modes, so its easy to see how different indexed pictures can be.

I agree, but I'm not saying these modes are trying to represent RGB data. I'm just saying that if you consider HAM a compression for RGB data then you could as well consider the various gfx-modes found on 8bit machines as compression for fixed palette data.

I understand you, but what is exactly INPUT data?

In HAM mode you have 12bit RGB INPUT and you can at least psychovisually represent it in 6bits. When on INPUT is green on output you also have Green, maybe not exactly the same but still green.

On C64 fixed palette modes HAM_CONVERT replaces sometimes shades of green with dithered brown (coz find it mathematically more closer to input). Is it still the same data???

The very concept of compression is to represent the same or similar data. It is clear that you can create great graphics on c64 using only indexed palette, but YOU JUST CAN NOT represent some RGB values.

When exactly stasrts the boldness?? How much hair you need to loose to call yourself the bold man? ;-)

Of course we can call JPEG pictures comnverted using quality slider at 1 still a lossy compression, but it would similar to call someone with only single hair on his head to have friseur.

There are other converters around than HAM_CONVERT, you know ;)

And as for input, I'd use an image with the exact same colors used as the output gfx-mode has.

No you can't, but I'm _NOT_ talking about converting/compressing random RGB-pictures either :D

Yes I know, in fact I even suspected you will point it out, when i will mention only ham_Convert and for your information I mentioned it because it is ham_convert topic and no matter what converter you use indexed colours will stay the same ie. they will sometimes be way ahead of what RGB input colour is.



You can prove everything if you set your OWN rules and yes if you would prepare 24bit RGB input when you would use only those 16 indexed colours or even some not far different shades (to replace tchem using dithering) then you will change huge 24bit file into very small one, but exemptions do not make Majority.

What I'm saying is that, for example, the VIC modes can be seen as a compression for a fixed palette mode (with 4bits of colordata represented with only 2bits), if HAM can be seen as a compression for 12bit RGB. Nothing more, nothing less.

But whatever, you can keep on considering HAM the first ever hardware gfx compression and I'll keep on thinking it's hilarious :)

I see now where lies the problem of misunderstanding. I had in mind RGB space as an universal input, but now I see your point.
HAM is for sure the first ever hardware gfx compression operating in RGB mode and I had pointed out long ago there are other ways to minimise memory usage of fixed palette, so all this disscussion was not because we differ on facts, but we differ on words.
I really do not understand why we had to go throught tens of posts and create the mess out of this forum thread to figure it out???

Probably because of your amusment. You really could not resist, dont you?? Let me tell you one thing, doing so you have lost in my eyes and from everyone who will read it and see what you have done here.
I hope it was worth it.