[Openicc] W3C recommendations for displaying RGB JPEG images with embedded ICC-profiles

Chris Lilley chris at w3.org
Fri Aug 26 09:44:53 PDT 2011


On Monday, August 15, 2011, 5:26:36 PM, Jan-Peter wrote:

JPH> Hello Chris, hello list

Hi Jan-Peter. I'm just back from vacation/convalescence, sorry for the delay.

JPH> JPEG image formats allow to embedd ICC-profiles into image files, to 
JPH> give a clear color reference, if the colorspace of an image is not sRGB.
JPH> I have done some research on the W3C site to get an impression, if W3C
JPH> does any statements, if its forbidden to to use JPEG images with 
JPH> embedded profiles, or if this is allowed.

Its certainly not forbidden!

Over the years, the approach at W3C has changed. Early specifications, like HTML3.2, HTML4 and CSS1, were very open-ended regarding referenced media. The early HTML specifications defined an img element but said nothing about the types of images that could be referenced. Similarly CSS1 allowed background images but  said nothing about the format.

The limitations of this approach were clear with SMIL; implementations that followed the spec exactly were non interoperable, because the media formats were not defined (and the market leader at that time used a range of proprietary formats).

So later specifications are tending to specify this in more detail. As an example SVG 1.2T requires all implementations to support at least JPEG/JFIF and PNG. Other formats are allowed, but not required.

The level of support is defined in an appendix - basically all of PNG, and the commonly-implemented interoperable subset of JPEG/JFIF corresponding to what is in libjpg.
http://www.w3.org/TR/SVGTiny12/jpeg.html

JPH> During my research, I got the impression that this topic is currently 
JPH> out of the scope of the W3C.
JPH> Is this correct ?

Somewhat. That is changing though.

JPH> On the other hand, concerning the SVG specification, which are 
JPH> maintained by W3C, there are clear statements on conformance levels and
JPH> ICC support for SVG viewers.

SVG 1.1 supports color management but as an optional feature. So the SVG 1.1 and 1.2T specs currently say nothing about handling of embedded ICC profiles in images. SVGT 1.2 does say to treat untagged image data as sRGB, when converting from YCC to RGB. 

JPH>  From my point of view, it would make sense, if the W3C would define 
JPH> some levels of Browser conformance for usage on embedded profile JPEG 
JPH> (and PNG) images.

The SVG Color spec requires color management, and adds an explicit conformance requirement for support of embedded ICC profiles in images.
http://dev.w3.org/SVG/modules/color/master/SVGColor.html#color-managed-images

It also requires support for both IC v.2 and v.4 profiles
http://dev.w3.org/SVG/modules/color/master/SVGColor.html#assert_ICv4

I agree that more specific statements about ICC profiles in JPEG/JFIF and in PNG should be added there.

JPH> It is possible to (and e.g. als available with Firefox), that 
JPH> ICC-profile support is implemented at application (e.g. browser) level.

Yes. Unfortunately Firefox chose to throw out the well-supported LCMS library in favour of their own solution which has partial ICC v.2 support and no ICC v.4 support.

JPH> We also have a growing number of devices and platforms (e.g. Android and
JPH> Apple iPad), which currently do not provide an display profile to 
JPH> applications.

Unbelievable in this day and age, especially from Apple.

JPH> This situation could be solved, if applications (e.g. browsers) are 
JPH> using sRGB as an default internal Display profile, if the platform do 
JPH> not delivers an display-profile. In this case JPEG images with e.g. 
JPH> embedded AdobeRGB ICC-profile would be rendered with application based
JPH> colormanagement to sRGB and than displayed on a device.

Yes, that could work. At least, it would be better than throwing raw AdobeRGB at the screen and expecting a reasonable result.



JPH> Chris, could you please describe the W3C view on JPEG (and PNG) with 
JPH> embedded profile in W3C compliant viewers (e.g. browsers) ?

I would say that going forward, the W3C view is to specify an interoperable minimal set of media, where that can be done in a royalty-free fashion (so, a big problem for specifying required formats for video,  unfortunately) and to more closely define for each format which features must be supported. Othwer features and other formats may be supported.

Also, going forward, W3C specs will define how to treat tagged and untagged images in a color managed browser environment, and giving better guidance on how to deal with tagged and untagged images in a non-colormanaged environment seems reasonable.

The advice and feedback of experts on this list towards those ends is warmly welcomed.






-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups



More information about the openicc mailing list