Cover Color Conundrums

I've done only a few covers, but only one came out exactly as intended.

Taking advice I'd read a few times here and there, I initially decided to keep my covers simple. The first had no background color. That looked good until printed on high-gloss stock. Lots of white space on really a shiny cover is a bad idea. With fancy gold text, it might work out for a book about wedding planning; otherwise that's a mistake I won't make again.

I changed that cover for the better, with a background and images that are basically shades of what I'd call "khaki to olive drab" (RGB 141 130 84). The next proof came out a little more greenish than anticipated, but wasn't skewed so much that I needed to fix it. The background colors of some of the inserted images and graphics didn't exactly match, but I decided to leave well enough alone (mainly because I didn't know how to fix that anyway.)
The next attempt had a background which was gray with a slight tan cast (RGB 234 240 235). Again, the proof was a big disappointment. It came back not with my nice very light earth-tone gray, but with an unappetizing light greenish cast all over; about the shade of "light cyan1" (RGB 224 255 255).

I was using Lulu.Com to proof these books. Perhaps it was just a coincidence, but the covers delivered looked a lot like the thumbnail images in the "cover art" section of the book's "Edit Content" page on lulu.com, which always seem to have a greenish cast. However, the "View press-ready PDF file" downloads never look any different than what I originally upload, and what always comes out of my old desktop ink jet looking just like they do on the screen.

I decided I need to learn about the basic issues, and spent a lot of time reading up on:

     • RGB vs. CMYK
     • spot vs. process color
     • color management systems
     • inconsistencies between printer color systems
     • paper characteristics (creme vs. white, matte vs. gloss)
     • etc.

So I then understood why the output of ColorCentric or LightingSource machines would not necessarily match what I see on my old CRT or new flat-panel monitors, or what comes out of my desktop printers (old HP and new Lexmark ink jets). Yet it didn't seem to make sense that each submission should be like "buying a pig in a poke."

There must be a "right" was to do this. Hmmmm ... What to do?

After reading a whole lot more about color management, sRGB vs. CMYK gamuts, and all that stuff, I decided the situation was impossible. For one thing, I didn't have software that could output CMYK color information, and even if I did, there was no guarantee that was I was seeing on the computer monitor would match what the printer's machine would produce. And then too, ColorCentric has one kind of machine, Xerox I suppose, and LightningSource has something else. So maybe I could beat my brains out trying to guarantee a result, but never achieve an exact match anyway.

For the above case, I solved my problem by loading up my original nice-looking cover layout, then clicking on my desktop to access my display driver setup and tweaking the color controls until it looked like the greenish version I'd gotten back from Lulu. I then went back into my cover layout program, readjusted the colors until the cover came back to the look I wanted, saved that as a new PDF and uploaded it to Lulu. What came back this second time around was exactly what I was shooting for the first time.

I don't know if this was just a coincidence, or if this is a useful work-around. Next time I have a problem with cover colors that don't come out, I'll try it again. Meanwhile, since you can get single proof copies of your book from Lulu at cost plus shipping, this is a cheap and dirty solution to an otherwise intractable problem.

Another thing I've learned is to not mix tools. For example, if there are graphic components on the cover, such as photographs, logos, and so on, the logical thing to do would be to prepare them in an image editor, then place them on the cover in a cover layout program. If the background of the imported graphic needs to match the cover background; good luck with that. It rarely ever will. Notice the background ghosting in the example shown here, which was taken from the second cover I ever did (check the link above for the first, which was "not so good.")

A better solution is to incorporate all the graphic components in a single image the size of the cover layout, then import that into the cover layout as a background - a opposed to establishing a background color in the cover layout program, then importing the individual graphics onto that and trying to match their backgrounds. Even if you get a good match on your monitor, the results from the printer will probably be disappointing.

The last cover I've done was easy - it was all grayscale on a black background.

That's another good way to solve color matching problems!

-=glw=-