Maintaining a 1-bit Bridge
Aug. 14th, 2019 08:39 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
krpalmerTrying out a Python program that dealt with images did remind me how I’d got another program in that language working. Closer yet to the arrival of macOS 10.15 “Catalina” and its retirement of all “32-bit applications,” I decided to reassure myself of my potential replacement for something between an utility and a diversion for me, a program that can render an image with the peculiar nostalgia of “1-bit,” black-and-white Atkinson dithering.
Before launching the program anew, though, I decided to update my Python distribution, even if something went awry such that I just wound up reinstalling it. I then started the program from Terminal, only to be hit with a spray of error messages. It took some careful reading through them and following a link to sort out the just-in-time compiler module that was supposed to speed up the pixel-by-pixel inspections of dithering couldn’t deal with a particular function call in the sped-up section and was now reporting how it was dropping back to a less impressive form of acceleration. Whether this had been an unnoticed problem all along or now just threatened to invoke half-sensed warnings to “never upgrade under any circumstances ever” (if most often perceived when worrying about changing operating systems), I still wondered if I might actually solve the problem.
Disabling the compiler eliminated the error messages, but slowed down the program quite a bit. My first naive thought was to move the problematic function call outside the function, but a few error messages later I had sorted out how to pass variables and other quantities to functions in Python. At that point, though, I started getting hit with error messages from the image-handling library. Another rally from impending despair later, I had the impression the error had to do with the array of numbers returned by the sped-up dithering function was filled with integers with too many bits to be turned into a new image, and the problem only cropped up when the compiler was used. My first thought was that I could somehow set up the arrays passed to the dithering function to be filled with integers of the appropriate bit length, but my best efforts to do that (and get the program to report its in-progress states) didn’t seem to make a difference.
At that point, I took a look at another Python program I’d turned up, which offered no pretensions of “fast output” but which did offer multiple dithering algorithms and the possibility of using limited palettes less limited than black and white, such as the infamous four colours of CGA or the more fondly remembered Commodore 64 colours. (It, however, had taken sorting out how to get Python 2 running alongside Python 3.) All of a sudden, I realised the “integer type” I wanted to pass to image handling could be invoked as a function itself. However, between the realisation and the implementation I had to go to work, which left me wondering for a day if this really would work or if I hadn’t yet perceived something still more elusive.
When I had my chance at last to work on the program again, adding the conversion eliminated the error messages and started producing output again. Before I could find satisfaction in that, though, I’d realised the output didn’t look the way it once had; it seemed “blown-out and raggedy.” Passing a different threshold value between black and white to the program made the output look a bit better, but that still didn’t feel like a complete solution. Then, though, I happened to think I still had my previous attempts to pass “shorter integers” to the dithering function, and when I took them out things were sorted out at long last.
While I did feel as if I’d accomplished something, and perhaps might even ought to sign up for Github and sort out how to make my modifications available to more people, I could at least consider this sort of program modification might amount to someone managing to strike a match on a rock rather than a worn-out matchbox even as others construct arc lights all around. Not that long after getting the program running I was looking at the Internet Archive’s old Macintosh software to see a Hypercard stack using “Stranger Things” images, and therefore a recent creation, that mentioned using the old mainstay GraphicConverter to create its 1-bit images. Checking the application’s manual suggested it had Atkinson dithering built in. It would be expensive for a one-trick pony (and I’m not touching up images the way I once did with a different photo editor), but it’s still something to consider going ahead.
Before launching the program anew, though, I decided to update my Python distribution, even if something went awry such that I just wound up reinstalling it. I then started the program from Terminal, only to be hit with a spray of error messages. It took some careful reading through them and following a link to sort out the just-in-time compiler module that was supposed to speed up the pixel-by-pixel inspections of dithering couldn’t deal with a particular function call in the sped-up section and was now reporting how it was dropping back to a less impressive form of acceleration. Whether this had been an unnoticed problem all along or now just threatened to invoke half-sensed warnings to “never upgrade under any circumstances ever” (if most often perceived when worrying about changing operating systems), I still wondered if I might actually solve the problem.
Disabling the compiler eliminated the error messages, but slowed down the program quite a bit. My first naive thought was to move the problematic function call outside the function, but a few error messages later I had sorted out how to pass variables and other quantities to functions in Python. At that point, though, I started getting hit with error messages from the image-handling library. Another rally from impending despair later, I had the impression the error had to do with the array of numbers returned by the sped-up dithering function was filled with integers with too many bits to be turned into a new image, and the problem only cropped up when the compiler was used. My first thought was that I could somehow set up the arrays passed to the dithering function to be filled with integers of the appropriate bit length, but my best efforts to do that (and get the program to report its in-progress states) didn’t seem to make a difference.
At that point, I took a look at another Python program I’d turned up, which offered no pretensions of “fast output” but which did offer multiple dithering algorithms and the possibility of using limited palettes less limited than black and white, such as the infamous four colours of CGA or the more fondly remembered Commodore 64 colours. (It, however, had taken sorting out how to get Python 2 running alongside Python 3.) All of a sudden, I realised the “integer type” I wanted to pass to image handling could be invoked as a function itself. However, between the realisation and the implementation I had to go to work, which left me wondering for a day if this really would work or if I hadn’t yet perceived something still more elusive.
When I had my chance at last to work on the program again, adding the conversion eliminated the error messages and started producing output again. Before I could find satisfaction in that, though, I’d realised the output didn’t look the way it once had; it seemed “blown-out and raggedy.” Passing a different threshold value between black and white to the program made the output look a bit better, but that still didn’t feel like a complete solution. Then, though, I happened to think I still had my previous attempts to pass “shorter integers” to the dithering function, and when I took them out things were sorted out at long last.
While I did feel as if I’d accomplished something, and perhaps might even ought to sign up for Github and sort out how to make my modifications available to more people, I could at least consider this sort of program modification might amount to someone managing to strike a match on a rock rather than a worn-out matchbox even as others construct arc lights all around. Not that long after getting the program running I was looking at the Internet Archive’s old Macintosh software to see a Hypercard stack using “Stranger Things” images, and therefore a recent creation, that mentioned using the old mainstay GraphicConverter to create its 1-bit images. Checking the application’s manual suggested it had Atkinson dithering built in. It would be expensive for a one-trick pony (and I’m not touching up images the way I once did with a different photo editor), but it’s still something to consider going ahead.