OpenEuphoria

2. Re: TGA image format

• Posted by Mike.Burrell at GEOCITIES.COM Jul 16, 1997
• 622 views

> I have nearly finished a TGA loader / saver which works the same way as the
> BMP loader does - If any of you out there have writen any colour reduction
> code perhaps we could exchange notes.

well maybe you should look at my post a day or so ago...  i was
thinking of using fake hi-colour (18-bit colour using 256 colours)...
the algorithm would look something like this and would only work
(saddly) if the picture was 24-bit true-colour:

set palette 0 to black
set palette 1 through 64 to red (with the corresponding red value,
   going from black to bright red)
palette 65 through 128 would be green (same idea) and palette 129
through 192 would be blue (again)
palette 193 through 255 would not be used

divide each rgb value in the picture by 4, so that where it once
ranged from 0 to 255 it would now range from 0 to 63.75 (or 63 for
our purposes)

go through the bitmap like you would, scanning each pixel of EVERY
THIRD ROW (yes this would mean you would get one third the original
resolution)...

suppose the rgb value of this particular pixel you were looking at
(say it was at (5,3)) had an rgb value of (62,29,34)...  we're
looking at a picture from mars or something :)
put a pixel at (5,3) with colour 62 (representing red value 62)
put a pixel at (5,4) with colour 29 (representing green value 29)
put a pixel at (5,5) with colour 34 (representing blue value 34)

of course you come across a value of 0, just plop down a 0 (black)

the problem with this of course is that you get one third the
quality...  you could get around this...  if the picture was small
enough and your screen was big enough, you could blow it up...  this
probably won't happen often however (especially considering the
common uses of targa bitmaps)

another way is as follows:
we're still at (5,3) which still has an rgb of (62,29,34), so at
(5,3) we put a pixel with colour 62 (to represent the red)

now instead of skipping the next 2 lines in the file, we read EVERY
LINE

so let's say we plot all our other pixels on line 3 and we're back to
(5,4) now..  before we would have plotted the green value from (5,3),
but instead, we now plot the green value from (5,4)...  at (5,5) we
plot the blue value from (5,5)

so in conclusion we're still using 256 colours (or 192 actually)
which is why it isn't so great...  this idea may not sound so great
on paper when you see it in real life (even with resolutions as low
as 640x480) it looks okay...  it looks kind of like watching a big
screen TV...  you can notice the scan lines but somehow it still
looks like a picture

now there is a variation on this...  instead of taking up 3 pixels
(red, green and blue) to draw a pixel, we can use 2 pixels to do the
same thing (yellow and blue; cyan and red; magenta and green)...
however the problem with this method is that instead of having 64
scales of red, blue and green, you would only have approx 15

the way you would do this is by setting a for loop like this (this is
assuming you're using the yellow/blue method):

for red = 0 to 14 do
  for green = 0 to 14 do
    if atom(palette(green * 15 + red,
      63 / 14 * {red,green,0})) then
      -- uh oh we have an error
      -- btw the reason i multiply by 63 / 14 is so that even though
        -- we only have 15 shades, the brightest shades will still
        -- have a value of 63
    end if
  end for
end for
-- the
for blue = 1 to 30 do
    if atom(palette(blue + 225, 63 / 30 * {0,0,blue})) then
      -- uh oh an error
    end if
end for

now if you had a pixel of rgb value (63,29,34) to plot at (5,5) we
would do it like this:
at (5,5) we would plot
   floor(r * 63 / 14) * 15 to get the red value (which turns
      out to be 14 * 15 which is 210 i think

   PLUS

   floor(g * 63 / 14) and i have no clue what that comes out to be
      (let's say it's 6)

so at (5,5) we plot 210 + 6 = 216 (red * 15 + green = 216)

then at (5,6) we would plot the blue value:
   floor(b / 63 * 14) + 225 which comes out to be about 7
so at (5,6) we plot 232

and the end result is maybe better maybe worse i'm not sure...
anyway this message went on longer than i thought it would heh...



 .   o   O  Mike Burrell  O   o   .
.  o O burrellm at geocities.com O o  .
  .  o  O mikpos.base.org O  o  .