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.)

The description for bouncey's github repo is:

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

It covers Newton's laws of motion.

Pause

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

Try refreshing.

CSS3!

Point operations are image alterations that affect all pixels equally. Other operations, like blurring for example, each result pixel depends on adjacent pixels.

This demonstrates changing contrast, value, saturation, hue, color inversion, and threshold point operations. Note that there is a bug with increasing value and increasing saturation which I never got around to fixing.

your browser does not support canvas

It's powered by an early version of an old JS toolkit I wrote called JSImage. The latest version is available at my JSImage github repo. Don't be fooled by the 2011 commits, those are just artifacts from svn->git migration. No guarantees that the histo's are actually correct. :)

I used an old version of a rectangular selection tool called marquee. I believe it's still located here but I can't be totally sure that's the same project.

Click, drag, and taste the magic. :|