English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 15 March 2020, 00:49   #1
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 581
Conversion of 24bit RGB Image to HAM6

Anyone have a good and quick algorithm for this? ideally one that can uses a fixed 16 colour base palette
DanScott is offline  
Old 15 March 2020, 00:50   #2
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 581
or 12bit 0x0RGB format to HAM6 too would also be ideal
DanScott is offline  
Old 15 March 2020, 09:12   #3
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 740
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
alpine9000 is offline  
Old 15 March 2020, 10:29   #4
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,779
Just an idea: what about Dynamic Low-res were you can have 32colors for each line?
sandruzzo is offline  
Old 15 March 2020, 12:08   #5
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 342
Quote:
Originally Posted by DanScott View Post
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.
Thomas Richter is offline  
Old 15 March 2020, 13:20   #6
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 581
Quote:
Originally Posted by sandruzzo View Post
Just an idea: what about Dynamic Low-res were you can have 32colors for each line?
Not suitable for the use case
DanScott is offline  
Old 15 March 2020, 14:48   #7
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 581
Quote:
Originally Posted by Thomas Richter View Post
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 is offline  
Old 15 March 2020, 14:52   #8
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 581
Quote:
Originally Posted by alpine9000 View Post
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)
DanScott is offline  
Old 15 March 2020, 16:12   #9
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 228
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.
chb is offline  
Old 15 March 2020, 23:56   #10
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 740
Quote:
Originally Posted by chb View Post
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.
alpine9000 is offline  
Old 16 March 2020, 09:43   #11
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,689
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.
meynaf is offline  
Old 16 March 2020, 10:05   #12
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 304
Quote:
Originally Posted by DanScott View Post
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?
Bruce Abbott is offline  
Old 16 March 2020, 10:32   #13
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 669
Quote:
Originally Posted by Bruce Abbott View Post
Why? And why are you converting 24 bit to HAM anyway?
Wild guess, generating graphics for an intro/demo at runtime
britelite is offline  
Old 16 March 2020, 11:21   #14
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 581
Quote:
Originally Posted by Bruce Abbott View Post
Why? And why are you converting 24 bit to HAM anyway?
Because I want to
DanScott is offline  
Old 16 March 2020, 12:37   #15
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,621
Quote:
Originally Posted by meynaf View Post
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.
PeterK is offline  
Old 16 March 2020, 13:48   #16
thellier
Registered User
 
Join Date: Sep 2011
Location: Paris/France
Posts: 223
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
thellier is offline  
Old 16 March 2020, 14:22   #17
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,689
Quote:
Originally Posted by PeterK View Post
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.


Quote:
Originally Posted by PeterK View Post
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.
meynaf is offline  
Old 16 March 2020, 15:13   #18
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,621
Quote:
Originally Posted by meynaf View Post
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.

Last edited by PeterK; 16 March 2020 at 15:18.
PeterK 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
Image conversion from RGB to indexed color sparhawk Graphics 3 15 January 2020 22:53
DB25 to DB23 (RGB Connector) DIY Conversion Nightshft support.Hardware 4 11 April 2019 14:06
Sculpt animate 4D raw RGB files conversion christianlucio support.Apps 12 06 January 2019 20:15
Command line image conversion tools roondar Coders. General 7 07 August 2018 12:56
Batch conversion of Truecolour images to HAM6 earok support.Apps 0 20 May 2015 12:02

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 11:48.


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