Re: Colour communication beyond sRGB

This thread is labeled color communication.
That seems to be a bit of mis-communication.

When I set out to contribute to the table I had a wider scope or intent:
- What color spaces do engineers need to know about in order to convert
correctly between them?
This seems to be lost in this conversation which seems to focus on
distribution.

If we focus only on distribution there’s not that much to learn or share.

As most color conversions happen before distribution, engineers would he
helped by having convenient access to the details of the color spaces used
here, regardless of whether these are distribution spaces or not. It was
my intent to summarize this.
Thus the P3 spaces are included as some engineers need to convert to those.

The table is subdivided by image state - scene-referred and
display-referred.
Many colorimetric conversions between color spaces of the display-referred
image state are trivial (ignoring gamut issues and re-rendering).
So subdividing an image state over multiple tabs seems like an enabler for
engineers making the wrong decisions by inadvertently mixing image states.

As color conversions that change the image state usually include some form
of color rendering, these usually require more details than a simple table
can provide, so out of scope (Feel free to disagree). ACES RRT ODT is a
complex example. Default rendering of 709 is a counter example for simple,
but not one to be recommended.

Another reason to organize clearly by image state is that many engineers
are still confused about what TF to use when converting video, and some
still use the camera curve of 709. (As Pierre notes below)
As you might note the camera curve of 709 is hidden in the scene tab.
Hopefully we can leave it hidden, although it’s used in the
non-recommended case of BT.2087.

As BT.2100 still evolves, PQ scene should be deferred for now, until there
is normative text for PQ <> HLG conversion. It’s not clear we need to
include HLG scene at all, but it’s in there for now as that one is easy to
spec. Let’s see what’s actually needed.


There are some omissions.

Should these color spaces be added?
Important camera spaces such as ARRI LogC.
The three(?) core YCC encodings
Adobe RGB, ColorMatch RGB, sc-RGB, bg-RGB, ProPhoto, ROMM, RIMM…


Color rendering specifications from scene to display? (ACES RRT?)

Viewing conditions are not included. Should we indicate at least dark,
dim, average surround?

Dynamic range is not indicated. The TF as shown implies that 709 has
infinite DR. Does this need to be addressed?


Given the challenges of providing sufficient info to be useful, is this an
effort in vain? 
Or would this table he helpful for anyone?
Please advise.

Lars



On 3/4/17, 7:46 PM, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:

>Hi Craig,
>
>My input below.
>
>> We can add this. Where does the 'COLOR.6' name come from?
>
>COLOR.6 is defined in SMPTE ST 2067-21:2016 (IMF Application #2),
>which is the closest to a formal definition of P3D65/PQ that exists,
>AFAIK.
>
>> I think it may be better to include only the necessary primary
>>references for each encoding.
>
>The challenge is that the reference to BT.1886 is easily missed,
>leading implementers to invert the OETF specified in BT.709. I would
>add least add a note.
>
>> The intent is to describe how the colour data is communicated - in some
>>cases this is with reference to a
>> display and in other cases it is with reference to a scene.
>
>Ok. The colorspace specified in RP 432-1* is never communicated or
>encoded. What is encoded is specified in ST 428-1, which uses XYZ
>components and does not specify a white point.
>
>I recommend collapsing the DCI P3 lines to a single "D-Cinema
>Reference Projector" line (specified in RP 431-2), and moving it to a
>"reference display" tab.
>
>> What should we show as the reference white luminance for the digital
>>cinema spaces?
>> Is there another reference besides 431-2?
>
>There is no white point defined in the D-Cinema encoding/decoding
>equations.
>
>There is a reference projector defined in RP 431-2.
>
>> I have indicated spaces not intended for broadcast by highlighting in
>>blue.
>
>As Lars pointed out, I am not sure "broadcast" is the right term. I
>would use "distribution" instead -- in contrast with "professional"
>applications, e.g. mastering and production (and arguably D-Cinema).
>
>>  in some cases this is with reference to a display and in other cases
>>it is with reference to a scene.
>
>Can you elaborate? For instance, I am not sure why HLG is present on
>the "to scene" tab, but not PQ.
>
>> On the CSS documentation for 'image-p3' I see that this talks about
>>'image-p3' [DCI-P3], however
>>I think these both use different transfer functions. There is also a
>>typo for the y value of the white
>> chromaticity - it should be '0.3290'.
>
>I would think this should ultimately be filed as an issue against the
>CSS specification. Not sure what the timing is, perhaps Chris Lilley
>can provide some guidance.
>
>Best,
>
>-- Pierre
>
>* Did you mean RP 431-2 instead of EG 431-2 by any chance? RP 431-2
>defines a reference projector, whereas EG 431-2 is more of a how-to.
>
>On Fri, Mar 3, 2017 at 4:00 AM, Craig Revie <Craig.Revie@ffei.co.uk>
>wrote:
>> Hi Pierre,
>>
>> Thanks for your feedback. I have attached a revised version of the
>>spreadsheet that shows my suggested changes. Please let me know if you
>>think I have misunderstood anything - see my comments below.
>>
>> You said:
>>> - the table is missing the COLOR.6 (P3 primaries, D65 white point and
>>>PQ EOTF)
>> We can add this. Where does the 'COLOR.6' name come from? Perhaps it
>>would be more consistent (and informative) to refer to this as DCI P3
>>D65/PQ.
>>
>>
>>> and COLOR.4 (xvYCC709 as specified in IEC 61966-2-4) systems used in
>>>IMF App 2E (SMPTE ST 2067-21)
>> This is not an RGB space and so can't easily be added to this document.
>>There are a number of such encodings which may be useful to document
>>separately.
>>
>>
>>> - If I am not mistaken, BT.709 (to display) is specified in BT.1886
>>> (BT.709 specifies only the OETF)
>> You are right. However BT.709 references BT.1886 (see note to table on
>>page 3). There are also other references, for example the reference
>>viewing environment is specified in BT.2035 and it could be confusing to
>>include them all. I think it may be better to include only the necessary
>>primary references for each encoding.
>>
>>
>>> - Shouldn't the "to display" tab should be split into "display
>>>colorspaces" and "encoding colorspaces",
>>> i.e. pixels are not encoded in the DCI P3 D55 colorspace and many
>>>displays that accept Rec.2020 signals
>>> cannot reproduce the full Rec.2020 gamut.
>> I am not sure that I follow this point. Can you explain further? The
>>intent is to describe how the colour data is communicated - in some
>>cases this is with reference to a display and in other cases it is with
>>reference to a scene. The table shows the relationship between what is
>>communicated and the reference display/scene. As I say, I am not sure I
>>have understood your comment clearly so please clarify.
>>
>>
>>> In fact, perhaps the "encoding colorspaces" tab should
>>> further differentiate between mastering/professional colorspaces
>>>(COLOR.6 and DCDM) from
>>> colorspaces in use for distribution.
>> I agree that it would be a good idea to differentiate these. I have
>>indicated spaces not intended for broadcast by highlighting in blue.
>>
>>
>>> - the sRGB reference monitor peak is 80 nits
>> Agreed.
>>
>>
>>> - 48 nits is only required for the Xenon reference white in 431-2
>> What should we show as the reference white luminance for the digital
>>cinema spaces? Is there another reference besides 431-2?
>>
>>
>>> - 'Display P3' has been renamed 'image-p3' in the most recent CSS
>>>draft [1]
>>> [1] https://drafts.csswg.org/css-color/

>> I understand. I have a request from Apple to refer to the space they
>>use as 'Display P3' but I have added (aka Image-P3) on the assumption
>>that these are the same. It seems from the documentation that they are
>>intended to be.
>>
>>
>> On the CSS documentation for 'image-p3' I see that this talks about
>>'image-p3' [DCI-P3], however I think these both use different transfer
>>functions. There is also a typo for the y value of the white
>>chromaticity - it should be '0.3290'.
>>
>> Best regards,
>> _Craig
>>
>> Best,
>>
>> -- Pierre
>>
>> On Mon, Feb 27, 2017 at 12:35 AM, Craig Revie <Craig.Revie@ffei.co.uk>
>>wrote:
>>> I would be interested to receive feedback from members of this group
>>> on the attached document which provides a summary of a range of colour
>>> spaces used for broadcast and display of colour information that I
>>> have put together with help from Lars Borg of Adobe.
>>>
>>>
>>>
>>> Specifically, are there any important colour spaces that are missing,
>>> have we made any incorrect assumptions, is there anything that we can
>>> add that would be helpful.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Craig Revie,
>>>
>>> FFEI Limited
>> ________________________________
>>
>> [FFEI_Logo_BoxOnly[1].png]<http://www.ffei.co.uk> [FFEI wins 3rd Queens
>>award for innovation]
>><http://www.ffei.co.uk/ffei-wins-third-queens-award-for-innovation/>
>> CONFIDENTIALITY AND DISCLAIMER NOTICE
>>
>> This message and any attachment is confidential and is protected by
>>copyright. If you are not the intended recipient, please email the
>>sender and delete this message and any attachment from your system.
>>
>> Dissemination and or copying of this email is prohibited if you are not
>>the intended recipient. We believe, but do not warrant, that this email
>>and any attachments are virus free. You should take full responsibility
>>for virus checking.
>>
>> No responsibility is accepted by FFEI Ltd for personal emails or emails
>>unconnected with FFEI Limited's business.
>>
>> FFEI Limited is a limited company registered in England and Wales
>>(Registered Number: 3244452).
>>
>> [Join us on Linked In]<http://www.linkedin.com/company/ffei> [Follow
>>@FFEI_ltd] <https://twitter.com/FFEI_ltd>  [FFEI YouTube Channel]
>><http://www.youtube.com/user/FFEIPrintTechnology>
>> Registered Office: The Cube, Maylands Avenue, Hemel Hempstead,
>>Hertfordshire, HP2 7DF, England.
>

Received on Monday, 6 March 2017 02:52:17 UTC