Blog: [Blog Home] [Archives] [Search] [Contact]

Archive for May, 2014

A Pillar of Rock at Grand Canyon National Park

Wednesday, May 21st, 2014

Rock Pillar, Grand Canyon National Park, Arizona
Rock Pillar, Grand Canyon National Park, Arizona

Twenty20 (formerly Instacanvas) is a art and photography print-on-demand (POD) service that I joined earlier this year just to see about using it as a means of selling my mobile photography posted to Instagram. That didn’t last long. I rather quickly decided to start posting artwork and my DSLR photography to Instagram/Twenty20 – rather than photos taken with my smart phone’s camera.

One aspect of Twenty20 that has kept me adding new content is their challenges in which members are encouraged to submit images to theme-based contests. I most recently decided to submit a photograph to their Rock Formations Challenge and was quite pleased when I got an email from Twenty20 telling me that my contest submission was being featured on the Twenty20 home page. NOTE: My day in the sun has already come and gone but the Rock Formations Challenge is still underway.

It took some time for me to locate a photograph that emphasized a rock formation. Actually I have lots of photographs of rock formations but finding one that I wanted to submit was the challenge. I finally settled on a photograph of a pillar of rock photographed from the South Rim of Grand Canyon National Park in Arizona. Adding to the drama of the scene that day was the stormy weather – far more dramatic than clear blue sunny skies.

There are two interesting points I would like to make regarding this photograph. First, the photo I posted to the contest has a significant portion of the image cropped out. In part this was to satisfy Twenty20’s square aspect ratio requirements. The other consideration was cropping the image for composition purposes in order to emphasize the rock pillar.

The second and far more interesting point is that this photograph was never meant to stand alone. It was one in a series of bracketed exposure photographs to be used in the construction of an HDRI (High Dynamic Range Imaging) photograph. By bracketed I mean taking multiple photographs of the same scene varying only the exposure time. I take three or more photographs: one or more under-exposed, one correctly exposed, and one or more over-exposed. The over-exposed shot reveals details in the dark regions of the image while the under-exposed shot preserves details in the bright regions. Stacking and merging three separate photographs together produces an image rich in detail and color. In Photoshop the creation of an HDR image is most simply accomplished by selecting the individual images using Adobe Bridge and then using the Merge to HDR Photoshop tool option.

Three Full Frame Exposures for Rock Pillar Grand Canyon
Three Full Frame Exposures for Rock Pillar Grand Canyon

It was the HDR version that I was going to submit to the contest. However in looking at each of the three individual exposures as photographs in their own right, I was struck by the mood created by the underexposed photograph. I happened to open up the Photoshop channels palette to check out each individual RGB channel. Individual channels are gray scale images and it was seeing the photograph in black and white that led me to desaturate the photo. To my surprise I found the black and white version much more appealing than the color version. And that is how I came to submit an underexposed black and white photograph – rather than an HDR photograph – to the contest.

With respect to the image cropping, you can compare the cropped version of Rock Pillar Grand Canyon at Twenty20.com with the uncropped version of Rock Pillar Grand Canyon at Artflakes.com

The moral to this story is to keep your options, your eyes, and your mind open when it comes to the creative aspects of art and photography. Make it a point to explore and consider alternatives. Your work will be the better for it.

Bookmark it:  Stumble It  Bookmark this on Delicious  Digg This  Technorati  Reddit Tweet It


Image Processing and Telling RGB/HSB Color Lies

Thursday, May 8th, 2014

Squashed Blue Man Statue
Squashed version of Blue Man Statue digital painting for testing

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.

Appearance to RGB-reading software
Image 2. How the image looks to RGB-reading software when the file actually contains HSB information.

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.

multiple random RGB-to-HSB and HSB-to-RGB conversions
Image 3. Running multiple, random RGB-to-HSB and HSB-to-RGB conversions.

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.

Bookmark it:  Stumble It  Bookmark this on Delicious  Digg This  Technorati  Reddit Tweet It