Antique Artifacts Anew
Mar. 26th, 2023 03:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
krpalmerHappening to think again of a program I’ve used to make “double hi-res” images for the Apple II (in emulation most of the time), I checked it out once more and discovered its programmer had added a feature speculated about before. The program can now also boil its input down to the earlier but perhaps more familiar “hi-res” Apple II format. I suppose it’s an alternative to a different program for Windows that converts to that format, which I run using “Wine.” (It’s not altogether a replacement; to get the graphics files made by the command-line program onto Apple II disk images I’ve used the utility “CiderPress,” which still means using Wine.)
Amid those homely, minor charms, though, I did get to thinking of a different old computer with different and still simpler graphics, but which is rooted further back in my own past. Apple II high-resolution colour graphics are made up of black, white, orange, blue, green, and violet (which makes representing the different “six colours” of the period company logo a bit tricky). The last four colours are “composite artifact” colours; on a monochrome monitor they’d appear as alternating dark and bright vertical lines. I understand there are tricks to just how a full four colours result from that (the very first Apple II computers could only show green and violet), and as for the Radio Shack Color Computer my family used, the artifact colours were just orange and blue. There’s something familiar for me to this day about that unchanging palette (although with one racing game I did twiddle the TV set’s tint to turn “blue” into “green grass.”)
Around the same time as I was trying out the upgraded program I happened on a Wikipedia article about composite artifact colours that had a section on the Color Computer. The section going to the point of suggesting black and white pixels had been spaced out in ways varying enough to produce “sixteen shades” had me thinking “citation needed,” for all that I did remember some programs had attempted “lighter orange” and “lighter blue.” I also started thinking about the “retro image” application on my iPad I’d used just to see what sort of bitmapped image could squeeze onto a TRS-80 Model 100’s screen, and how I could at least try and create a “four-colour ‘CoCo’ palette” in it, using an graphic program “eyedropper” on a screenshot from Wikipedia. Once I’d done that, I got to thinking again. If the “wide” orange and blue blocks were “really” alternating white and black lines, it just might be possible to convert them to that and run that monochrome image through Color Computer emulation.
To do that I accepted the pointer of the first converter and began delving into the Python image-manipulation library “pillow.” I’d once bought a book about learning to program in Python, but not got much beyond its type-in examples. With an online tutorial or two at hand and much combing through the pillow documentation, though, I did begin to get a sense of how to read through a four-colour image from my iPad pixel by pixel, determine the colour of each block, and replace it with two pixels varying by what they’re supposed to represent.
This took realising the array-manipulation library “numpy” the tutorial had pointed me to described its arrays in “y, x” order, and then sorting out I could actually do everything with pillow. I needed to remember when to put colons at the ends of lines setting up loops and logic cases and just how to represent numbers, and also that with the way I was trying to make images I had to represent “white” with the number 255, not 1. In the end, though, I had a black and white image full of vertical stripes. At that point I could resort to a command-line tool I’d already used before to create “RLE image files,” which are almost as old as Color Computer images themselves and larger than those bitmaps for all that they’re cross-platform and simple to describe. I worked one RLE image into a Color Computer disk image and started an emulator, to discover its default artifact colours made what I’d hoped would be orange blue and what I’d hoped would be blue orange. That, though, wasn’t hard to change. I did have the distinct impression the emulator’s “orange” and “blue” were different from Wikipedia’s suggestions, and tried adjusting my iPad converter; that, though, had more of an effect on the converted images than I’d thought.
My Python converter is still primitive, hard-coded, and without built-in error-checking, but I did get to the point of going from a modern replica to an emulated computer screen. I also got to thinking, though, that a pixel artist could be defter than the “halving the horizontal resolution” trick I’d resorted to. It did bring modern “text-to-image” programs to mind. I don’t want to condemn those who (think they) “can’t draw” getting excited at the thought of producing an image apparently unseen in whole before, or even those who can draw a little (like me) resorting to the “image-to-image” mode. At the same time, it has to be acknowledged it isn’t the same as drawing unaided.
Amid those homely, minor charms, though, I did get to thinking of a different old computer with different and still simpler graphics, but which is rooted further back in my own past. Apple II high-resolution colour graphics are made up of black, white, orange, blue, green, and violet (which makes representing the different “six colours” of the period company logo a bit tricky). The last four colours are “composite artifact” colours; on a monochrome monitor they’d appear as alternating dark and bright vertical lines. I understand there are tricks to just how a full four colours result from that (the very first Apple II computers could only show green and violet), and as for the Radio Shack Color Computer my family used, the artifact colours were just orange and blue. There’s something familiar for me to this day about that unchanging palette (although with one racing game I did twiddle the TV set’s tint to turn “blue” into “green grass.”)
Around the same time as I was trying out the upgraded program I happened on a Wikipedia article about composite artifact colours that had a section on the Color Computer. The section going to the point of suggesting black and white pixels had been spaced out in ways varying enough to produce “sixteen shades” had me thinking “citation needed,” for all that I did remember some programs had attempted “lighter orange” and “lighter blue.” I also started thinking about the “retro image” application on my iPad I’d used just to see what sort of bitmapped image could squeeze onto a TRS-80 Model 100’s screen, and how I could at least try and create a “four-colour ‘CoCo’ palette” in it, using an graphic program “eyedropper” on a screenshot from Wikipedia. Once I’d done that, I got to thinking again. If the “wide” orange and blue blocks were “really” alternating white and black lines, it just might be possible to convert them to that and run that monochrome image through Color Computer emulation.
To do that I accepted the pointer of the first converter and began delving into the Python image-manipulation library “pillow.” I’d once bought a book about learning to program in Python, but not got much beyond its type-in examples. With an online tutorial or two at hand and much combing through the pillow documentation, though, I did begin to get a sense of how to read through a four-colour image from my iPad pixel by pixel, determine the colour of each block, and replace it with two pixels varying by what they’re supposed to represent.
This took realising the array-manipulation library “numpy” the tutorial had pointed me to described its arrays in “y, x” order, and then sorting out I could actually do everything with pillow. I needed to remember when to put colons at the ends of lines setting up loops and logic cases and just how to represent numbers, and also that with the way I was trying to make images I had to represent “white” with the number 255, not 1. In the end, though, I had a black and white image full of vertical stripes. At that point I could resort to a command-line tool I’d already used before to create “RLE image files,” which are almost as old as Color Computer images themselves and larger than those bitmaps for all that they’re cross-platform and simple to describe. I worked one RLE image into a Color Computer disk image and started an emulator, to discover its default artifact colours made what I’d hoped would be orange blue and what I’d hoped would be blue orange. That, though, wasn’t hard to change. I did have the distinct impression the emulator’s “orange” and “blue” were different from Wikipedia’s suggestions, and tried adjusting my iPad converter; that, though, had more of an effect on the converted images than I’d thought.
My Python converter is still primitive, hard-coded, and without built-in error-checking, but I did get to the point of going from a modern replica to an emulated computer screen. I also got to thinking, though, that a pixel artist could be defter than the “halving the horizontal resolution” trick I’d resorted to. It did bring modern “text-to-image” programs to mind. I don’t want to condemn those who (think they) “can’t draw” getting excited at the thought of producing an image apparently unseen in whole before, or even those who can draw a little (like me) resorting to the “image-to-image” mode. At the same time, it has to be acknowledged it isn’t the same as drawing unaided.