Image Processing and Telling RGB/HSB Color Lies

As a practitioner of digital art and image processing, and with a background in both math and computer programming, I regularly create my own graphics programs using the Processing programming language. Pictured at the top of this post is a squashed version of a digital painting I did using Adobe Photoshop and some custom brushes I had created. Pretty straight forward stuff.

Recently I've been exploring the world of generative art creation by writing my own generative art programs. For some of these programs, rather than starting with a blank canvas I provide an initial image from which to work. The image may be a photograph or a work of digital art. For example in one instance I took a selfie (a self-portrait photograph), created a painted version of that photograph and fed that into one of my generative art programs. (Note: you can see the resulting artwork Generative Selfie at Artflakes.com.)

Unfortunately with large size images complex generative programs can take quite a while to run. Consequently I use whatever tricks I know to speed up program execution. One common ‘trick' is to avoid using Processing's canned color routines and to use bit-shifting instead. Bit-shifting allows for very speedy access to an image's color information which is encoded in an RGB (red,blue,green) format. This means that color is defined by the three values of red, green, and blue. Bit-shifting works because the four individual values for red, green, blue, and alpha (transparency), are all stored in a single 32-bit integer field.

The other night I thought of a cool modification that I could make to one particular generative art program I've been working on. However that change would require that I work in HSB (aka HSV) mode. With HSB/HSV, a color is defined by the three values of hue, saturation, and brightness (sometimes referred to as value). Working programmatically in RGB has several drawbacks when compared to the competing HSB color model. HSB provides much more flexibility when it comes to creatively manipulating color.

There is just one problem with the HSB approach. The color information in images is stored in RGB format. The bit-shifting method that works so nicely is not an option for working with HSB. There are standard routines that allow you to extract HSB information from the RGB color format but you pay a penalty in terms of the amount of processing time it takes to do that. And if you are working with an image that has tens of millions of pixels and you are performing a lot of color sampling, let's just say that your computer is going to be tied up for a while. My back of the envelope calculation leads me to believe that working with HSB would result in an additional 50 million-plus program statement executions in my code and an unknown number of additional statement executions in the underlying Processing and Java code.

By nature I'm an impatient person so for me all this additional program overhead was unacceptable. And then it dawned on me – I could LIE! You see computers are stupid and will believe whatever you tell them. As supporting evidence I offer up the views of science fiction author Arthur C. Clarke:

…the fact is that all present computers are mechanical morons. They can not really think. They can only do things to which they are programmed.

The LIE that came to me was to write a Processing program that would take all the RGB color information from an image file and replace it with HSB information. I could then use that modified version of the image file as input to my HSB generative art program and it would run just as fast as the original RGB version because I would be able to use those very efficient bit-shifting operations. While I was at it I also wrote a utility that converted the file from HSB back to RGB. This allowed me to visually compare the original image with an image after it had undergone the RGB to HSB and back to RGB conversions.

Of course the downside of stuffing HSB data into the RGB field is that every other program on my or anyone else's computer is going to read that image file and expect that the color information is in RGB format. Take a look at Image 2 below. It's a copy of the file shown above except I've put HSB information into the RGB field. Kind of cool.

Taking this whole lying idea a step further, what if I lie to my color converting utility? What if I do the same RGB-to-HSB conversion multiple times while throwing in a few HSB-to-RGB conversions as well? What you can wind up with is one confused picture. Image 3 is an example of the kind of image you can get. In fact you could argue that Image 3 is more artistic than the original painting.

Pablo Picasso once observed that art is a lie that makes us realize truth. That may be but in this case a lie was simply the most expedient way to achieve an artistic objective. Having spent all this time coming up with a nice RGB-to-HSB color conversion utility, it's now time to get to work on the HSB version of that generative art program.

References

For those of you who would like to know more about RGB, HSB, and Processing, you can check out the following references.

• Wikipedia entry for HSL and HSV
• Wikipedia entry for RGB color model
• Wikipedia entry for Comparison of color models in computer graphics
• Processing Programming Language

| Return to the Blog Index | This entry was posted on Thursday, May 8th, 2014 at 9:44 am and is filed under computer art, Computing, Digital Art, Generative Art, Processing.