From some reading I've done, CMYK color space was not originally part of the junk drawer known as jpeg, but work-arounds were found to get it to "fit". I remember that IE3 had a similar display problem with CMYK color space in a jpeg.

I haven't found anything online about a specific CMYK or JPEG issue with IE8. I searched the online IE8 Feedback database [connect.microsoft.com] and there were no results.

So I'm guessing that your problem may be something about the original software created those jpeg files - that is, how the original image creation software managed the technical work-around to get a CMYK image into the "purist" jpeg format. At least in the old days, some software would create a displayable CMYK and others would not.

I hate to say it, but your best bet may be to recreate the problem files in RGB.

Did some searching, and apparently CMYK is not a real web "standard", and IE8 has gone (mostly) standard, so I suspect what you say is the case.

The images in question were done back around 2004 for printing, and are actually images converted from TIFF or some other file format.

I could be wrong (probably am), but I've never known CMYK to display in browsers. (?) A browser is inherently meant to display on a monitor, which is RGB; CMYK is meant for printing to a CMYK PostScript device. We've always been able to save CMYK in jpg compression, it just won't display in browsers because browsers don't carry the CMYK color lookup tables.

A similar example, when you try to print a CMYK file to most desktop printers it won't work unless the program printing it has a CMYK to RGB conversion method. What you get is the RGB preview of the image, which will be low resolution.

I remember a web project from many moons ago where news publishers needed to exchange articles and CMYK files between offices. I had to use ImageMagick to convert a copy of the CMYK's to RGB so we could display thumbs of the CMYK images.

From my years of experience in the printing industry, if you understand the gamut issues between CMYK and RGB, it kind of makes sense that CMYK's won't work in a browser.

IE7 used to display those same images, but thinking back on it, it may be because I had an addon for it. Oddly, some (not all) of those same images work in Firefox.

Easy to fix, just converted them all to standard RGB/8, just thought it odd that IE8 was the first browser to not show them at all.

[edited by: Wlauzon at 9:28 am (utc) on April 6, 2009]

RGB (Red, Green, Blue) are primary colours (light source), i.e. pure colour. Red, green and blue light sources projected to a common neutral space will produce white light.
CMY(K)(Cyan, Magenta, Yellow, [not sure what K is but guess it relates to Black] are complimentary colours (opposite, reflective), i.e. for print or paint, which filters light and allows unfiltered colour to be reflected back.

So, yes, RGB for monitors, CMYK for print.

Hope this helps, makes sense...

Looking at HTML (and CSS) to be screen only is rather limiting, there's no reason why html and CSS should not be used for print. As a matter of fact CSS has features specifically designed for print media. So supporting CMYK images isn't stretching things at all in my book.

RGB (Red, Green, Blue) are primary colours...CMY(K)(Cyan, Magenta, Yellow...are complimentary colours (opposite, reflective)

Primary colors and complimentary colors can exist in any color gamut. Primaries are Red, Blue, and Yellow for reflective colors, and as you say, RGB for colored light. Complimentary colors are any color directly across from another on the color wheel - for example, the compliment of blue is orange; the compliment of red is blue-green.

I think what you meant here is RGB is additive color and CMYK, like any pigmented color, is subtractive color. as you add colored light values, the light levels increase until you get white light, 225-255-255.

Subtractive color is so called because the theory goes (and it is just a theory, as we still don't know exactly how humans interpret color) that as a light source reflects off a pigment, all the colors in the spectrum are absorbed (subtracted) except the reflected visible color. Also, as you increase values of color pigments, the colors subtract in value until they reach black, which would be the total absorption of all light hitting a surface - the exact opposite of RGB.

CMY(K)(Cyan, Magenta, Yellow, [not sure what K is but guess it relates to Black]

Indeed it does, and this relates to my earlier comment about it making sense that CMYK doesn't work in a browser. Depending on the printing presses you use, one of two things occurs in an RGB to CMYK conversion: under color removal or gray component replacement. They are very close but distinctly different; for the purpose of simplicity, suffice it to say that the gray values or values that will be "covered up" by black are reduced in the CMY and moved to the black channel. This is to avoid ink "tacking" - if the ink gets too thick in CMY, the black won't stick to the paper.

So if you have a CMYK image, the browser must carry the CLUT (color lookup table) of the original to re-convert it back to RGB. That's a lot of overhead to carry for a single image.

CSS has features specifically designed for print media. So supporting CMYK images isn't stretching things at all in my book.

True, but those only print in low resolution to non-PostScript printers. The resolution issues of quality printing make this impossible.

Caveat: VML (?) may make this possible as this deploys vectored graphics, and vectored graphics don't render until they reach the output device. It's entirely possible to render a VML web page to a browser at 72 DPI, but print to an output device at high resolution. I don't know if browsers adequately support this or of any working solutions in the wild.

The post-chop bug is getting worse here :-(