Re: 8 bit values in mode 13h?
From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 10/21/03
- Next message: Alex McDonald: "Re: assembler testing tool"
- Previous message: wolfgang kern: "Re: The Microsoft Way (OT)"
- In reply to: JGCasey: "8 bit values in mode 13h?"
- Next in thread: JGCasey: "Re: 8 bit values in mode 13h?"
- Reply: JGCasey: "Re: 8 bit values in mode 13h?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 21 Oct 2003 15:03:34 +0100
JGCasey wrote:
> Beth wrote:
> > ...it's perfectly possible to set any colour
> > index to represent any colour from a stupidly large palette (three
> > primaries from 0-63 each...64^3 = 262144 colours...note that
modern
> > video cards actually have 0-255 (8-bit) for each primary and it is
> > possible to switch this on to get the same massively large choice
of
> > colours as 24-bit colour modes - though only 256 of them can be
> > on-screen at once - but the VGA was originally only 6 bit, not 8
bit
> > and the program you've got here uses the VGA in its 6-bit mode, as
it
> > originally was)...
>
> How can I turn on the 8-bit values in mode 13h ?
Well, I confess to not actually having done it myself - rather just
hearing about it being possible and seeing the option listed in
documentation - because I usually strive for "compatibility" when VGA
programming...
And the problem with this is that it's a "non-standard" thing...an
8-bit rather than 6-bit DAC can be enabled in these VGA 256 colour
modes but it's not actually part of the original VGA standard...thus,
the method to get the mode into its 8-bit DAC mode differs...
For instance, GREP'ing through my video reference folder I have here,
a "video 7"-based chipset uses:
3C4h index C1h (R/W):
bit 0 Set to enable 8bit DAC rather than 6bit.
While a COMPAQ QVision has an extension to INT 10h (AX=BF03h), where
bit 7 of CL controls it...while one of the ATI cards has a bit in one
of its extended registers...
They all have a simple bit that allows the DAC to be easily switched
in these modes but it's really an SVGA thing, which can simply be
applied to a VGA mode and isn't really part of the original VGA (hence
what I meant by "modern cards", as in "better than VGA" :)...
Now, there is one possible sneaky way to discover how it's done for a
particular card...the VESA VBE functions return controller information
about whether the DAC can be switched to 8-bits...and, also, function
AX=4F08h of the VESA VBE is specifically used to control the DAC's
width...so, if your video card has VESA VBE installed then one sneaky
little possibility is to start disassembling the VBE BIOS code that
results from making a AX=4F08h INT 10h call to see how the VESA VBE
itself is getting and setting the DAC's width for that particular
card...the results of doing things this way, though, are certainly not
guaranteed to be necessarily "portable" in any way...
Unfortunately, video cards stopped being "standardised" at exactly the
point where this sort of thing was introduced...it is a possibility to
do this on modern video cards in some way but, from all the
documentation that I can gather, there's no "one size fits all" method
to do it (if anyone knows any differently on this, please let me know
but I've scoured the files I can find and found nothing useful)...as I
say, it's really an SVGA thing exploited in a VGA mode rather than a
normal VGA thing...
Now, as you have a _particular_ use for this - where "compatibility"
isn't overly important, perhaps? - then you might be able to discover
how your particular video card does it (for instance, by tracing
through the AX=4F08h VESA function perhaps? Because the code to do it
directly with the hardware must be in the VESA BIOS there somewhere
;)...but it's not going to be "portable"...well, not unless you learn
how to do it for all the different cards and then select the correct
routine according to which card is present...something like the UNIVBE
utility, for instance, must also be doing things this way to provide
VBE support from a universal software driver...although, that utility
is ever so slightly anicent that it probably can't cope with modern
cards, anyway, only the first few SVGA chipsets that came out...but
there's another source for you to investigate to see how this might
work...
> At the moment I use,
[ snip code ]
> One method I used to display 24 bit images in mode 13h was
> to make palette 0-63 the red range, 64 - 127 the green range,
> 128 to 191 the blue range and 192 to 255 the gray range for
> monochrome images.
>
> Then I used 3 pixels one for each color value rgb and it looked
kinda
> like viewing the image through a fly wire screen. I had intended
using
> the same trick in the a higher resolution 256 color mode because I
> think the result would look much better.
Well, despite being called 24-bit images, they never use all the
colours...it's physically impossible, in fact...at 1024x768, for
instance, there's only 786,432 pixels...so even if all the pixels were
completely different - grossly unlikely for any "natural" picture -
then there's just not enough pixels by far to display all 24-bit
colours on the screen at one time...
Thus, if you actually check how many _unique colours_ there really are
and what ranges they are in, it's possible to "bias" your limited
palette so that it'll better represent what's there...also, if this is
a JPEG 24-bit image then the compression method itself tends to - how
shall we put it? - "slaughter" a large amount of the colours in an
image (if you have something with a background that has very subtle
variation in colour - say, a blue sky that's gradiated in an
ever-so-subtle manner - with something else in the foreground actually
taking up the focus of the colourspace then, often _very visibly_, the
JPEG compression method can reduce this to literally a handful of
colours with blatantly obvious "banding" effects)...therefore,
checking the amount of _unique colours_ on a well-compressed JPEG
image is often liable to shock on occasion that it's reduced the
number of colours so severely...
But this is a trick that web designers know a bit about...if you have
a paint package where you can easily ask it to reduce the colour
palette in an "intelligent" way then it's amazing sometimes just how
far you can push the palette down before the image gets visibly crap
for doing so...even more especially when it has things like "error
correction" built-into its palette reduction stuff (which dithers and
moves the colours around a bit so as to account for the "errors" it
may introduce by reducing the colour)...
Hence, it's possible that though the image is using more than 256
colours, it's not vastly more (that is, in a relative sense, that it's
far closer to 256 colours than the stupidly big 16 million available
;) and by "biasing" the palette then you can get a pretty close
approximation using some simple dithering effects or whatever...the
fixed palette, of course, is far, far easier to implement and
stuff...but "biasing" the palette will help get better results...
Especially for "natural" scenes...for instance, you won't find very
many blue plants or foods...all greens and browns and yellows, tends
to be Nature's colours of choice...people require some flesh
shades...and that sort of thing...it's one of the things I like to
stress to people, actually...that 24-bit images are often not strictly
necessary but it's a "convenient" way to store things...they are
actually _grossly wasteful_...as noted, on a 1024x768, there's not
enough pixels to get anywhere near needing the full 24-bit
palette...to put it in numerical terms, even if every single pixel on
the screen was a different colour, there's still - wait for it -
15,990,784 colours you're NOT able to display...that's the vast, vast,
vast majority of the available 24-bit palette...and, in practice,
you'll find that most images are also far from this theoretical "every
pixel is a different colour" situation by some way too, not getting
anywhere near even the 786,432 "one colour for each pixel on the
screen"...and this is even worse still for modes like 800x600 or
640x480, as you can imagine, where there's even fewer pixels again...
It's all just a "convenience" thing to have simple "one byte per
primary, three bytes per pixel" (also, some cards have 32-bits per
pixel and literally throw away the fourth byte, simply for the
"convenience" of DWORD-alignment)...even with these 16- and 24-bit
modes, paletted images still have a place for the memory
conscious...the trick is encoding _ranges_ of colours for a palette
(all colours are put into order, say, and then "all the reds" is
specified as one simple range of colour indexes rather than listing
each one out one by one) and then the palette takes up next to nothing
but you can reduce the image to 16 / 15 / 14 / 12 / 9 / 8 bits without
losing a single bit of information or quality (except, of course,
something like the Windows' BMP format doesn't allow such non-powers
of two colour depth...even though they are supposedly
"device-independent" ;)...because all those extra bits are strictly
wasted for "conveniences" sake...if you get yourself a program - or
write one - to count the number of unique colours in most images and
then compare it to the stupidly big 16,777,216 potential palette then
you can realise just how grossly wasteful I really mean...
Also, the human eye is more sensitive to some colours than others...in
16-bit colour depths, this is often exploited for the "spare" bit (as
16 doesn't divide by 3 evenly :) to give an extra bit of the green
component - 5:6:5 for the RGB - as the eye tends to be more sensitive
to those colours with some green in it (natural "colours of the field"
like greens, yellows and browns because that once came in very handy
for our ancestors looking for foods and making sense of being in
forests and that sort of thing, so evolutionary theory suggests,
anyhow ;)...thus, there's also some room to "bias" a palette to be
more defined for these types of colours but less defined elsewhere and
then the palette size can also be reduced without that causing much -
if any - noticable visual difference...
It's actually another interesting fact for you; 16-bit colour contains
more colours than the human eye can discern...you might think "really?
I can tell the difference sometimes between a 16-bit and a 24-bit
image"...but that's because though there are more colours than can be
discerned, the eye does not see all colours equally...while, on the
other hand, 16-bit colour depth spaces out the colours evenly (only
one extra bit of green component to "bias" it a tiny bit)...so, yes,
16-bit images can still demonstrate banding so they went "whole hog"
for a byte per component - 24-bit - and solved the problem...although,
this can really be considered an "overkill" solution because 16-bit
colour gets very, very close and, conceivably, if the palette were
"biased" more to human perception instead then there's sufficient
colourspace to cover the lot and render 24-bit not useful for anything
humans look at...it's just that the colourspace this would require
would be quite weird and not so "uniform" as it is now, which would
make dealing with such bitmaps a bit complicated...24-bit images _do_
solve this but do so by massively exceeding human perception...an
"overkill" solution, as I like to call it...banging in a small nail
into a soft material but using an absolutely massive sledgehammer to
do so ;)...
With a good paint / photo package, in fact, it's educational to grab a
whole bunch of images and ask it to reduce them to 256 colours
(specially adapted to the image with "error diffusion" switched on and
so forth ;) then see that, despite what is a _drastic_ reduction in
the colourspace, many images will seem - visually - to be hardly any
different..._IF_, in fact, you can see a visual difference
whatsoever...depends on the nature of the image, though, of course, as
some with lots of subtle gradients will start to "band" the more
extreme you get...but "banding" it must be remembered is an extreme
"worse case" scenario...it's hard to explain in words but though
there's much subtle gradients in natural photographs, much of it is
"informationally unnecessary" to a person looking at it...for
instance, JPEG is delibrately attuned to natural scenes to get good
compression on photographs...but if you apply it to crisp and clear
simple flat colour images, the JPEG compression actually blurs out and
even badly distorts once crisp and clear divisions between colours...
Which is another thing you find in computing that's a bit
misplaced...this whole thing about crisp and clear lines and
stuff...no such thing in the real world...everything is actually very
much blurred and the majority of what you're looking at is simply out
of focus (very blurred), except for a very small area in the
middle...this is the bit our brains always concentrate on so we
actually tend to think that the world is more "clear and crisp" than
it actually is...that's how and why anti-aliasing works...you
_delibrately_ "blur out" a line and that actually looks more "natural"
because there's no such thing as a perfectly crisp line (even if
you've got excellent 20/20 vision then this is _still_
happening...it's the nature of light and human sight itself
:)...hence, though this might go against many people's instincts,
better colour depth is usually more useful for photographic-like
images than resolution...TV images, for instance, actually have quite
a low-quality resolution in computer terms...VHS images even worse,
though this rarely spoils a VHS film you've hired from the
store...even the refresh rates tend to be far worse (for example, most
TV images are actually filmed at something like 25 / 30 fps and are
simply shown _twice_ for the 50Hz / 60Hz refresh rate of a PAL / NTSC
TV respectively :)...
So, how come with such "lesser" resolution and "lesser" refresh rate
does it produce totally reasonable results that doesn't bother anyone
at all? The reason is _colour_...the colour depth is high...with
analogue signals, theoretically "infinite"...and TVs are almost always
showing "natural" photographic scenes, where ideas like "crisp lines"
aren't much use...of course, the reasons why people think of
resolution and refresh rates first with computers are because you tend
to sit far closer to a computer monitor, are staring at it longer and
you're often looking at lots of text or something (where _shape_ is
more important than its colour...because most text is monochrome and
it's _totally_ about discerning shape in order to read it...which is
actually "unnatural" compared to the usual stuff the human eye was
designed to do, where colour is more important)...but for
"photographic" things - like computer games, movies, etc. - colour
depth actually takes the priority...
A different way you might consider for displaying these 24-bit images
is to actually create _two_ images and then alternating between them
back and forth, synchronised to the vertical blank...it'll be
"flickery" but by constantly moving back and forth between the two
images, the corresponding pixels in both images will start to blend
together, effectively giving you a far larger "palette"...it's a
little more complicated to work out - reducing the combined "error"
between the two images - and it'll look "flickery"...but, otherwise,
the images won't be "stretched" by your attempts to display them and
if you stand back and / or squint a bit then the flickering can be
ignored and the colours really do blend together surprisingly
effectively this way...
Beth :)
- Next message: Alex McDonald: "Re: assembler testing tool"
- Previous message: wolfgang kern: "Re: The Microsoft Way (OT)"
- In reply to: JGCasey: "8 bit values in mode 13h?"
- Next in thread: JGCasey: "Re: 8 bit values in mode 13h?"
- Reply: JGCasey: "Re: 8 bit values in mode 13h?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
