Color HGR image conversion
BLuRry
140x192 in size. Seemed to work pretty well, except the algorithm
doesn't account for NTSC anomalies. Hi-res images are somewhat
confounding to me though, because of that darn hi-order bit. I would
like a good general-purpose algorithm to convert arbitrary images to
hi-res, but also make use of the pixel characteristics for B&W line
art where possible. I was thinking of something like the following:
-Create a set of HGR patterns that represent a palette of colors,
similar to those in Blazing Paddles or other paint programs
-Create a lookup of those patterns to their nearest RGB equivalents,
e.g. alternating Green/Orange pattern would be a yellowish/brown RGB
color.
-Resize source image to 560x192 or smaller (why 560? For B/W
conversion)
-Posterize image to 256 (or less) colors to eliminate some noise
-Dither image to lookup palette using diffusion/error/whatever
algorithm
And I get that far but I struggle with the rest of how to get a really
solid conversion out of it. Possibilities:
-Separate B/W mask from colors, such that color mask only indicates
areas with color
-Create one HGR image using B/W mask, using hi-order bit to shift
pixels a little where it is a closer fit.
-Create another HGR image using color mask and using x/y coordinates
modulus to determine what pixels to plot and hi-order bit state to
use.
-Merge B/W mask using a preference for bits 0-6 of the B/W mask and hi-
order bit of the color mask
What I'm not too sure about is how to deal with adjacent pixels of
contrasting colors that use different hi-order bits. Any thoughts?
Should I create three masks, one for b/w, one for green/purple and one
for blue/orange?
-Brendan
BLuRry
> contrasting colors that use different hi-order bits. Any thoughts?
> Should I create three masks, one for b/w, one for green/purple and one
> for blue/orange?
>
> -Brendan
And following that thought process, does it make it any easier to
convert the colors into a Y'UV color space and use dithering based on
the approx. Y'UV space of the Apple hi-res colors? This was discussed
back in Sep. '05 by Linards Ticmanis who gave a great rundown of YUV-
to-RGB conversion for apple colors.
-B
BLuRry
moral support from Nick, I managed to get together a basic conversion
program to generate color HGR images from arbitrary jpg, gifs, etc. I
used the pseudo-color stuff I wrote a while back as a starting point
and implemented a new way of managing the palette as YIQ (ntsc color
scheme) rather than RGB. The rest kind of fell into place once the
bugs crawled away.
It's not perfect (doesn't follow the complete algorithm I proposed in
the previous posts), but going the YIQ colorspace sure made things
easier!
The code is checked in to the apple game server in sourceforge SVN:
For information on using the SVN repo: http://sourceforge.net/svn/?group_id=185513
You can see examples here: http://brendan.robert.googlepages.com/HGRditherexamples.zip
Each example has the original image, the "calculated" image which the
program thinks the hi-res should look like (yeah, it mixes up hi-order
and lo-order colors I know...), and a screenshot from the actual image
showing up in Jace (which still uses a strict 140-cols RGB rendering
mode for graphics at the moment).
Enjoy!
-B
Michael J. Mahon
I did!
Excellent first cut!
If you restrict your color dither to alternating horizontal lines
rather than adjacent horizontal "pixels", many of your high-bit
problems will go away. Logically, this cuts the vertical resolution
by as much as a factor of two, but actually, the starting and ending
of a color region can still be quantized to 1 line, so a region just
gets a "fringe"--just like a vertical edge does. ;-)
Since a notional "pixel" is then two lines high, all the high-bit-set
parts of a byte go into one line and all the high-bit-reset parts go
into the next line.
This is quite consistent with the normal digital encoding of video,
in which the luminance channel has twice the horizontal and vertical
resolution of the U and V channels.
As with all dithering, the key to viewing is to back up (or take off
your glasses ;-).
-michael
******** Note new website URL ********
NadaNet and AppleCrate II for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
BLuRry
> BLuRry wrote:
> > Okay, so a cool update. After a lightning coding run and lots of
> > moral support from Nick, I managed to get together a basic conversion
> > program to generate color HGR images from arbitrary jpg, gifs, etc. I
> > used the pseudo-color stuff I wrote a while back as a starting point
> > and implemented a new way of managing the palette as YIQ (ntsc color
> > scheme) rather than RGB. The rest kind of fell into place once the
> > bugs crawled away.
>
> > It's not perfect (doesn't follow the complete algorithm I proposed in
> > the previous posts), but going the YIQ colorspace sure made things
> > easier!
>
> > The code is checked in to the apple game server in sourceforge SVN:
> > For information on using the SVN repo:http://sourceforge.net/svn/?group_id=185513
>
> > You can see examples here:http://brendan.robert.googlepages.com/HGRditherexamples.zip
> > Each example has the original image, the "calculated" image which the
> > program thinks the hi-res should look like (yeah, it mixes up hi-order
> > and lo-order colors I know...), and a screenshot from the actual image
> > showing up in Jace (which still uses a strict 140-cols RGB rendering
> > mode for graphics at the moment).
>
> > Enjoy!
>
> I did!
>
> Excellent first cut!
Thank you! :-)
>
> If you restrict your color dither to alternating horizontal lines
> rather than adjacent horizontal "pixels", many of your high-bit
> problems will go away. Logically, this cuts the vertical resolution
> by as much as a factor of two
Yeah I know exactly what you mean! :-) I let java do the dithering
blindly and anticipated the result. More realistically, it would
work better if I dither two seperate images, one for low and one for
high, and combine the same way you've described, and probably do a
little cleanup on the fly wherever needed. At any rate, the
algorithms to manage this are simple once working in the YIQ color
space.