khronosgroup / dataformat Goto Github PK

Hello 👋

the example DFD for unsigned BC6h in table 48 (around here, not sure how to link to the actual table) has a sampleLower of 0xBF800000U = -1.0f although it's an unsigned format, and the signed flag is not set in the channel qualifiers.

Is this an error in the table or an intentional choice? dfdutils doesn't make this exception and chooses sampleLower = 0.0f for _UFLOAT Vulkan types, contradicting the example.

1. It would be nice for variables to consistently use italic font throughout the spec. E.g.:
   

2. Also, there're some syntax issues (notice backslashes):
   

3. Probably, broken links:
   
   

From https://www.khronos.org/bugzilla/show_bug.cgi?id=1463 (which should also be closed when this is taken care of):

On the Kronos Data Spec page, there is a copy paste typo under the
There is a documentation copy/paster typo on this page:
https://www.khronos.org/registry/dataformat/specs/1.1/dataformat.1.1.html

Under the KHR_DF_TRANSFER_SRGB description, the definition of G' when
converting from linear encoding to nonlinear encoding incorrectly refers to the
R component in the G < 0.0031308 case.

It should be corrected from:

G' = \begin{cases}
R \times 12.92, & G \leq 0.0031308
1.055 \times G^{1\over 2.4} - 0.055, & G > 0.0031308
\end{cases}

To:

G' = \begin{cases}
G \times 12.92, & G \leq 0.0031308
1.055 \times G^{1\over 2.4} - 0.055, & G > 0.0031308
\end{cases}

https://www.khronos.org/registry/dataformat/

The current version is 1.1, February 16, 2015.

this should be

The current version is 1.1, February 16, 2016.

As detailed here: KhronosGroup/KTX-Specification#131
It appears that a PVRTC surface must always have at least 2x2=4 data words.
Specifically this seems from this: KhronosGroup/KTX-Specification#131 (comment)

From the OpenGL ES IMG_texture_compression_pvrtc extension:

• For PVRTC 4BPP formats the imageSize is calculated as:
  (max(width, 8) * max(height, 8) * 4 + 7) / 8
• For PVRTC 2BPP formats the imageSize is calculated as:
  (max(width, 16) * max(height, 8) * 2 + 7) / 8

Seems like 32 bytes is the minimum PVR image size possible.

This is kind-of ambiguous with this document's phrasing of "At least one word of PVRTC data must exist in each mip level of a texture.", because although it's correct it probably should read "At least four words of PVRTC data must exist in each mip level of a texture because interpolation requires 2x2 data words".

To repository owners: please rename the default branch of this repository from 'master' to 'main', using the Github renaming tool. This request is per policy set by the Khronos Promoters in May 2021, to follow Github community practice for respectful naming.

The Github renaming tool sets up URL redirections and retargets outstanding pull requests, so the impact on repository users is minimal. The most visible issue is that people with local repo clones will probably want to rename their clone's 'master' branch, following the popup instructions that will be seen when browsing the github repository after the change; or just delete 'master' and pull the new 'main', if it's purely a tracker with no local content.

You may wish to coordinate with @outofcontrol if you are doing auto-updates from this repository to another location, whether via push/pull mirroring or other mechanisms. The redirects setup by Github should accommodate most such uses transparently, but it's still good practice.

Based on experience with other KhronosGroup repositories which have undergone this renaming already, this is a reasonable approach:

• Agree on a date for the renaming within the Working Group or other owners of the repository, and document that date here.
  • Date can be adjusted to avoid interaction with major releases in flight.
• Provide notice to repository users outside Khronos, insofar as possible (adding a comment in the repo README with the switchover date is one way).
• Once the renaming is done, edit the new 'main' branch to replace hardwired references to 'master' with (preferably) 'default branch' or 'main'.
• Update the repo README to note the change.

If you have questions or issues about this, please raise them on Khronos internal gitlab 'khronos-general' issue 106 if possible. If not possible, you can @-tag me here.

While we will not force any WG into acting precipitously, this is our agreed policy. Please try to accommodate renaming relatively soon.

Note that this issue is automatically generated, due to the large number of KhronosGroup repositories it's being raised in.

Now that 1.3 is published in the repo please make 1.3 the default branch. I don't know if it is possible to make a PR to do such a thing.

There is must be a typo in table 111. G1 and B1 should be 7 bytes long, but table says they stored in a bits 29..34 and 42..49, which is 6 and 8 bits long respectively.

From channel_type description:

If the KHR_DF_SAMPLE_DATATYPE_FLOAT bit is set, the sample holds floating point data in a conventional format of 10, 11 or 16 bits, as described in Section 16, “Floating-point formats”, or of 32, or 64 bits as described in [IEEE 754]. Unless a genuine unsigned format is intended, KHR_DF_SAMPLE_DATATYPE_SIGNED should be set.

Yet in the Table 113, "A single 16-bit floating-point red value, described normally", channel_type has no flag bits.

My browser (Firefox) refuses to load the MathJax script when viewing the latest version of the spec, because the server emits this header:

Content-Security-Policy: base-uri 'self'; form-action 'self' cdn.khronos.org; script-src 'self' 'unsafe-inline' 'unsafe-eval' cdnjs.cloudflare.com www.googletagmanager.com www.google-analytics.com

Here's the error message:

Content Security Policy: The page’s settings blocked the loading of a resource at https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML (“script-src”).

Section 3.2 explains how formats such as Y'CbCr 4:2:0 are described with two Y' planes under the specification (when other conventional APIs would only use one Y' plane). Table 96 contains an example descriptor for this format.

However, I don't see any way to make the difference between two consecutive planes and two interleaved planes. Section 3.2 uses per-plane byte offsets and strides to denote the difference, but I don't see these reflected anywhere in the descriptor in table 96?

Is the expectation that there is no way to make the difference in general? Or, as the following note explains, is the expectation that descriptors may reflect interleaved planes via the fourth sample coordinate, but this isn't mandatory?

One suggested convention for interlaced data is that the field of a sample be encoded in the fourth sample coordinate (the first field as samplePosition3 = 0, the second field as samplePosition3 = 1, etc.)

Or, am I missing something else?

There are two broken links in the Dataformat 1.3 specification on this page https://www.khronos.org/registry/DataFormat/specs/1.3/dataformat.1.3.html.

1. Near the bottom in this paragrahp: "The international standard for ACES, SMPTE ST 2065-1:2012 - Academy Color Encoding Specification (ACES), is available from the SMPTE, and also from the IEEE." a link to https://www.smpte.org/store is now 404.
2. The Khronos Logo linked to in this CSS file config/df-xhtml.css is missing.

  background-image: url(../images/Khronos_RGB_June18.svg);

I am trying to understand how to represent the RGB9E5 format as shown for:

• GL : https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_shared_exponent.txt
• VK : https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#textures-sexp-RGB

Note that the conversion to a value is given in both of the above as value = mantissa x 2^(exponent - bias - bits_in_mantissa)
For this format, bias = 15 and bits_in_mantissa = 9, and there is no implicit 1 or sign bit.

The data format spec (section 10.4, non-standard float formats) explains how to encode custom formats, and it gives an example of RGB9E5 as well (table 98), but I think I'm missing how that follows.

sampleUpper is supposed to be the mantissa value that represents 1 for exponent (after bias) 0.
sampleLower is supposed to be the mantissa value that represents 0 for exponent (after bias) 0.
For RGB9E5, substituting 0 for exponent - bias, we are left with value = mantissa x 2^(0 - 9).
To represent the value 1, mantissa should then be 512 because 1 = 512 x 2^-9.
To represent the value 0, mantissa should then be 0 because 0 = 0 x 2^-9.

However, in Table 98 (the example for RGB9E5) sampleUpper is set to 256, not 512.
(As expected though, sampleLower = 0, bitLength = 9 and bias (sampleUpper for the exponent sample) = 15).

I wonder if Table 98 contains a mistake, or if I am missing something somewhere.

PS: if 512 is indeed the correct value, then that runs afoul of the "implicit one detection", because 512 is one larger than the representable mantissa value. Moreover, to actually represent the value 1 in RGB9E5, I believe you need to use exponent-after-bias 1 (or higher) or you run out of mantissa bits.

PS2: And by extension, there is no single representation of 1 in RGB9E5 either, because I can arbitrarily bump the exponent by one and shift the mantissa by one, and it's still a value of 1. Is there a specific "representation of 1" that should be used?

OpenGL extension says (issue 7 here) that spec requires bit-exact decompression. Yet it doesn't give a formula for getting final pixel values from factors and endpoints.

Here's an example of possible confusion: GPUOpen-Tools/compressonator#36.

The definition of the sRGB EOTF given in this document is the sRGB inverse OETF. The sRGB EOTF however is a pure 2.2 power function.

Related discussion: https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/12