- Baggers 16 color FatPixel driver: http://forums.parallax.com/showthread.php?115798 you have one of 16 colors for every pixel, perhaps this is good enough for a GUI and saves you a lot of Hub RAM.
Attached is an bitmap display for NTSC. (Untested, but I'm 90% certain it will work.) No demo code, but the interface is very simple:
LONG i_ptr ' pointer to screen (bytes), 0 = inactive
LONG i_width ' number of columns, must be divisible by 4 (i_width*i_clocks < 3192-3894MHz/CLK)
LONG i_height ' number of rows (max i_lines, does not need to be integer multiple)
LONG i_clocks ' pixel width in 16x colorburst clocks (min 515MHz/CLK, e.g. 6 at 80MHz) square pixel = 4.67
LONG i_lines ' number of active lines (max 481)
LONG i_pin ' i_pin = LSB, i_pin+2 = MSB, must be divisible by 4
Note: NTSC8bpp input parameters not validated, minimum clockspeed 16.364MHz (16MHz might work or might have glitches).
Pixel scaling is controlled by i_clocks for the horizontal and i_lines for the vertical.
Please note - the pixel bytes are Propeller TV color codes, i.e. $02 - $07 for black/grey/white, $xB - $xE for muted colors and $y8 & $yF (where y := x XOR $8) for saturated colors.
Pixels are stored in display order - left to right, top to bottom. Output is interlaced, pixel bitmap is not.
We need a tutorial on this. There are too ($&%#(*$(*$#%@#$% many TV driver setup methodologies!
For any TV driver, you need to know the value put into the counter, clock, VCFG, and the pin mask. I would go farther and test for you, but I'm not where I can get to my PPDB and setup your pins to test...
As my driver shows, the only input a TV driver requires is the base pin, everything else can be calculated by the driver (although there are certain advantages to being able to specify the FRQA value). TV.spin squeezes an ungodly number of options into it's tv_pins parameter, but it was designed to be an "everything including the kitchen sink" driver.
I would also encourage people to borrow my FRQA calculation and vertical scaling routines.
For TV setups I suggest you look at my 1pin TV driver in the obex (under debug 1pin TV & 1pin Keyboard). I calculate everything uilising the compiler from only the number of rows and columns.
@potatohead - I'm having trouble with the pin settings - I tried changing two or three lines of code but I think one of them is wrong. TV is on pins 16,17,18
@ericball - do you have a demo to link with that driver?
@Ariba - Yes the 16 color driver will be perfect for a GUI - higher resolution. And the 64+ color drivers will be great for movies. I'm working on movies right now but will go back to the GUI.
@Perry - I'm in Australia but these 'car reversing' LCD TV monitors can handle PAL or NTSC.
@Baggers - I got your 'world map' working with these parameters - if you want to add these to your file
Public Sub RGBtoHSV(ByVal Red, ByVal Green, ByVal Blue, ByRef Hue, ByRef Sat, ByRef Value)
Dim min As Double, max As Double, delta As Double
If Red <= Green And Red <= Blue Then min = Red
If Green <= Red And Green <= Blue Then min = Green
If Blue <= Red And Blue <= Green Then min = Blue
If Red >= Green And Red >= Blue Then max = Red
If Green >= Red And Green >= Blue Then max = Green
If Blue >= Red And Blue >= Green Then max = Blue
Value = max
delta = max - min
If Not delta = 0 Then
Sat = delta / max
Else
Sat = 0
Hue = 0
Exit Sub
End If
If Red = max Then
Hue = (Green - Blue) / delta
ElseIf Green = max Then
Hue = 2 + (Blue - Red)
Else
Hue = 4 + (Red - Green) / delta
End If
Hue = Hue * 60
If Hue < 0 Then Hue = Hue + 360
End Sub
I'm deep inside the color theory at the moment, with a view to writing a translator from pictures (jpg, bitmap) into something that can be displayed on the propeller TV.
First complexity - there are two systems, HSV and HSL. And in each of these, "S" means something quite different.
Then there is the RGB or HSL or HSV color space, which is a three dimensional shape, and this needs to be mapped to the two dimensional propeller system, "chroma" and "luminance".
I've been playing around with Paintshop, and the color picker, and also vb.net. I've got some code to convert to HSV, and fortunately, HSL is internal to vb.net.
mycolor = Color.FromArgb(255, R * 255, G * 255, B * 255)
TextBox30.Text = Strings.Str(mycolor.GetHue)
TextBox29.Text = Strings.Str(mycolor.GetSaturation)
TextBox28.Text = Strings.Str(mycolor.GetBrightness)
Take a look at the wikipedia page, and scroll down to the "swatches". In HSV mode, the propeller colors follow around the outside of the swatch. Ones towards the center are "gray" and the prop can't do these.
In simplistic terms, HSL probably is closer to the propeller colors. Hue is Chroma, L is luminance from white to black, and you can discard Saturation. (Not so with HSV mode, where the prop luminance is a hybrid of S and V).
But it is still not this simple. Look at the HSL swatch for cyan. Say the RGB value came up with the S of 1/4 and L of 5/8. This is a rather steel gray blue. If we ignore S and map this over to L on the left side, with a value of S=1 and L=5/8, this is a much brighter blue.
A closer match (to my eyes at least) is S=1 and L=3/8.
I suspect that even with lots of mathematical formulas, the easiest thing might be to take the 16 Hue values, build a swatch for each of those, then put the propeller LCD display with the Palatte program running next to a VGA screen and work out the closest colors. Then build up some sort of formula for each hue, which ought to be simpler as it is now two dimensions. Take out the gray scale down the middle of the swatch, the white, and the black, and there are 28 values that need to be mapped to 5 propeller values.
And then we could think about dithering with the gray scale...
@Dr_A, I used my BMPtoLite.exe program to convert to .bit files.
Btw, what are you wanting to do?
Are you wanting to convert JPG to .bit files? and are you wanting to convert the same size jpg to the same size .bit or resize any size jpg to a .bit file?
Well there are many things I'd like to do with this, but the first one is to replicate Kye's movie code on a portable screen.
One thing I have noticed about the NTSC driver is that on the LCD TV screen, the Yellow is coming out a very orange/brown color on the demo Palette program.
If I switch to PAL mode (which the TV will handle automatically), Yellow comes out a better looking color. However, in PAL mode there is a bit of shimmering on the screen and it is not quite as 'rock solid' as the NTSC screen.
So I'm not sure whether to do the color conversions for the NTSC colors or the PAL colors.
Actually, to convert from RGB to Propeller TV values you need an RGB to YUV conversion.
First, scale R, G, B to be in the range 0..1
Second calculate Y (luma) from the standard Rec.601 color difference equation:
Y = 0.299R + 0.587G + 0.114B
Third calculate the U & V color difference signals:
U = 0.492 * (B - Y)
V = 0.877 * (R - Y)
Now working from the Propeller end. Each byte is three values bits [7..4] are hue, bit [3] is color enable, bits [2..0] are luma.
if color is disabled
Y = (luma - 2) / 5
U = 0
V = 0
if color is enabled and luma = 1..6 and using the standard Propeller colorburst
Y = (luma - 2) / 5
U = 0.215 * cos( 2pi * hue/16 )
V = -0.215 * sin( 2pi * hue/16 )
if color is enabled and luma = 0
Y = 0.4
U = 0.646 * cos( 2pi * (hue+8)/16 )
V = 0.646 * sin( 2pi * (hue+8)/16 )
if color is enabled and luma = 7
Y = 0.2
U = 0.646 * cos( 2pi * (hue+8)/16 )
V = 0.646 * sin( 2pi * (hue+8)/16 )
Now, what this all means is although it's possible to get a "close" Propeller TV color equivalent to some RrGgBb colors, there are a lot which don't match (in either direction).
PAL colors will be slightly different because of how colorburst is generated. The easy way means the burst isn't at 135/225 degrees, the hard way shifts everything by a half a hue step (versus NTSC).
Please note: the color formulas are based on theoretical, not measured. In particular the saturation values are an estimate.
Great links - this is going to be a lot of fun to play around with.
Just a thought - if the propeller can produce video, can it also read a video signal?
Maybe the sigma delta is not fast enough, but the 3 resistor D to A is 8 bits of resolution, and we need the phase information. At that low resolution, one could almost think about 4 op amps and a resistor chain, and feed the video input into 8 propeller pins. That ought to be very fast. Or maybe video capture already exists (I think I recall seeing something about B&W but not color?)
Great links - this is going to be a lot of fun to play around with.
Just a thought - if the propeller can produce video, can it also read a video signal?
Maybe the sigma delta is not fast enough, but the 3 resistor D to A is 8 bits of resolution, and we need the phase information. At that low resolution, one could almost think about 4 op amps and a resistor chain, and feed the video input into 8 propeller pins. That ought to be very fast. Or maybe video capture already exists (I think I recall seeing something about B&W but not color?)
my stupid video does B/W capture 64x240 30fps with 64 grey shades and audio and records to SD
I thought few people realized how good it had become.
I think it's good enough now for some surveillance applications.
My latest project using that is a " Video Door Bell".
That sounds really impressive. There are a range of 'security cameras' that are very cheap, and also the 'reversing car' cameras that pair with the screens I'm playing with.
I can see some very cost effective robotic solutions with your video capture.
I'm playing around with some code to convert colors. Convert from RGB to HSL. Then a few rules eg if L>0.9 then make it white = 1.0
And if S<0.25 then make it grayscale.
Am getting some oversaturation of skin tones. I might do some experiments with dithering, ie take two pixels side by side, average them, then produce a color pixel and a grayscale pixel side by side. This might give 5 new values for each prop palette color ie 16x5x5 colors.
It may smooth things and lighten up skin tones, but at the expense of creating blur.
Comments
before you use NTSC only drivers, here are some links to better solutions:
- the original thread of the 8bc driver: http://forums.parallax.com/showthread.php?108795
- Baggers 16 color FatPixel driver: http://forums.parallax.com/showthread.php?115798 you have one of 16 colors for every pixel, perhaps this is good enough for a GUI and saves you a lot of Hub RAM.
- Baggers modified FatPixel driver with 1 byte per pixel: http://forums.parallax.com/showthread.php?119058
Andy
LONG i_ptr ' pointer to screen (bytes), 0 = inactive
LONG i_width ' number of columns, must be divisible by 4 (i_width*i_clocks < 3192-3894MHz/CLK)
LONG i_height ' number of rows (max i_lines, does not need to be integer multiple)
LONG i_clocks ' pixel width in 16x colorburst clocks (min 515MHz/CLK, e.g. 6 at 80MHz) square pixel = 4.67
LONG i_lines ' number of active lines (max 481)
LONG i_pin ' i_pin = LSB, i_pin+2 = MSB, must be divisible by 4
Note: NTSC8bpp input parameters not validated, minimum clockspeed 16.364MHz (16MHz might work or might have glitches).
Pixel scaling is controlled by i_clocks for the horizontal and i_lines for the vertical.
Please note - the pixel bytes are Propeller TV color codes, i.e. $02 - $07 for black/grey/white, $xB - $xE for muted colors and $y8 & $yF (where y := x XOR $8) for saturated colors.
Pixels are stored in display order - left to right, top to bottom. Output is interlaced, pixel bitmap is not.
Bean made a very good driver on this thread http://forums.parallax.com/showthread.php?112910-Color-NTSC-160x192-16-colors/page2&highlight=bean+color+driver
It's probably the simplest driver of them all, and you get 1 byte per pixel 16 colors and 16 shades.
The 160x112 pixels with double buffering and graphics interface.
by the way you are in Australia do yo want PAL or NTSC TV?
Perry
As my driver shows, the only input a TV driver requires is the base pin, everything else can be calculated by the driver (although there are certain advantages to being able to specify the FRQA value). TV.spin squeezes an ungodly number of options into it's tv_pins parameter, but it was designed to be an "everything including the kitchen sink" driver.
I would also encourage people to borrow my FRQA calculation and vertical scaling routines.
@potatohead - I'm having trouble with the pin settings - I tried changing two or three lines of code but I think one of them is wrong. TV is on pins 16,17,18
@ericball - do you have a demo to link with that driver?
@Ariba - Yes the 16 color driver will be perfect for a GUI - higher resolution. And the 64+ color drivers will be great for movies. I'm working on movies right now but will go back to the GUI.
@Perry - I'm in Australia but these 'car reversing' LCD TV monitors can handle PAL or NTSC.
@Baggers - I got your 'world map' working with these parameters - if you want to add these to your file
'{Dracblade Setup _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 modepins = %010_0000 NES_RIGHT = %00000000_00001000 NES_LEFT = %00000000_00000100 NES_DOWN = %00000000_00000010 NES_UP = %00000000_00000001 NES_START = %00000000_10000000 NES_SELECT = %00000000_10000000 NES_B = %00000000_00100000 NES_A = %00000000_00100000 keybase = 26 AUDIO_L = 0 AUDIO_R = 0 SDPins = 12 '}Did you use any special software to convert bitmaps to the .bit file? Is there a formula around that takes RGB (0-255 for each) and converts to the TV byte values? Addit: I'm studying this which I think answers this question http://www.rayslogic.com/propeller/Programming/TV_Colors.htm and some formulas here http://en.wikipedia.org/wiki/HSL_and_HSV
Playing around with this code at the moment
Public Sub RGBtoHSV(ByVal Red, ByVal Green, ByVal Blue, ByRef Hue, ByRef Sat, ByRef Value) Dim min As Double, max As Double, delta As Double If Red <= Green And Red <= Blue Then min = Red If Green <= Red And Green <= Blue Then min = Green If Blue <= Red And Blue <= Green Then min = Blue If Red >= Green And Red >= Blue Then max = Red If Green >= Red And Green >= Blue Then max = Green If Blue >= Red And Blue >= Green Then max = Blue Value = max delta = max - min If Not delta = 0 Then Sat = delta / max Else Sat = 0 Hue = 0 Exit Sub End If If Red = max Then Hue = (Green - Blue) / delta ElseIf Green = max Then Hue = 2 + (Blue - Red) Else Hue = 4 + (Red - Green) / delta End If Hue = Hue * 60 If Hue < 0 Then Hue = Hue + 360 End SubThe theory is fascinating and complex. There is an explanation in wikipedia http://en.wikipedia.org/wiki/HSL_and_HSV
First complexity - there are two systems, HSV and HSL. And in each of these, "S" means something quite different.
Then there is the RGB or HSL or HSV color space, which is a three dimensional shape, and this needs to be mapped to the two dimensional propeller system, "chroma" and "luminance".
I've been playing around with Paintshop, and the color picker, and also vb.net. I've got some code to convert to HSV, and fortunately, HSL is internal to vb.net.
mycolor = Color.FromArgb(255, R * 255, G * 255, B * 255) TextBox30.Text = Strings.Str(mycolor.GetHue) TextBox29.Text = Strings.Str(mycolor.GetSaturation) TextBox28.Text = Strings.Str(mycolor.GetBrightness)Take a look at the wikipedia page, and scroll down to the "swatches". In HSV mode, the propeller colors follow around the outside of the swatch. Ones towards the center are "gray" and the prop can't do these.
In simplistic terms, HSL probably is closer to the propeller colors. Hue is Chroma, L is luminance from white to black, and you can discard Saturation. (Not so with HSV mode, where the prop luminance is a hybrid of S and V).
But it is still not this simple. Look at the HSL swatch for cyan. Say the RGB value came up with the S of 1/4 and L of 5/8. This is a rather steel gray blue. If we ignore S and map this over to L on the left side, with a value of S=1 and L=5/8, this is a much brighter blue.
A closer match (to my eyes at least) is S=1 and L=3/8.
I suspect that even with lots of mathematical formulas, the easiest thing might be to take the 16 Hue values, build a swatch for each of those, then put the propeller LCD display with the Palatte program running next to a VGA screen and work out the closest colors. Then build up some sort of formula for each hue, which ought to be simpler as it is now two dimensions. Take out the gray scale down the middle of the swatch, the white, and the black, and there are 28 values that need to be mapped to 5 propeller values.
And then we could think about dithering with the gray scale...
Btw, what are you wanting to do?
Are you wanting to convert JPG to .bit files? and are you wanting to convert the same size jpg to the same size .bit or resize any size jpg to a .bit file?
Cheers,
Baggers.
Fantastic code - thanks++
Well there are many things I'd like to do with this, but the first one is to replicate Kye's movie code on a portable screen.
One thing I have noticed about the NTSC driver is that on the LCD TV screen, the Yellow is coming out a very orange/brown color on the demo Palette program.
If I switch to PAL mode (which the TV will handle automatically), Yellow comes out a better looking color. However, in PAL mode there is a bit of shimmering on the screen and it is not quite as 'rock solid' as the NTSC screen.
So I'm not sure whether to do the color conversions for the NTSC colors or the PAL colors.
First, scale R, G, B to be in the range 0..1
Second calculate Y (luma) from the standard Rec.601 color difference equation:
Y = 0.299R + 0.587G + 0.114B
Third calculate the U & V color difference signals:
U = 0.492 * (B - Y)
V = 0.877 * (R - Y)
Now working from the Propeller end. Each byte is three values bits [7..4] are hue, bit [3] is color enable, bits [2..0] are luma.
if color is disabled
Y = (luma - 2) / 5
U = 0
V = 0
if color is enabled and luma = 1..6 and using the standard Propeller colorburst
Y = (luma - 2) / 5
U = 0.215 * cos( 2pi * hue/16 )
V = -0.215 * sin( 2pi * hue/16 )
if color is enabled and luma = 0
Y = 0.4
U = 0.646 * cos( 2pi * (hue+8)/16 )
V = 0.646 * sin( 2pi * (hue+8)/16 )
if color is enabled and luma = 7
Y = 0.2
U = 0.646 * cos( 2pi * (hue+8)/16 )
V = 0.646 * sin( 2pi * (hue+8)/16 )
Now, what this all means is although it's possible to get a "close" Propeller TV color equivalent to some RrGgBb colors, there are a lot which don't match (in either direction).
PAL colors will be slightly different because of how colorburst is generated. The easy way means the burst isn't at 135/225 degrees, the hard way shifts everything by a half a hue step (versus NTSC).
Please note: the color formulas are based on theoretical, not measured. In particular the saturation values are an estimate.
there are some good movies played by the prop in it.
DeepFry prop video player
http://forums.parallax.com/showthread.php?104291-DeepFry-prop-video-player-%28update-6-20-08%29
Perry
Just a thought - if the propeller can produce video, can it also read a video signal?
Maybe the sigma delta is not fast enough, but the 3 resistor D to A is 8 bits of resolution, and we need the phase information. At that low resolution, one could almost think about 4 op amps and a resistor chain, and feed the video input into 8 propeller pins. That ought to be very fast. Or maybe video capture already exists (I think I recall seeing something about B&W but not color?)
my stupid video does B/W capture 64x240 30fps with 64 grey shades and audio and records to SD
I thought few people realized how good it had become.
I think it's good enough now for some surveillance applications.
My latest project using that is a " Video Door Bell".
I can see some very cost effective robotic solutions with your video capture.
It does allow you to use a tiny $12 NTSC camera and capture images with just a few simple parts.
And if S<0.25 then make it grayscale.
Am getting some oversaturation of skin tones. I might do some experiments with dithering, ie take two pixels side by side, average them, then produce a color pixel and a grayscale pixel side by side. This might give 5 new values for each prop palette color ie 16x5x5 colors.
It may smooth things and lighten up skin tones, but at the expense of creating blur.