This is a speedy post about a speedy update I made today to ColorPal, an HTML5 tool I wrote that automatically generates color palettes from a photograph.

Previously, ColorPal provided hex codes for each color extracted from the image. Eight individual <input>s at the bottom of the page displayed the colors.

I use ColorPal a lot (my own dogfood and all that) when designing websites, and it wasn't long before I got fed up (hah!) with copying values from eight freaking inputs.

Blah:

Huzzah:

All eight colors can be pasted out in one fell swoop of the mouse.

ColorPal Demo

Works in Chrome and Firefox.

Pro tip: you can edit the values in the textarea and the palette will be instantly updated to reflect your edits. This means you can also paste in a list of colors (hex format only for the time being).

If you it out ColorPal, shoot me an email or give me a shout on Twitter with your thoughts.

Here are github repos for ColorPal and median-cut.js.

This minor update is part of the groundwork for some exciting changes to my sorely neglected photography site. I still post photos regularly, but haven't given it any fresh coding love for about two years. See how the colorscheme of each page matches the photograph? That's done with an older palette generation implementation (which I should write about someday), but pretty soon it'll be ColorPal pumping out those swatches.

That's not the only change. If you're not excited, don't worry. I am!

Happy coloring!

First, I converted the classic SVG tiger into a set of canvas drawing instructions using Professor Cloud's conversion tool. The output looks like this. Each call to cvm.getColor() used to be a string literal.

Vim's regex saved me from having to edit 100,000 lines of canvas instructions by hand to replace the color strings.

The demo uses Knockout for handling all the update/draw events as well as updating the URL hash. Check the source code and you'll see that there isn't a vast tangled nest of event wirings. Each time one of the colors in this ViewModel is changed, Knockout automatically triggers the canvas redraw and the updates the URL with the new palette. Conversely, if the URL is changed, the ViewModel will update itself with the new value. Knockout calls this a "two-way data binding".

I replaced the aforementioned color strings with calls to cvm, which is a Knockout ViewModel (in this case, an object that holds all the color data). cvm is populated with the SVG tiger's default colors.

    ko.observableArray( [
        { hex: ko.observable("#000000") },
        { hex: ko.observable("#323232") },
        // .... many more ....
        { hex: ko.observable("#ff727f") },
        { hex: ko.observable("#ffffff") }
    ]);

Play with the colors, then copy the URL and send your tiger to your friends. :]

Crazy tiger.

Please note, this is only a simulation of an indexed color palette. It is not a true, usable, indexed-color API for canvas (someday, maybe!).

The color picker is Farbtastic. If you're interested in reading more about the history of indexed color, and a mind-blowing canvas demo, go here.

I've converted the site layout to Bootstrap.

Massive appreciation to Doug Latornell for continuing development of Blogofile, the static blog compiler that powers this site. His contributions can be found at the official blogofile GitHub repo.

Converting the layout to Bootstrap was a breeze thanks to the Mako templates.

This is a lackluster post, but I didn't want to let such a big layout change go by without mention. Customization of the default Bootstrap theme is coming.

Update Thanks Doug, I've updated the GitHub link to point to the official repo.

In my last post on the subject, I introduced ColorPal, my HTML5 color palette generation tool. It didn't perform well with certain types of images, so I fixed it. :)

Color palettes will now match the image even better. Especially for images with infrequent but important colors. Here's a comparison of the old and new methods, on an image that is mostly black:

You can see that with the old method, the black pixels definitely took over the palette.

Try it with your own images!

For some images, this change won't affect palettes at all. But for images with low-population, high-importance colors, like the one above, palettes will look much better!

Technical discussion below.

Why the 'median' in median-cut?

Median Cut is an algorithm typically used to reduce the number of colors in an image.

The steps to perform median cut are fairly straightforward:

1. Find the smallest box which contains all the colors.

2. Sort the enclosed colors along the longest axis of the box.

3. Split the box into two regions at median of the sorted list.

4. Repeat the above process until the original color space has been divided into N regions where N is the number of colors you want.

Not too bad, right? The question remains, though, why median?

Mean, median, and mode all attempt to measure the location of a probability distribution. Worded more intuitively... they try to find the center of a set of numbers. They just employ different definitions of "center".

(Thanks Wikipedia)

As you can see clearly in the dashed data set, the mean tends to follow the tail. In other words, mean is useful when outliers are important. When generating a color palette, outliers are essential. Outliers may be the small streak of color in an otherwise drab sky, or a small red rose in the middle of a green field.

The goal of median cut is not to generate a color palette. It's to efficiently reduce the number of colors in an image. Since my goal with ColorPal is to find good-lookin' colors, I've modified the algorithm to split boxes at the mean instead of the median. Mean splits boxes closer to the outliers, which keeps low-population colors nicely segregated from the high-population colors.

Thus step 3 becomes:

The result? Mean Cut! Also: awesome color palettes.

Interesting side-note on color distributions

Interestingly, photographs of nature tend to have nice, close-to-normal color distributions. A "normal distribution" is a formal term for a "bell curve".

Check out the red, green, and blue distributions for a photograph of a forest.

For comparison, here are the distributions for a shot of NYC.

What's next for ColorPal? Color spaces.

Mean-cut improves ColorPal dramatically for some images, but it's still not perfect. Perfection probably won't be attainable, but there are still many ways to improve.

My next test will be converting to a color space other than RGB.

HSL is common, and the RGB/HSL conversion formulas are in my very old JSImage project. It may not turn out well, though, as the concept of "widest box" loses most of its meaning when each axis is a completely different unit of measure. Although, in a way, I suppose RGB has a similar problem. Red, Green, and Blue could be thought of as unrelated units. I'll try it out and see how it goes. I wonder if my old JavaScript RGB/HSL code has rotted away yet...

Most likely, I'll skip HSL and try one of the Lab color spaces first, since they are not composed linear values like RGB and HSL. Instead, Lab color spaces use non-linear scales that closely match human perception of color. Perfect for my purposes. How fortuitious for me that CIE invented it way back in 1931.

There are three "Lab" color spaces: XYZ, Hunter-Lab, and CIELAB. XYZ will be first to the plate, since the RGB/XYZ formulas are the simplest. Let me take this opportune moment to plug EasyRGB.com.

Lend a hand

As I've mentioned before, ColorPal is in an early stage of development. It needs testing in multiple browsers, and I'm very interested in hearing people's feedback. Code development help is welcomed too.

If you try out ColorPal, shoot me an email or give me a shout on Twitter with your thoughts. Thanks!

Here are github repos for ColorPal and median-cut.js.

As a developer, I'd use a framework, write a bunch of testBlahFoo functions, and the framework would magically run them.

Then I realized... "Oh, it's just introspection."

// Create an object with three properties, all functions
var myfuncs = {
    func1: function() { console.log("func it up"); },
    func2: function() { console.log("func's old brother"); },
    func3: function() { console.log("bring back da func"); }
};

// Run all functions attached to myfuncs
for( func in myfuncs ) {
    myfuncs[ func ]();
}

// Outputs:
// 
// func it up
// func's old brother
// bring back da func

So simple. Later, I wrote a very basic unit testing framework, purely as an educational excercise.

The guts are almost simple as the example above.

var JTestSuite = function () {                                                                                                                                                                         

    var version = 0.1,
        jt,

    init = function( callback ) {
        jt = JTests();
        jt.init( callback );
    },

    run = function() {
        var fn,
            prop;

        // Run all functions that begin with "test"
        for( prop in this ) {
            if( typeof this[prop] === "function" ) {
                if( prop.slice(0,4) === "test" ) {
                    console.log( this[prop](jt) );
                }
            }
        }
    };

    if( !(this instanceof JTestSuite) ) return new JTestSuite();

    return {
        init : init,
        run  : run
    };

};

In the run function's loop, I first check that each property is a function before attemping to run it. This avoids a called_non_callable TypeError. I then check that the name of the property begins with the string "test". When dynamically calling functions, it's usually a good idea to call obj.hasOwnProperty(propname) to ensure the property wasn't inherited from some unknown source (especially if the property you wanted to reference may have been deleted, but a property with the same name is now surfacing from a parent object), but in this case I'd like to leave open the possibility for inherited Test Suites.

The JTests object created in the init function is a separate object that contains a bunch of assertions. It looks something like this:

var JTests = function () {

    var version = 0.1,
        result_callback,

    init = function( callback ) {
        result_callback = callback;
    }

    assertTrue = function( a ) {
        var result = a === false;
        result_callback( {                                                                                                                                                                         
            name   : "assertTrue",
            args   : [ a ],
            result : result
        } );
    };
    
    return {
        assertTrue : assertTrue
    };

};

...except with many more assertions. :)

Both JTestSuite and JTests use the revealing module pattern.

I have a lot of ideas for improvement, like DRYing up the assertions, so the {name,args,result} object doesn't have to be defined in each assertion. But many others have already done a great job, and I don't want to reinvent too many wheels.

// Define a custom handler for the result
function test_callback( result ) {
    console.log(result);
}

// Create a new JTestSuite object and initialize it with the callback
var TestSuite = new JTestSuite();
TestSuite.init( test_callback );

// Create some tests
TestSuite.testMath = function(jt) {
    jt.assertEquals( 2 + 2, 4 );
};

TestSuite.testFalsy = function(jt) {
    // [], "", and "0" all == false in javascript
    jt.assertFalsy( [] );
    jt.assertFalsy( "" );
    jt.assertFalsy( "0" );
};

// Run all the tests
TestSuite.run();

The callback allows a user to determine how the results from the unit test should be processed or displayed. Results could be printed to console.log, displayed on a page by adding them to the DOM, sent to a Web service with AJAX, or any arbitrary service with Web Sockets.

After writing this toy framework, and explaining it to a colleague, I was told that the Rails unit tester uses almost the exact same approach. I'd wager a few bucks that JUnit uses the Reflection API's Class.getMethods() to find and run all the methods added to a TestCase class. Only a few bucks, though.

I've been toying with color palette generation for years. My photography website has always had some form of dynamic palette, so the theme of each page matches the photo. You can see the current iteration here:

I owe the idea of photo-matching website palettes to Noah Grey. Each iteration of my photo site has gotten a slightly more advanced palette generation tool. You can see murmurs of them in the old canvas demos I've posted. Sooner or later I'll make a more thorough post about the tools I've created for each iteration of the site. Anyway, back to ColorPal.

ColorPal is an HTML5 palette generation tool. Currently it's in a very early stage, and I've only tested it in Chrome. I have many ideas for improvements, and I'd love to hear anyone's ideas as well.

It's powered by canvas, data URIs, File API, and my homespun median-cut implementation, which I'm calling median-cut.js.

Bear in mind that while I've kept median-cut.js nice and clean, I did hammer out ColorPal as quickly as possible, so it's a mess. Why? I expect median-cut.js to be useful to other programmers, but ColorPal is just a tool for designers. Or it will be, anyway. :)

Here are github repos for ColorPal and median-cut.js.

And, as a reward for reading to the end, a live demo!

Poor, glorious N9.

It's impossible not to love the N9 if you're a geek, especially a programming, bash-loving, Linux-hankering geek. It's like a nerd talisman. This post isn't about the N9, specifically, so I'll save the love-fest for another time.

This post is about how difficult it can be to get text (especially passwords) onto a smartphone securely. I've come to like the approach of using QR codes. Most (all?) smartphones have a barcode scanner, and QR codes are one of many convenient ways to encode text into an image. In the case of the N9, it's MeeScan.

qrencode is an extremely easy to use encoder. Pass it a string, it produces an image.

qrencode "mypassword" -o mypass.png

KeePassX is an excellent password manager. Unfortunately...

Sadly, there is no KeePassX client on the N9. At least, not yet. Even if there were, I'm skeptical that it's a good idea at all to be carrying around a database of personal passwords on a smartphone. It's encrypted, sure, but touchscreen keyboards encourage weak passphrases. Who wants to enter a 64+ character passphrase on a vkbd?

This evening, I spent about an hour hacking QR-code support into KeePassX. It's a seriously messy hack, using system() to call qrencode, pass in the password, then call evince to view it. Even worse, I just tacked it onto the "Copy Password" function, instead of figuring out how to create a new menu item. It doesn't even delete the generated image after viewing. Definitely nothing more than a proof of concept.

Here it is in action.

I won't be distributing my mod unless someone really wants it, but it would be cool to see this available as plugin to any password managers that support plugins. It could be handy to have clipboard managers generate QR codes too.

In retrospect, it really could have used some narration...

It is still...

"a buggy, rudimentary, just-for-fun javascript physics simulator."

This version has:

• pre-defined initial states
• gravity
• friction

It still has the "clinging" bug. I know how to fix it, but didn't deem it important enough to spend time on it. :)

The code is well commented, so feel free to hack on it.

Click on one of the initial states to begin the simulation.

Initial states: Random POOL HEAD_ON_COLLISION

Sorry, your browser does not support HTML5 canvas. Lame.

Pause

  velocity sum: NONE
x velocity sum: NONE
y velocity sum: NONE

(The POOL initial state reproduces the clinging bug.)