A Pixel is a Pixel
“If you want a professional result, you can't use GIMP.” I don't know if I've ever heard this sentiment stated so explicitly, but I've definitely run across it many times, in a variety of contexts. When I heard it come up in a discussion of indie authors creating their own book covers, it “inspired” me to write this blog post. (In this case, “inspired” is a polite euphemism.) This post is about digital images and software, not the decision to make your own book covers or hire a designer. That decision merits discussion, but it is a separate issue from digital images and software.
If you think you need to spend a lot of money on a certain brand of software to create “professional” images, you need to stop going along with that company's marketing ploy. A pixel is a pixel no matter how it gets created. This goes beyond digital images, it's also true for other things too, such as e-book files. What matters is the correctness of the end result, and that end result is not more or less professional depending on what tool was used to make it. Continue reading if you're not sure what I mean or if you think a certain brand of software is necessary.
If you look at the “example” book cover image shown in this blog post, you might think it's terribly unprofessional. I would agree with that sentiment, it's not something I'd want on my own book. However, the reason for its unprofessional appearance is my lack of time to work on it today, not the software I chose. But what software did I choose? Was it GIMP? Was it Photoshop? I have them both installed. Or was it something different, like DAZ Studio? I'll answer that question below. First, it's necessary to understand digital images in the context of digital self-publishing platforms.
Most services like Amazon KDP, NOOK Press, Kobo Writing Life, etc. require “raster” images for the covers. That actually may be true for all of them, but I can't survey all of them because there are many obscure ones (e.g., those that accept Bitcoin), and small ones can come and go readily. I've never seen support for vector covers, which is a little unfortunate, but that's another issue. (Read more about “raster versus vector images” if you wish.) A raster image is a lot like a piece of graph paper with each block filled in with a different color. In a digital image, those squares are called pixels, i.e., picture elements. The “resolution” of a digital image is often described using the pixel dimensions (see every megapixel claim from digital camera manufacturers), so a cover image that is 625x1000 (currently the minimum size allowed by KDP) is literally just a digital image that is 625 pixels wide and 1000 pixels high.
Pixels are software-neutral. There are different file formats used to store the pixel data, and those files can be created using a wide variety of tools. You're probably familiar at least with the JPEG and GIF formats, and you may also be familiar with PNG, BMP, GIF, and TIFF formats. Some file formats, such as PSD and XCF, contain extra data that allows for powerful editing features, but the underlying image is still a raster image, i.e., a bunch of pixels in columns and rows, just like graph paper.
Each pixel will use a certain amount of computer memory to represent its color. The final pixel color is selected by choosing values of primary colors, which can be specified in various ways, all of which are eventually converted to binary values. An “8-bit image” uses a string of eight 1s and 0s (bits) for each value, so one bright red pixel in an 8-bit RGB image might be stored by the computer as
111111110000000000000000 (that is 8 “on” switches and 16 “off” switches, representing decimal values of 255 for red and zero for both green and blue). Do you see anything in there about Photoshop or GIMP or PaintShop Pro or any other software? No: A bright red pixel is a bright red pixel, no matter how it was created. And since a raster image is just a collection of pixels, that applies to the whole image. It doesn't matter what software created it.
So what does matter, if getting the “right” brand is not necessary? Artistic talent, for one. The worst designer with the best digital image creation tools will come up with sub-par results, while the best designer with the most clumsy tools can still come up with usable results, if they have enough patience. However, artistic talent alone will not suffice; imagine Michelangelo coming back to life and sitting down at a computer. No amount of artistic talent will resolve an inability to use the tools, so artists must have the technical knowledge to use the tools available to them. Finally, time matters, because the most artistic and technically proficient artist won't be able to come up with useful results without sufficient time.
Talent, tool competency, and time are all important for getting the best final result. Some tools will compensate (to a degree) for limited talent. Different people will find that different tools are “easy” or “hard” to learn. Some tools will provide time-saving features. Those are all relevant and useful considerations when choosing a tool for your work. Having the right brand name on your tools, however, is irrelevant.
As I mentioned above, this is relevant to other files used in digital publishing. For example, there are many ways to create an ePUB file, and what matters is the correctness of the ePUB file itself, not the tool that was used to create it. If you really want to, you can create an ePUB with nothing more fancy than a text editor and a ZIP-compatible compression tool. Or, you can spend large sums for commercial software, or find a solution somewhere between those extremes. If the final result is valid, your readers won't care; if it's not, you can't blame the software.
I said I would answer the question about what software I used for the hasty sample cover image shown in this blog post. It wasn't Photoshop. It wasn't GIMP. It wasn't even a graphical image editor at all. I didn't draw any lines or curves, or select any brushes, to create that image. Instead, I wrote code and processed that code through the POV-Ray ray-tracing software. I cropped it in an image editor, but could have done so with code also, and I only took that shortcut because I lacked the technical competency to do it directly in the tool I chose and I lacked the time to learn. You can download the image source code using the link shown below if you want to read it. Why take such an obscure route? To demonstrate the main point: A pixel is a pixel, no matter what tool was used to create it!
About the Author
Stuart J. Whitmore is an author of fiction and nonfiction, as well as a photographer, technology developer, and more. If you enjoy reading his blog posts, you might also enjoy reading his books. Take a look at the books by Stuart J. Whitmore today, and download your copy of one that looks interesting to you!