Welcome to WebmasterWorld Guest from 188.8.131.52
Forum Moderators: open
After a couple of hours I found out that the images that are either blocked, or simply don't work, are using CMYK mode. These worked in IE7, and still work in FireFox.
If I take the same image and convert it to RGB/8 or RGB/16 with Photoshop, it works fine.
[edited by: Wlauzon at 7:01 am (utc) on April 5, 2009]
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.
The images in question were done back around 2004 for printing, and are actually images converted from TIFF or some other file format.
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.
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]
So, yes, RGB for monitors, CMYK for print.
Hope this helps, makes sense...
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 :-(