Adding a <Colorspace> element (or similar) to <InputDescriptor> and <OutputDescriptor> elements

clf
Tags: #<Tag:0x00007fd5a5d99950>
(Scott Dyer) #1

@walter.arrighetti, I believe this stemmed from a request made by you when this group was first forming. And I may have misunderstood your intent, so let’s discuss as a group in this thread.

The desire here seems to be to better describe the intended input and output of a LUT - i.e. color primaries, white point, transfer function, viewing environment, etc. However, for whom is the “colorspace” being described?

Is it for an application to be able to parse and somehow use it? If so, I think that’s a noble, but unattainable goal. As mentioned during the call, this has been attempted by many groups in many other instances (e.g. DPX) and it has always failed. Enumerated lists always end up underspecified and so in practice end up getting ignored because they are never set properly.

If this item is solely intended as an informative field for the user, then how does adding another element to InputDescriptor and OutputDescriptor help? Isn’t that what those two arbitrary string elements are already intended for?

During the call it was suggested we could potentially add optional attributes to the InputDescriptor and OutputDescriptor elements: such as ‘colorSpace’, ‘transferFunction’, ‘whitePoint’, etc. This would avoid adding additional levels to the XML structure and allow for arbitrary order/presence of these labels.

If we insist on adding some additional structure to describe the intended input and output, my vote is for doing it via attributes.

(Scott Dyer) #2

This topic is one of the additions to the specification that needs input from you!

This was discussed at length in our Spec Review meetings. According to my memory of things, we decided that longer-term, this would be an interesting and noble effort, but a standardized, all-encompassing, machine-readable way to tag all relevant color space information would not be attainable in such a short time frame (or maybe ever).

I’m working on the draft updates to the spec and need input from you on this particular item.

Did we all agree that we would (at least for this revision) accomplish this by adding attributes to Input/OutputDescriptor elements?

(Scott Dyer) #3

The specification already has <InputDescriptor> and <OutputDescriptor> comment fields for describing the intended source/output code values of the ProcessList.

The goal with this addition to the spec is to provide a place to better describe the intended input/output of a LUT. Things such as: color primaries encoding, white point encoding, transfer function, peak luminance?, image state, viewing environment, etc.

Overall:
Pros: provide a field of important information to prompt them to include useful metadata to communicate intended usage
Cons: people might not fill, or worse, not fill correctly

Without writing an entire new language to communicate all this information (which would undoubtedly overlook things), I see three options:

  1. Add sub-elements to the XML structure to nest under Input/OutputDescriptor
    Pros: Explicit, ordered
    Cons: Based on my limited understanding of XML parsing, this is undesirable because it adds levels to the XML and unnecessarily complicates parsing?
  2. Add attributes to Input/OutputDescriptor
    Pros: Order doesn’t matter and no deeper level XML parsing, no parsing of a single structured string
    Cons:
  3. Add no additional XML structure and just provide guidelines as to what information should be put into the InputDescriptor and OutputDescriptor elements to provide useful information. aka “structured string”
    Pros: No change to schema
    Cons: Requires a custom parser of the structured string, and requires people to adhere to a specific ordering and format

I believe the conversations in the earlier group meetings left us leaning toward #2. Please correct me if you remember differently. Also, weigh in with whatever other ideas you might have.