Post by hydrophilic on Aug 9, 2014 16:10:30 GMT
This is my 1st in a series of threads. (Several will deal with topics from "the forum that was".) In summary (err... preview), all I can say is colors, colors, COLORS!
I say this because I've been toying with color conversion of images on C128 for years... I said it: years! Normally, this would make feel like a complete flipping retard, but (as I understand it) an entire group of image professionals, the CIE, began (trying to) develope an accurate, computationaly simple, model of human color vision in 1973... and three years later (1976) they finally decided that they couldn't decide!!! (That makes me feel better ) Instead, they introduced two similar but different color models: L*uv and L*ab (here is an intersting article about both).
Well, this is not complete geek speek (i.e., theory), as you can play around with real software from myself (old ImageWork software [working on new version now]) or from others (such as CSAM and Timanthes). However, I would like to "geek out", if I may, and discuss color in general, and how it applies to CBM computers in general and the C128 in particular (shock!)
So first is a simple color model that I keep in my head, and you've probably seen it in various image programs (well probably not exactly the same, but very similar). I call it the "geographic" coordinate system and is very similar to BASIC polar coordinates (if you know what I mean). Anyway, at the top is Red (0 degrees), then proceeding clockwise to Green (120 degrees), then there is Blue (240 degrees), and finally (going through purple/violet) we come back to Red (360 degrees = 0 degrees). I truly hope that makes sense! After reviewing the associated image, if you are still confused, then you should give up reading because everthing else is based on this...
There are some important characteristics that should be noted about my color model, "Red/Lime" for lack of a better name (note this is really RGB[W] converted into polar coordinates). First, all colors have the same "intensity"; this is properly termed chrominance (or loosly, "saturation"). Second, the two axes (Red and Lime) are orthigonal (90 degrees) in this common/uniform color wheel. Third, the Red/Cyan axis (shown with a black line) corresponds with well-known colors but the conjugate axis (shown with a white line) only has approximate names (in English) which I call Lime (and Grape... yummy, fruits .
I think it is important to consider how real "analog" video chips (like TED, VIC-I, and VIC-II[e]) work... well, this varies based on NTSC/PAL standard! There is a nice article about VIC-II colors by Philip Timmermann and it seems fairly reasonable for both NTSC and PAL, but all his color measurements are from PAL chips, and using his values on my NTSC machine generates some colors that are slightly "wrong". (I don't have the hardware to perform detailed measurements.) Anyway, here is the PAL (YUV) color wheel.
First (most obvious, I hope) is that the colors do not have the same saturation, but they do all have the same luminance ("brightness") and the same chrominance (color "power"). So for example, "Yellow" (in the top-right quadrant) is very dull ("washed-out") compared to the same color angle in the common wheel shown in the first image (this is 60 degrees if you care). (By the way, comparing the two, you should be able distinguish between saturation [constant with the previous "Red/Lime"] and chrominance [constant with this YUV]. If that doesn't make sense, you should use a program [like ImageWork] that lets you filter images by either chrominance or saturation, and then it should become obvious.). Second, the U and V axes are orthogonal (90 degrees apart). Third, neither axis corresponds with a well-known color. However, the "plus U" axis (250.5 degrees) is approximately equal to Blue (240 degrees), or an "error" of about 10 degrees. The "plus V" axis (340.5 degrees) is less approximately equal to Red (360 degrees), or an "error" of about 20 degrees. The term "error" is just from a conceptual standpoint, in computer programming, this is normally quite irrelevant.
Finally I present the bastard NTSC (YIQ) color wheel.
First (again, hopefully obvious) is the fact that the colors do not have the same saturation, but they do all have the same luminance ("brightness") and (less obvious) the same chrominance (just like YUV). Second, the I and Q axes are not orthogonal (90 degrees apart) in the "ideal color wheel". However, electrically, they are 90 degrees apart; the reason this is not seen in the image is because (unlike PAL/YUV) the NTSC(YIQ) signal does not assign the same bandwidth to each axis... NTSC/YIQ uses an analog version of image compression! (This works [or not] because human vision is more sensitive to color changes near orange [flesh tones] and less sensitive to color changes near green [or the complement, violet]. For optimal effect, electronic circuits need to be tuned with different bandwidths and one of the signals needs a phase-shift [time delay]; however, many TVs skimped on one or both of these requirements resulting in the joke "Never The Same Color" [NTSC].) Third, neither axis corresponds with a well-known color. However, the Q axis is very close (5 degree "error") to the Lime/Grape axis in the "common color wheel". And the "plus I" axis (22.5 degrees) is close to "orange" (30 degrees) which is an "error" of about 7 degrees. Again, the term "error" is just from a conceptual standpoint...
Well, I think that is enough to start... I'll add more info in the future, but in the meantime, do post any links to relevent web pages you know about. Or comment on about color concepts in general...
Oh yeah, the 80-column VDC chip uses a "digital" color model, but that is a whole other can of worms that I don't want to open right now
Double oh yeah... if you wonder why my images look quite different from those of Philip Timmerman, it is because he starts with Blue=0 degrees (at the right) and he goes counter-clockwise in his diagram. Going counter-clockwise (from the right) is quite common in mathemtical/engineering documents so no fault there... but I do find it strange he would start with "blue." More important is that YUV "blue" (zero degrees per his terms) is not true blue, but slightly off (by about 10 degrees at 250.5 degrees as shown above). This fact makes me questions all his results... by shifting colors 10 degrees, I got a closer color match on my real NTSC machine (40-column mode) but some colors (especially light red and [less noticably] cyan) were still a bit wrong... Of course as shown above, YIQ (NTSC) color axes are radically different from YUV (PAL/SECAM) so my results/theory are just as dubious...
Edit
I just wanted to mention those color wheels shown above are actually 1-D color models (hue) that have been streched into 2-D (a circle). A more accurate representation of RGB / YUV / YIQ color wheels (real 2-D) would show a smooth gradient from gray (at the center) to most colorful (along the parameter of the circle). However, after playing with a few image editors, I haven't been able to generate an accurate color wheel in true 2-D (let alone a 3-D showing "brightness" too). Well, I guess I'll need to write some software to do that! I got a nice graphics generator (similar to MatLab) but it only graphs functions in monochrome (i.e., a point of the function has the foreground color, or it is not on the function has the background color)... I guess I would need to change it to allow RGB(etc.) definitions of each point... what a pain. But I do think it should be documented... Wikipedia does a fair job of documenting RGB/YUV/YIQ (and SECAM) seperately, but there is no good comparison (and there are others to compare too, like HSV, HSL, HSI, HchY).
Oh yeah, if you have any info about color algorithms in general then do post! Since this is Cross-Platform board, it doesn't need to be CBM-Specific, but if it could be useful for making/improving images on CBMs, then that would be definite bonus!
Edit 2
Fixed some typos, and misnomers: in a few parts I was using the terms chrominance and saturation incorrectly... they are not the same! If I'm gonna write about it, a damn well should be accurate. Well, I try
I say this because I've been toying with color conversion of images on C128 for years... I said it: years! Normally, this would make feel like a complete flipping retard, but (as I understand it) an entire group of image professionals, the CIE, began (trying to) develope an accurate, computationaly simple, model of human color vision in 1973... and three years later (1976) they finally decided that they couldn't decide!!! (That makes me feel better ) Instead, they introduced two similar but different color models: L*uv and L*ab (here is an intersting article about both).
Well, this is not complete geek speek (i.e., theory), as you can play around with real software from myself (old ImageWork software [working on new version now]) or from others (such as CSAM and Timanthes). However, I would like to "geek out", if I may, and discuss color in general, and how it applies to CBM computers in general and the C128 in particular (shock!)
So first is a simple color model that I keep in my head, and you've probably seen it in various image programs (well probably not exactly the same, but very similar). I call it the "geographic" coordinate system and is very similar to BASIC polar coordinates (if you know what I mean). Anyway, at the top is Red (0 degrees), then proceeding clockwise to Green (120 degrees), then there is Blue (240 degrees), and finally (going through purple/violet) we come back to Red (360 degrees = 0 degrees). I truly hope that makes sense! After reviewing the associated image, if you are still confused, then you should give up reading because everthing else is based on this...
There are some important characteristics that should be noted about my color model, "Red/Lime" for lack of a better name (note this is really RGB[W] converted into polar coordinates). First, all colors have the same "intensity"; this is properly termed chrominance (or loosly, "saturation"). Second, the two axes (Red and Lime) are orthigonal (90 degrees) in this common/uniform color wheel. Third, the Red/Cyan axis (shown with a black line) corresponds with well-known colors but the conjugate axis (shown with a white line) only has approximate names (in English) which I call Lime (and Grape... yummy, fruits .
I think it is important to consider how real "analog" video chips (like TED, VIC-I, and VIC-II[e]) work... well, this varies based on NTSC/PAL standard! There is a nice article about VIC-II colors by Philip Timmermann and it seems fairly reasonable for both NTSC and PAL, but all his color measurements are from PAL chips, and using his values on my NTSC machine generates some colors that are slightly "wrong". (I don't have the hardware to perform detailed measurements.) Anyway, here is the PAL (YUV) color wheel.
First (most obvious, I hope) is that the colors do not have the same saturation, but they do all have the same luminance ("brightness") and the same chrominance (color "power"). So for example, "Yellow" (in the top-right quadrant) is very dull ("washed-out") compared to the same color angle in the common wheel shown in the first image (this is 60 degrees if you care). (By the way, comparing the two, you should be able distinguish between saturation [constant with the previous "Red/Lime"] and chrominance [constant with this YUV]. If that doesn't make sense, you should use a program [like ImageWork] that lets you filter images by either chrominance or saturation, and then it should become obvious.). Second, the U and V axes are orthogonal (90 degrees apart). Third, neither axis corresponds with a well-known color. However, the "plus U" axis (250.5 degrees) is approximately equal to Blue (240 degrees), or an "error" of about 10 degrees. The "plus V" axis (340.5 degrees) is less approximately equal to Red (360 degrees), or an "error" of about 20 degrees. The term "error" is just from a conceptual standpoint, in computer programming, this is normally quite irrelevant.
Finally I present the bastard NTSC (YIQ) color wheel.
First (again, hopefully obvious) is the fact that the colors do not have the same saturation, but they do all have the same luminance ("brightness") and (less obvious) the same chrominance (just like YUV). Second, the I and Q axes are not orthogonal (90 degrees apart) in the "ideal color wheel". However, electrically, they are 90 degrees apart; the reason this is not seen in the image is because (unlike PAL/YUV) the NTSC(YIQ) signal does not assign the same bandwidth to each axis... NTSC/YIQ uses an analog version of image compression! (This works [or not] because human vision is more sensitive to color changes near orange [flesh tones] and less sensitive to color changes near green [or the complement, violet]. For optimal effect, electronic circuits need to be tuned with different bandwidths and one of the signals needs a phase-shift [time delay]; however, many TVs skimped on one or both of these requirements resulting in the joke "Never The Same Color" [NTSC].) Third, neither axis corresponds with a well-known color. However, the Q axis is very close (5 degree "error") to the Lime/Grape axis in the "common color wheel". And the "plus I" axis (22.5 degrees) is close to "orange" (30 degrees) which is an "error" of about 7 degrees. Again, the term "error" is just from a conceptual standpoint...
Well, I think that is enough to start... I'll add more info in the future, but in the meantime, do post any links to relevent web pages you know about. Or comment on about color concepts in general...
Oh yeah, the 80-column VDC chip uses a "digital" color model, but that is a whole other can of worms that I don't want to open right now
Double oh yeah... if you wonder why my images look quite different from those of Philip Timmerman, it is because he starts with Blue=0 degrees (at the right) and he goes counter-clockwise in his diagram. Going counter-clockwise (from the right) is quite common in mathemtical/engineering documents so no fault there... but I do find it strange he would start with "blue." More important is that YUV "blue" (zero degrees per his terms) is not true blue, but slightly off (by about 10 degrees at 250.5 degrees as shown above). This fact makes me questions all his results... by shifting colors 10 degrees, I got a closer color match on my real NTSC machine (40-column mode) but some colors (especially light red and [less noticably] cyan) were still a bit wrong... Of course as shown above, YIQ (NTSC) color axes are radically different from YUV (PAL/SECAM) so my results/theory are just as dubious...
Edit
I just wanted to mention those color wheels shown above are actually 1-D color models (hue) that have been streched into 2-D (a circle). A more accurate representation of RGB / YUV / YIQ color wheels (real 2-D) would show a smooth gradient from gray (at the center) to most colorful (along the parameter of the circle). However, after playing with a few image editors, I haven't been able to generate an accurate color wheel in true 2-D (let alone a 3-D showing "brightness" too). Well, I guess I'll need to write some software to do that! I got a nice graphics generator (similar to MatLab) but it only graphs functions in monochrome (i.e., a point of the function has the foreground color, or it is not on the function has the background color)... I guess I would need to change it to allow RGB(etc.) definitions of each point... what a pain. But I do think it should be documented... Wikipedia does a fair job of documenting RGB/YUV/YIQ (and SECAM) seperately, but there is no good comparison (and there are others to compare too, like HSV, HSL, HSI, HchY).
Oh yeah, if you have any info about color algorithms in general then do post! Since this is Cross-Platform board, it doesn't need to be CBM-Specific, but if it could be useful for making/improving images on CBMs, then that would be definite bonus!
Edit 2
Fixed some typos, and misnomers: in a few parts I was using the terms chrominance and saturation incorrectly... they are not the same! If I'm gonna write about it, a damn well should be accurate. Well, I try