In short, CMYK is intended for print and RGB is intended for screen. Because is has 4 values (Cyan, Magenta, Yellow, Black) it is capable of producing many more color variations than RGB (Red Green Blue).

The bottom line is that RGB is colored light. CMYK are pigments, which is color perceived by reflected light. Since browsers are designed to work with monitors and colored light, there is no implementation to manage the "fourth channel."

Actually there are less attainable colors with CMYK than with colored light, it's our electronic display systems that limit the color range of RGB. CMYK is a controlled color system to attempt to compensate for the impurities in printing inks and facilitate proper ink tacking in offset printing. Four layers of ink won't stick if the coverage is heavy. This is done by under color removal and gray component replacement, a system to remove portions of CMY and replace it with black in neutral areas, or remove the contaminant color and replace it with black in low chroma color areas.

I've never heard of CMYK JPEG. It can be done, but I've never heard of it. Pretty durn inefficient.

Have them re-render the JPEG from RGB.

CMYK stands for Cyan, Magenta, Yellow, blacK. CMYK files are, by definition, bigger than RGB files by 33%, and are limited.

CMYK should only be used just before printing, although many, many people tune their whole workflow to use it.

Basically, printers use four "reflective" colors, as explained by rocknbill. Changing from RGB (Red, Green, Blue), which is close to the "native" color space of digital capture devices (such as scanners and digital cameras), to CMYK is a "lossy" process. This means that, once you're a pickle, you'll never be a cucumber again.

Different printers have different requirements for CMYK, so you should only use CMYK when you are absolutely positive of what printer you will use. You don't want to tune your whole workflow for a LinoType/Hell offset press, then print the files on a Kodak Dye-Sub printer, unless you are using the Dye-sub as a proofer, in which case, it will be part of the workflow, and "tuned" accordingly.

The concept of running a complete CMYK workflow is actually pretty old-fashioned. It stems from the days when printers would purchase a complete closed-loop system, from drum scanner to high-volume offset press. These systems cost a mint, and you usually had to hire someone to come in on a regular basis and tune the system up. Because of this, people considered a CMYK process to be "what the big boys use," so would set up their own processes in the same way.

Nowadays, you can have a complete calibrated RGB system with different manufacturers' components. For example, my wife and I use Nikon cameras and Scanners, Apple computers and Epson printers. The whole system is calibrated, and we get very good color consistency without ever needing to go into CMYK. We can deliver files to anyone that can be "repurposed" into device-specific CMYK.

Most JPEG files are tuned to sRGB, a "lowest common denominator" color space that is designed to work on a range of electronic display devices.

Thanks for the explanations. I knew the cause and now understand the underlying problem. I have already come to a resolution which is obvious, find the images in error and convert them from CMYK to RGB.

Some searches turned up a few discussions on the topic but nothing real spectacular when it comes to mass updates. I ran the following command (if you have imagemagick and grep installed) to locate the CMYK images:

identify -verbose "/path/to/images/*.jpg" ¦ grep -B 6 "Colorspace: CMYK"

The count was low enough we were able to address each individually. We didn't want to mass update every image, only find and fix those that met the CMYK criteria. Anybody have a better "locate and convert" solution?

The forum breaks the pipe character [webmasterworld.com], so don't forget to rekey it if you copy/paste the command

[edited by: limbo at 9:57 am (utc) on Mar. 23, 2007]
[edit reason] linked proviso [/edit]

Not sure how best to separate the CMYK images from the RGB, but once you've got them, the easiest way to convert them to RGB would be to create a custom action in photoshop and do the whole "batch" at once.

Wow, that was a run-on sentence.

Let me know if you need any more details on how to create the custom action or run a batch.

It was actually pretty easy to script, too. I found that PHP's getimagesize() [php.net] function will return the channels in one of the indexes if the image is a jpeg. Channels will be 3 for RGB pictures and 4 for CMYK pictures.

// $image could be a command line argument you pass 
// or it could be from looping through a directory in a script 
$getimagesize = getimagesize($image); 
if ( 
 isset($getimagesize['channels']) &&  
 $getimagesize['channels'] == 4 &&  
 $getimagesize[2] == IMAGETYPE_JPEG 
 ) { 
  $im = @imagecreatefromjpeg($image); 
  if ($im) { 
    imagejpeg($im, $image, 100); 
    imagedestroy($im); 
  } 
}

It was actually pretty easy to script, too. I found that PHP's getimagesize() function will return the channels in one of the indexes if the image is a jpeg. Channels will be 3 for RGB pictures and 4 for CMYK pictures...

Hi coopster - how does that process compare to manually altering the colour space using a image editing tool? I ask because from what I understand the the switch between CMYK and RGB in Photoshop (for examples sake) is a clever algorithm designed to make the least impact... particularly the saturation of green...

Does using that script have the same result or is quality diminished in the process?

Well you're really asking the wrong guy, I'm out of my element when it comes to graphics and multimedia design! But when I look at the image, it actually seems more defined, brighter now than it was before. It looks better in this particular case. I had to compare using another graphics viewer of course as browsers will not render the CMYK version of the jpg image.

You know, it does look "greener" though, not that you mention it.

it actually seems more defined, brighter now than it was before.

In what program?

The lookup tables in Photoshop for screen display attempt to emulate the color contamination you get from offset printing. This will vary with the monitor profile and output profiles you have set up. So a CMYK image may often have a "dirtier" look in some of the more subtle colors.

A good rule of thumb when deciding color balance, don't use the display in front of you. Open the info window, sample the colors and look it up on a printed color selector. A neutral color will always be slightly higher in cyan, example 7/5/5/0.

In what program?

A few different programs, including Windows Picture and Fax Viewer and Photoshop. I'm not sure if what you are describing was Photoshop viewing there, but I was watching the designer open the original CMYK, a Photoshop RGB conversion as well as my RGB converted version. Layers (channels) were turned off and on and subtle differences were noticeable, including the "greener" look in my converted version. Photoshop seemed to retain the original picture color closer than my automated conversion.

You might consider the file sizes too, if the images are large and/or there are many of them. The "save for web function" in photoshop can massage your file sizes down with or without noticeable loss (depending on how small a file size you want).

This function can also be automated using Actions and Batches.

I took a larger image today, a 1MB jpeg, and ran it through both the PHP script mentioned earlier as well as the ImageMagick "convert" utility from the command line. The script-modified RGB image didn't look too bad to me, but as stated, I'm no graphics professional. Perhaps limbo can comment in that regard as he has been sent copoies of the revised images.

I decided to also run the image through ImageMagick's "convert" utility and even with different command line switches found that I could not get the image to display like I expect. It looks like an "overexposed" picture, frosted on the edges and highlights with an extremely bright light. You can still make out the image, but it is covered everywhere with bright white highlights.

In the graphics world, what is this called? If I knew that I might be able to find the correct switch to make necessary adjustments during conversion.

We call it "overxposed."

You would correct for it with exposure compensation or brightness.

One caution: When you darken an overexposed image, strange things can happen. What was once white can become either gray, or other interesting colors. All exposure compensation algorithms are not created equal.

Thanks Coopster. I took a look at the images you sent.

In instance 1 (image converted using your first technique): I'd say the conversion was pretty good. The overall brightness is up, as is contrast. Perhaps a little more than you'd want - especially on Mac displays, where the levels of brightness are higher anyway. But a successful conversion none-the-less.

In instance 2 (converted using imagemagik): It's not exactly over exposed. However the conversion was a disaster. It appears that the black channel has been completely replaced by a white one. So it appears a bit like a slide negative, only the other colour info has remained in tact giving it a white glow where shadows would ordinarily lie. The brightness is up about 30% and increased contrast has washed out the more subtle areas of tone. Maybe there are some settings on the imagemagik script that will allow the black channel to remain…

One other thing I noticed was the overall file size difference between the original and the two that had been adapted by scripts. The original image was 988kb. In instance 1 the file size was the lowest at 860kb and instance 2 was 940kb.

In summary, if you use a script to change a JPG's colour mode then the first instance is definitely the way to go based on this experiment so far; it has the best result colour wise + the added bonus off knocking off a few KB's.

I'd be interested to know if the imagemagik script can be adapted. Is there something you can do to make the switch to RGB without removing the black, while maintaining the original images brightness?

In instance 1 (image converted using your first technique): I'd say the conversion was pretty good. The overall brightness is up, as is contrast. Perhaps a little more than you'd want

In the script I set the quality parameter in the imagejpeg [php.net] function to 100. quality is an optional parameter, and ranges from 0 (worst quality, smaller file) to 100 (best quality, biggest file). The default is the default IJG quality value (about 75). Perhaps I should have left it at the default.

I'd be interested to know if the imagemagik script can be adapted. Is there something you can do to make the switch to RGB without removing the black, while maintaining the original images brightness?

The ImageMagick method was a command, although it could be scripted if so desired. I was using it along with the grep utility to locate the files I needed to update. The step I am missing would be to take the filename found and pipe that to the ImageMagick "convert" or "mogrify" command. "mogrify" overwrites the original image file whereas "convert" writes to a different image file.

But before any of that would even be worthwhile automating, you are correct, I would need to nail down the correct switches to get the image converted satisfactorily. ImageMagick is an open source project with an online documentation manual. I tried a few of the command line options to try and get the convert [imagemagick.org] command to render the image more true to the original but failed. I tried both the "normalize" and "quality" options. Do you see any others that I should be attempting?

I decided to also run the image through ImageMagick's "convert" utility and even with different command line switches found that I could not get the image to display like I expect. It looks like an "overexposed" picture, frosted on the edges and highlights with an extremely bright light.

This is still attempting to convert a CMYK to an RGB, correct? If my assumptions are correct, this is *not* overexposure.

See my previous message about adding the "fourth" channel to CMYK, and how there are a variety of degrees and methods of doing this (Under color removal, gray component replacement, etc.) ImageMagick does not inherently know how to extract an accurate RGB from a CMYK correctly. For that you need a color profile to tell it how to distribute the CMYK among the three RGB channels.

I know this because I worked with a printer who wanted to exchange CMYK files via their website and of course the thumbnails wouldn't display. Since the idea was to exchange unmodified CMYK files, it was confusing to create an RGB version before upload just for display of thumbnails on the site.

Basically using the utilities provided by ImageMagick you extract a profile from one of the image files, store the profile in a file, then upon executing convert tell ImageMagick to use this profile in converting:

/usr/local/bin/convert -colorspace RGB -profile [/path/to/profile.icm] [originalimage] [outputimage]

profile documentation [imagemagick.org]

It's a royal pain, but once set up and functioning correctly it reliably outputs decent RGB's from CMYK's without manual intervention. I even got it down to a selectable series of profiles - "if you know the CMYK profile, select it from this list."

OK, I'm learning something here! Thanks. This is exactly the direction I needed. However, upon extracting and then converting, the image still looks like I described earlier, just not there yet. I ran the identify to find out that the exifdata is in 8bim format so I ran the following ...

convert imgCMYK.jpg exifdata.8bim 
convert -colorspace RGB -profile exifdata.8bim imgCMYK.jpg imgRGB.jpg

The exifdata.8bim file gets created in the same directory in which I am running the command, just like I expected. However, the convert command renders the imgRGB.jpg image just as before. It still has that "overexposed" look to it. Any ideas what I might be doing wrong?

Hmm you may be on your own there. :-) Did you open exifdata.8bim to see if there's any data in it at all? It may not actually be doing anything. The ones I worked with were almost exclusively Photoshop files so it extracted an .icm.

Hmm you may be on your own there. :-)

LOL! Hey, thanks rocknbil! Just when I thought I was getting somewhere ;)

Joking aside, yes, I made sure there was an extracted file and that it contained content and it does, 16,384 bytes. The "identify" command on the image that I am extracting the profile from tells me ...

Exif:Software: Adobe Photoshop CS Macintosh 
... 
Profile-8bim: 12692 bytes

... so I'm certain the extraction I ran was appropriate. I tried a .app1 extension but received an error. I'm assuming from the information discovered via "identify" that I am extracting correctly ...?

Sorry, never worked with those profiles, only ICM's - but I do recall things "not working" sometimes and we came to the conclusion that it is not actually applying the profile and is not providing errors to tell you what went wrong. You could try using full system paths to both the images and the profiles.

I told you it was a royal pain. :-)

Indeed.

You could try using full system paths to both the images and the profiles.

Exhausted that possibility before posting. I should have mentioned that.