Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify use of transfer functions #222

Merged
merged 7 commits into from
Feb 5, 2025
Merged

Clarify use of transfer functions #222

Changes from 6 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
1ee4611
First draft of use of transfer functions.
MarkCallow Jan 29, 2025
055a327
Fix punctuation per review comment. Remove note.
MarkCallow Jan 29, 2025
7be4f2e
Fix more punctuation.
MarkCallow Jan 29, 2025
622b438
Define OOTF abbreviation.
MarkCallow Jan 29, 2025
335eaf8
Match language to other similar bullets.
MarkCallow Jan 29, 2025
f158b4d
Update revision history.
MarkCallow Jan 29, 2025
8f18ab5
Rewrite for TF aliases and to address review comments.
MarkCallow Feb 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions ktxspec.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1014,6 +1014,45 @@ Still, `KHR_DF_PRIMARIES_BT709` / `KHR_DF_PRIMARIES_SRGB` is recommended
for standard dynamic range, standard gamut images.
====

==== Use of Transfer Functions
The majority of transfer functions listed in Chapter 13 _Transfer
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that's true. Most of the transfer functions correspond only to either the OETF or the EOTF, with a small number of exceptions where the two are the same. BT.601/709/2020 don't comment on the reference display, for example - that's what BT.1886 does. Equally, while the sRGB description does talk about how it can be integrated into a BT.709-based authoring environment, it is of itself only documenting the EOTF - it is for displaying computer content, so there is no concept of a camera capturing a scene in sRGB itself.

functions_ of <<KDF13>>, with corresponding enumerators given in
Chapter 5 _transferFunction_, have a linear opto-optical transfer
function (OOTF). That is the opto-electrical transfer function
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: the EOTF or OETF doesn't "have" an OOTF - they are defined in specifications which define an OOTF.

(OETF) is the inverse of the electro-optical transfer function
(EOTF). When a KTX file has one of these transfer functions

* applications should use the EOTF to decode prior to sampling and
filtering;
* mipmap generation should use the path EOTF → scaling → OETF.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By definition, if the OOTF is linear, the EOTF is the OETF-1 and the OETF is the EOTF-1. If they're symmetrical, they also have the same enum. That does mean this processing path is correct, although I would find it a little confusing to state it that way.


These transfer functions have no suffix in their enumerator names.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The KDFS enumerators without a disambiguating either EOTF or OETF in the name indicate that the originating specification defines only an EOTF (such as sRGB), only an OETF (such as BT.709), or there is a linear OOTF. The proposed updated enum aliases clarify this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is a linear OOTF

I think this is the only thing KTX cares about in practice.


The sRGB transfer function is one of these, defining an EOTF. EOTF^-1^
is used as the OETF.
Copy link

@fluppeteer fluppeteer Feb 2, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not true (there is no OETF in sRGB, and no defined OOTF, unless combined with a scene-referred standard such as BT.709).


Some transfer functions have a non-linear OOTF. That is the OETF
is not the inverse of the EOTF. These have two separate enumerators,
one with an `OETF` suffix, the other with an `EOTF` suffix. When a
KTX file has an explicit OETF
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Has an explicit OETF" means the enum chosen corresponds to the OETF defined by the specification, yes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It means that the DFD enum has the _OETF suffix.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "some transfer functions have a non-linear OOTF" read strangely to me - the OOTF is one transfer function, the OETF is another, the EOTF is a third, so they don't "have" each other. Perhaps "some color spaces", or "some standards"?


* the images are _scene referred_ and intended to be decoded to
scene-linear values;
* applications should use OETF^-1^ to decode prior to sampling and
filtering;
* mipmap generation should use the path OETF^-1^ → scaling → OETF.

When a KTX file has an explicit EOTF
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correspondingly, this means the enum identifies the EOTF defined by a specification? I think it's sufficient to say that KTX tools will process in the display-linear space or scene-linear space, determined by the enum encoding (for any enum that identifies either an EOTF or OETF; it would require additional information to specify the corresponding function for specifications that only define one transfer function). Applications creating a KTX file should indicate the authoring space that they used to create the content, whether that is scene- or display-referred.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correspondingly, this means the enum identifies the EOTF defined by a specification?

Ditto. It means that the DFD enum has the _EOTF suffix.

Applications creating a KTX file should indicate the authoring space that they used to create the content, whether that is scene- or display-referred.

The KTX header defines how to process the file, not how it was created. The intention is to use _EOTF and _OETF enum suffixes to disambiguate the scene vs display linearity for cases when the OOTF is not linear..

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The KTX header defines how to process the file, not how it was created. The intention is to use _EOTF and _OETF enum suffixes to disambiguate the scene vs display linearity for cases when the OOTF is not linear..

I'm expecting it to affect the tooling, on the assumption that any mip chain generation probably shouldn't change the colour space identifiers and that this is a useful way to pass that information to the tool chain. If this documents how user applications might wish to receive similar instructions, sure. For an application converting content to screen space for display, it should always find an EOTF to use, whatever that EOTF may be. If converting to content that is part of a LDR video stream, it should be following the OETF instead. Hopefully the application knows what it's doing, and can make that decision.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully the application knows what it's doing, and can make that decision.

Yes and that's out of the KTX scope. Remember that KTX is not a general-purpose image or video format related to cameras or screens.

One could say that _EOTF files would be "images to be displayed" and _OETF files would be "material textures to be sampled from".


* the images are _display referred_ and intended to be decoded to
display-linear values;
* applications should use the EOTF (often derived from the OOTF) to
decode prior to sampling and filtering;
* mipmap generation should use the path EOTF → scaling → EOTF^-1^.

OETF and EOTF formulae are given in Chapter 13 _Transfer functions_ in
<<KDF13>>
MarkCallow marked this conversation as resolved.
Show resolved Hide resolved

==== Providing additional information
There are several cases where the _dfDescriptorBlock_ is used to
provide information beyond that given by <<_vkformat,`vkFormat`>>.
Expand Down Expand Up @@ -2471,6 +2510,8 @@ include::appendices/vendor-metadata.adoc[]
- Remove requirement for bytesPlane
0 in DFDs of supercompressed
files.
- Add rules for use of transfer
functions.
|===

[discrete]
Expand Down