ColorView files
From: Michael Current (aa700@cleveland.Freenet.Edu)
Date: 03/23/93-09:55:12 AM Z
From: aa700@cleveland.Freenet.Edu (Michael Current)
Subject: ColorView files
Date: Tue Mar 23 09:55:12 1993
From: phbill@cyberden.sf.ca.us
"The general way of viewing ColorView files."
By Bill Kendrick, NBS 1993.
ColorView files:
ColorView mode is a 4096 color mode generated on the Atari Classic
line
of computers. It was created by Jeff Potter in a program called
"ColrView"
which is used in conjunction wit a GIF viewer called "APACView" (which
originally used a different, 256 color screen mode created by him as
well).
It is done by viewing three 16 color screens "simultaneously." These 16
color screens are in 80 x 192 resolution (not exactly high for today's
standards), and are simply part of the Atari's built-in graphics modes.
This 80 x 192 x 16 mode supports 16 shades of a specified color. This
has come in handy with ColorView, because by using three screens, one
being red, the second green, and the third blue, the Atari simulates 4096
true colors. (Another great advantage to ColorView modes was what it was
originally made for: viewing GIF files. GIF files store their palettes'
colors as red/green/blue values, so a program that converts GIFs into
Color-
View files only needs to know how to read the "RGB" palette and
uncompress
the image.)
ColorView files are really made of three files. (Actually, this is
really just the standard created by the inventor of ColorView, Jeff
Potter.)
The three files all have the same filename (8 characters), and have
extenders of ".R", ".G", and ".B" (for "red", "green", and "blue.")
Now that you know how ColorViews are viewed and stored, all you need to
know is how to read in the intensity values from each file. (These will
be 0 to 15 (16 shades of each color), so you have a total of 12-bits of
color on the screen, so if you're using a graphics mode on your system
that
can't handle that much, you'll have to just drop some of the lower bits.
(The number of bits of color of just one of the screens alone is 2^4=16,
so
a whole ColorView image uses (2^4)x(2^4)x(2^4)=4096, three sets of 4
bits=12!
The closest one can get in an 8-bit color mode (which is more or less
"standard VGA") would be (2^8)=256 colors! Converting a 4096 color value
to a 256 color value would mean dropping some bits. One way someone can
overcome this is to use dithering by drawing the actual red, green, and
blue
pixels onto the screen! (not just drawing a pixel with the blended color)
In this case, you're only using three sets of 16-colors which is only 48,
so
the palette size is greatly reduced, but the image quality is lower. One
of
the reasons I mentioned this is because compared to a normal (320 x 200 x
256)
VGA screen, ColorView (80 x 192 x 4096) has pixels 4 times as wide.
Alright, now the format of the single files... Each file is
composed
of an uncompressed 80 x 192 x 16 image, so each line is 40 bytes wide
(16 colors takes only 4 bits, or 1/2 a byte, so each byte represents >2<
pixels). The actual byte size of the file is 40 x 192 = 7680 bytes.
Let's look at it binarily:
76543210 <- bit positions. The decimal values derived from these are
really just 2^position, so the if only the leftmost bit was
on,
the decimal value of that byte would be 128. If the
rightmost
bit only was on, it'd be 1. If both the left and right were
on,
it'd be 129, if all were on, it'd be 255, and if all were
off,
it'd be 0!
10000000 <- 128
00000001 <- 1
10000001 <- 129
11111111 <- 255
00000000 <- 0
Now, remember, each byte represents >2< pixels, each having a value
(representing brightness) of 0 to 15. The leftmost (high) 4 bits are the
left pixel, and the rightmost (low) 4 bits are the right pixel.
11111111 <- 255
1111 <- left (these 4, being high, represent 240)
1111 <- right (these 4, being low, represent 15)
11001001 <-
1100 <- left (these 4, being high, represent 192 (128 + 64))
1001 <- right (these 4, being low, represent 9 (8 + 1))
Well, we've just found out that the highest 4 bits are WAY too high.
Fortunately, all we need to do is divide the value by 16 to get the
brightness value (which will be 0-15)!!!
Simple. Now, how does one go about splitting a byte up into two high/low
values? Just use "binary AND" (what represents it all depends on what
language you're using).
"AND" the byte with "240" (all left bits on) to get the left bits all
alone.
"AND" the byte with "15" (all right bits on) to get the right bits all
alone.
Simple example:
---
Open red file for read
Open green file for read
Open blue file for read
Set up screen (320 x 200 x 256 or more colors prefered)
Set up palette
Set X,Y coordinates to (0,0)
Repeat:
Get next from red file
Binary AND the red value with 240
Divide it by 16
Set the color to that intensity of red
Plot at X,Y
Binary AND the red value with 15
Set the color to that intensity of red
Plot at X+(one-80-column-pixel),Y
Get next byte from green file
Binary AND the green value with 240
Divide it by 16
Set the color to that intensity of green
Plot at X,Y
Binary AND the green value with 15
Set the color to that intensity of green
Plot at X+(one-80-column-pixel),Y
Get next byte from blue file
Binary AND the blue value with 240
Divide it by 16
Set the color to that intensity of blue
Plot at X,Y
Binary AND the blue value with 15
Set the color to that intensity of blue
Plot at X+(one-80-column-pixel),Y
Increase X by two 80-column pixels (which would be "8" VGA pixels)
If X is past the right edge of the screen Then:
Set X to 0
Increase Y by 1
End-If
Until you've read 7680 bytes
---
The end. Need any help? Contact Phbill.
(Phbill@Cyberden.SF.CA.US)
-----------------------------------------------------------------------
--
Michael Current, Cleveland Free-Net 8-bit Atari SIGOp
Carleton College, Northfield, MN, USA / UUCP: ...!umn-cs!ccnfld!currentm
Internet: currentm@carleton.edu / Cleveland Free-Net: aa700
-----------------------------------------
Return to message index
