16 November

Safari vs. WordPress 6.7 Block Editor: Who’s to blame for forced PNG-to-HEIC conversion?

Look at this image:


Now look at this one:


What if I told you those were the same image? Well… I mean… they’re not. Obviously. But they’re supposed to be. They were both the same image when they were on my computer. The same exact file. But I uploaded them to this page in two slightly different ways, and that made all the difference.

The one on top — the screwed-up one — I placed by inserting an Image block in the WordPress Block Editor, and then clicking the Upload button in that block, navigating my hard drive, and locating the image. The one on the bottom, I placed by again inserting an Image block, but this time I just dragged the image from a Finder window into the Safari window. WordPress supports drag-and-drop uploads.

Looking “under the hood,” I discovered that the file on top was somehow getting converted to Apple’s “High Efficiency Image Format,” HEIC (the reason for the C instead of an F is something I’ll leave to the Apple podcasters). WordPress just added HEIC support in version 6.7, which was released this week. Since browsers (other than Safari, I assume) can’t display HEIC images, WordPress automatically converts uploaded HEIC files to JPEG. And that’s why these two images look different. JPEG doesn’t support transparency, so the areas that were transparent in the original PNG got flooded with the nearest available colors1.

But, why should the results of these two upload processes be any different?

Well, after starting in the WordPress Support Forums and then moving over to the Make WordPress Core Trac and finally searching until I stumbled upon a year-old, barely active thread on the Apple Developer Forums, I discovered that Safari has a bug — I mean it has to be a bug, right? — where, if a file upload input field says it accepts HEIC format, Safari automatically converts the uploaded file to that format, apparently with no option not to do that. (I looked around all of the settings, even the developer ones, and didn’t see anything about this “feature” at all.)

And sure enough, WordPress 6.7 is a bit haphazard with its “support” of HEIC uploads, which made it easier to confirm the cause. There are two ways, generally speaking, that WordPress handles file uploads: the browser upload, via an <input type="file"> HTML field, and a JavaScript/AJAX/React/whatever drag-and-drop option.

The <input type="file"> field in the Image block of the Block Editor has added HEIC support via the accept="image/heic" attribute. But the input field in the old school Media Library upload page has not been similarly updated. (It’s become a fact of life in the WordPress world that most of the core team’s attention is on Block Editor stuff these days, and older features get ignored.) Uploading images in the Media Library does not do the conversion. Likewise, whatever exactly is going on with the drag-and-drop method also does not involve the accept="image/heic" attribute that causes Safari to do its mischief.

Unfortunately, it looks like the only “solution” at this point would be for WordPress to do a browser sniff and remove the accept="image/heic" attribute if the browser is Safari. The only reason that was explicitly added was to get Chrome to support HEIC uploads; as I understand it, Safari would support them regardless, but explicitly declaring HEIC support is apparently what triggers Safari to make the conversion.

So, practically speaking, Safari users who want to upload PNGs to their WordPress sites just need to be sure to only upload via drag-and-drop, or the Media Library.

(I haven’t tested, but I suspect JPEG uploads are likewise getting converted to HEIC and then back to JPEG, which probably results in a reduction of image quality.)

Side note on how I discovered this in the first place: Two days ago I was writing another blog post somewhat critical of Apple, and I found when I was trying to upload a screenshot of a window from my Mac — Mac screenshots are saved as transparent PNGs — the transparency was turning black. I was so driven to distraction over the situation that I barely managed to finish writing the post.

1 Saying those areas are flooded with color is an oversimplification. It looks like the color of each pixel is being determined consistently with how PNG compression works.

Covering Kraftwerk: the process (part 1)

As my Twitter followers know, I’ve concocted a harebrained scheme to record an EP of Kraftwerk covers, using solely the Pocket Operator calculator-esque synthesizers from Teenage Engineering. This project was inspired by my love of Kraftwerk and my assumption that Teenage Engineering was directly influenced by Kraftwerk (especially the song “Pocket Calculator”) in creating the Pocket Operators.

I’m taking a, let’s say, judiciously-paced approach to this project. Partly because I don’t have a lot of free time at the moment, and partly because I need to let this thing fully gestate in my brain. Also because I’m still learning how the Pocket Operators work. They’re ingeniously designed, but not exactly intuitive. (Then again, I don’t find any electronic devices besides computers intuitive. Let’s not even get started on fax machines.)

I’ve identified the four Kraftwerk songs I want to cover:

  1. Ruckzuck (1970)
  2. The Man-Machine (1978)
  3. Pocket Calculator (1981)
  4. Tour de France, Étape 1 (2003)

My first baby steps into the project were in the form of some brief tinkering with the Pocket Operators themselves to lay down the basic foundation of “Ruckzuck”, which I did from memory. (It was easy to do this one from memory; after all, I watched a lot of Newton’s Apple as a kid.) I commemorated this with a brief video posted to Instagram:

A video posted by Scott Anderson (@room34) on

This past weekend I took my second step, which went a bit further. I have decided that part of what is challenging to me with playing these Kraftwerk songs (as simple as they are) on the Pocket Operators is that I don’t have any written music to work from. So I’m introducing a second step in the process, but one that will not at all make its way into the final product. I’m creating versions of the songs entirely with software instruments in Logic Pro X, just so I have my own transcriptions (really, adaptations, because I’m not trying to get it perfect) to work from when I program the Operators.

Here we have the beginnings of my rough Logic Pro X interpretation of “The Man-Machine.”


I am excited about this project! Just hoping I can find some time in the near future to keep pushing it forward.

What will the end results be? I’m not sure. While I’ve dabbled with recording covers before, I’ve never taken them through to completion and released them into the world. I’m not even sure how I want to go about that. But so far it’s still a long way off.

New Room 34 CD coming soon…

The time has come once again for me to engage in the extreme narcissism of producing a compilation album. I’ve recorded a crap-ton of music this year (even outpacing 2008, my most prolific year to date). Most of it I’m pretty proud of. Some, not so much. But this CD is just the good stuff. 13 tracks, 10 recorded in 2011 and 3 recorded in 2010. All remixed and remastered, with a kick in the pants in the form of boosted bass. So if you like your music with more low end than I’m accustomed to giving, this CD should suit you fine.

I’m putting the finishing touches on the masters this week, and am hoping to have the CD ready for production next week. In the meantime, here’s the cover art…

Update: So, yeah… this is available now. You can get it on iTunes or Amazon MP3 or, if you prefer physical media, direct from Kunaki. No free downloads yet. TBD on that.

Reason enough (for me) to install Windows (and Google Chrome)

Sure, I own a real NES. Two, in fact. I also own a GBA Micro, Nintendo DS, and a Wii, with emulated versions of all of my favorite NES classics. And then, of course, there’s emulation.

But as a web developer, I just have to geek out on this: the very idea of a working NES emulator running entirely in JavaScript… wow. I’ve known about JSNES for a few months, but I hadn’t had the time and/or inclination to fire it up in Google Chrome (still Windows-only), the only browser so far that has a JavaScript interpreter efficient enough to run it at a decent frame rate.

The last time I tried running it was on the iPhone. Yes… it did run… at about 1.5 FPS. And, of course, there’s no way to access the controls. But in Chrome… it’s actually playable. A smidge slower than the real thing (which would be at 60 FPS), but as you can see, I got it up to 46 FPS. Not bad. Especially considering that I was running Windows 7 with Parallels Desktop on the Mac. Nice!

JSNES