[Openicc] Extra metadata keys for review

[Richard Hughes]

On 6 May 2012 08:58, Chris Lilley <chris at w3.org> wrote:
> I am happy to help wordsmith more precise text.

That would be most appreciated. Thanks.

> 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)?

I figured that the spec would list all the options. In colord we have
an API where the program can say "give me the profile that is marked
as adobe-rgb'" so you can use profiles supplied by the distro or from
another proprietary package. I just listed the common colorspaces, and
chose to delimit spaces with '-' and used all lower case. I don't
think we need to list *all* colorspaces here, just the common ones we
want people to actually use.

> 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)?

standard == known and well used colorspace standard, such as AdobeRGB
or ProPhotoRGB.

> RH> CMF_version             The color management framework version that generated
> RH> this profile, e.g. "3.1.1"
>
> ok

This is something we wanted to use for audit purposes too.

> 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?

I figured DATA_source would be "Where have the numbers to make this
profile come from".

> 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?

It's the ColorKeyWords specified in the PPD by default, but it's
really freeform text so you can do what you want. If the _format
matches the three color keywords in the PPD then CUPS does the right
thing (tm) -- if we move to printerd in the future then we might want
to use different keys (e.g. "model;paper;ink;resolution" or even XML
or something) and so I've left it deliberately underspecified.

> 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?

I've documented this here:
https://gitorious.org/colord/master/blobs/master/doc/device-and-profile-naming-spec.txt
but it's horribly colord and gnome-color-manager specific. I don't
mind at all if we either drop this suggestion or just write something
like "The specific CMS can use this key for whatever data it uses to
identify the device".

> 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...

Yes, it sucks that a certain company can't seem to come up with any
new product names. This is the list I've been using in colord:
https://gitorious.org/colord/master/blobs/master/libcolord/cd-enum.c#line325
which is probably a good start.

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

Sure, sane.

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

Ahh, yes, good idea. Something like:

MEASUREMENT_device_id = The device used to create the profile....e.g. "dtp41"
MEASUREMENT_device_serial = The measurement device serial number.

> 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?

Good question. I'm not sure the average user knows much more than if
the screen is shiny or not. I don't actually set this in colord, but i
know Florian does in dispcalgui.

> 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.

So, have SCREEN_brightness as a percentage and have SCREEN_luminance
as a value in 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?

You have internal displayport in new (I think unreleased) laptops. I
think _type is probably orthogonal, but that then suggests another
key:

CONNECTION_physical = The physical connector connection, either
"internal" or "external".

> Does thunderbolt count as displayport?

That's a really good question. As I understand thunderbolt, it's a
superset of the (already complicated) displayport specification, along
with a PCI-E bus for good measure. I think from what we want to use
the information for I think thunderbolt == displayport, but I'm open
for ideas on that.

> 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?

Right, sure.

> 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?

I think using the 3D space makes sense, I don't see any value in doing
this for 2D. I know working out the intersections of two hulls is
computationally expensive, which is why I think it's best as a
metadata key rather than just generating it in the GUI program.
Florian and I spoke a bit about this and he convinced me to add it :)

> 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.

That sounds perfect.

> 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.

Right. I think for the moment having them in hardcoded in the spec
makes sense, as at least for g-c-m, adding new enums means adding new
translations which I can't do in a stable release.

Richard.