Hypothetical: Is it better to use 256x96 with 86 colors, or 256x192 with 16 colors?
Attached is a screenshot of a 256x192 picture compressed with Floyd Steinberg compression using the standard Windows 16 color palette. (The story of the image is here http://en.wikipedia.org/wiki/Lenna)
Original at top left. 16 color palette top right. 256x192 with 16 colors bottom left. 256x96 with 86 colors and "tall" pixels bottom right.
Apologies for the large image file, but this needs to be a bitmap rather than a jpeg to retain the image quality.
I haven't got this onto a propeller yet as I need a little help from Baggers. Specifically;
i) Have you got the code for the 256x192 driver?
ii) Is the palette you are using similar to this palette?
iii) Do we need to color match this palette to the actual nearest colors on a propeller?
I'm looking forward to seeing this on a propeller TV, as one interesting thing is that the physical size of the picture on my computer is slightly larger than the actual TV, so I'm hoping that might blur some of the dithering.
If you look in the source you will see that I have moved the sprite data away from the normal location of $5000 to $1800 where there is 2K of free space. This limitation is due to memory constraints of 16 colour bitmap mode and we don't expect this mode to be used with sprites that much.
re my post #96, for the 256x192 driver, when you say there is a palatte of 16 colors, is that 16 colors in total for the whole display, or can you have a different set of 16 colors for each tile (eg select the 'best' 16 colors from the 86 colors available).
re my post #96, for the 256x192 driver, when you say there is a palatte of 16 colors, is that 16 colors in total for the whole display, or can you have a different set of 16 colors for each tile (eg select the 'best' 16 colors from the 86 colors available).
If yes, we could push the resolution further...
Dr_A,
The bitmap modes don't have attributes ( apart from the Spectrum modes and C64 modes )
However, the 4bit charmap mode does have attributes in the charmap area $1800-$1fff which holds the character number (0-1023) and in the bits (13-10) has the palette number (0-15)
I'll show Coley the how-to and he'll add it in his list of demo/examples.
Thanks baggers. Would you have a link to the 256x192 driver by any chance - I would like to check out how it works with the pictures I have created.
As an aside, I have bought some LCD displays - a 3.5", a 4.3" and a 7" display. They are all very reasonable prices on ebay. The larger ones seem more 16:9 than 4:3 so might need some pre-processing to get the ratio right. (The simple way to do this is to start with a picture of a circle and check it ends up as a circle).
Does the the 256x192 fill the screen or does it have black bars at the top and the bottom?
It's not a driver as such but part of PropGFX Lite binary release. (Details in the top post of this thread)
I'll speak with Baggers about doing a demo and will post on here.
Re: LCD's it doesn't fill the screen there is a border all the way round the image.
I should add that the 192x96 code worked "right out of the box", and as such all attribution goes 100% to the authors. No need to change anything.
I'm very much looking forward to testing out the 256x192 code. The reason is that I think that 256x192x16 colors with Floyd Steinberg might hit a 'sweet spot' with respect to graphics.
Looking at a number of images, I think that 256x96 with 86 colors and 256x192 with 16 colors look very similar. But with twice the 'y' resolution, more things become possible.
In particular, with some scroll bars, this might be enough to build a reasonable web browser. See below for what Google would look like with 256x192, only 16 colors, and some F-S image manipulation on the "Google" text. Not too bad if you don't zoom in too close...
I'm thinking of what you need, and what we have.
1) Access to the internet. I think the spinneret can do this sort of thing.
2) Ability to parse html files. Certainly the simpler html files are just text and graphics. Text is easy. Graphics...
3) Ability to display bitmap files. Do a Floyd-Steinberg manipulation 'on the fly' on any bmp files. (I have that working in vb.net, so Spin and C ought to be possible) Convert .jpg to .bmp first (maybe a little harder).
4) The 'building blocks' of a web page - buttons, text boxes, different fonts. I have this working in Catalina C. Translate from html and put them on the screen.
5) Hardware. I have hardware that can run Catalina C with big programs up to 512k, and a new design (boards being make by BatchPCB) that ought to speed up XMM code by at least 10x.
6) Processing code. Most of the searches on Floyd-Steinberg came up with C code. I translated this to vb.net, and Spin would be possible too, but it will be even easier to drop it into Catalina C.
There must be some cool 'cloud computing' things this could open up - eg, rather than try to write a fancy word processor, there must be something out there on the internet that does the same thing. Particularly since small screen web browsing is becoming more popular due to mobile phones.
So many building blocks have been proven to work, or are very close to working.
Even Monet is not too bad at 256x192 with 16 colors.
Apologies for the enthusiasm, but I'm like a kid in a lolly shop waiting for this 256x192 code *grin*!
Google docs?
No worries, 256x192 charmap demo will be a little while I'm working on big scroller demo for OBC.
Oh btw, zooming in on the image is what prop does on a TV
Here's a demo of the 16colour charmap mode.
To grab a 8bit bmp for 16 colour mode, use :- Grab16 filename
I've done a fix to BMP8toLite too as it wasn't storing the palette in the map.
I've got Coley trying to find a free app that will convert an image into a palettised image creating 16 * 16 colour palettes for the image to keep each 8x8 in a 16 colour range.
I use ProMotion which isn't a free app, so we're trying to find a free alternative.
I tried the ProMotion 6.0 Demo and fought with it horribly. Just back to (free) Paint.Net and I was able to generate this in 30 seconds using your new version of Bmp8toLite.
Rescued and adapted some old pixel graphics, that dates back to amiga days
I'm using the same palette as Dr_Acula (RGBI) otherwise I get scrambled colors.
Wow... I'm seriously impressed with that! I'll bet we could devise some really nice Propeller controls with that graphic.
Could you expand on how you are doing your conversion? (program wise) I'm a little lost with palette changing.
Wow... I'm seriously impressed with that! I'll bet we could devise some really nice Propeller controls with that graphic.
Could you expand on how you are doing your conversion? (program wise) I'm a little lost with palette changing.
OBC
Jeff, I'm afraid that I'm as lost as you with palettes... In photoshop, I manually used "replace color" 16 times to ensure all the colors will fall in the auto-choosing range when I later switch from RGB color (24bit) to Indexed Color (forcing a fixed RGBI 16 color palette). Then save the image as 8bpp for bmp8toLite processing.
I think saving the BMP in 4bpp could be used for direct blits to gfx mode, since the RGBI order is mantained, and the BMP header can be simply skipped (once you manually set same palette).
The original graphics had orange and 2 more gray shades traded for light cyan and light/dark magenta. Still 16 colors, but slightly better visual result:
While waiting on the 256x192 code I thought I would take a look at the video driver to see how things work. There is some commented out code and there is some code that is not used - eg the palette in the main driver is not used at all.
I was a bit confused by this until I realised that the palette numbers are pre-processed before being made into a picture or a movie, so the numbers in the picture are the actual palette bytes.
Taking a look at the video loop, I think this might explain this rather simple code
Which I think replaces some more complex code in "xloop" (commenting out xloop and it still worked).
So, take some color bytes, eg $02 and $07 etc, and with 86 colors, one byte per pixel, out they go with no processing.
But for 256x192, the bytes are going to need to be matched up to a palette, right? ie a 16 color palette
eg each byte now contains two pixels. So a pixel would contain a value, 0-15, which is matched to a palette.
That implies some processing in that video loop - ie read a byte, split off the high and low nibble, look up the palette byte value, output that byte.
If that is how it is working, then I am wondering where the palette information comes from.
Thinking forensically about how the code has evolved, this is the main startup code
tvparams long 0 'status
long 1 'enable
long modepins 'pins
long mode 'mode
long x_tiles 'hc
long y_tiles 'vc
long my_hx 'hx
VSyncFlag long 0
nextline long 0
tvbitmapptr long @screen+$10
bordercolour long $02
long @palette+$10
'palette byte $02,$07,$28,$8d,$ba,$1a,$db,$3d,$8f,$5f,$3f,$5b,$d8,$04,$02,$02
screen byte $1b[256*96] 'file "title.bit"
with the palette commented out as expected.
But - if we need the palette put back in again for 256x192, does that palette have to be fixed (red, green, blue, black, gray etc), or can it vary?
Specifically, the values for a palette could exist locally in cog ram. But equally, could it be possible to read out a new palette every scan line? That palette could be incorporated into the picture.
If so, is there any reason why you could not optimise each line in the picture for the 'best' palette of 16 colors, eg for sky, mostly white, grays and blues.
Is there time available in the backporch to read off 16 bytes from hub into cog ram?
Would it add much to the memory - eg 256x192 with 2 pixels per byte is 24576 bytes. Add 16 bytes per line = another 3072 bytes. Hmm - maybe pushing things for movies.
Or can one compromise a little - eg the tiles are 16 lines high, so you have a palette for each 16 lines. It should still optimise the picture, eg mostly sky at the top, mostly skin tones in a face. 12 tiles with 16 palettes = only another 192 bytes instead of 3072.
Or could you have a different palette for each 16x16 tile.
Or maybe it isn't worth the effort - the F-S transform is doing a pretty good job with the 16 standard windows colors with a variety of different images.
In any case, is the extra code needed to do the 256x192 driver the code needed to load in a palette and calculate the actual colors from two nibbles?
Thanks OBC - that is exactly what I was thinking of.
I wonder how this would go with various tile driver code examples.
Many thoughts racing around in my head at the moment - pushing F-S dithering to 256x96 with the (eagerly anticipated) driver. Pushing it to 256x240 with the tile driver (I resurrected that thread with an example of Mario at 256x240 with dithering) and color quantization. Or even crazy ideas like using external ram as a video buffer.
This is a quick circuit I drew up to brainstorm the idea of video ram.
Is this possible?
Ignoring the switching regs and the D9 and max232 (just my personal quirks), serial data comes in from another prop (or any chip really), 3 pins for TV, and 24 pins devoted to the ram chip. 64 x 8k blocks, and within an 8k blocks the propeller is controlling the memory chip pins directly, so it is as fast as possible.
Do you think this would be fast enough to read data for a 320x240 display?
Way back when the first RAM extensions started to appear we did a extensive tests with a Prop directly connected to an SRAM and we came to the conclusion that it is no good for video, the hub bottleneck is just too much. (If Baggers couldn't make it work then that's enough proof for me although we would love to be proved wrong )
I guess that is why there aren't any video RAM addons out there.
RE: Palettes and other stuff, Photoshop is FAR better than anything else out there but it costs an arm and a leg so my search for a low cost solution continues, I have a couple of commandline applications that we have managed to snag the sourcecode for so Baggers will be looking at them to see if they can be incorporated into BMP8TOLITE.
Well, I think it would be fill rate limited. The reason why the prop rocks on video is the various cogs can all hit the hub allowing for parallel operation. When there is external ram, that's off the table. At the least, it costs a cog to move the data to and from the RAM, and it takes time to move. So, it can be streamed, which can display a bitmap, but when streaming, addressing is hogged up, leaving only the blanking periods to update, which leads to the fill rate limit. Doing overlays on that is expensive too. Better to just use two propellers. (ask Jim about that)
(finally getting to setup a PropGFX)
You know, if it's color that is desired, we do have some options. Eric has written a pretty great NTSC driver that can do nearly 8 bit color. It's NTSC, but it's also one of the better color spaces we have. Horizontal resolution on something like that runs about 160 pixels though. Has to be a trade-off. Either resolution or color. He's also got a 228 pixel one with a very good, software driven color space. That particular driver hasn't been well exploited. A lot is possible.
IMHO, color is good at 160 pixels as many more shades can be done with NTSC. On the other hand, if advanced dithering is desired, I think a 320 pixel display, with palettes is the better way to go. All depends on the desired image quality and detail. On Props, we can do both. Low resolution - high color, or higher resolution, up to the limits of the TV, less color, more detail. Gotta pick one, or blend.
Comments
@Coley, A quick question while you guys are busy writing materials.
Could you provide the correct bmp8tolite.exe command lines for converting images or sprites to usable files under this release of PropGFX lite?
http://propellerpowered.com/?p=642
OBC
Attached is a screenshot of a 256x192 picture compressed with Floyd Steinberg compression using the standard Windows 16 color palette. (The story of the image is here http://en.wikipedia.org/wiki/Lenna)
Original at top left. 16 color palette top right. 256x192 with 16 colors bottom left. 256x96 with 86 colors and "tall" pixels bottom right.
Apologies for the large image file, but this needs to be a bitmap rather than a jpeg to retain the image quality.
I haven't got this onto a propeller yet as I need a little help from Baggers. Specifically;
i) Have you got the code for the 256x192 driver?
ii) Is the palette you are using similar to this palette?
iii) Do we need to color match this palette to the actual nearest colors on a propeller?
I'm looking forward to seeing this on a propeller TV, as one interesting thing is that the physical size of the picture on my computer is slightly larger than the actual TV, so I'm hoping that might blur some of the dithering.
See the fourth post on..
http://www.savagecircuits.com/forums/showthread.php?763-I-think-I-just-figured-out-PropGFX-sprites&p=5862#post5862
Edit: got some background loading as well now.
OBC
Got 16 color background with 16 color sprites.
http://www.savagecircuits.com/forums/showthread.php?763-I-think-I-just-figured-out-PropGFX-sprites&p=5870#post5870
OBC
I just modified your demo to include a bitmap ( 8 bit 128x96 )
Then I added your sprites and animated them
GFX_C64_Sprites3_V2.zip
More to follow......
Regards,
Coley
PropGFX_Lite_16_Col_Bitmap_Sprite_Demo-bst-archive-110725-225251.zip
If you look in the source you will see that I have moved the sprite data away from the normal location of $5000 to $1800 where there is 2K of free space. This limitation is due to memory constraints of 16 colour bitmap mode and we don't expect this mode to be used with sprites that much.
I've also uploaded a memory reference guide to PropGFX site.
Regards,
Coley
re my post #96, for the 256x192 driver, when you say there is a palatte of 16 colors, is that 16 colors in total for the whole display, or can you have a different set of 16 colors for each tile (eg select the 'best' 16 colors from the 86 colors available).
If yes, we could push the resolution further...
Dr_A,
The bitmap modes don't have attributes ( apart from the Spectrum modes and C64 modes )
However, the 4bit charmap mode does have attributes in the charmap area $1800-$1fff which holds the character number (0-1023) and in the bits (13-10) has the palette number (0-15)
I'll show Coley the how-to and he'll add it in his list of demo/examples.
As an aside, I have bought some LCD displays - a 3.5", a 4.3" and a 7" display. They are all very reasonable prices on ebay. The larger ones seem more 16:9 than 4:3 so might need some pre-processing to get the ratio right. (The simple way to do this is to start with a picture of a circle and check it ends up as a circle).
Does the the 256x192 fill the screen or does it have black bars at the top and the bottom?
It's not a driver as such but part of PropGFX Lite binary release. (Details in the top post of this thread)
I'll speak with Baggers about doing a demo and will post on here.
Re: LCD's it doesn't fill the screen there is a border all the way round the image.
Regards,
Coley
I'm very much looking forward to testing out the 256x192 code. The reason is that I think that 256x192x16 colors with Floyd Steinberg might hit a 'sweet spot' with respect to graphics.
Looking at a number of images, I think that 256x96 with 86 colors and 256x192 with 16 colors look very similar. But with twice the 'y' resolution, more things become possible.
In particular, with some scroll bars, this might be enough to build a reasonable web browser. See below for what Google would look like with 256x192, only 16 colors, and some F-S image manipulation on the "Google" text. Not too bad if you don't zoom in too close...
I'm thinking of what you need, and what we have.
1) Access to the internet. I think the spinneret can do this sort of thing.
2) Ability to parse html files. Certainly the simpler html files are just text and graphics. Text is easy. Graphics...
3) Ability to display bitmap files. Do a Floyd-Steinberg manipulation 'on the fly' on any bmp files. (I have that working in vb.net, so Spin and C ought to be possible) Convert .jpg to .bmp first (maybe a little harder).
4) The 'building blocks' of a web page - buttons, text boxes, different fonts. I have this working in Catalina C. Translate from html and put them on the screen.
5) Hardware. I have hardware that can run Catalina C with big programs up to 512k, and a new design (boards being make by BatchPCB) that ought to speed up XMM code by at least 10x.
6) Processing code. Most of the searches on Floyd-Steinberg came up with C code. I translated this to vb.net, and Spin would be possible too, but it will be even easier to drop it into Catalina C.
There must be some cool 'cloud computing' things this could open up - eg, rather than try to write a fancy word processor, there must be something out there on the internet that does the same thing. Particularly since small screen web browsing is becoming more popular due to mobile phones.
So many building blocks have been proven to work, or are very close to working.
Even Monet is not too bad at 256x192 with 16 colors.
Apologies for the enthusiasm, but I'm like a kid in a lolly shop waiting for this 256x192 code *grin*!
No worries, 256x192 charmap demo will be a little while I'm working on big scroller demo for OBC.
Oh btw, zooming in on the image is what prop does on a TV
Here's a demo of the 16colour charmap mode.
To grab a 8bit bmp for 16 colour mode, use :- Grab16 filename
I've done a fix to BMP8toLite too as it wasn't storing the palette in the map.
I've got Coley trying to find a free app that will convert an image into a palettised image creating 16 * 16 colour palettes for the image to keep each 8x8 in a 16 colour range.
I use ProMotion which isn't a free app, so we're trying to find a free alternative.
Cheers,
Baggers.
I tried the ProMotion 6.0 Demo and fought with it horribly. Just back to (free) Paint.Net and I was able to generate this in 30 seconds using your new version of Bmp8toLite.
OBC
I'm using the same palette as Dr_Acula (RGBI) otherwise I get scrambled colors.
Wow... I'm seriously impressed with that! I'll bet we could devise some really nice Propeller controls with that graphic.
Could you expand on how you are doing your conversion? (program wise) I'm a little lost with palette changing.
OBC
Jeff, I'm afraid that I'm as lost as you with palettes... In photoshop, I manually used "replace color" 16 times to ensure all the colors will fall in the auto-choosing range when I later switch from RGB color (24bit) to Indexed Color (forcing a fixed RGBI 16 color palette). Then save the image as 8bpp for bmp8toLite processing.
I think saving the BMP in 4bpp could be used for direct blits to gfx mode, since the RGBI order is mantained, and the BMP header can be simply skipped (once you manually set same palette).
The original graphics had orange and 2 more gray shades traded for light cyan and light/dark magenta. Still 16 colors, but slightly better visual result:
Anyone feel free to reuse the bits if you like.
While waiting on the 256x192 code I thought I would take a look at the video driver to see how things work. There is some commented out code and there is some code that is not used - eg the palette in the main driver is not used at all.
I was a bit confused by this until I realised that the palette numbers are pre-processed before being made into a picture or a movie, so the numbers in the picture are the actual palette bytes.
Taking a look at the video loop, I think this might explain this rather simple code
:xloop2 rdlong pixels,ptr add ptr,#4 xor pixels,phaseflip waitvid pixels,#%%3210 djnz x,#:xloop2 jmp #:doneWhich I think replaces some more complex code in "xloop" (commenting out xloop and it still worked).
So, take some color bytes, eg $02 and $07 etc, and with 86 colors, one byte per pixel, out they go with no processing.
But for 256x192, the bytes are going to need to be matched up to a palette, right? ie a 16 color palette
eg each byte now contains two pixels. So a pixel would contain a value, 0-15, which is matched to a palette.
That implies some processing in that video loop - ie read a byte, split off the high and low nibble, look up the palette byte value, output that byte.
If that is how it is working, then I am wondering where the palette information comes from.
Thinking forensically about how the code has evolved, this is the main startup code
tvparams long 0 'status long 1 'enable long modepins 'pins long mode 'mode long x_tiles 'hc long y_tiles 'vc long my_hx 'hx VSyncFlag long 0 nextline long 0 tvbitmapptr long @screen+$10 bordercolour long $02 long @palette+$10 'palette byte $02,$07,$28,$8d,$ba,$1a,$db,$3d,$8f,$5f,$3f,$5b,$d8,$04,$02,$02 screen byte $1b[256*96] 'file "title.bit"with the palette commented out as expected.
But - if we need the palette put back in again for 256x192, does that palette have to be fixed (red, green, blue, black, gray etc), or can it vary?
Specifically, the values for a palette could exist locally in cog ram. But equally, could it be possible to read out a new palette every scan line? That palette could be incorporated into the picture.
If so, is there any reason why you could not optimise each line in the picture for the 'best' palette of 16 colors, eg for sky, mostly white, grays and blues.
Is there time available in the backporch to read off 16 bytes from hub into cog ram?
Would it add much to the memory - eg 256x192 with 2 pixels per byte is 24576 bytes. Add 16 bytes per line = another 3072 bytes. Hmm - maybe pushing things for movies.
Or can one compromise a little - eg the tiles are 16 lines high, so you have a palette for each 16 lines. It should still optimise the picture, eg mostly sky at the top, mostly skin tones in a face. 12 tiles with 16 palettes = only another 192 bytes instead of 3072.
Or could you have a different palette for each 16x16 tile.
Or maybe it isn't worth the effort - the F-S transform is doing a pretty good job with the 16 standard windows colors with a variety of different images.
In any case, is the extra code needed to do the 256x192 driver the code needed to load in a palette and calculate the actual colors from two nibbles?
http://en.wikipedia.org/wiki/Color_quantization
Photoshop appears to be a good way to handle this. (Not free unfortunately)
OBC
I wonder how this would go with various tile driver code examples.
Many thoughts racing around in my head at the moment - pushing F-S dithering to 256x96 with the (eagerly anticipated) driver. Pushing it to 256x240 with the tile driver (I resurrected that thread with an example of Mario at 256x240 with dithering) and color quantization. Or even crazy ideas like using external ram as a video buffer.
Paste the image into Photoshop, resize, Mode:Index color, save as .BMP.
I'll see if I can find a way to create a simple slide show for these. I've got a bunch of images that look great!
Edit: Make sure your images are 96dpi. I was getting some flickering because Photoshop jumps to 71dpi.
OBC
Is this possible?
Ignoring the switching regs and the D9 and max232 (just my personal quirks), serial data comes in from another prop (or any chip really), 3 pins for TV, and 24 pins devoted to the ram chip. 64 x 8k blocks, and within an 8k blocks the propeller is controlling the memory chip pins directly, so it is as fast as possible.
Do you think this would be fast enough to read data for a 320x240 display?
Way back when the first RAM extensions started to appear we did a extensive tests with a Prop directly connected to an SRAM and we came to the conclusion that it is no good for video, the hub bottleneck is just too much. (If Baggers couldn't make it work then that's enough proof for me although we would love to be proved wrong
I guess that is why there aren't any video RAM addons out there.
RE: Palettes and other stuff, Photoshop is FAR better than anything else out there but it costs an arm and a leg so my search for a low cost solution continues, I have a couple of commandline applications that we have managed to snag the sourcecode for so Baggers will be looking at them to see if they can be incorporated into BMP8TOLITE.
Regards,
Coley
(finally getting to setup a PropGFX)
You know, if it's color that is desired, we do have some options. Eric has written a pretty great NTSC driver that can do nearly 8 bit color. It's NTSC, but it's also one of the better color spaces we have. Horizontal resolution on something like that runs about 160 pixels though. Has to be a trade-off. Either resolution or color. He's also got a 228 pixel one with a very good, software driven color space. That particular driver hasn't been well exploited. A lot is possible.
IMHO, color is good at 160 pixels as many more shades can be done with NTSC. On the other hand, if advanced dithering is desired, I think a 320 pixel display, with palettes is the better way to go. All depends on the desired image quality and detail. On Props, we can do both. Low resolution - high color, or higher resolution, up to the limits of the TV, less color, more detail. Gotta pick one, or blend.