User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; en-us) AppleWebKit/527+ (KHTML, like Gecko) Version/3.1.1 Safari/525.20 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 Two JPEGs containing identical RGB values, one without embedded ICC profile, one with sRGB profile embedded, display slightly different. Unlikely to be visible to most users with most display profile, but the greater the divergence the display is from sRGB, the greater the difference between these two images will be. Reproducible: Always Steps to Reproduce: 1. An image saved twice from Photoshop CS3, one copy without profile embedded, another copy with sRGB embedded. Specifically sRGB Color Space Profile.icm (internal name: sRGB IEC61966-2.1) which comes with Adobe products and is the default RGB Working space in them. 2. Set gfx.color_management.enabled;true, restart app. 3. Drag/drop the two JPEGs onto FF. 4. Confirm values between the two using DigitalColor Meter (found in Applications/Utilities) 2. Actual Results: With known good display and display profile there is maybe 1-2 levels of difference between the untagged and sRGB embedded versions of the image. A display profile reporting a substantial deficiency in the blue primary for the display results in much greater variation between the tagged and untagged images - up to 25 levels - and is slightly noticeable on screen. Expected Results: My understanding of gfx.color_management.enabled;true is that untagged JPEG is assumed to have sRGB as the source color space. So I expect untagged and tagged JPEGs to preview with identical values. Listed as minor bug due to gfx.color_management.enabled default is false. Easy work around is to revert to this default setting, and the visual discrepancy is only very slightly noticeable to me. But severity may need to be escalated. Bug 418538 may depend on this bug. MacBook Pro 10.5.3 Photoshop CS3 10.0.1 Will attached test images and display profiles that exhibit the problem.

so far only 1-2 levels of discrepancy between tagged and untagged with this profile set as the current display profile

Origin of this profile "ICC Profile that Causes Firefox Problems" in bug 440940 With this profile, difference in blue is ~25 levels between tagged and untagged JPEGs.

Possible problem with either precision or accuracy of the chromaticities used for the hardwired sRGB space?

On the iMac (alluminium, summer 2007 model) with the default profile the top row (reds) shows 1 level difference in the reds. All other colours are identical.

There are conflicting specifications for what to do with untagged JPEG images. The JFIF specification says that the converted RGB values are linear (gamma==1), while the sRGB specification says that any untagged images are in sRGB. I don't think anyone actually treats untagged JPEG images as linear. The libpr0n jpeg decoder has a comment about treating untagged images as sRGB, but there seems to be no call to cmsCreate_sRGBProfile() similar to the one in the PNG decoder. The PNG decoder doesn't use color management for untagged PNG images.

(In reply to comment #7) > There are conflicting specifications for what to do with untagged JPEG images. > The JFIF specification says that the converted RGB values are linear > (gamma==1), while the sRGB specification says that any untagged images are in > sRGB. I don't think anyone actually treats untagged JPEG images as linear. JFIF calls for RGB data to be encoded as Y'CbCr. Y' is luma and as far as I can tell doesn't act or look like it lacks a tone curve. Anyway the RGB data is what the ICC profile applies to. The RGB data is directly convertible to and from Y'CbCr so it doesn't really matter what their encoding is. > The libpr0n jpeg decoder has a comment about treating untagged images as sRGB, > but there seems to be no call to cmsCreate_sRGBProfile() similar to the one in > the PNG decoder. > > The PNG decoder doesn't use color management for untagged PNG images. I don't think it's very easy to make fully untagged PNG images. They've required at least TRC data for a long time, and then shortly thereafter the chroma chunk, and now ICC. I don't have an easy way to make all the variations of PNG, so I'm not sure what Firefox does and does not recognize. But if it has TRC information but not chroma chunk sRGB primaries should be assumed. If it is completely untagged then sRGB should be assumed. I understand many specs are absent in explicitly stating sRGB is to be used if a format is untagged, but they also are absent in explicitly stating Monitor RGB should be used for untagged, and yet that is what happens if sRGB is not assumed.

(In reply to comment #8) > I don't think it's very easy to make fully untagged PNG images. They've > required at least TRC data for a long time, and then shortly thereafter the > chroma chunk, and now ICC. None of those are required. gAMA (TRC) and cHRM (chroma) were part of the original PNG spec, and sRGB and iCCP were added a year or so later on. The first character of the chunk name being lowercase indicates that a chunk is optional. Some applications will automatically add at least the gAMA chunk, but others don't write any of these colorspace chunks unless you ask for them explicitly. You can use the pngcrush application to remove any unwanted optional chunks.

(In reply to comment #9) > None of those are required. gAMA (TRC) and cHRM (chroma) were part of the > original PNG spec, and sRGB and iCCP were added a year or so later on. The > first character of the chunk name being lowercase indicates that a chunk > is optional. That's unfortunate. Worse that is the PNG spec says it's OK to ignore this optional metadata. Why not make honoring 1/2 of one of the channels optional? Anyway, I strongly suggest assuming sRGB across the board for anything untagged. JPEG, GIF, PNG.

> (In reply to comment #7) > JFIF calls for RGB data to be encoded as Y'CbCr. Y' is luma and as far as I can > tell doesn't act or look like it lacks a tone curve. http://www.w3.org/Graphics/JPEG/jfif3.pdf talks about YCbCr not Y'CbCr. Y means luminance (no gamma correction) while Y' means luma (gamma corrected). It isn't the JFIF spec but common practice that changed Y to Y'. As I said earlier, I don't think anyone actually uses gamma==1 to decode JPEG images, but there is a conflict between the JFIF spec and the sRGB spec. The PNG spec simply says that untagged images have an unknown colorspace, so there is no conflict if we follow the sRGB spec and display them using sRGB. Similarly, the GIF spec says nothing about colorspace, so it's OK for us to follow the sRGB spec and apply sRGB or do whatever we want.

(In reply to comment #11) > http://www.w3.org/Graphics/JPEG/jfif3.pdf talks about YCbCr not Y'CbCr. > Y means luminance (no gamma correction) while Y' means luma (gamma corrected). I'm not finding anything so far that there is any difference between YCbCr and Y'CbCr or YCC. It's not an absolute space anyway so luminance in the sense of Y in CIExyY or CIEXYZ I don't think is applicable. Re-encoding 8bpc data to linear when creating the file and then tone mapping it again when reading it would be rather destructive and unnecessarily so. If the spec actually uses the term linear, then I would sooner think they mean original encoding remains intact in the conversion to/from Y'CbCr. > It isn't the JFIF spec but common practice that changed Y to Y'. As I said > earlier, I don't think anyone actually uses gamma==1 to decode JPEG images, > but there is a conflict between the JFIF spec and the sRGB spec. I think there is no conflict for three reasons: 1. Stated above. Y = Y' in the case of YCbCr 2. it makes no sense to re-encode, it would cause a lot of unnecessary loss via limited bit depth. 3. In any event, the original RGB data is returned intact, as is. And that data is separate from any conversation on the encoding of the YCC data in the file. The RGB data is tone mapped and absolutely can be assumed to have sRGB primaries and tone reproduction.

OK I could have saved us time by looking this up. Page 4 of the spec shows 8bpc formula for computing Y. It's just taking weighted amounts of each channel. That's it. The resulting image would look like you'd converted it to grayscale. In other words, it is maintaining the image's original encoding, and thus no conflict with assuming sRGB. Y = 0.299 R + 0.587 G + 0.114 B This Y has no correlation at all to Y in xyY or XYZ and is appropriately called luma rather than luminance.

The file "test JPEG with sRGB IEC61966-2.1 embedded" has its intent flag set to absolute colorimetric which is causing the problem listed in this bug. When intent is set to relative colorimetric, there is no mismatch between FF assumed sRGB source for untagged JPEG. Recommend marking this bug as duplicate of Bug 444014, which was just posted and further clarifies the problem and issues involved.

Good call - marking as a duplicate.