Posts tagged imagemagick for book design
Ken's Guide to Indie Publishing on Linux (Cover Design 3)

I'm now going to walk through the details of the cover design for my forthcoming book The Way Around. There may seem to be a lot of steps but, as with the interior, the time investment is small compared to writing the book itself! Each of my novels has taken about 500 hours to write and edit to completion. By comparison, the cover only took a few hours. Yet it’s the cover which sells the book!

The first time I created a cover, it took 4ish hours (I didn’t do the actual artwork, of course). Subsequent revisions have a gone a lot quicker. Though there are many words in these posts, the actual ideas are relatively simple.

Because my own process involved several “redos”, and that’s natural, I’ll include some of those additional steps in the narrative. This will help clarify how to fix mistakes (or accommodate changes), and show that such things are relatively painless.

One important thing with cover design is to do as much calculation by hand as possible. The less you have to aim a mouse to get things just right, the less you’ll want to fling yourself, the book, and the entire design profession off the top of a tall building.

So we’ll start with a simple but essential calculation: the aspect ratio of the image.

Step 1: Compute the correct aspect ratio

We have a template from Ingram. In theory, this tells us precisely what we need. In reality, we are given only a set of blue and pink regions and it is left to us to figure out the actual dimensions. Fortunately, this is not hard.

In Inkscape, the ruler tool will do the trick. Unfortunately, there is no simple aspect-ratio tool I’m aware of. But using the ruler at a big enough magnification (to allow precision) will give a pretty good estimate. I suggest setting the units to inches.

Why do we care about the aspect ratio (one number) and not the actual dimensions (two numbers)? It is very easy to scale images in Inkscape, but much more troublesome to crop them. What we want to start with is a very high-resolution image of the correct aspect ratio.

First let’s look at the Ingram Template a bit more closely, though. It comes in the form of a pdf representing a 15x12" sheet. On this sheet is an active region consisting of pink and blue rectangles. The pink is the part guaranteed to be printed, while the blue is bleed. It allows for variation in the print process. To produce the cover file they require, you must replace the active part of the template with your own cover image. Both pink and blue should be fully covered, but any active elements (title, isbn, etc) should sit only in the pink region. As a general rule of thumb, each overlaid pink region should look good by itself — as well as with a little extra added around the edges.

In my case, the active region consists of a 0.25" blue border, two pink pages (each 5x8, the size of my book), and a spine which is 0.259 wide with two bleeds, each 0.125". Note that the spine measurement includes some of the blue.

Horizontally we have

0.25in blue
4.75in pink
0.125in blue
0.259in blue/pink/blue (a little blue, pink, a little blue)
0.125in blue
4.75in pink
0.25in blue

These add up to 10.509 in.

Vertically, we have

0.25in blue
7.75in pink
0.25in blue

These add up to 8.25 in.

To compute our aspect ratio, we divide these and get 1.27381. We don’t need this to achieve this exactly, of course. But if we miss the target we’ll have to expand the image accordingly, which will lose a little from one edge or another. Best to get as close to the aspect ratio up front in a way we like and then lose only a pixel or two when we tweak it.

Step 2: Crop the illustration to the desired aspect ratio

We next need to crop the raw illustration to our aspect ratio. In my case, cropping would also remove any non-illustration cruft from the image (fade-off near the edge of the page and the artist information at the bottom).

As it later turned out, the nature of the illustration required an additional design choice. Certain imagery (a big tree in particular) would have wrapped onto the spine in a displeasing manner as things stood, so I decided to further crop the image while maintaining the aspect ratio. I’ll discuss that later on, but for now we’ll crop as little as possible.

There are two ways to do this, and which approach you take is a personal preference. I’ve used both.

Method 1: GIMP. The photoshop-alternative GIMP has a nifty feature which lets you create a constant-aspect ratio box and then place it over the image and crop to it. Better yet, GIMP allows you to manually enter the aspect ratio. When saving, it’s best to write a png file with no compression. Mine came to 150 MB.

Method 2: Imagemagick. You can use a command-line approach and try cropping in different ways (directly enforcing the aspect ratio by hand), and use eog or some other image viewer to see what looks right. The back and forth is less painful than it sounds, and probably would take no more than 5 minutes.

This is a good point at which to mention some handy Imagemagick commands.

“identify myfile” will provide useful info about the pixel dimensions of an image.

“convert oldfile [options] newfile” is the command to do most manipulations — file format conversions, cropping, etc. Here’s a cropping example, with an explanation of the relevant options:

“convert oldfile.jpg -gravity mychoice -crop 80%x80%+0+0 +repage -quality 80 newfile.jpg

-crop tells it to crop to a given size with a certain displacement from the reference point. If you’re cropping against a corner, the displacement should be +0+0 otherwise the suitable +x+y in pixels. The 80%x80% says to crop width and height to 80% each. Exact pixels like -crop 7958x6247+0+0 could be used too.

-gravity tells it what the reference point is. “mychoice” can be any of the following: SouthWest removes from top and right, SouthEast removes from top and left, NorthWest removes from bottom and right, and NorthEast removes from bottom and left.

-quality tells it the compression level to use when writing to a compressed format (jpg, png, etc). I recommend using 100 for all our purposes. We’ll use lower quality down the road when meeting file-size constraints for certain purposes. But for printing, we need the best quality possible.

+repage This is a technical option. When cropping occurs, the cropped image can be thought of as its own thing or as sitting on a canvas that was the original size. Each approach can be useful in some contexts. +repage tells it to treat the new image as its own thing (i.e. set the canvas to equal the cropped dimensions). This almost invariably is what we want for our purposes.

It’s also useful to know how to resize an image, even though we aren’t doing that here. Resizing is actually a challenging task in general because tradeoffs need to be made in terms of how sampling occurs. I find the defaults in Imagemagick serve well for simple purposes. To resize (scale instead of crop):

“convert oldfile.jpg -resize spec -quality 100 outfile.jpg”

Here, spec tells it how to resize. It can do so to an arbitrary widthxheight (pixels or percent). But it also can do so to a given width (ex. -resize 100) or height (ex. -resize x100) keeping the aspect ratio.

Resizing is another handy way to reduce file sizes. While resampling to higher resolutions can serve some purposes, we’ll have no need of it in general. Our original image is very high resolution and all our resizing will be down.

Step 3: Generate Logo

At this point we’ll make a minor digression, because we need to produce a mini logo for the spine. If for some reason you’re not using your own imprint, or if you already have a suitable image for it (or its just a simple text logo), then this step is unnecessary. Also, don’t worry if you don’t understand the details. We’ll discuss the use of LaTeX when it comes to the interior of the book. Feel free to return to it at that point.

Inkscape’s own tools suffice when it comes to most text elements, but it happens that my own imprint requires a little bit of finesse. The formal name of the press is “Epsilon Books” but the logo begins with a particular type of curly Greek epsilon rather than an E.

The following LaTex code did the trick:

\documentclass[12pt]{memoir}
\usepackage{mathpazo}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage[artemisia]{textgreek}
\setstocksize{0.66in}{2.1in}
\settrimmedsize{\stockheight}{\stockwidth}{*}
\settypeblocksize{0.66in}{2.1in}{*}
\setlrmargins{*}{0in}{*}
\setulmargins{*}{0in}{*}
\setlength{\footskip}{0pt}
\begin{document}
\pagestyle{plain}
\vglue -1.84in
\hglue -1.4in
{\fontsize{60pt}{0}\selectfont\textbf{\textepsilon}}{\fontsize{40pt}{0}\selectfont \hglue -1pt \textbf{psilon}}
\end{document}

Most of this is cruft necessary to declare the type of document. Worry not, when it comes to the interior the cruft to content ratio will be much lower. Think of it like the overhead necessary to write a C program. It seems like a lot of effort for “Hello World,” but is relatively insignificant for any real program. In any event, it took a few minutes of tweaking to get things right and I was done.

To compile it, I ran "pdflatex mylogo.tex", which produced the following pdf:

Ken’s Guide to Free Indie Publishing on Linux. Imagemagick and LaTeX example.

Step 4: Adjust Alpha Channel

I’ve separated out this step, even though it’s really a simple adjustment to the logo we generated. Even if you skipped that section, you may find the information in this section worth knowing. While the logo and its vagaries are specific to me, this is a good place to discuss the alpha channel.

The logo above may look good, but we must be careful. The background is transparent. As it turns out, that is fine for our purposes, but I should take the opportunity to explain a bit about what it means and its implications. When displayed in some programs it will look no different than a white background. On others it may mask the foreground image — appearing as a solid block of black. And on yet others the background may appear greyed out. It all depends what canvas a program decides to display it against.

When I was a kid, there were 3 color channels. The color of any pixel could be determined by those three numbers. Actually it started as 2 bits for CGA, then 4 bits for EGA, then 8 bits for VGA. Only later did it resolve into the 3 distinct RGB channels (24 bits total) once graphic cards could drive that many colors. But the idea is the same: each pixel’s “color” solely was determined by some representation of its physical place on the spectrum. This was fine for many purposes.

However, photo manipulation programs and other design tools evolved the notion of layering as a convenient means of mimicking the real design process. To be useful, layers needed the ability to blend into one another. While it’s possible to identify the background color and map or merge pixels accordingly, this can lead to other problems (misassignment of colors, misidentification of the background color, etc). In fact, many images have no clear notion of “background” vs “foreground” colors. So an “alpha” channel was added, an additional 8 bits. It represents absence of information, transparency, or whatever else we want to call it. Intuitively, it is a 4th number which tells us how transparent the image is. No doubt my little history blurb is wildly inaccurate, but the basic idea of the alpha channel is important.

Not all formats can accommodate it, and not all programs can recognize it. The main problem is knowing it is there, and the effect it can have. Sometimes we want it, sometimes we don’t. From a practical standpoint, if a picture overlays in a weird way, then there’s a good chance either the alpha channel is present and you don’t want it or it’s absent and you do want it. Imagemagick’s “identify” tool can help you make that determination.

In the case of my logo, the alpha channel is there and set to full transparency. We want this, since the logo will be overlaid on the image. But we don’t want the foreground color to be black. The cover image is dark and we need a white logo. As it turns out we’ll have to take further measures to ensure spine text visibility as well, but we’ll get to that later. For now, we just want to make the foreground white while retaining the alpha channel.

Looking ahead a little, it turns out that Inkscape has a slightly easier time importing SVGs than PDFs. There’s no good reason for this, and it’s just one of the idiosyncracies of the program (every program has them). So we’ll convert to SVG format.

We accomplish both steps with one command:

"convert mylogo.pdf -negate mylogo.svg”

Now that we’ve gathered all the necessary pieces, we can begin work assembling them into a cover. Next week, we’ll begin work in Inkscape. If you haven’t yet, it may be worth playing around with it a little and familiarizing yourself with how its menus, palettes, and so on.