Apple IIgs Color Dither Problem
Immortal Nephi
vertical strip which is called dithering, but real Apple IIgs' monitor
does not show dithering.
Do you have a way to combine dithering into solid true color on any
Apple IIgs emulator? I know that 640x200 resolution has only four
colors each horizontal line. You may need color dither translation
table.
magnusfalkirk
Part of the problem could be if you're taking the signal from the RGB
port on the GS. The GS RGB signal is ANALOG RGB which would not work
well with a DIGITAL monitor without a converter of some type.
Just my two cents worth,
Dean
Eric Rucker
> Part of the problem could be if you're taking the signal from the RGB
> port on the GS. The GS RGB signal is ANALOG RGB which would not work
> well with a DIGITAL monitor without a converter of some type.
They wouldn't work with a digital (read: DVI, HDMI, DisplayPort)
monitor at all unless you use a converter.
If you've got a VGA monitor capable of 15 kHz... then the explanation
is simple. (BTW, VGA is just analog RGB, just at faster sync rates.)
You can see the dithering because the VGA monitor is high enough
quality to show it to you.
The AppleColor RGB is not high enough quality, and therefore hides the
dithering from you by blurring it all together.
Michael J. Mahon
As Eric pointed out, the resolution of a modern monitor is much better
than the Applecolor RGB, so the dithering--which is supposed to be
averaged out to be useful--is resolved into fine lines of blue and
white.
If you are not seeing 640 fine lines, but a considerably smaller
number, then you are seeing a moire pattern formed by the "beat"
between the 640-pixel dithered line and the LCD's real pixels and/or
its resampling clock.
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon
"The wastebasket is our most important design
tool--and it's seriously underused."
Immortal Nephi
> Immortal Nephi wrote:
> > Please explain why CRT / LCD screen for VGA monitor show colored
> > vertical strip which is called dithering, but real Apple IIgs' monitor
> > does not show dithering.
>
> > Do you have a way to combine dithering into solid true color on any
> > Apple IIgs emulator? I know that 640x200 resolution has only four
> > colors each horizontal line. You may need color dither translation
> > table.
>
> As Eric pointed out, the resolution of a modern monitor is much better
> than the Applecolor RGB, so the dithering--which is supposed to be
> averaged out to be useful--is resolved into fine lines of blue and
> white.
I apologize not to explain clear. I did not say that CRT / LCD screen
for VGA monitor is connected to Apple IIgs' RGB port. I simply talk
about Apple IIgs' real RGB monitor and VGA monitor.
> If you are not seeing 640 fine lines, but a considerably smaller
> number, then you are seeing a moire pattern formed by the "beat"
> between the 640-pixel dithered line and the LCD's real pixels and/or
> its resampling clock.
Michael pointed that Apple IIgs' real RGB monitor does not show
dithering because it does not have higher frequency so colored
vertical strip is harder to be seen inside the screen. For example,
AppleColor monitor does not show black vertical strip on HGR / DHGR
screen because it is on 3.58 MHz. You will see black vertical strip
if higher frequency like 7M is enabled. I wonder that my example may
look like dithering.
I am asking how do you overcome dither problem on any CRT / LCD screen
for VGA monitor while you are running Apple IIgs Emulator. There is a
way to hide dither by combiing each pair of pixels into solid color
with dithering translation table.
magnusfalkirk
>
> I am asking how do you overcome dither problem on any CRT / LCD screen
> for VGA monitor while you are running Apple IIgs Emulator. There is a
> way to hide dither by combiing each pair of pixels into solid color
> with dithering translation table.
Which Apple IIGS emulator are you running that you're getting
dithering on the LCD screen from? At work I'm running KEGS 32 on a PC
running Windows XP with a 17 inch LCD and I don't have any dithering
problems. At home I'm running Sweet16 on a Mac Mini running OS X
10.4.11 with a 19 inch LCD and have no dithering problem there either
and that includes when I set Sweet16 to Full Screen Mode so it looks
like I'm actually using my real GS hooked up to the LCD monitor.
Dean
Eric Rucker
> Which Apple IIGS emulator are you running that you're getting
> dithering on the LCD screen from? At work I'm running KEGS 32 on a PC
> running Windows XP with a 17 inch LCD and I don't have any dithering
> problems. At home I'm running Sweet16 on a Mac Mini running OS X
> 10.4.11 with a 19 inch LCD and have no dithering problem there either
> and that includes when I set Sweet16 to Full Screen Mode so it looks
> like I'm actually using my real GS hooked up to the LCD monitor.
>
> Dean
This is a really bad way to do the comparison, but...
http://bhtooefr.ath.cx/images/gsrescompare.PNG and
http://bhtooefr.ath.cx/images/gsrescompare2.PNG
In both, the bottom image is what you see on an emulator.
The top image is similar to what you see on a real GS, although in
reality, it's about halfway in between the two. (The comparison was
taking the image, scaling it to 320x200 using a Lanczos filter, then
back to 640x400.)
Immortal Nephi
I use either KEGS 0.84 and KEGS 0.91 running in Windows XP. I do see
dithering screen on my HP LCD screen. I wonder how your LCD screen
does not show dithering. I am curious.
tonykavadias
> I apologize not to explain clear. I did not say that CRT / LCD screen
> for VGA monitor is connected to Apple IIgs' RGB port. I simply talk
> about Apple IIgs' real RGB monitor and VGA monitor.
Hi there, thought I'd explain this in another point of view...
... the frequency of the 640 dot clock in the video signal of an Apple
IIGS results in scans that exceed the resolution (dot pitch) of the
original AppleColor RGB Monitor that Apple sold for their machines.
Because the resolution of the video signal was higher than the
resolution of the monitor used to display it, the effect was that
adjacent pixels on a 640 display "blurred" together resulting in the
mixing of pixels by the monitor hardware itself to produce tertiary
additive colours. This was Apple's so-called "13-colour experimental
dithering" technique used in many programs, including the Apple IIGS
QuickDraw II Toolbox (the graphics routines used to draw to the Super
High-Res display).
The reason why it was "13 colours" was because for a 640-wide scan
line, 4 colours would be assigned to even pixels, and two other colours
would be assigned to odd pixels--both even and odd pixels would have a
colour assignment for black and white in the system's standard colour
palettes. Out of a total of 16 colours per scan line, 3 colours would
appear twice for an even-odd pixel pair: black, white and grey. The
two grey colours would have a phase-shift characteristic which would
allow programmers to draw black and white graphics at a higher
resolution in amongst the dithered colour in 640 mode, which was used
to provide sharp 80-column text and monochrome user interface elements
in amongst the colour graphics.
On LCD displays (or with VGA monitors with a high enough dot pitch to
precisely match the resolution of your computer's display) with a
display rendered by an Apple IIGS emulator, you can actually see what
the Apple IIGS would have drawn to its Super High Resolution display
memory, because today's LCD monitors are pixel-perfect. The AppleColor
RGB Monitor wasn't pixel-perfect at 640-wide scan lines, thus producing
the results that Apple IIGS users would have seen on their displays.
The example you noticed was how the Apple IIGS used an array of blue
and white vertical stripes to produce the blue pastel colour that the
AppleColor RGB Monitor would have shown for the Finder desktop. On an
LCD display, that would literally show up as an array of blue and white
vertical stripes!
To display dithered colour on an LCD monitor, you have to drop the
resolution of your display so that pixels in graphics memory no longer
have a 1:1 relationship with pixels on your LCD monitor: on Macintosh
computers, you can do this by choosing a resolution which is about a
quarter to half the size of the maximum that your Macintosh can
produce. This forces the graphics processors to produce an image where
pixels in video memory have to span across "one-and-a-half" pixels on
the LCD display matrix to achieve the same sort of dithering that
earlier AppleColor RGB Monitors would have produced. For your
particular Macintosh model, try applying different desktop sizes to see
the results shown on your Apple IIGS emulator's display window on the
display showing it.
On PCs, whether this technique will work depends on your monitor's
video hardware. Some older monitors don't dither lower-resolution
video signals onto LCD displays, instead showing display pixel colours
along the monitor's pixel borders on the display matrix. Today's
monitors seem to handle lower resolutions more uniformly.
Otherwise, you'll have to rely on your emulator to simulate, in
software, how the AppleColor RGB Monitor produces dithered colours...
and even then, the dithering isn't perfect because the dithering
algorithms used by Apple IIGS emulators are too simplistic compared to
images produced by the AppleColor RGB Monitor.
Cheers!
--tonza
Immortal Nephi
What do you mean "dithering algorithms used by Apple IIgs emulators
are too simplistic"? KEGS probably does not have dithering algorithm
to hide vertical strip. There has to be another way. Like I said
color dithering translation table may be needed to prevent from
showing dithering on the screen.
tonykavadias
> What do you mean "dithering algorithms used by Apple IIgs emulators
> are too simplistic"? KEGS probably does not have dithering algorithm
> to hide vertical strip. There has to be another way. Like I said
> color dithering translation table may be needed to prevent from
> showing dithering on the screen.
I use an emulator called Sweet 16, which is a Mac OS X "version" of an older
emulator called Bernie ][ The Rescue for Mac OS 8 and higher. While I could
argue that this is the best Apple IIGS emulator ever written for the Macintosh
to date, there are some shortcomings... one of them is its "AppleColor
RGB Monitor
mode".
What this does is combine the colours of even-odd adjacent pixels for
pixels that
are not black nor white in order to come up with a way to display cleaner
640-resolution graphics.
However, in my opinion, I find that while the algorithm does the job in killing
the vertical stripes of adjacent colours on 640 displays, it does so by
killing the accuracy (fidelity) of the picture, particularly since while black
and white even-odd pixel pairs are not blended to make grey, other colours
do not get the same treatment, so if there was a picture that relied on
coloured
edges to define a picture, those edges would be distorted by the software
dithering process.
However, to make a "smarter" dithering algorithm would mean to be able to
identify where to blend colours and where not to, and this would require a
degree of artificial intelligence to do the job... something I'd rather not
apply anyway (I disable "AppleColor RGB Monitor mode" and just put up with
the vertical stripes!).
You mentioned using KEGS... I noticed that it does not have software dithering
like Bernie does. If you can, you might like to try Bernie/Sweet 16 to see if
they can help you achieve the graphics results you're looking for:
http://www.sheppyware.net/downloads/downloads-mac/files/Sweet16%202.1.3.dmg
(The above link is only useful for Mac OS X only.)
Cheers!
-- tonza
Michael J. Mahon
> On 2009-09-17 05:59:53 +1000, Immortal Nephi
> <Immorta...@hotmail.com> said:
>
>> I apologize not to explain clear. I did not say that CRT / LCD screen
>> for VGA monitor is connected to Apple IIgs' RGB port. I simply talk
>> about Apple IIgs' real RGB monitor and VGA monitor.
>
>
> Hi there, thought I'd explain this in another point of view...
>
> ... the frequency of the 640 dot clock in the video signal of an Apple
> IIGS results in scans that exceed the resolution (dot pitch) of the
> original AppleColor RGB Monitor that Apple sold for their machines.
> Because the resolution of the video signal was higher than the
> resolution of the monitor used to display it, the effect was that
> adjacent pixels on a 640 display "blurred" together resulting in the
> mixing of pixels by the monitor hardware itself to produce tertiary
> additive colours. This was Apple's so-called "13-colour experimental
> dithering" technique used in many programs, including the Apple IIGS
> QuickDraw II Toolbox (the graphics routines used to draw to the Super
> High-Res display).
And it's worth pointing out that "dithering" is a technique that is
employed _only_ when the indended viewing environment low-pass filters
the pixels into a lower-resolution perceived image.
This is true even of pointillist paintings, which collapse if viewed
close-up.
Therefore, dithering on the IIgs at 640 resolution should be viewed as
a design decision based upon the "smoothing" characteristic of the IIgs
monitor(s). Increasing the bandwidth thus invalidates this design, and
so such a display is not faithful to the intent of the designers.
The same argument can be made for hires graphics displays designed for
all the Apple II machines--they were overwhelmingly designed to be seen
as displayed by an NTSC monitor, with all its color ideosyncrasies.
I would add that the appropriate, but missing, element of most emulators
is a variable-bandwidth digital lowpass filter to limit the bandwidth of
the emulated monitor so that it faithfully matches the display(s)
originally used. Faithful video emulation is frequently neglected by
programmers accustomed to thinking of video simply digitally.
Michael J. Mahon
This inconsistent behavior is a characteristic of all _ad hoc_ blending
methods.
> However, to make a "smarter" dithering algorithm would mean to be able to
> identify where to blend colours and where not to, and this would require a
> degree of artificial intelligence to do the job... something I'd rather not
> apply anyway (I disable "AppleColor RGB Monitor mode" and just put up with
> the vertical stripes!).
Actually, no AI is needed to blend _everything_ as the Applecolor RGB
monitor would have done it. This means accepting softer text if you are
also viewing color graphics. (An emulator should provide multiple types
of emulated monitors, so you can have your sharp text when you want it.)
Where things get tricky--and I mean arbitrary--is in applying blending
selectively in an attempt to get the best of both worlds (sharp text
_and_ smooth color gradations).
Digital filtering solves this problem, but it can be computationally
expensive. So a more practical approach would be to "precompute" the
desired filter response and then use a short history of pixels (shift
register) as an index into a "response table" to generate each pixel.
The table size needed is usually much less than the cache size of modern
processors, so there need be little performance impact to provide a
faithful emulation of older displays.