Going beyond 16 colors...
BLuRry
16x16 colors to produce roughly 144-ish colors. However, most of these
colors were rather jarring to look at because of the high amount of
objectionable flicker. Now that applewin has a convienent "Bload"
facility (which helps with rapid prototyping of code) and I have a //c
that I can send arbitrary code to quickly (using apple game server), I
have been able to work on this more now. (though if anyone can help me
find a better way to do VBL detection on a //c, I am all ears)
I marked off the colors that are completely unviewable and stripped it
down to 68 colors that either appear solid (there are a handful of
those actually) or only have a slight amount of flicker. I have a gif
of the simulated palette made with photoshop, as well as a photoshop
rgb color index file. I also have made a spreadsheet documenting which
index colors go where in the simulated color grid, which means that it
should eventually be possible to convert images using this palette in
photoshop and then (most likely) passing the converted image in to a
java program to process as a series of two double-hires images that are
alternated to produce a pseudo 68-color image.
I have also updated the apple program to black out the unviewable
"colors" and have checked it using a //c on a regular TV. There is a
little noticable flicker, but it is a lot easier to look at than when I
started. Maybe it's because I've stayed up way too late working on it
and my eyes are playing tricks on me. But that was also the same kooky
frame of mind I was in when I loaded up moon patrol the first time from
a serial cable, so who knows what will come of this crazy
experimentation? More to follow soon (after I do this whole sleeping
ritual and such).
-B
heuser...@freenet.de
>
> I have also updated the apple program to black out the unviewable
> "colors" and have checked it using a //c on a regular TV. There is a
> little noticable flicker, but it is a lot easier to look at than when I
> started.
If you have a standard NTSC TV set you'll get 30 hz for the "combined
picture". This flickers quite noticeably and will give you eye strain
in the long run, IMHO.
With PAL its only 25 hz - and believe me: It flickers like hell,
especially with bright colors.
Because of this I never used similar trickery with the 8 bit Ataris to
display 256 "real" colors or the interlaced modes of the Amiga with
twice the vertical resolution.
However, you may get much better results with a TV set that is capable
of displaying a NTSC or PAL picture at twice the normal frequency (120
/ 100 hz) or a modern LCD or plasma TV set.
bye
Marcus
BLuRry
> especially with bright colors.
Exactly, in fact almost any color alternated with white flickers
horribly -- even the lighter colors. However, there are a few colors
where the flicker is not as bad or noticable and a small handful that
don't *appear* to flicker AT ALL -- at least not on the zenith NTSC
television I was plugged in this week's hotel room. If you alternate
between red/magenta (1) and dark blue (2) you get a nice solid dark
purple that doesn't kill your eyes. Try it. :-)
-B
Michael J. Mahon
> Previously, I experimented with flickering between all combinations of
> 16x16 colors to produce roughly 144-ish colors. However, most of these
> colors were rather jarring to look at because of the high amount of
> objectionable flicker. Now that applewin has a convienent "Bload"
> facility (which helps with rapid prototyping of code) and I have a //c
> that I can send arbitrary code to quickly (using apple game server), I
> have been able to work on this more now. (though if anyone can help me
> find a better way to do VBL detection on a //c, I am all ears)
On a //c you have the option of enabling the VBL IRQs, and doing
your page flipping in the IRQ routine.
> I marked off the colors that are completely unviewable and stripped it
> down to 68 colors that either appear solid (there are a handful of
> those actually) or only have a slight amount of flicker. I have a gif
> of the simulated palette made with photoshop, as well as a photoshop
> rgb color index file. I also have made a spreadsheet documenting which
> index colors go where in the simulated color grid, which means that it
> should eventually be possible to convert images using this palette in
> photoshop and then (most likely) passing the converted image in to a
> java program to process as a series of two double-hires images that are
> alternated to produce a pseudo 68-color image.
I noticed that colors composed of widely different luminances were
hard to look at, and barely distinguishable among the darker alternate
colors.
> I have also updated the apple program to black out the unviewable
> "colors" and have checked it using a //c on a regular TV. There is a
> little noticable flicker, but it is a lot easier to look at than when I
> started. Maybe it's because I've stayed up way too late working on it
> and my eyes are playing tricks on me. But that was also the same kooky
> frame of mind I was in when I loaded up moon patrol the first time from
> a serial cable, so who knows what will come of this crazy
> experimentation? More to follow soon (after I do this whole sleeping
> ritual and such).
Something that you could do to decrease the effect of the flicker
is to interleave the pair of colors on alternate lines, and swap
the lines on the "flip" frame. That way, the flicker is all small-
area flicker, as opposed to large-area flicker, which the eye has
a much lower threshold for detecting.
-michael
Parallel computing for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."
Michael J. Mahon
The eye is a remarkable system, and exhibits widely varying sensitivity
to flicker based on absolute brightness, relative brightness, and color,
as well as, of course, frequency. The angular area of the flicker has
a big effect, too, with flickering details being much less obvious than
large areas (though small-area flicker remains quite visible).
Several scientific instruments and measurement techniques are based on
alternating between two different images at a "flicker" rate, so that
the eye will be drawn to differences. For example, planets, asteroids,
and comets used to be found this way--and many still are, after computer
culling.
BLuRry
> ritual and such).
I now have a java program that converts any image (auto-rescaling as
necessary) to a 140x192 double-hires image. I've tested the output
against the dhgr viewer in CiderPress (cool stuff, Andy!) and it is
looking good. I was able to convert a color-bar image successfully to
a dhgr color bar image. The color detect method is a simple distance
formula that looks for the closest fit color for each pixel. For my
purposes, works great.
I've written the code to calculate the 48 color palette (based on my
perception of which colors flicker less annoyingly) and also keep track
of what two apple colors are combined for each color. So all that is
left is to generate two double-hires images, load them into a real //
computer, and flicker between them. So i'll post a disk image online
once I get something working (which of course will not look as
convincing in an emulator, but cest la vie)
BLuRry
BLuRry wrote:
> >More to follow soon (after I do this whole sleeping
> > ritual and such).
even more progress. as in, I can now convert images and view them.
Right now I'm using the a2gameserver as the loader, but now that I know
it works I can slap together a disk image with an example or two.
Current issues:
-Hurts yer eyes. Some of the colors are more flickery than I had
thought. However, some are not bad at all -- they look almost like
normal pixels. The choices for this are to eliminate more possible
color combinations (mostly those involving brighter colors) but this
reduces the virtual color depth.
-Color palette is not adjusted for an NTSC television. At least, not
the one I'm using over here. So the images, while demonstrating the
color depth I had hoped for (and then some), look a little off.
Especially images where there are a lot of grays used, because the
palette I used is based on the rgb monitor where both grays were
different whereas on a TV they are both dark gray.
-The conversion program I wrote isn't very configurable about how it
selects color. Because of this, the only way to control the quality of
the converted image is to reduce the color palette in photoshop or the
gimp first (convert to indexed color and use the calculated palette).
Since I have the same palette in java as I do in photoshop, images come
back 1:1 as they appear in photoshop (except of course the palettes in
use are not calibrated for a TV display so it still looks a little odd)
Despite the difficulties, it still looks better than I thought it
would. If used for brief periods of time (e.g. not for a whole game
but just for a title screen or brief slideshows) this would be suitable
for some interesting results -- if anything it would definately catch
the average retro // user way off guard. ;-)
Now that I have a few fun images to look at, I will post them soon and
update this thread with a link.
-B
BLuRry
> update this thread with a link.
Have fun guys!
http://brendan.robert.googlepages.com/pseudo-colorexperiment
I added the arror-key delay feature to my copy of the source so that
you can use left/right arrows to alter the delay manually. This also
has auto-detect for //c VBL as well as the regular // series. I hope
you like the test images I created, especially the reclaming of the
apple chrome logo with our favorite color scheme. ;-)
-B
mdj
I enjoyed the logo, very cool :-)
BLuRry
You might enjoy the fact that I ditched one of the "// infinitum" pics
in favor of a photo of Billie Piper (all the Dr. Who fans in the house
please stand up)
-B
mdj
:-) Please upload the updated disk image then :-)
BLuRry
Done and verified. You should be able to get it from the exact same
place as before:
http://brendan.robert.googlepages.com/pseudo-colorexperiment
TJFM
> Because of this I never used similar trickery with the 8 bit Ataris to
> display 256 "real" colors or the interlaced modes of the Amiga with
> twice the vertical resolution.
Agreed. doing that can get painful very fast.
However, I was wondering about the use of a similar technique. I believe
it works by essentially halving the horizontal resolution to increase
colour depth.
I think it works by utilising two columns to create colour instead of one.
It looks pretty ordinary up close, but stand back a little and it becomes
quite effective. Combine that effect with this page flipping technique,
and far more perceived colours may be possible.
Only problem is, I'm not at all sure it would work given the colour
creation constraints of the platform.
It's something to think about, anyway.
--
/* Who is this General Failure and why is he reading my C: drive? */
/* http://blog.myspace.com/13604531 */
BLuRry
> However, I was wondering about the use of a similar technique. I believe
> it works by essentially halving the horizontal resolution to increase
> colour depth.
This is what most popular drawing programs did, basically checkerboard
patterns between two different colors. Trouble is that with the color
bleed you don't really see the colors correctly when certain
combinations are next to each other...
-B
heuser...@freenet.de
>
> However, I was wondering about the use of a similar technique. I believe
> it works by essentially halving the horizontal resolution to increase
> colour depth.
> I think it works by utilising two columns to create colour instead of one.
Its essentially dithering.
This was a very successful graphics technique on the Apple - Graphics
Magician claimed to be able to output "121 colors" - but they had more
complex patterns. The good concept of the software, the fast drawing
routines and their licensing practice made it the leading software in
this software segment. Lots of graphics adventures and educational
software used it.
> It looks pretty ordinary up close, but stand back a little and it becomes
> quite effective.
Maximise the viewing distance and your eye (and the monitor) smears the
pixels into a single color.
> Combine that effect with this page flipping technique,
> and far more perceived colours may be possible.
With the same disadvantages.
> Only problem is, I'm not at all sure it would work given the colour
> creation constraints of the platform.
>
> It's something to think about, anyway.
Why not stick with dithering alone?
bye
Marcus
heuser...@freenet.de
> > However, I was wondering about the use of a similar technique. I believe
> > it works by essentially halving the horizontal resolution to increase
> > colour depth.
>
> This is what most popular drawing programs did, basically checkerboard
> patterns between two different colors.
Ha ha, beat me to it! ;o)
> Trouble is that with the color bleed you don't really see the colors
> correctly when certain combinations are next to each other...
Which was mostly intentional, I'm sure.
And which is why I prefer the II(e/c) platform for non-GS-software over
the GS or an emulator. Though I hope that the latter will someday
incorporate a more realistic composite simulation.
bye
Marcus
TJFM
> Its essentially dithering.
I wasn't sure if dithering was the correct term to apply before, but I
guess it was.
>
> This was a very successful graphics technique on the Apple - Graphics
> Magician claimed to be able to output "121 colors" - but they had more
> complex patterns.
Up until recently, my //e had only ever really been used as a ][. Until I
decided to revisit it, I was painfully aware of its capabilities.
Are there any easily locatable programs that use this method?
I'd like to see them on my //e. Especially since I dug out the apple
composite colour monitor from the shed.
> Maximise the viewing distance and your eye (and the monitor) smears the
> pixels into a single color.
Many people like myself have a builtin feature to emulate the effect.
Although it does require a special piece of hardware to disable it :)
>> Combine that effect with this page flipping technique,
>> and far more perceived colours may be possible.
>
> With the same disadvantages.
True. You gain flicker and lose resolution.
> Why not stick with dithering alone?
I have absolutely no idea.
In a theoretical sense, maybe, it might be possible that
if a dithering algorithm were carefully selected for both pages in the
page flipping method the flickering may be less pronounced, or some more
perceived colours may be added to the mix.
I've never really liked graphics programming, so I'll leave it to people
that do.
BLuRry
> > patterns between two different colors.
>
> Ha ha, beat me to it! ;o)
GMTA. ;-)
> > Trouble is that with the color bleed you don't really see the colors
> > correctly when certain combinations are next to each other...
>
> Which was mostly intentional, I'm sure.
Yeah, but it makes the image look rather gritty. Sure, the scott adams
graphic adventures used the penguin (whoops polarware) drawing routines
to push out some amazing looking stuff. But it was difficult to view
on a green screen. And you lose resolution on top of that unless
you're filling large areas with one "color". You can't do gradients or
other rapid color transitions very easily.
Some colors when alternated actually produce a black-and-white
checkerboard pattern. So the dithering technique has a very limited
amount of appeal. However, you can "sort of" get a good color
dithering conversion using photoshop to scale down the palette of an
image to the apple's 16-color palette and play with the diffusion
controls until you're happy with it.
If I can understand how programmatic dithering works I might be able to
develop an algorithm that can account for the color bleed of an apple
composite signal and take that into account when converting an image
(if there's any real interest in it.) I understand the theory of why
these things happen (most notably because the 7mhz instead of 7.5mhz
timing or somthing like that causes pixels to overlap each other with
an apple, hence why nintendos and commiedores don't do this on a TV)
and I am very accustomed to seeing the color fringe. But I don't know
how to calculate it very well.
heuser...@freenet.de
>
> Up until recently, my //e had only ever really been used as a ][. Until I
> decided to revisit it, I was painfully aware of its capabilities.
> Are there any easily locatable programs that use this method?
Well, several versions of Graphics Magician ("GM") are available as
disk images at the usual "water holes". The same goes for other
graphics applications like Koala Paint or other paint programs that use
some dithered colors in their palette.
Keep in mind that GM is mostly a tool to help produce some software
that uses graphics (lots of them, as the picture files are relatively
small).
So if you only want to doodle a bit you should test some paint programs
as they are a bit easier to use.
The demo section of GM however is something worth watching - especially
the double hires version.
If you rather want to see demos than doing stuff yourself you can
simply download some disk images of graphics adventures for the Apple
II(e/c). Lots of them actually used GM for generating pictures, some
used other routines to draw the pictures, and others used ready made
pictures that are stored on disk.
With the exception of the double hires stuff most things work on a 48
or 64K Apple II.
And another thing:
Dithering the standard hires colors doesn't really increase the color
spectrum - its more like texturizing or increasing "picture complexity"
for the lack of better words.
Maybe that's why I like it.
> I'd like to see them on my //e. Especially since I dug out the apple
> composite colour monitor from the shed.
There are several possibilities to transfer disk images "back" to the
Apple hardware. Use the CSA2 FAQs or Google group search for finding
old threads (there is usually one per month ;-).
> Many people like myself have a builtin feature to emulate the effect.
> Although it does require a special piece of hardware to disable it :)
And the effect usually works better the older one gets ;-)
> In a theoretical sense, maybe, it might be possible that
> if a dithering algorithm were carefully selected for both pages in the
> page flipping method the flickering may be less pronounced, or some more
> perceived colours may be added to the mix.
As was said earlier there are colors that work well and others don't.
On the other hand this technique costs memory. Lots of it.
Two DHGR pages are 32 KB - which takes time to fill (either by loading
from disk or by drawing like GM).
Without the possibility to show some other graphics in the meantime.
Animation isn't exactly the first think that comes to my mind, either.
So the practical use is probably a bit limited, anyway.
> I've never really liked graphics programming, so I'll leave it to people
> that do.
No need to actually do programming - but maybe you want to draw or
paint or simply tinker with existing software.
bye
Marcus
Michael J. Mahon
No, that's not why. ;-) There are no "overlapping pixels" on an Apple.
Unlike the other systems you mention (which generate a true chroma
subcarrier), *all* color on the Apple is NTSC artifact color. There
*is* no other native color. And virtually all Apple graphics were
designed to be viewed as NTSC color images, so the "color bleed" you
talk about was an *intended effect* in most of those images.
(BTW, the reason everyone designed for NTSC color is that other ways
of viewing Apple color images were a small fraction of the market.
For many years, the most common way of using an Apple II was connecting
it to a TV set.)
There are two difficulties with Apple color that must be designed around
by a graphic artist: 1) the limited number of pure colors, and 2) the
inablilty to mix green or purple with orange or blue in the same 7-pixel
byte on the screen. Any apparent color that can be produced by any
pattern of pixels is fair game--sometimes this is described as dithered
color. Dithering can be horizontal and/or vertical (adjacent lines),
and it is *always* used for its color effect, and is *never* meant to
look good on a monochrome display (though sometimes the textures are
interesting).
The problem with using a "reduced palette" technique to synthesize
Apple graphics is that none of the tools for doing so takes into
account the actual NTSC artifacts that result in a color image for
Apple graphics. It would be possible to do so--and might be a very
interesting project--but it has not yet been done. Certainly the
current crop of emulators do a very poor job of rendering what would
be seen on an NTSC monitor, which is what the graphic artist intended.
Michael J. Mahon
> Up until recently, my //e had only ever really been used as a ][. Until I
> decided to revisit it, I was painfully aware of its capabilities.
> Are there any easily locatable programs that use this method?
From a graphic point of view, everything except the rarely-used DHR
is plain old Apple II graphics--it's hard to avoid!
> I'd like to see them on my //e. Especially since I dug out the apple
> composite colour monitor from the shed.
That's the one to use! ;-)
> In a theoretical sense, maybe, it might be possible that
> if a dithering algorithm were carefully selected for both pages in the
> page flipping method the flickering may be less pronounced, or some more
> perceived colours may be added to the mix.
Since the human perceptual system is much more sensitive to large-area
flicker than small-area flicker, page-flipping between complementary
dither patterns would be much less visible than page-flipping between
pages with big areas of different colors.
The effect would be the same color palette as dithering, but with the
resolution of a non-dithered image. Of course the cost would be twice
the memory (I'm assuming that we're talking dithered HGR images here.)
Joshua Bell
>
> Unlike the other systems you mention (which generate a true chroma
> subcarrier), *all* color on the Apple is NTSC artifact color. There
> *is* no other native color. And virtually all Apple graphics were
> designed to be viewed as NTSC color images, so the "color bleed" you
> talk about was an *intended effect* in most of those images.
I very recently picked up the book Applied Concepts in Microcomputer
Graphics by Bruce Artwick (Sublogic, Flight Simulator) off of an Amazon
second hand seller for a whopping USD$5.44 including shipping. Awesome book.
Until I read it I had only self-invented hypothesis for how Apple color
artifacting worked, and zero knowledge of NTSC. Although I've done a lot of
graphics programming, I was always abstracted away from the display hardware
sufficiently to ignore it.
FWIW, my "folk hypothesis" growing up was to consider the horizontal signal
to be divided into [R][G][B] sub-pixels, and Apple screen bits to be
approximately a half-pixel wide, e.g. [0][0] is the same width as [R][G][B].
The bit-7 shift would offset things so the same two bits [0][0] would
overlap the neighboring [G][B][R] subpixels instead. A pattern of [1][1]
would light up RGB (==white). A pattern of [0][1] would light up mostly
[B]=blue and [1][0] would light up [R][G]=orange, or with the bit-7 shift
[0][1] would light up [B][R] = violet and [1][0] would light up mostly [G] =
greeen.
Now I *know* that NTSC does not address individual pixels, but my
"folk-hypothesis" was remarkably effective so it burnt into my brain.
Looking at page 96, I see that it's strangely almost correct - there are 180
cycles across the screen of a color signal which goes through the spectrum
MROYGCBV, and if the monochrome signal is "on" in a particular field of that
you get those colors; Apple's pixels do address half of one of these cycles
each. So [0][1] lights up GCB=green, [1][0] lights up MRO = purple. Shift a
little bit over and you get. [0][1] lighting up CBV=blue and [1][0] lighting
up ROY=orange.
This also explains the "fringing" rather nicely. The pattern
[0][0][1][1][0][0] which in (Apple Hi-Res)theory is perfect
black-white-black will inevitably have the "white" signal "leaking" to
either magenta or yellow on the edges depending on where it is within the
cycle.
Really, at the price, if you're doing Apple graphics programming you gotta
get this book.
Joshua
Joshua Bell
> If I can understand how programmatic dithering works I might be able
> to develop an algorithm that can account for the color bleed of an
> apple composite signal and take that into account when converting an
> image (if there's any real interest in it.)
Actually, the way that Floyd-Steinberg error-diffusion dithering works makes
it ideal for dealing with Apple's esoteric graphics. Here's the dithering
algorithm in a nutshell:
Start in the top-left of the image you want to dither. Pick the closest
color from your palette and plunk that in the corresponding location. Now
note that the color you were forced to use was close, but not perfect.
Quantify that difference (e.g. what's the delta in RGB space) and call it
the "error". Now divvy up the error to the neighboring pixels you haven't
drawn yet - 7/16th to the right, 5/16th to the bottom, and so on. (See
http://en.wikipedia.org/wiki/Floyd-Steinberg_dithering for the numbers). Now
repeat to the right, then down.
For example, let's say you're converting a 9x9 grayscale image to black and
white, and it's a simple 50% gray fill. So the pixels can be considered:
0.5 0.5 0.5
0.5 0.5 0.5
0.5 0.5 0.5
Start in the top left - the "closest color" is a toin coss here, so let's
say black [0]. That's got an error of 0.5, so divvy it up among the
neighboring pixels like so:
[0] 0.7 0.5
0.7 0.6 0.5
0.5 0.5 0.5
Now go to the right - we've got 0.7 now which is easily mapped to white [1],
giving an error of -0.3, which we divvy up:
[0] [1] 0.2
0.7 0.4 0.5
0.5 0.5 0.5
To the right once more, putting the error where we can:
[0] [1] [0]
0.7 0.4 0.7
0.5 0.5 0.5
And on to the next row:
[0] [1] [0]
[1] 0.2 0.7
0.4 0.5 0.5
And so on:
[0] [1] [0]
[1] [0] 0.8
0.4 0.6 0.5
And so on:
[0] [1] [0]
[1] [0] [1]
0.4 0.6 0.3
And ending up with:
[0] [1] [0]
[1] [0] [1]
[0] [1] [0]
And what do you know - we got a perfect checkerboard, which isn't a bad
approximation of 50% gray on a black-and-white display.
In theory, an Apple II-aware version of this would be able to account for
both color bleed and even the bit-7 shift - the algorithm just "tries its
best" and makes up for the inevitable errors across the rest of the image.
Joshua