English Amiga Board Converting 8bit colour components to 4bit
 Register Amiga FAQ Rules & Help Members List  /  Moderators List Today's Posts Mark Forums Read

 10 February 2021, 01:08 #1 DanScott Lemon. / Core Design   Join Date: Mar 2016 Location: Tier 5 Posts: 999 Converting 8bit colour components to 4bit How do YOU do it? I guess the simplest way is to >> 4 But... then \$EF as an 8 bit component is closer to \$F (as a 4bit) than it is to \$E I know that when converying from 4bit to 8bit, the general concensus is to use \$xyz -> \$xxyyzz (ie. \$4C3 would become \$44CC33), but going back the other way there are issues perhaps ?
 10 February 2021, 01:15 #2 roondar Registered User   Join Date: Jul 2015 Location: The Netherlands Posts: 2,890 I've done this in code just once so far, but I did indeed just do >> 4 in my script. But reading your post, I'm now thinking about using a floating point divide and rounding that instead. This would be more accurate, after all. However, there may be better ways yet. Perhaps some sort of perceptual conversion where the conversion keeps in mind that human eyes don't really do linear colour might even be a neat trick. Don't have an algorithm at the ready, but common wisdom has it that our eyes are more sensitive to green than any other colour so perhaps rounding green up and the rest down might do the trick? Then again, perhaps a simple linear conversion is best after all. Might test that out for fun.
 10 February 2021, 01:19 #3 DanScott Lemon. / Core Design   Join Date: Mar 2016 Location: Tier 5 Posts: 999 Yes, probably rounding each component up or down to the nearest \$X0 value? So \$E7 would round to \$E0, and \$E8 to \$F0 I know some people swear by dividing each component by 17 (as going from 4bit to 8bit, you do the equivalent of a multiply by 17).. but then this has issues where (for example) \$FFFFFF is the only 8bit RGB value that would generate \$FFF as a 4bit colour value
 10 February 2021, 01:31 #4 Jobbo Registered User   Join Date: Jun 2020 Location: Lexington, MA Posts: 189 I'm sure you've though of this but you could go with: fourbit = (eightbit + 8) / 17
 10 February 2021, 02:25 #5 orangespider Registered User   Join Date: Feb 2021 Location: Becej / Serbia Posts: 120 This really depends on what you want to accomplish. The mathematically most perfect solution is the one written above (y = (x + 8) div 17), however in that solution you will get less white and black pixels than any other color. You will end up with 9 8bit colors being remapped to black and white and 17 colors being remapped to the rest. The fastest approach with >> 4 will give you less precise colors, but every single 4bit value will have 16 corresponding 8bit values so the actual output might look better. Alternatively you can use pattern dithering with (x+d) div 17 where the d values can be taken from this table: 1, 9, 3, 11 13, 5, 15, 7 4, 12, 2, 10 16, 8, 14, 6 It's pretty straightforward since you can just use (x and 3) and (y and 3) to get the values from the dither table. note: The dither table starts from 1 instead of 0 because this way the average we get is 8.5 which is pretty good for average rounding. If you don't want the div, you can go with y = ((x << 4) - x + d) >> 8, just need to scale the dither table up (or just use a constant d=128 for rounding).
10 February 2021, 23:27   #6
ross
Defendit numerus

Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 51
Posts: 3,283
Quote:
 Originally Posted by DanScott Yes, probably rounding each component up or down to the nearest \$X0 value? So \$E7 would round to \$E0, and \$E8 to \$F0 I know some people swear by dividing each component by 17 (as going from 4bit to 8bit, you do the equivalent of a multiply by 17).. but then this has issues where (for example) \$FFFFFF is the only 8bit RGB value that would generate \$FFF as a 4bit colour value
Hi Dan, I faced a similar problem (an effect in ham for 'vertical copper').
And my reasoning was to use code that would allow me to reverse the duplication of the nibble when doing RGB4 to RGB8.

So I used the central RGB8 color and 'draw around' it an area using it as a pivot.
This give me usually 8+1+8 values (excluding the reduced extremes and a different negligible point at 8).

Visually:
Code:
```      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00   00 00 00 00 00 00 00 00  01 01 01 01 01 01 01 01
10   01 01 01 01 01 01 01 01  01 02 02 02 02 02 02 02
20   02 02 02 02 02 02 02 02  02 02 03 03 03 03 03 03
30   03 03 03 03 03 03 03 03  03 03 03 04 04 04 04 04
40   04 04 04 04 04 04 04 04  04 04 04 04 05 05 05 05
50   05 05 05 05 05 05 05 05  05 05 05 05 05 06 06 06
60   06 06 06 06 06 06 06 06  06 06 06 06 06 06 07 07
70   07 07 07 07 07 07 07 07  07 07 07 07 07 07 07 08
80   08 08 08 08 08 08 08 08  08 08 08 08 08 08 08 08
90   08 09 09 09 09 09 09 09  09 09 09 09 09 09 09 09
A0   09 09 0A 0A 0A 0A 0A 0A  0A 0A 0A 0A 0A 0A 0A 0A
B0   0A 0A 0A 0B 0B 0B 0B 0B  0B 0B 0B 0B 0B 0B 0B 0B
C0   0B 0B 0B 0B 0C 0C 0C 0C  0C 0C 0C 0C 0C 0C 0C 0C
D0   0C 0C 0C 0C 0C 0D 0D 0D  0D 0D 0D 0D 0D 0D 0D 0D
E0   0D 0D 0D 0D 0D 0D 0E 0E  0E 0E 0E 0E 0E 0E 0E 0E
F0   0E 0E 0E 0E 0E 0E 0E 0F  0F 0F 0F 0F 0F 0F 0F 0F```
Code (input and output in d0):
Code:
```    move.b  d0,d1
lsr.b   #4,d1
sub.b   d1,d0
lsr.b   #4,d0```
In this way I don't preclude myself or crush too much on the black and white colors like other methods.

I have no idea if there is a similar accepted algorithm in the literature, but it is as simple, fast and correct (for me) .

 10 February 2021, 23:44 #7 DanScott Lemon. / Core Design   Join Date: Mar 2016 Location: Tier 5 Posts: 999 Yeah, I like that one Ross!! Remaps a good range of pure black and pure white it's a conundrum that's plagued my mind for a long time So simple from 4bit -> 8bit, but so many ways going back the other way, which to all intents and purposes, will never be entirely correct. I guess it's how it looks visually, that's the only way to determine what method will give the best results.
 19 February 2021, 15:08 #8 Photon Moderator   Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 4,954 Range is 15 vs 255, not 16 vs 256, so just shifting will make all colors but 255 darker. (E.g. \$1f -> \$1) Rounding will make bright colors darker, dark colors brighter, and be kind of randomly all right in the middle. (E.g. \$12 -> \$2) \$11, \$22, and so on compensates for 15/16 by multiplying by 17. It's pretty close (99.61%). This spreads out the range of 15 evenly across 255. So the correct color going the other way for \$1 is \$11, not \$18 or \$17 (rounding). It must be spread out. (Rounding must be done w/r to 17, not 16.) So the correct color reduction is divide (rounded) by 17. This can be done with a 256-byte LUT (or a 128 byte one if you want to shuffle nibbles around ) generated with addq.w #8,d0;divu #17,d0. Last edited by Photon; 19 February 2021 at 15:14.
 19 February 2021, 20:13 #9 Thomas Richter Registered User   Join Date: Jan 2019 Location: Germany Posts: 1,148 You don't need a division. As posted earlier, y = ((x << 4) - x + d) >> 8 for all 8 bit numbers. Try to proof this (Hint: Neumann series).
 19 February 2021, 20:49 #10 a/b Registered User   Join Date: Jun 2016 Location: europe Posts: 384 These are not equal in all 3 cases (columns are i, round(i/17.0), (i-(i>>4)+8)>>4, ((i<<4)-i+128)>>8): Code: ```08: 00 01 00 * 19: 01 02 01 * 2a: 02 03 02 * 3b: 03 04 03 * 4c: 04 05 04 * 5d: 05 06 05 * 6e: 06 07 06 * 7f: 07 08 07 * 91: 09 09 08 * a2: 0a 0a 09 * b3: 0b 0b 0a * c4: 0c 0c 0b * d5: 0d 0d 0c * e6: 0e 0e 0d * f7: 0f 0f 0e *```
 19 February 2021, 21:18 #11 Photon Moderator   Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 4,954 Well, I have answered the question asked.

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

 Similar Threads Thread Thread Starter Forum Replies Last Post Signman support.Other 0 10 October 2019 02:39 slk486 support.Hardware 26 04 May 2010 20:09 Specksynder MarketPlace 0 30 October 2009 16:18 jimbob005 MarketPlace 1 20 June 2008 17:17 Smiley support.Hardware 4 25 April 2006 11:20

 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 Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home News Main     Amiga scene     Retrogaming General Discussion     Nostalgia & memories Support     New to Emulation or Amiga scene         Member Introductions     support.WinUAE     support.WinFellow     support.OtherUAE     support.FS-UAE         project.AmigaLive     support.Hardware         Hardware mods         Hardware pics     support.Games     support.Demos     support.Apps     support.Amiga Forever     support.Amix     support.Other Requests     request.UAE Wishlist     request.Old Rare Games     request.Demos     request.Apps     request.Modules     request.Music     request.Other     Looking for a game name ?     Games images which need to be WHDified abime.net - Hall Of Light     HOL news     HOL suggestions and feedback     HOL data problems     HOL contributions abime.net - Amiga Magazine Rack     AMR news     AMR suggestions and feedback     AMR data problems     AMR contributions abime.net - Home Projects     project.Amiga Lore     project.EAB     project.IRC     project.Mods Jukebox     project.Wiki abime.net - Hosted Projects     project.aGTW     project.APoV     project.ClassicWB     project.Jambo!     project.Green Amiga Alien GUIDES     project.Maptapper     project.Sprites     project.WinUAE - Kaillera Other Projects     project.Amiga Demo DVD     project.Amiga Game Factory     project.CARE     project.Amiga File Server     project.CD32 Conversion     project.Game Cover Art         GCA.Feedback and Suggestions         GCA.Work in Progress         GCA.Cover Requests         GCA.Usefull Programs         GCA.Helpdesk     project.KGLoad     project.MAGE     project.Missing Full Shareware Games     project.SPS (was CAPS)     project.TOSEC (amiga only)     project.WHDLoad         project.Killergorilla's WHD packs Misc     Amiga websites reviews     MarketPlace         Swapshop     Kinky Amiga Stuff     Collections     EAB's competition Coders     Coders. General         Coders. Releases         Coders. Tutorials     Coders. Asm / Hardware     Coders. System         Coders. Scripting         Coders. Nextgen     Coders. Language         Coders. C/C++         Coders. AMOS         Coders. Blitz Basic     Coders. Contest         Coders. Entries Creation     Graphics         Graphics. Work In Progress         Graphics. Finished Work         Graphics. Tutorials     Music         Music. Work In Progress         Music. Finished Work         Music. Tutorials

All times are GMT +2. The time now is 20:15.

 -- EAB3 skin ---- EAB2 skin ---- Mobile skin Archive - Top