fast HAM8 conversion ?

[meynaf]

Hi all,


Are there guru coders in here ? I think yes

My goal is to change 24-bit RGB data into an 8-bitplane HAM-8 intuition screen (to show true color images, that is).

I already did it, and the result is satisfying (in terms of rendering quality). But it's too slow (at least on my 50 Mhz '030)...

The method is basically reading the values, and find out which in fixed, R, G, B type pixels is the closest, then write its value. The c2p is applied afterwards (and takes less than 10% of the total time).

I wrote it in raw pure bleeding ASM, counted clock cycles, and I dunno if it can be optimized further (I doubt).

Are there other methods to do that ?

I can post my source code here if you ask for it, but I think it's now more a matter of algorithm rather than implementation...

[pbareges]

Originally Posted by meynaf

Hi all,


Are there guru coders in here ? I think yes

My goal is to change 24-bit RGB data into an 8-bitplane HAM-8 intuition screen (to show true color images, that is).

I already did it, and the result is satisfying (in terms of rendering quality). But it's too slow (at least on my 50 Mhz '030)...

The method is basically reading the values, and find out which in fixed, R, G, B type pixels is the closest, then write its value. The c2p is applied afterwards (and takes less than 10% of the total time).

I wrote it in raw pure bleeding ASM, counted clock cycles, and I dunno if it can be optimized further (I doubt).

Are there other methods to do that ?

I can post my source code here if you ask for it, but I think it's now more a matter of algorithm rather than implementation...

i can'T help you with the method but i can give you a good benchmark to know if you can optimize it further. you should try to perform the conversion from personal paint (freely available) and check how long it takes and if the rendering is comparable to yours...good luck!

[Thorham]

I'm no guru, but if you're trying to get the program to convert faster then some of the jpeg/bmp viewers out there, then good luck.

In the end it might just be impossible.

The only way I know to convert 24bit to ham is to use three ham pixels to represent a single 24bit pixel in combination with super hires. Although the end results are quite good, the biggest drawback is that you only get an effective resolution of 1280/3 pixels=426 pixels (or 480 if you use maximum overscan). The advantages are that the algorithm is very simple, and you only have to write 18 bits per 24 bit pixel to chip mem, because you can write the two mode bits for the entire screen before doing any conversion (and then re-use them).

[StrategyGamer]

I thought Personal Paint only worked with 256 color pics?

[Graham Humphrey]

I thought it did too... Deluxe Paint 4 handles HAM images though doesn't it?

[meynaf]

I never saw Personal Paint as fast when doing that...

Originally Posted by Thorham

I'm no guru, but if you're trying to get the program to convert faster then some of the jpeg/bmp viewers out there, then good luck.

I have rouhly the same speed right now.

Originally Posted by Thorham

In the end it might just be impossible.

I think I'll keep my code "as is" then.

Originally Posted by Thorham

The only way I know to convert 24bit to ham is to use three ham pixels to represent a single 24bit pixel in combination with super hires. Although the end results are quite good, the biggest drawback is that you only get an effective resolution of 1280/3 pixels=426 pixels (or 480 if you use maximum overscan). The advantages are that the algorithm is very simple, and you only have to write 18 bits per 24 bit pixel to chip mem, because you can write the two mode bits for the entire screen before doing any conversion (and then re-use them).

Sure that would be quite fast, but is the result good enough ? (that is, does it reach the quality a program like FJpeg would get ?)

What I'm doing is that :
- find out (in a precomputed table) which fixed color is the closest and compute the error done
- compute the error I'd do with every other pixel type (R,G,B)
- take the pixel type with the smallest error
- put the pixel value in output buffer (chunky)

I think the existing viewers do the same...

[pbareges]

Originally Posted by StrategyGamer

I thought Personal Paint only worked with 256 color pics?

yep but it displays 24-bit in ham mode to give an idea of the quality of the conversion....

by the way i hope you intend to share this tool with us right ? can you give us an idea of the time consumed by the conversion with details about your config ? thanks!

[meynaf]

Originally Posted by pbareges

by the way i hope you intend to share this tool with us right ? can you give us an idea of the time consumed by the conversion with details about your config ? thanks!

Tool isn't exactly the word. It's more an include file to re-use for whatever tool you intend to write.

There is some sort of speed-vs-accuracy tradeoff on such a rendering, and as some parts are facultative, so the timings can vary.


Let's take an example.

Since HAM-8 colors are 6-bit rather than 8, shall I simply remove the two lower bits or round the value to the nearest ?

This would lead to the following code if I truncate :

 moveq #-4,d1            ; fc
 and.b (a0)+,d1
 moveq #-4,d2
 and.b (a0)+,d2
 moveq #-4,d3
 and.b (a0)+,d3

And this one if I round it :

 moveq #2,d1            ; use 1 to round only 3, 2 to round 2 and 3
 moveq #2,d2
 moveq #2,d3
 add.b (a0)+,d1
 subx.b d0,d0            ; 00 if ok, FF if overflow
 or.b d0,d1               ; unchanged if ok, FF if overflow
 add.b (a0)+,d2
 subx.b d0,d0
 or.b d0,d2
 add.b (a0)+,d3
 subx.b d0,d0
 or.b d0,d3
 moveq #-4,d0            ; fc
 and.b d0,d1
 and.b d0,d2
 and.b d0,d3

In all cases you take (a0) as source data and you get d1-d2-d3 as rgb values.

[Thorham]

Quality wise, the method I described is almost the same as a real 18 bit frame buffer, the only downside is that the resolution becomes lower.

When you want the best color quality and can make do with an effective resolution of 426 pixels, then that method is the one to go for.

However, the fast jpeg viewers preserve the resolution of the image, so resolution wise this method is best. Because none of them actually calculate an optimal base palette the image will suffer from ham fringing (but this makes them much faster then Adpro for example).

Choosing which method is best, depends on your needs.

As for chopping of bits versus rounding, it's pretty safe to say you can just chop the bottom two bits off. That's simpler and faster, and shouldn't make a real difference.

Added a bit later:

I've actually checked the fast viewer method with Visage. In super hires it looks pretty good, in hires the quality does go down though. And for the method I described: Good in super hires but you still have the issue of the resolution. The frame buffer method is actually only to be used when you need an 18 bit frame buffer (games/demos), so you'll probably want to stick to the method you implemented already.

[meynaf]

I think I'll test this 3-pixel method anyway, just to see...
Is there an already existing implementation that I can check ?

The original purpose of this is to write a jpeg viewer, maybe I could include a "quick'n'dirty" mode using this method, but it would have a big drawback : apart from the resolution reduction it imposes, you lose the pixel aspect ratio (that is, pixels won't be square).

Also, a problem arises when you're viewing large images (on autoscroll screens). If you scroll them (to the right) you see long lines of wrong pixels in the left, especially if you have an area of the same color. Any idea on how to prevent this ? (my actual method is to change the default pixel type based on the pixel loop counter...)

[Thorham]

The only implementation I know of is a program I've written in Free Basic for Windows (which does ham emulation). I've done this to test the method. In it's current state you would need Free Basic to use it. Thats why I've uploaded some test pictures to ImageShack, so you can view them here (I first put them on a file hosting site, where you had to download the pics....).

There are six images here, three of them are the originals (800x600) the other three are the ham8 pictures, converted to jpeg and with the scan lines doubled, so they can be viewed on the pc in 1280x1024 as they would appear on aga in 1280x512 ham8. I've made them by scaling the originals down to 426x512 (with re sampling) and then running them through the basic program.

As for the ham fringing screwing up parts of the image: You have to set three pixels at the start of each scan line to match the rgb value of the fourth pixel (the simplest method).
You also need to save the three pixel strip, so it can be restored when the screen scrolls again, or the image will become screwed up.

Also, the quick and dirty method doesn't have this problem. It's true the aspect ratio won't be correct, the image's horizontal size has to be reduced to one third, which without re sampling would be very ugly.

3x1 ham8 versions:







Original versions:

[meynaf]

Ok, but resizing an image isn't computationnally cheap (if you want enough quality), so the method would be even slower...

For the fringing, this is a good idea. However, it implies :
1) knowing which pixel is the leftmost one (I dunno if it's tricky or not in an intuition screen),
2) being able to detect that the image moved before the display is actually updated, and being quick enough to save/restore the area (so we'll not see any intermediate state),
3) keeping the original rgb values of the image somewhere, which can in turn eat a *lot* of memory (even though we don't have to keep all of it).

I guess I can use a vbl server to do the trick, and find correct values in the screen structure. The code should be fast enough for only six pixels to change, but for the amount of data I see no solution...

EDIT: nice pics btw

[Thorham]

Thanks.

As for the scaling, this is exactly why I shouldn't have mentioned the frame buffer method in the first place

You said something about changing six pixels, so the following might be redundant, but since I'm not sure you mean the same thing, I'll put it in any way:

The memory problem shouldn't be too bad, you could make do with just storing one in four 24bit pixels. Setting the rgb values in ham will then result in a border on the left, ranging from three to six pixels wide. The memory requiered for a 1280x1024 24bit image on a standard 640 hires screen, would be about: (1280-640)*1024/4*3=480kb. Imho this is accepteble, seeing how large the 24bit image is.

Also, you could turn of auto scroll for your screen, and have your own routine scroll 8x1 pixels. This way you would have total control over what happens, reduce the memory overhead to 240kb (storing one in eigth 24bit pixels) and the border becomes only two pixels.

Unforunately, this is about the best I can come up with, so I'm sorry if all this was of no help...

[Frog]

i don't know if it could help you but Smack / Infect has done a JPG2HAM8 & IFF24HAM8 Viewer.

[meynaf]

Originally Posted by Frog

i don't know if it could help you but Smack / Infect has done a JPG2HAM8 & IFF24HAM8 Viewer.

The sources are included, so, yes, it helps. At least I have an asm implementation of this sort of rendering and can benchmark it

Originally Posted by Thorham

Thanks.

As for the scaling, this is exactly why I shouldn't have mentioned the frame buffer method in the first place

The RGBB method used by Smack / Infect looks more interesting in that aspect : a factor of 4 is easier to handle.

Originally Posted by Thorham

You said something about changing six pixels, so the following might be redundant, but since I'm not sure you mean the same thing, I'll put it in any way:

What I meant about six pixels is that : you replace 3 pixels with R,G,B value of the 4th, and restore the last 3 pixels for which you did it before - that's six pixels to move.

Originally Posted by Thorham

The memory problem shouldn't be too bad, you could make do with just storing one in four 24bit pixels. Setting the rgb values in ham will then result in a border on the left, ranging from three to six pixels wide. The memory requiered for a 1280x1024 24bit image on a standard 640 hires screen, would be about: (1280-640)*1024/4*3=480kb. Imho this is accepteble, seeing how large the 24bit image is.

Acceptable, yes. But exactly how many pixels are invisible in the left with maximum overscan ?
And copying data may well be slower than my actual GBRB method (that is, in case of identical rows of pixels I get this pattern, for 12 clock cycles per pixel on '030).

Originally Posted by Thorham

Also, you could turn of auto scroll for your screen, and have your own routine scroll 8x1 pixels. This way you would have total control over what happens, reduce the memory overhead to 240kb (storing one in eigth 24bit pixels) and the border becomes only two pixels.

I don't think the control will be total. It would still be possible to manually scroll it (with RAmiga-LMB and moving the mouse, if I remember correctly).
Well, I prefer smooth scrolling anyway.

Originally Posted by Thorham

Unforunately, this is about the best I can come up with, so I'm sorry if all this was of no help...

I got interesting ideas here, and even if they don't make it to my code it is far better than nothing at all.
So thanks.

I'll make some tests this week-end. I dunno if it could be interesting to post/upload my sources here, as they depend on a library I didn't finish either, and they're not exactly easy to read (and all comments are in french).
My actual viewer (yes there is one) is AGA-only (and 020+, and V39+), it supports ilbms and gifs, maybe not all of them, but it is very fast (twice faster than those using iffparse.library and nearly 10% faster than zgif). It is a work in progress and I didn't release it. I can post a binary for you to test/benchmark it if you like.
Then I wanted to do the same for jpeg and iff24, however that's a little bit more complex.

[Thorham]

You're welcome

It might be a good idea to make those sources available here, even though the comments are in French. I'd love to take a look at them. Same goes for the binaries and unfinished library, it would be greatly appreciated.

I'll also be taking a look at the Smack / Infect code, thanks Frog!

As for the smooth scrolling, I know, nothing beats it! And it would be a shame to replace it by a coarse 8x1 scroll if it proves not to be necessary.

I'll see if I can come up with anything interesting, and I hope you do, too, I'm looking forward to read about it.

Happy coding!

[meynaf]

I'll be busy this week-end then.

Ah, oh, yes, I should warn you : I began coding without any of the OS includes, and kept the habit. I also started 68k coding on the Atari St, not the Amiga. So you might see strange things...
(especially if you dare to look into the library code)

I truly wonder what other people will think when looking at that... ... or ?

[Thorham]

Oh yes, I dare to

I started out with a hardware book which didn't use the include files either, and I still don't have the complete chipset includes (they're non-aga, amongst other things), and the os includes are quite old and incomplete. The only thing that bothers me about all that is that sometimes it's quite hard to get other peoples sources to work.

As for the atari 680x0 style, can't wait to see it.

Looking forward to it, and have a good weekend.

[meynaf]

Originally Posted by Thorham

Oh yes, I dare to

*gasp*

Originally Posted by Thorham

I started out with a hardware book which didn't use the include files either, and I still don't have the complete chipset includes (they're non-aga, amongst other things), and the os includes are quite old and incomplete.

Mine are incomplete because of read errors on the disk where I got them
For aga all you need is aga.guide.

Originally Posted by Thorham

The only thing that bothers me about all that is that sometimes it's quite hard to get other peoples sources to work.

Same for me !!!
But this is one of the reasons which make me prefer ASM over C : you're independent (if you want to).

Originally Posted by Thorham

As for the atari 680x0 style, can't wait to see it.

clr.w -(a7)
trap #1
(you asked for it )

Originally Posted by Thorham

Looking forward to it, and have a good weekend.

You too.

[Doc Mindie]

for 12 clock cycles per pixel on '030

A picture of 640*512 (Hires+laced) will then take 327680*12 cycles, or just under 4 million cycles. Meaning, on 50MHz 030, you'ld be able to convert 12 pictures per second.

Sorry, I saw a maths problems where the probably wasn't one........

This is before taking into any considerations, the number of bitplanes/bit per pixels, though