Posts by Alexander Synaptic

Experimenting with Google’s deepdream project on OS X

Dreaming new worlds into being
This is what happens when you leave deepdream on overnight.

I have been experimenting with Google’s deepdream project in the last few days. Since I started posting images around (most prominently this collection of dreamscapes) people have been asking: how can I make my own? This short collection of notes represents an early attempt to gather up enough information for technically-minded people on Mac OS X to start dreaming.

Rather than compile from source I used Ryan Kennedy’s Docker container method. If you are new to Docker (like I was) you may find this guide to be helpful, assuming you already use Homebrew. From this we can assemble some rough steps to follow (but be sure to reference the original guides for more details):

  1. Install Homebrew.
  2. Install VirtualBox. You’ll need to download an installer and execute it the old-fashioned way. This is used to run boot2docker, a lightweight Linux distribution specifically designed for running Docker containers.
  3. Install Docker and boot2docker from the command line with: brew update, brew install docker, and brew install boot2docker.
  4. Initialize and load boot2docker with boot2docker init and boot2docker up. I also had to run some command line voodoo with $(boot2docker shellinit) to get things working. If all goes well you’ll get an IP address you can use in the next step.
  5. Set a Docker environment variable with export DOCKER_HOST=tcp:// (or whatever IP address you saw in the last step).
  6. Fetch the deepdream container with docker pull ryankennedyio/deepdream.
  7. Load the container with docker run -d -p 443:8888 -e "PASSWORD=password" -v /[path]:/src ryankennedyio/deepdream. Be sure to replace [path] with a valid path to a working folder. This will be accessible from within the Docker container (which means you can also store other models there).
  8. Run boot2docker ip and navigate your browser to the IP address it returns (prefaced with https://). Ignore the security warning, enter password, and this should load the Python notebook originally released by Google.

After a system restart you will need to repeat most of the steps from 4 to 8 above (without boot2docker init or step 6).

Actually using the notebook requires some trial and error if you’re not familiar with the conventions (as I wasn’t). Ryan Kennedy’s original post provides some basic tips on navigating the interface. In short, click on code blocks from the very top and hit the play button until you reach the code block that defines the img variable. Here you will want to enter a filename that matches one in the path specified when the Docker container was originally loaded. If you want to skip right to the “inception” style image generation head down to the pair of code blocks that starts with !mkdir frames and execute both in sequence. If everything is wired up correctly your computer will start dreaming.

How about customizing the output? I am no expert in Python or neural nets so I’m doing a lot of guesswork that might be foolish or wrong but I can relate a few things I’ve found.

First of all, to swap in another model you can download one from the model zoo, copy the files to your working folder, and alter the model definitions in the second code block like so:

model_path = '/src/models/googlenet_places205/'
net_fn = model_path + 'deploy_places205.protxt'
param_fn = model_path + 'googlelet_places205_train_iter_2400000.caffemodel'

These are the settings for Places205-GoogLeNet, another neural network used in the original post by Google. As the name would imply this one has been trained to recognize a dizzying variety of different places. In my admittedly limited experience thus far I’ve mainly seen regular features of manmade landscapes—temples, windmills, castles, and so on—as well as a variety of other scenes like baskets of fruit, piles of clothing, grocery store shelves, halls filled with chairs, and the like.

Whatever model you use you’ll want to execute net.blobs.keys() to see what layers are available. These layers are then targeted by specifying the end variable in the make_step and deepdream functions defined under the “Producing dreams” heading. Here you may also wish to play with step_size, jitter, iter_n, octave_n, and octave_scale. Here I should note that I haven’t had any good results from setting both end parameters to different layers. If you’re looking to dream coherent objects then you may wish to set them to the same layer.

How about the layers themselves, what do they produce? The emerging community of r/deepdream is a good place to look for stuff like this. Here is one test suite I found useful. In short, the layers of the default neural net optimize for slightly different dreams. In my experience I noted the following (and I will expand and correct these notes as I continue exploring):

  • inception_3a: mostly geometric patterns
  • inception_3b: still just patterns
  • inception_4a: eyes and some dogs
  • inception_4b: lots of dog faces
  • inception_4c: starting to get more into cars and buildings
  • inception_4d: more of a menagerie
  • inception_4e: lots of different animals; birds, snakes, monkeys, and so on

Of course, your results will be highly dependent on your source images (assuming you get outside of the “dog-slug” default layers). One run produced boats on an otherwise empty ocean stretching to the horizon which was quite cool.

Another note: the scale coefficient s in the block of code that actually generates images can be adjusted to reduce the amount of cropping that occurs with every step of the feedback loop. The scaling is necessary to provide the neural net with slightly new information on each pass. If you’re using your own images you may want to allow for some trimming depending on how strong of an effect you are looking for.

If you would rather setup your own web service to drop images into try clouddream. I’m still working from the Python notebook for the time being it offers way more customization options.

Finally, if you’d like to check out some of my own work you can find a few early experiments on my main blog.

More updates to come!

A few notes about Medium’s typographic manifesto

Marcin Wichary has a fantastic series of posts documenting Medium’s commitment to beautiful web typography. Apart from being intrigued about some of the little tricks they use to enforce better typing habits, like disallowing users from entering two spaces in a row, I was also interested to read the technical supplement for designers and developers. It reminded me of a few things I’ve been meaning to add to my main theme and introduced several things I hadn’t really thought about.

Continue reading →

A Sass micro-library for working with named colours

This week I published another one of my small projects, a Sass micro-library by the name of sass-named-colors. The purpose of this is simple: provide an easy interface to a standardized list of 1,500+ named colours originally compiled by Chirag Mehta and converted to Sass by James Pearson. No need to puzzle out hex values; just use k-colour(emerald), k-colour(monsoon), k-colour(cloud), and so on. The library also features aliased functions and variable names for those who prefer to work with colours (the non-American spelling), admittedly a bit of a pedantic flourish. Plain old “colors” is the default, though personally I stick with the spelling I am used to in my own work (and in this post).

Installation is a breeze via Bower: bower install sass-named-colors -D. This library has no dependencies but requires Sass 3.3+ due to reliance on the map-get() function and an approach outlined by Erskine Design.

This library ships with one function: k-colour($colour, $fallback, $library). Only $colour is required; the remaining arguments are mainly for internal use. Example:

@import "sass-named-colors/named_colours";

.element {
  color: k-colour(red);
  &:hover {
    color: rgba(k-colour(orange), .9);

To extend the built-in colours on a per-project basis:

$k-colours: map-merge($k-colours, (
  norse-blue:     #5cb6cc,
  suomi-blue:     #559dd1,
  steel-sky:      #444547,
  jove:           #24221E

Need a tool to browse the options? Try the colour picker on the original Name That Color project page.

A Sass micro-library for web-safe font stacks

Sass Font Stacker is a small library of web-safe font stacks bundled with some utility functions and a simple mixin to make font-family declarations a breeze. The syntax is similar to what you’d be writing anyway. For example:

@include k-font-family("Open Sans", helvetica);

This will output:

font-family: "Open Sans", "Helvetica Neue", Helvetica, Arial, "Nimbus Sans L", "Liberation Sans", Arimo, sans-serif;

The mixin (and related utility function k-font-stack() accepts an arbitrary list of fonts but requires the last (or only) argument to match one of the pre-defined font stacks. This way you can specify naming variations or even entirely different fonts at the head of a custom font stack.

I won’t list all the font stacks included in this project (as this information is likely to change) but will cite a few of the more commonly used fonts in web design:

  • Andale Mono
  • Arial
  • Baskerville
  • Book Antiqua
  • Calibri
  • Cambria
  • Century Gothic
  • Constantia
  • Courier
  • Garamond
  • Helvetica
  • Helvetica Neue Light
  • Hoefler Text
  • Lucida Grande
  • Palatino
  • Segoe
  • Times New Roman
  • Trebuchet MS
  • Verdana

All of these stacks contain a liberal sprinkling of Croscore, DejaVu, Liberation, and URW++ fonts for those viewers who lack the proprietary fonts common on the big two operating systems.

Crafting web-safe font stacks is more an art than a science these days. Usage data is neither current nor of a sufficient quality to make anything better than an educated guess in my estimation. But hey, a good guess is better than nothing—and the use of a Sass library allows for those good guesses to be formalized and consistent across projects. If anyone out there has expect knowledge to contribute please consider opening an issue or sending a pull request. Here’s that GitHub link again: Sass Font Stacker.

An AJAX page loading script for WordPress

I have been experimenting with a custom AJAX page loader for my WordPress blog in recent months. Today I broke this project out into its own repo, available here: WP AJAX Page Loader. It is readily installed via Bower: bower install wp-ajax-page-loader. Some additional work is required to integrate and configure this script for your own projects.

I starting working on this project after learning about some of the many problems associated with history.js, a polyfill that many infinite scrolling implementations rely on to this very day. After having a look at some of the options I decided to adapt one of my own scripts to achieve pretty much the same effect with a much smaller payload size and a bit of a smoother user experience (or one that suits my needs anyway).

This script requires jQuery (already included in WordPress), HTML5 History API, and spin.js. Without jQuery (but with the other dependencies) it clocks in at about 15.5 Kb minified (comparable to the 21 Kb of Paul Irish’s Infinite Scroll).

Read the documentation or peruse the source code for more information or have a look at Pendrell for an example of integration and configuration. This script is currently active on this site so you should be able to demo it by browsing around any of the archives and clicking on “next” (or simply positioning the viewport near—but not at—the bottom of the page, for I am running the script in “footer safe” mode).

Roll your own SVG sprite sheets with Bower and Gulp

In this article I will show you how to integrate a custom set of open source icons into a project using Bower (a front-end package manager) and Gulp (a command line task runner). This isn’t exactly the sort of tutorial where you can copy and paste a bunch of code and get up and running—it is more a collection of working notes and scraps of code meant to point you in the right direction. I will assume readers have a basic understanding of modern front-end development tools and the command line. I happen to be using WordPress and PHP to implement the markup but also include some vanilla JavaScript that could be adapted for use pretty much anywhere.

Continue reading →

Getting up to speed with responsive images and Picturefill

This week I have challenged myself to get up to speed with responsive images and Picturefill, a polyfill for the upcoming HTML5 picture element as well as two new attributes for the img element. It wasn’t easy—there’s a surprising amount of reading and processing that needs to be done to understand the many problems and proposed solutions to responsive images on the web. Along the way I realized that I am not yet hugely interested in the art direction use case—which means I have focused more of my time on two less hyped img element attributes, srcset and sizes. Together these provide for most of what I am interested in: swapping source imagery at different resolutions.

Continue reading →

Removing the taxonomy base from WordPress permalinks

A comment archived from Twitter:

Another WordPress thing that should be easy but isn’t: removing the taxonomy base from the URL. ‘Use a random old plugin’ is not a great option.

Responsible use of WordPress plugins requires code evaluation. Sometimes this is easy and straight-forward but at other times one must stop and ask about the benefit derived versus time invested. For this little feature I decided I had better come back to it later. Some promising leads:

Adding term descriptions to the quick edit box in WordPress

Writing term descriptions for categories, tags, and custom taxonomies can be a real chore in WordPress. It is easy enough to edit term names and slugs with the quick edit box but if you’d like to edit descriptions it will be necessary to open up the full edit screen. This is less than optimal if we wish to write or maintain complex taxonomies with dozens or even hundreds of terms.

WordPress is highly customizable and extensible so there’s a way of making this easier. Of course, this being WordPress, things aren’t nearly as straight-forward as they could be. The problem, in this case, is that you cannot hook the quick_edit_custom_box action without the presence of a custom column. Since description is among the default columns this action is not called and there is no opportunity to modify the contents of the quick edit box. The current solution (as of version 4.0) is a bit of a hack: use a hidden custom column to trigger the quick_edit_custom_box action and output the necessary HTML.

Continue reading →

WordPress term descriptions in Markdown

Recently I wrote a little about using Markdown and WordPress together. This time around I’d like to share some tricks for using Markdown in term descriptions.

But first, a recap. Terms, in WordPress jargon, are objects in a taxonomy—a system of organizing content. WordPress ships with categories (which I don’t use) and tags (which I do—extensively). You can also implement custom taxonomies to organize content in whatever way you wish. I happen to organize some of my posts into series and many others by location but the sky’s the limit as far as custom WordPress taxonomies are concerned.

Continue reading →