English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 09 November 2007, 18:10   #1
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,641
Question fast HAM8 conversion ?

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...
meynaf is offline  
Old 09 November 2007, 19:43   #2
pbareges
Registered User
pbareges's Avatar
 
Join Date: Feb 2005
Location: montreal / canada
Age: 43
Posts: 722
Quote:
Originally Posted by meynaf View Post
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!
pbareges is offline  
Old 12 November 2007, 01:01   #3
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,086
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).
Thorham is offline  
Old 12 November 2007, 02:10   #4
StrategyGamer
Total Chaos AGA is fun!
 
Join Date: Jun 2005
Location: USA
Posts: 873
I thought Personal Paint only worked with 256 color pics?
StrategyGamer is offline  
Old 12 November 2007, 10:55   #5
Graham Humphrey
Moderator
Graham Humphrey's Avatar
 
Join Date: Jul 2004
Location: Norwich, Norfolk, UK
Age: 33
Posts: 11,061
I thought it did too... Deluxe Paint 4 handles HAM images though doesn't it?
Graham Humphrey is offline  
Old 12 November 2007, 11:32   #6
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,641
I never saw Personal Paint as fast when doing that...

Quote:
Originally Posted by Thorham View Post
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.

Quote:
Originally Posted by Thorham View Post
In the end it might just be impossible.
I think I'll keep my code "as is" then.


Quote:
Originally Posted by Thorham View Post
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...
meynaf is offline  
Old 12 November 2007, 15:10   #7
pbareges
Registered User
pbareges's Avatar
 
Join Date: Feb 2005
Location: montreal / canada
Age: 43
Posts: 722
Quote:
Originally Posted by StrategyGamer View Post
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!
pbareges is offline  
Old 12 November 2007, 15:59   #8
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,641
Quote:
Originally Posted by pbareges View Post
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 :
Code:
 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 :
Code:
 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.
meynaf is offline  
Old 13 November 2007, 04:23   #9
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,086
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.

Last edited by Thorham; 13 November 2007 at 04:54. Reason: Update
Thorham is offline  
Old 13 November 2007, 11:32   #10
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,641
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...)
meynaf is offline  
Old 13 November 2007, 21:33   #11
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,086
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:






Last edited by Thorham; 13 November 2007 at 23:23. Reason: Update
Thorham is offline  
Old 14 November 2007, 11:39   #12
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,641
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
meynaf is offline  
Old 15 November 2007, 00:22   #13
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,086
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...
Thorham is offline  
Old 15 November 2007, 01:21   #14
Frog
Junior Member

Frog's Avatar
 
Join Date: Aug 2001
Location: France
Posts: 1,307
i don't know if it could help you but Smack / Infect has done a JPG2HAM8 & IFF24HAM8 Viewer.
Frog is offline  
Old 15 November 2007, 11:40   #15
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,641
Quote:
Originally Posted by Frog View Post
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

Quote:
Originally Posted by Thorham View Post
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.

Quote:
Originally Posted by Thorham View Post
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.

Quote:
Originally Posted by Thorham View Post
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).

Quote:
Originally Posted by Thorham View Post
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.

Quote:
Originally Posted by Thorham View Post
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.
meynaf is offline  
Old 16 November 2007, 00:54   #16
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,086
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!

Last edited by Thorham; 16 November 2007 at 01:03.
Thorham is offline  
Old 16 November 2007, 11:31   #17
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,641
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 ?
meynaf is offline  
Old 16 November 2007, 13:03   #18
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 43
Posts: 3,086
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.
Thorham is offline  
Old 16 November 2007, 13:59   #19
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,641
Quote:
Originally Posted by Thorham View Post
Oh yes, I dare to
*gasp*

Quote:
Originally Posted by Thorham View Post
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.

Quote:
Originally Posted by Thorham View Post
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).

Quote:
Originally Posted by Thorham View Post
As for the atari 680x0 style, can't wait to see it.
clr.w -(a7)
trap #1
(you asked for it )

Quote:
Originally Posted by Thorham View Post
Looking forward to it, and have a good weekend.
You too.
meynaf is offline  
Old 16 November 2007, 16:07   #20
Doc Mindie
In deep Trouble
 
Join Date: Sep 2004
Location: Manchester, Made in Norway
Age: 47
Posts: 834
Quote:
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
Doc Mindie is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
HAM8 screen question. Thorham Coders. General 28 04 April 2011 20:26
HAM8 C2P Hacking NovaCoder Coders. General 2 25 March 2010 11:37
Problem making ham8 icons. Thorham support.Apps 0 12 March 2008 23:30
Multiple HAM8 pictures? killergorilla support.Other 4 15 February 2007 15:41

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 19:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09734 seconds with 14 queries