[Openicc] Extra metadata keys for review

[Chris Lilley]

On Sunday, May 6, 2012, 8:45:29 AM, Richard wrote:

RH> As discussed with Kai-Uwe, I'm presenting a list of additional
RH> metadata keys for review for the ICC metadata spec. I'm not
RH> particularity attached to the names, although they have been used in
RH> gnome-color-manager and dispcalgui for some time, so I'd prefer not
RH> changing them if possible.

Noted.

I haven't suggested any name changes below but I have asked some clarifying questions that would make a more precise specification. I am happy to help wordsmith more precise text.


RH> STANDARD_space          A standard space, where "srgb" -> sRGB; "adobe-rgb" ->
RH> AdobeRGB; "prophoto-rgb" -> ProPhotoRGB

Is this a complete list, or three examples (thus, others can extend it with other tokens like ECI-rgb)? If it is an extensible list, where is the registry (so two users don't come up with different tokens for the same space)?

Does 'standard' mean 'standardised somewhere' or 'commonly used' or (looking at DATA_source below) does it mean 'this is where I got the numbers from, for this profile that was not produced by calibration)?

RH> EDID_md5                The EDID MD5 checksum
RH> CMF_product             The color management framework name that generated this
RH> profile, e.g. "GNOME Color Manager"
RH> CMF_binary              The color management framework binary that generated this
RH> profile, e.g. "gcm-calibrate"
RH> CMF_version             The color management framework version that generated
RH> this profile, e.g. "3.1.1"

ok

RH> DATA_source             The data source of the profile, where: "edid" -> From a
RH> display EDID blob; "calib" -> From a calibration; "standard" -> From a
RH> standard, e.g. "sRGB"; "test" -> For testing, e.g. "BGR"

Good. But suppose my monitor has several emulations (Adobe RGB, sRGB), I set the monitor to one of these, calibrate, characterise and produce a profile. In this case I set DATA_source to calib, not standard, and I leave STANDARD_space blank or do I set it to adobe-rgb or whatever?

If I have understood what STANDARD_space is for, it may be better to make the definition refer explicitly to DATA_source=standard.

RH> MAPPING_format          The format used for matching, e.g.
RH> "ColorModel.OutputMode.OutputResolution"

Is there a registry for the allowable tokens? I think I asked this at LGM but I forget the answer -is the list of tokens ordered by importance or freeform?

RH> MAPPING_qualifier       The qualifiers the profile should adopt by default,
RH> e.g. "RGB.Plain.300dpi"

Good.

RH> MAPPING_device_id       The device this profile should be paired with, e.g.
RH> "cups-Photosmart-B109a-m"

Is this a device model number, or a combination of a model number and other qualifiers to form a print queue name, or what?

RH> ACCURACY_dE76_avg       The calibration delta-E average value
RH> ACCURACY_dE76_max       The calibration delta-E maximum error value
RH> ACCURACY_dE76_rms       The calibration delta-E RMS error value

(Good that these state *which* dE is meant).

RH> MEASUREMENT_device      The device used to create the profile, e.g.
RH> "colormunki" or "huey"

I think a little more guidance could be given here, given that there are now two entirely different devices (and three different packages) called colormunki, two very different devices with i1 in their name, four different spyders, etc. So this key should be defined such that very dirrerent devices (e.g. the "colormunki display" colorimeter and  the "colormunki photo" spectro) don't use the same token.

Argyll spits out some sort of instrument identifier, maybe we could use that to populate a registry of measurement devices.

There could also be scope for an additional metadata key containing the serial number of the measurement device.

RH> SCREEN_surface          The screen panel surface type, where: "matte" ->
RH> Matte, textured surface "glossy" -> Glossy, shiny surface

Are these the only two values, or are they examples?

RH> SCREEN_brightness       The screen brightness as set during calibration as a
RH> percentage, e.g. "50"

While that may be helpful for the one user that created the profile, it is less helpful for another user or for the same user once their screen is a few years older.

An additional key giving the aim point for white luminance would be helpful (e.g. 120 cd/m-2)

RH> CONNECTION_type         The connection type of the video output, where:
RH> "internal" -> Internal digital, e.g. LVDS; "vga" -> Analogue VGA;
"dvi" ->> Digital DVI; "hdmi" -> Digital HDMI; "displayport" -> Digital
RH> DisplayPort

Good. Are there any devices that use, for example, internal displayport? In other words is internal/external an orthogonal variable to connection type?

Does thunderbolt count as displayport?

RH> GAMUT_volume            The volume of the gamut, (scaled to sRGB = 1.0)
RH> expressed as a positive floating point value.

In CIE Lab space, I assume?

RH> GAMUT_coverage($x)      The coverage of the gamut compared to a standard
RH> gamut, given as $x. The values in $x can be any of the standard spaces
RH> allowed in STANDARD_space for example "adobe-rgb". This is expressed
RH> as a positive floating point value where 0.0 is none, and 1.0 is full
RH> coverage.

Is this a 3D coverage by volume, or a 2D coverage on a chromaticity diagram, as used in marketing?

RH> Initial comments from Kai-Uwe and me were that:
RH>  * STANDARD_space makes a ton of sense when you want to use the Adobe
RH> supplied profile rather than the Clay profile, or the Facebook sRGB
RH> rather than the official sRGB.
RH>  * EDID_md5 is a no-brainer
RH>  * CMF_ is a good idea, but Kai-Uwe didn't like the Color Management
RH> Framework nomenclature prefix
RH>  * DATA_source for when you've used a tool should "characterisation",
RH> although it's longer and we have to decide on en_US or en_UK.

How about "measured". That encapsulates both the calibration and the characterisation phases.

It also differentiates objective measurement with subjective fiddling about with gamma and saturation sliders.

RH>  * MAPPING_device_id probably only makes sense for colord, although I
RH> guess Oyranos could do something with it too. (I'm okay not to propose
RH> this key if that's an issue)

RH> Comments welcome. Thanks

Several times above I have suggested registries of tokens, if they are an extensible set. This need not be particularly complicated, a wiki page per registry would be fine.

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