Skip to main content
The Khronos Data Format Specification was first released on July 29, 2015 and is regularly updated.
Components of computer systems often work on collections of small, fixed-size units, such as pixels, normals or coordinates, which can have several possible representations. In the past, each API has tended to use its own scheme for describing its layout. These schemes usually enumerate each option, which then need to be implemented explicitly. A format implemented in this way is either supported or not - there is no convenient way to write flexible code that can support a variety of input that has not been seen before. It is time-consuming to add new functionality that supports each format, hard to compare formats, and hard to add support for new formats.
Data may need to be shared with other parts of the system, meaning that translation between the proprietary representations is needed to communicate across each interface. This translation requires significant programmer effort and can be error-prone. This work relies on the quality of documentation, which is often intended to be human-readable and can be imprecise - and the description of the formats makes the documentation itself more complicated.
APIs are typically designed to support only a subset of possible formats and make domain-specific assumptions about how the data should be interpreted. When additional flexibility is later needed - for example, compressed formats or multi-planar YUV - retrofitting additional flexibility can be more complicated than if it were designed in at the beginning. The lack of a standard scheme for interoperation also makes management of metadata awkward. For example, both the application and the user interface may understand color spaces, but information needed to correctly represent the image may go missing if it has to be passed through a library that does not have a representation of this concept.
Last but not least, the lack of a standard way to describe data often leads to misconceptions and miscommunications between developers. When each team has its own naming conventions and implicit assumptions, a lot of time can be wasted resolving the confusion.
Khronos’s specification aims to solve the issues seen in previous data format schemes:
The format descriptors defined by the Khronos Data Format Specification are small and simple enough to allow fast interpretation and easy copying. However, it is not expected that these format descriptors will be interpreted on every function call to a real-time API, nor does existing software or hardware need to be rewritten to use this standard. Most APIs will continue to use an enumeration scheme to describe formats, but may choose to use this enumeration as an index into an array of standard format descriptors. This allows descriptors to be accessed when needed by generic code or when transferring data outside the API, while retaining a minimal enumeration when the range of possible formats used by an entry point is limited. More flexibility can be added by making this mapping array user-extensible. Descriptors complying with the Khronos Data Format Specification have been generated internally for the OpenGL, OpenVX and Vulkan APIs, demonstrating the possibilities of this scheme.