APAC 256 color mode 80x240 'interlaced': has this been done?

[Synthpopalooza]

Think I read somewhere, that the Gr.10 shift happens, if you first switch to Gr. 8 and then to Gr. 10 (or first to Gr. 10, then to Gr. 8 and back again to Gr. 10), not sure if thats true. The end result is the pixel shifting, giving a resolution of 160x200 / 160x239 pixels instead of the normal 80x pixels. This pixel-shifting seems only to happen in Gr. 10 and not in the other GTIA modes 9 and 11. Maybe someone wants to try Gr. 10+11 with Gr. 10 shift active for 160x200 or 160x239 pixels resolution, Gr. 10 giving 8 different lumas like 0,2,4,6,8,10,12,14,0 (where 0 = black and 14 = white); and Gr. 11 giving 16 colours. This would result in 8 lumas x 16 colours =128 colours in 160x200/239 resolution. (Yes, I always ask for this, because I would like to see the result and compare it to RIP with Gr. 10+9).

 

-Andreas Koch.

It's actually 9+10 for HIP ... the shift also happens when you use a non gtia mode like 8 or 15, which can get you the resolution of the non-gtia mode, but you would need to shift the 8 or 15 mode one color clock to the right manually to make the display line up.

 

As for mode 10+11: I did this myself in my ICE text mode experiments (a mode I named CHIP) ... it's decent, but the resolution is not as sharp as in RIP (9+10 with color chromas for 10) ... the problem is that all of the lumas in mode 11 are the same, so the added horizontal resolution is not as apparent except when the graphics are atop a black background.

 

Here some example pictures I did in this mode ... to give you an idea:

 

 

As you can see, it is very difficult to make out the shifted pixels, unlike HIP mode.

 

Some of these used a color render of the Graphics 10 part instead of monochrome. While not as sharply defined, these tended to flicker less than CHIP pictures using greyscale in mode 10, and they also brought in some subtle color gradients which closely matched the original. One other problem in this mode, is that you can't do greys, unless you blend colors from opposite sides of the color wheel (purple+green, red+cyan, blue+yellow).

Edited September 27, 2013 by Synthpopalooza

[Joey Z]

Here is a Pic I did: I am pleased with the results, although I did have some complications with the converter and I needed to convert it with an NTSC palette for it to look right. corners look a bit dark because of the rear projection TV, and there might be a spot from a spider lurking around behind the screen

[+Stephen]

Here is a "labour of love" The ATR contains 37 images. Below is a sample so you know what to expect. PLEASE NOTE - it is in a spoiler tag for a reason! UFC fans rejoice.

Click for the goods

 

 

 

 

Here is an ATR of the viewer with all 37 images.Ariani Cleste BGP Viewer.zip

[Irgendwer]

Could it be that your version is the once commercially sold program Digi-Paint or what else is the source ?!? This is no rhetoric question, I am asking seriously for an answer, because my original Digi-Paint diskette does not work and nowadays this disk seems hard to find (and I have no clue whats on the Digi-Paint disk).

 

No, even it looks a little bit like a rip-off and uses the same interlaced mode, 'Digi-Paint' is a different program. Maybe your disk does not work because the application is very sensible to drive speeds? It ran on my 'Speedy' only in 'Slow'-Mode and the attached ATR starts only correct in the emulator if SIO-Patches are off and accurate timing is on! After the program is up and running you can enable the patches again, otherwise you're getting old while loading/inspecting the (test-)images...

Warning! Some of the pic disks may contain blood pressure rising content!

DigiPaint.zip

[+CharlieChaplin]

It's actually 9+10 for HIP ... the shift also happens when you use a non gtia mode like 8 or 15, which can get you the resolution of the non-gtia mode, but you would need to shift the 8 or 15 mode one color clock to the right manually to make the display line up.

 

As for mode 10+11: I did this myself in my ICE text mode experiments (a mode I named CHIP) ... it's decent, but the resolution is not as sharp as in RIP (9+10 with color chromas for 10) ... the problem is that all of the lumas in mode 11 are the same, so the added horizontal resolution is not as apparent except when the graphics are atop a black background.

 

Here some example pictures I did in this mode ... to give you an idea:

 

As you can see, it is very difficult to make out the shifted pixels, unlike HIP mode.

 

Some of these used a color render of the Graphics 10 part instead of monochrome. While not as sharply defined, these tended to flicker less than CHIP pictures using greyscale in mode 10, and they also brought in some subtle color gradients which closely matched the original. One other problem in this mode, is that you can't do greys, unless you blend colors from opposite sides of the color wheel (purple+green, red+cyan, blue+yellow).

 

 

Oh,

how sad, I thought Gr. 10+11 (or 11+10) would give much better results. Some of the pics, e.g. Terminator, the three landscapes, look almost like pure Gr. 11 pics, you don`t see the 8 lumas from Gr. 10 very good. So I am wondering is it really Gr. 10 (only greyscales, used as luminance only mode and for the higher resolution / pixel-shifting of course) mixed with Gr. 11 ?!? If so, then the result is much worse than I thought and Rybags was right that more lumas (Gr. 9+10) give a much better result than more chromas (Gr. 11+10)...

 

@Irgendwer: Thank you very much for uploading the Digipaint disk-image ! Maybe my disk is not defect, but it just does not like the 1050 with Speedy upgrade in standard speed (the disk is not protected it seems, I could make copies easily) and therefore it does endless coldstarts after a few seconds. Will test my original disk again with Speedy in slow-mode and see what happens then...

 

It also looks like Paint 256 (from Happy Computer), Digi-Paint, Escal-Paint, Pryzm and maybe a few other programs all use the same Gr. 9+11 standard: 123 sectors in length, 80x192 pixels resolution via interlace/interleave (flicker-mode)...

 

Last not least, I attach a viewer/fader program for "my" 256-colour pictures in dutch Paint-256 Format (by A.Slaager, 62 secors / 7680 bytes). Maybe someone can patch it for the other 256-colour formats like

a) Digi-Paint, Escal-Paint, Pryzm, Paint 256 (Happy Computer) which all have a length of 123 sectors on disk and interlace/interleave or

b) the new BGB format with 154 sectors on disk, interlace/interleave and over/underscan which is the topic here...

 

-Andreas Koch.

ESCPAINT.zip

PRYZMART.zip

FADE256.zip

Edited September 27, 2013 by CharlieChaplin

[bugbiter]

Here is a "labour of love" The ATR contains 37 images. Below is a sample so you know what to expect. PLEASE NOTE - it is in a spoiler tag for a reason! UFC fans rejoice.

Your pics are running in an endless loop for the millionth time on my PAl crt and I'm beginning to think that your dithering algorithm gives better results than mine. Less colour speckles. How did you do it? can't wait to see your code...

[Synthpopalooza]

Oh,

how sad, I thought Gr. 10+11 (or 11+10) would give much better results. Some of the pics, e.g. Terminator, the three landscapes, look almost like pure Gr. 11 pics, you don`t see the 8 lumas from Gr. 10 very good. So I am wondering is it really Gr. 10 (only greyscales, used as luminance only mode and for the higher resolution / pixel-shifting of course) mixed with Gr. 11 ?!? If so, then the result is much worse than I thought and Rybags was right that more lumas (Gr. 9+10) give a much better result than more chromas (Gr. 11+10)...

All of the pictures are of Graphics 10 in color + 11 in color, excepting the nude pic in the top right which uses Graphics 10 in monochrome, so it probably gives you a better idea. It's not completely useless, in that you can get the extended resolution outline if the graphics are overlaid on a black background ... I have even designed a 6x8 ICE font in this mode, using this technique.

[+CharlieChaplin]

All of the pictures are of Graphics 10 in color + 11 in color, excepting the nude pic in the top right which uses Graphics 10 in monochrome, so it probably gives you a better idea. It's not completely useless, in that you can get the extended resolution outline if the graphics are overlaid on a black background ... I have even designed a 6x8 ICE font in this mode, using this technique.

 

 

Ah ok,

 

but as said before I want Gr. 10 for the higher resolution (pixel-shifting) and as greyscale/luma only, so instead of nine different colours we should have nine greyscales/lumas (but only eight of them are different, thus luma 1 and luma 9 should both be black). Gr. 11 should do the colors so we end up with 16 colours (Gr.11) x 8 lumas (Gr.10) = 128 colours in 160x239 pixels resolution. Maybe you can do some more experiments with this mode and post some screenshots here... -Andreas Koch.

Edited September 28, 2013 by CharlieChaplin

[a8isa1]

Fun stuff! Thanks bugbiter!

 

 

Some more pics and the .BGP files here. NTSC only (OlivierN.act palette). Sorry.

 

I use ImageMagick (linux version) to prepare file for bugbiter's converter like this

 

convert -resize 80x239\! -flip sourcefile target.bmp3

 

The 'bmp3' extension tells ImageMagick to use BMP version 3. No details for this were offered in the ImageMagick documentation but this is the type that was suitable for bugbiter's converter.

 

 

[Synthpopalooza]

 

 

Ah ok,

 

but as said before I want Gr. 10 for the higher resolution (pixel-shifting) and as greyscale/luma only, so instead of nine different colours we should have nine greyscales/lumas (but only eight of them are different, thus luma 1 and luma 9 should both be black). Gr. 11 should do the colors so we end up with 16 colours (Gr.11) x 8 lumas (Gr.10) = 128 colours in 160x239 pixels resolution. Maybe you can do some more experiments with this mode and post some screenshots here... -Andreas Koch.

 

Actually, luma 9 will be a greyish value ... as the brightness of register 712 controls the luminance of Graphics 11 in text mode, it is easier to leave this unchanged and just use 0-7 for the eight lumas.

 

I'll try to work up some demo pictures tonight ...

 

The thread here has a demo that I did using the CHIP (10+11) character mode to display a text demo screen, it shows you sort of what the strengths of this mode are. The characters look good against a black background, you can see the 160 resolution. But each group of two pixels uses the same luminance so the resolution is fuzzier.

 

http://atariage.com/forums/topic/152012-chip-and-hip-text-demo-and-font/?p=1860478

 

[bugbiter]

Fun stuff! Thanks bugbiter!

 

Some more pics and the .BGP files here. NTSC only (OlivierN.act palette). Sorry.

 

I use ImageMagick (linux version) to prepare file for bugbiter's converter like this

 

convert -resize 80x239\! -flip sourcefile target.bmp3

 

The 'bmp3' extension tells ImageMagick to use BMP version 3. No details for this were offered in the ImageMagick documentation but this is the type that was suitable for bugbiter's converter.

Thanks a lot! great pics.. luckily I have an ntsc 1200 xl and monitor :-)

[+CharlieChaplin]

 

Actually, luma 9 will be a greyish value ... as the brightness of register 712 controls the luminance of Graphics 11 in text mode, it is easier to leave this unchanged and just use 0-7 for the eight lumas.

 

I'll try to work up some demo pictures tonight ...

 

The thread here has a demo that I did using the CHIP (10+11) character mode to display a text demo screen, it shows you sort of what the strengths of this mode are. The characters look good against a black background, you can see the 160 resolution. But each group of two pixels uses the same luminance so the resolution is fuzzier.

 

http://atariage.com/forums/topic/152012-chip-and-hip-text-demo-and-font/?p=1860478

 

chip demo.png

 

Ooops,

 

you misunderstood or better I was unprecise. I just wanted to say instead of nine colours (standard for Gr. 10) use nine greyscales/lumas. Now Gr. 10 normally has nine colours, but if you use greyscales in Gr. 10 it has only eight *different* greyscales (one is doubled and I wanted to have black doubled). So lets say we use nine greyscales/lumas in Gr. 10, then like this:

1st greyscale/luma: x0 - black

2nd greyscale/luma: x2 - very dark grey

3rd greyscale/luma: x4 - dark grey

4th greyscale/luma: x6 - grey

5th greyscale/luma: x8 - grey

6th greyscale luma: xA - light grey

7th greyscale/luma: xC - very light grey

8th greyscale/luma: xE - white (or almost white)

9th greyscale/luma: x0 - black

Instead of luma 9 I should have written 9th luma, maybe. (Besides, if we only use lumas 0-7 the picture will be very dark I guess, not sure how the picture looks like if we use only the even lumas from 0 to 14 or 0 to E as shown above.)

 

Anyways, waiting to see some demo pics in this Gr. 11+Gr. 10 mode (where Gr. 10 is luma/greyscale only), hopefully it will not be a big disappoinment. -Andreas Koch.

[+Stephen]

Slight upgrade to my PC image convertor. I now have a user selectable option for a slightly better colour distance algorithm (it is a weighted RGB function, courtesy of http://www.compuphase.com/cmetric.htm). Is it slightly slower (515ms vs 345ms for a dithered image). The next two features I want to add are a dithering "strength" slider, and the ability to choose multiple files and do bulk conversions. When I get that working, I am considering adding an option to somehow help keep the aspect ratio closer. I will most likely just force black bars and center the image.

 

Also, I am curious to see how the proposed 11+10 mode images will work out.

 

Anyhow - here's 5 new images:

[bugbiter]

WOW-these look very good!

 

You seem to really dig deep into colour theory! Thanks for the link, thats really advanced stuff!

The orthogonal colour distance I really worked out myself, nice to see it here again :-)

 

I haven't read through all the link's content. One Idea that I came across earlier already is that it might be better to deal with a source BMP in HSB(hue,saturation,brightness) colourspace rather that rgb.

 

The dithering algorithm handles the three channels completetly independant from each other, meaning that a dithering 'spot' will occur once in a while in R or G or B individually, leading to those colour 'speckles' especially in almost grey areas.

 

If you use a hsb model, you dont get red blue or green dithering 'speckles' but the color dithering will just shift the hue into an adjacent colour occasionally which might look better.

 

 

Most pics (specially the pinups :-) are in portrait mode, so there is need for a ratio handling. Of course you can always crop a bmp to 'landscape' before converting, but automatically fitting it to size is very cool.

 

Filling the border with zeroes in the border is just fine now but in the long term I feel the urge we should not just pad the picture out but make a bgp pic with a genuinely smaller x resolution and set it into the center in the viewer. (save disk bytes and loading time)

If you look at my header configuration you will see that the first header double bytes after the 'mgic string' include the x/y size and an x/y position for the bgp pic. I was trying hard to put as much useful information into the header to begin with.

 

Only my viewer doesnt use the size and position info yet. But I will add it some time :-)

 

I'd really like to make the header guarantee backward compatibility with future improvements. Thats why I also added the 'auxbyte'-block in the header which is just being skipped now but could hold further infos in the future. For example I think the header should also keep infos about which source pic was used and how and with which parameters it was converted..

 

Any suggestion about this are very welcome, I'm working this all out myself for the first time now, maybe there's a better way?

[a8isa1]

Slight upgrade to my PC image convertor. I now have a user selectable option for a slightly better colour distance algorithm (it is a weighted RGB function, courtesy of http://www.compuphase.com/cmetric.htm). Is it slightly slower (515ms vs 345ms for a dithered image). The next two features I want to add are a dithering "strength" slider, and the ability to choose multiple files and do bulk conversions. When I get that working, I am considering adding an option to somehow help keep the aspect ratio closer. I will most likely just force black bars and center the image.

 

Also, I am curious to see how the proposed 11+10 mode images will work out.

 

Anyhow - here's 5 new images:

MulletsRock.pngMushroom.png

Rage.pngHypnotic.png

BGNeon.png

Why do you have a self-portrait and psychedelic pictures?

[AtariGeezer]

Why do you have a self-portrait and psychedelic pictures?

Why not? they show a wide variety of colors They look cool to me

[a8isa1]

bugbiter, seeing the 800 is the only working A8 I have to use at present I was hoping your viewer would work under FrOst BASIC 1.4.

 

Your program loads fine. However it crashes after displaying the memory information, It then displays the word "Error" without any number/description.

 

I don't know enough about APAC, TurboBASIC XL nor FrOst BASIC to even begin troubleshooting the problem. I'm guessing it's a memory issue.

 

Here's an ATR altered from a FrOst BASIC ATR, in the case you or someone else would like to try. I think the original ATR is straight from the Holmes collection. The sample programs were removed to make room for a couple of BGP pictures files and your viewer program.

 

Sorry, since your viewer is named AUTORUN.BAS on your ATR I didn't know its real name. I simply called it BGPVIEW.BAS.

 

I couldn't figure out which DOS is used on the FrOst BASIC ATR. DOS functions and FrOst BASIC are simply merged into one big DOS.SYS file.

 

I used SDX 4.46 and Atari800 emulator to edit the contents of the ATR. I can't guarantee that I did no harm in the process. I did save your program to H: from FrOst BASIC and load it back in TurboBASIC XL and it ran

 

 

frost_test.zip

[a8isa1]

Why not? they show a wide variety of colors They look cool to me

I was just ribbing Steve

[bugbiter]

a8ia,

 

I have an 800 myself and I know the current version will not run under 48K simply because there is too little memory left with frost basic.

The Atari Basic module gives you enough free user memory but the loader makes great use of the turbo basic features (Bload etc). I am currently working on substituting these routines with assembler so it is possible to get a working 48 version soon.

 

If you can't wait i can dig up one of the earlier versions which run with 48 k but it wont have the menu based loader though...

 

I love my 800 and I want to have it the bgp loader also :-)

[Creature XL]

Awesome!

 

well, youll probably need the source code for the colourmatch routine.

Ive still got the slow basic colourmatch routine somewhere as well..

 

The math is trivial. For each pixel you just compare all 256 palette entries from the laoo.act palette file to the original bmp rgb color.

The distance of these two colours in rgb colourspace is sqrt(delta_red^2+delta_green^2+delta_blue^2) the colour with the smallest distance to the original one is chosen. (as we are just looking for the smallest distance you can as well skip the square root and thus save time..)

Add floyd-steinberg dithering and youre done.

 

If youve got any questions, I'm here :-)

 

AFAIK that is not the "best" solution.

 

The A8 doesn't use RGB. Therefore, the RGB values of the palette file are just approximation (or: projection).

It would be better, to work in the HSV color space.

The Hue is given by the color value of the atari palette (1-15) and the Value is given by the lumminace (0-15) or {0,2,4,6,8,10,12,14} for non-GTIA modes.

 

EDIT: Just read further into the thread and saw you realised it already

Edited October 7, 2013 by Creature XL

[bugbiter]

 

AFAIK that is not the "best" solution.

 

The A8 doesn't use RGB. Therefore, the RGB values of the palette file are just approximation (or: projection).

It would be better, to work in the HSV color space.

The Hue is given by the color value of the atari palette (1-15) and the Value is given by the lumminace (0-15) or {0,2,4,6,8,10,12,14} for non-GTIA modes.

 

EDIT: Just read further into the thread and saw you realised it already

Hi!

 

my first approach was exactly like youre saying. I thought I could just make a greyscale pic of the bmp of luminance and one of the chrominance and voila, i could display that easily because gr. 9 is lum and gr.11 is chroma, but it didnt look right.

Firstly, high lumina colors on the atari are all nearly white, i.e. they have low saturation. A high intensity red for example has 100% lumina, 100% saturation and chroma 1 on the pc bmp file.

You translate that to chroma 3 (red) on the atari and luma 15 and what do you get? Not at all a pure red but nearly white. So I tried all sorts of correction curves, to give all the pure colors lower max luminas, and turn all the lower saturated areas to grey (chroma 0), but the results were not satisfactory...

Then I had the idea of comparing bmp rgb values to the atari pallette and that was the breakthrough. HSB model I think will get better results with dithering. But the palette files are all in rgb.....

[Creature XL]

First of all, sorry if I tell you stuff you already know. But I am short on time so I just put my thoughts out here:

 

I think when I said "HSV space" I really ment "YUV space". That is the space PAL and NTSC work in and this is what GTIA generates.

 

I think the theoretically correct solution would be to first transform each pixel from the RGB-space to the YUV-space.

After that you have to map the YUV vector to the ANTIC color values.

 

Something like this (C64) but for the A8 would be helpful

 

 

I have never looked deeper into it, but its a topic that interests me. However, with a very low priority.

Popmillio fiddled around with this kind of stuff for his PAL-blending converter AFAIK.

 

All I can say is that using RGB is not the best way. Because hue and luma values are distributed to all three components (RGB).

If you compare the BMP-RGB vector with the palett-vector the vector with the minimal difference represent a totally different hue where the slightly bigger distance could represent the perfect view with another saturation. And I think matching the hue is very important.

 

What I have read so far, most emulators for C64 and A8 switch from RGB palettes to color generation via YUV. MAy Phareon can say more about that topic.

Edited October 8, 2013 by Creature XL

[Rybags]

Agreed it's better to deal with YUV initially. At the least when the final conversion to RGB or a palette translation via emulation takes place, it's more likely that same colours of differing luma will gain the same conversion.

 

I've dealt with doing conversion back/forth using Photoshop and similar and they have an annoying habit of assigning colours that can be way off what you expect.

 

One way to make it more accurate I found was to increase the saturation on the source picture, at the least with that you're less likely to get missed assignments to shades of white.

The palette you use makes a difference as well. The problem that can arise is Pal/NTSC differences, the particular annoyance there is that you often get reds assigned to colour 4 which is definately not red on Pal, and sometimes greenish blues get assigned colour 10 which on Pal is definately green with a very small hint of blue.

[+Stephen]

Thanks for the hints - I am definitely interested in adding more options to the convertor, as far as different colour spaces go.

[+CharlieChaplin]

And err,

 

original blue colour often turns into violet or purple colour on PAL machines...

 

-Andreas Koch.