Archive for April 20, 2016

Wednesday, April 20, 2016

GPUImage 2, Redesigned in Swift

Brad Larson (tweet, comments):

The rewritten Swift version of the framework, despite doing everything the Objective-C version does*, only uses 4549 lines of non-shader code vs. the 20107 lines of code before (shaders were copied straight across between the two). That’s only 22% the size. That reduction in size is due to a radical internal reorganization which makes it far easier to build and define custom filters and other processing operations. For example, take a look at the difference between the old GPUImageSoftEleganceFilter (don’t forget the interface) and the new SoftElegance operation. They do the same thing, yet one is 62 lines long and the other 20. The setup for the new one is much easier to read, as a result.

* (OK, with just a few nonfunctional parts. See the bottom of this page.)

The Swift framework has also been made easier to work with. Clear and simple platform-independent data types (Position, Size, Color, etc.) are used to interact with the framework, and you get safe arrays of values from callbacks, rather than raw pointers. Optionals are used to enable and disable overrides, and enums make values like image orientations easy to follow.

Because of open-source Swift, it now supports Linux. On the Mac and iOS side, though, it is surprising that this sort of thing is necessary when Apple provides Core Image. The original project claims:

This framework compares favorably to Core Image when handling video, taking only 2.5 ms on an iPhone 4 to upload a frame from the camera, apply a gamma filter, and display, versus 106 ms for the same operation using Core Image. CPU-based processing takes 460 ms, making GPUImage 40X faster than Core Image for this operation on this hardware, and 184X faster than CPU-bound processing. On an iPhone 4S, GPUImage is only 4X faster than Core Image for this case, and 102X faster than CPU-bound processing. However, for more complex operations like Gaussian blurs at larger radii, Core Image currently outpaces GPUImage.

Developing for the Amazon Echo

Genady Okrain:

While people might argue that you can send an app to Apple for review and later change it completely from your backend. It is uncommon for people to do so. With Amazon Alexa Skills, you can update your response at any time. I am unsure if they monitor your updates and review them later.


To install a skill people need to have the Alexa app on their phone, this app is not a native app but some kind of web app and it’s really hard to navigate and use. While the capabilities of the Echo are remarkable, the app experience is very poor.

One important missing thing in the skills store is selling skills, currently everything is free. You can use your login and handle everything by yourself, but without a real business model for developers, I can’t see skills as a real game changer. Only small skills like ours and add ons for already existing services are possible.

The Echo initially sounded redundant to me, since I have an iPhone with “Hey Siri” and HomeKit support. But Siri is slower, doesn’t work when the phone is in my pocket, and doesn’t have an API. Amazon’s digital hub for the home seems to support more devices. Apparently, it even works with music from iTunes, via an iOS app. I still don’t really know what I would use it for, but it seems promising.

Update (2016-05-09): David Sparks:

Amazon’s Echo does a better job of parsing the question and giving you useful information. Too often, Siri gets confused because you don’t ask the question just right. Also, the Amazon Echo has never done that thing where it seems to understand me perfectly only report it can’t answer my question because of some mysterious problem out there on the Internet … somewhere. Either way, in the Sparks household the Amazon Echo has been a clear winner for my wife and children.

Update (2016-05-10): Daniel Jalkut:

One of his key points was that Alexa, by being theoretically less capable than Siri, manages to avoid the heightened expectations and subsequent disappointment that users feel when Siri fails to listen as well as it promises to. It may be less competent overall, but what it does do it does predictably and well.

A comparison that came immediately to my mind was Apple’s mid-1990’s failure with the Newton handheld computer.

Our Software Must Get Better

Seth Godin:

Imagine what would happen if this were true for buildings… if the efficiency and style and ambience of every building in the world could be fixed, all at once, in exchange for one investment.

Alas, software tends to be mediocre.


Perhaps the biggest problem: In many markets, especially online, software is free. And free software built by corporations turns us from the user into the product. If you’re not paying for it, after all, you must be the bait for the person who is. Which means companies spend time figuring out how to extract value once we’re locked in and can’t easily switch.