Visit Atarimax Store


Free-Net Logo
The Atari SIG Historical Archive
Created and hosted by: atarimax.com
[ HOME | GO ATARI | 8-BIT | ST/TT | PORTFOLIO | LYNX | JAGUAR | LIBRARY ]


Article #28 (51 is last):
From: aa700@cleveland.Freenet.Edu (Michael Current)
Newsgroups: freenet.sci.comp.atari.product.8bit.tricks
Subject: ColorView files
Reply-To: aa700@cleveland.Freenet.Edu (Michael Current)
Posted-By: xx004 (aa700 - Michael Current)
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





Visit Atarimax Store