Python Image Resizing


My journey to Python continues. I’ve been playing on a Raspberry Pi project and it’s been working quite well! In the meantime, I’ve still got work to do, and lately (at work) I’ve had to deal with a lot of screenshots that get emailed, and when I started it was just a few, so I’d open the PNG files in Photoshop, resize them, and save them out as compressed JPG files. This started to get painful as I had to do more of them, and as a fun little comparison, while Photoshop CS5 runs quite fast on my 2012 MacBookPro, Photoshop CC 2019 is terrible on my 2017 iMac.

Side-rant: I hate Adobe’s forced subscription model, and Photoshop CS5 does most of what I need to do. Adobe’s Creative Cloud is caught in an forced update cycle where they have to add things, many of which may not be useful (to you) and are probably resource hogs, too. CC 2017 was quite a bit faster than CC 2019. (End of rant!)

Anyway, back to Python. Since I’m often looking for excuses to write Python lately, I checked to see if there was an easy way to resize images and convert from PNG to JPG. There sure is, and it took me just a few minutes to find some working code. This sped up my screenshot situation quite a bit! The one hiccup in finding Python example code online is that it’s often for Python 2.x instead of Python 3.x and needs some minor adjustments.


While typing Python commands in the terminal was working fine, I’ve been around the block before with this sort of thing… In fact, in 2012 Wilfredo Sanchez put out DropScript and I used it for many Perl scripts to make my life easier. Luckily I wasn’t the only fan of DropScript, and there’s a modern version of DropScript! Oh yeah, so the way it works is that you can take a script (written in whatever language) and make it run when you drop files on it. It’s a customizable droplet. I remember I had a big folder full of droplets for web development and file management. It was handy.

So it took another 10 minutes, but I converted my Python script to a DropScript application so now things are even faster… drag and drop, no typing!

I still need to make my Python a little more accepting. For instance, I have to drop files on it, but it would be nice to be able to drop a folder full of files onto it. Baby steps, right? I’ll keep hacking away at Python as I get time. And I will admit, the cleanliness of Python is sort of nice…


uArm Swift Pro Plotting


We recently got a uArm Swift Pro robot arm at Brinn Labs and I’ve been putting it through its paces. It comes with software called uArm Studio that lets you do a lot of things, but for this post I’ll focus on drawing (or “plotting”) using a pen.


One of the tools I’ve used in the past with the Egg-Bot was StippleGen2 from our friends at Evil Mad Scientist Laboratories. StippleGen2 is a program written in Processing that takes an image and converts it into a series of lines, or more specifically, a single line, which is suitable for plotting.

Above is the image I started with, an “8-bit heart” as I call it. It’s a simple black and white image of a low-res heart. (Great for Valentine’s Day, right?)


After running the heart through StippleGen2 and choosing the appropriate complexity of the line drawing I wanted, I saved out the file as an SVG format vector file. Perfect for plotting. (In fact, since it’s a single line, the z axis never has to move up once it starts.)


I fired up uArm Studio and chose the Draw/Laser feature, and then loaded in the SVG file. I did have to scale it up a bit, as I still don’t have the exact dimensions I should use for artwork in uArm Studio.

Once the file is loaded, you hit start and there’s a step where you set the z axis so it know where the pen hits the paper. At this step, I wish there was a little more control over how the z axis moves. I think the smallest increment is one millimeter, and I think it should be smaller. (Most CNC software has some adjustment to how much you move things, so I can see adding in 0.5mm and perhaps 0.2mm as well.)


While the uArm Swift Pro is awesome, I’m still going to be a little critical… One of the issues I’ve come across in the Draw/Laser part of the software is that the speed seems to be hard-coded, with no way to adjust it to go faster (or slower.) As someone who understands G-code and how CNC machines work, I found this a little annoying…


So I set about to find a solution. I first posted a message on the forum, but then Chinese New Year hit and it seemed as though it would be two weeks (or more) before I got an answer. I had dug around and found that the G-code created by the Draw/Laser part of the software generates a file and drops it at ~/uarm/Temp/files/gcode/tmp_pen.gcode and I assumed that by editing the feedrate in that file, I could speed things up… I was right!


My first attempt was to connect with the arm using Universal Gcode Sender, which in this case was not universal, and failed to properly talk to the arm. I dug around a bit more and found which is a Python script to stream G-code to a device. Sadly, it was not compatible with Python3, but luckily, I’ve been writing a lot of Python lately, so I fixed it.

After I got it working (that is, after much hacking at the original code) I found that I could easily speed up the drawing to half the time. In this case, 5 minutes with the Python script versus 10 minutes with uArm Studio. For TSP art, great precision tends not to matter too much, and I think I could speed it up even more.

I’ll work on cleaning up my Python code and seeing if I can get it online in case others want to muck around with it.

Update: Code is here:


Python is (supposedly) Easy!

I decided that in 2019 I would dive into Python. I’ve used Python before, but I’m not at the level I want to be with it. I’ve developed a comfort with Perl over the last 20+ years, and it’s lived up to the name of “Swiss army knife” or “Swiss army chainsaw” of scripting languages. I’m sure I’ve written hundreds (thousands?) of Perl scripts to get things done over the years.

Python has been a bit different. I nearly jumped into Python in my former career when we were about to embrace Zope, but that didn’t happen, so I didn’t really get into Python. I started using Python a lot more seriously when I realized that support for Python on the Raspberry Pi was pushing way ahead of Perl on the platform. Add to that the stuff happening with CircuitPython and it’s the direction I want to go.

So let’s get started! First of all, I had to get Python3 installed, as Mac OS X ships with an older version. This is similar to how things worked with Perl, so I got Homebrew running, got Python3 and PIP working, and started writing some Python.

I also found Mu, a simple Python editor for beginner programmers (probably through Adafruit) and it seemed like a nice little editor to experiment with, and worked with CircuitPython.


I should note that learning a new (computer) language is probably easier now than it was 25 years ago. I remember printing out documentation and reading through it, highlighting things to try when I got in front of a computer. Twenty-five years ago I didn’t have a laptop or an always-on Internet connection, and the resources were not quite as abundant. Anyway. I wrote some code!

Above is a simple Python script to list every file in a folder. This is (or should be) dead simple and is needed in many scripts. When I ran it in Mu, it showed some output, but not all of the output I expected. I ran it again, and it showed something different. I ran it again, and got output I did not expect.


So I did what anyone who knows the command line would do, and ran the script there. It worked as expected. Perhaps it’s a bug in Mu? I searched the issues in github, and did some Google searches, and didn’t find anything. Weird. I liked Mu and didn’t want to abandon it, as I want to use it with CircuitPython, but is there some weird buffering bug?

I remembered that one of the most amazing things about when I first started using Perl was how fast it was. At least compared to AppleScript or UserTalk at the time. Maybe I’m going to fast…


I added one line to slow things down. I know that in other Python scripts I’ve used or written in the past few years that time.sleep was often used. Adding in a slight delay made the expected output get outputted. Weird. Whatever. Now I know… I guess?

When I started with Perl I wrote a bunch of simple scripts to learn the language. (I’ve done this with Processing, Arduino, and other languages/environments.) When I learned how arrays worked in Perl I wrote a script named “” and kept it around as an example. Same with “” and “” and so on. As I was learning things I’d reference these files to get a quick look at how a function worked.


I wrote a script named “” and it was dead simple, with just 3 lines, and the first line didn’t really do anything but I’m in the habit of using shebang lines because I’ve been around the *nix block a few dozen times. So really, two lines, an import and a print.


When I tried to run a Python script just slightly more complex than “Hello World” I got an error… Python nerds may have figured out what went wrong at this point.


Just for fun I dropped the code into Mu and tried to run it… of course you have to save your script before you can run it so… Ahhh, I guess I cannot name my script after an internal function/file that Python uses. At this point I’m just angry, and disappointed that now I have to somehow know what is and is not an acceptable filename for a Python script. I’m sure in the future I’ll name one wrong and it won’t work and I’ll spend more time than I should trying to remember this. (Hopefully I’ll find this blog post.)


I changed the name to and it worked fine. Damn you, Python! But I remain undeterred, and I plan to continue on with Python. In fact, all of the stuff above is part of replacing an old Perl script I had running on Raspbian to be written in Python. So… progress! Welcome to 2019, Python.


Defending Perl

I stand here today not to condemn Perl, but to defend it… Perl

And when I say “Perl” I want you to feel free to substitute any other language you see fit… Visual Basic, Fortran, Lisp, COBOL, Smalltalk, or even… Java.

I was given a programming assignment this week. Given a list of 2000 names, I was to provide 400 names randomly. (Yes, this was for work, and was a real-world assignment, not just some exercise.) I proceeded to open my ~/scripts folder, which contains well over 1,000 Perl scripts, and grabbed some existing code, and wrote some new code, and ran a few tests, and quickly had the list of 400 names.

I used Perl because it worked for me. I probably could have written in it PHP (as it’s another language I am pretty comfortable with) but since I’m more familiar with Perl, and have done very similar thing before with Perl, and had a gigantic library (nearly 15 years worth) of Perl scripts to pull from… I used Perl.

I’m sure others could tell stories just like this substituting Java, or Python, or Erlang, or whatever they have around, that they are the most familiar with… and that’s fine.

This is about using the appropriate tool for the job, and this case, with the job being performed by me, the tool was Perl.

I wasn’t creating some new framework, or building upon an existing application, or pushing some code to GitHub that I wanted others to collaborate on… it was a quick ‘n dirty task that needed to get done as fast as possible.

Much of the programming world (maybe it’s mostly in the web-programming world) gets hung up on the latest and greatest. There’s a chance that using Ruby someone could have completed this task in half the time… but that person would not have been me, as I’ve spent probably less than an hour using Ruby and I’m not familiar enough with it to bang out the needed code quickly. I’d like to have some time to dig into Ruby (or, whatever, pick a language) and get familiar enough with it to use it effectively, but I don’t know when that will happen.

I’m not even a programmer… I’m a hacker, and I think Perl is a hacker’s language. Make something work. Solve a problem. Do it quickly, and move on.

To some degree you could say I’m trapped in Perl, because it is so easy for me to get what I want done quickly, and yeah, there’s a module for almost everything… Where I mainly feel the pain is when I look for example code and narrow my search to Perl (or PHP) because I’m most familiar with them. I needed some code this week to do some serial port communication, and found only one good example written in Perl. I should probably task myself with re-writing the code in Ruby, or Python, or some other language I’m not as comfortable with as an exercise in forced learning.

And then there’s a part of me that just says “screw it, I’m gonna work with what I know, and get things done, and move on.”


Fear of an Aggregated Planet

Let’s mix it up a little… Perl, Python, HTML-TemplateAtom, RSS… Words, Photos, Links, and Objects of Desire…

Say what?

Say Planet Planet!

Or say Planet RasterWeb!

There are billions and billions of planets out there, well, ok dozens maybe. (Heck, there’s even a WordPress Planet.) the one that was the tipping point for me was Planet Burningbird, which is explained in It’s the Oddest Thing.

After seeing Planet Burningbird, I said “Heck, let’s do it!”

The Planet website has no real documentation and very little explaining things. (True geek software, eh?) I downloaded whatever version I could from whatever link I found, and took a look. Python. I mean, I completely gave up on Python earlier this year, but, well, OK. We’ll give it a try…

Now, on Mac OS X I did have a hiccup or two. Searching…. Ok, this post about Mac OS X fixed things. After that it was on to templating. Ah! HTML-Template, but done in Python. (Gosh, where have we heard about HTML-Template before?)

So templating was fairly simple, since I knew the tags. What’s next? Feeds! Yes, we need some feeds… I grabbed my own feed from this site, as well as my feeds from and Flickr and… Is that it? Hmmm, I need more feeds. Luckily I had been experimenting with a Perl module named WWW::Amazon::Wishlist to create an RSS feed of my Amazon Wish List. Of course some of the stuff on my wish list was from the year 2000, so I had to update it. (Honestly I don’t expect anyone to ever actually buy me a gift, but you know, if you want to, the option is there… hint, hint. Aw, who am I kidding? I can barely get feedback on the stuff I do here…)

So where was I?

Ah yes, Feed the Planet, yes… Oh, PubSub! I got two feeds there! One for sites that link to RasterWeb! and one for sites that “mention” RasterWeb!. You’d think if they mention it, they’d link to it, but they seem to have different results. So in theory now, if you link to this site, you should show up on the planet. (This might go sour in the future, we’ll see…)

Is there more? Sure! Though Planet doesn’t seem to handle enclosures in any way, we also have RasterWeb! Audio, which is one of those “podcasting” things we started back in August before podcasting even had a name…

Ok, so that’s the lowdown on the planet. It’s seems to have been released under the same license as Python, and a quick check with the Open-Source Initiative’s Licenses says it’s open-source. (I think.)

Any problems? Well, it doesn’t quite validate. I mean, all the feeds I have control over seem to validate fine, but the Planet page itself doesn’t, partly due to the foreign content from the PubSub feed, and maybe because of Planet doing something silly as well.

So that’s my combination of Perl, Python, HTML-Template, Atom, RSS,, Flickr, PubSub, and other things I won’t mention again. Enjoy!