commit local updates

- begin reorg of base directory structure
- create encodings sub-section in nav

docs/amf/guides/index.md

@@ -10,28 +10,18 @@ ACES Metadata File Implementation Guidelines and Best Practices
 Scope
 ----------------
 
-
 This document is a guide that recommends implementation guidelines and best
 practices related to the usage of the ACES Metadata File (AMF) in various
 workflows. These workflows may involve one or more tools that support the AMF
 specification and this guide attempts to help both implementers and users in
 order to facilitate interoperability.
 
 
-References
-----------------
-
-
-The following standards, specifications, articles, presentations, and texts are referenced in this text:
-
-* [Academy S-2019-001, ACES Metadata File (AMF)](https://aces.mp/S-2019-001)
-* [IETF RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace](https://standards.globalspec.com/std/1524451/RFC%204122)
 
 
 Introduction 
 ----------------
 
-
 The Academy Color Encoding System (ACES) is a color processing framework that
 enables the mix of various sources within a standardized color space in order to
 produce one or more outputs.
@@ -64,7 +54,6 @@ and tools that support those workflows.
 What is AMF
 ----------------
 
-
 AMF is an XML specification that describes the configuration of an ACES color
 pipeline, together with the various input transforms, look transforms and output
 transforms.
@@ -87,7 +76,6 @@ be described as a "many to many" relationship.
 Why is AMF needed
 ----------------
 
-
 The ACES framework is expanding and becoming richer in terms of input, look, and
 output transforms. AMF describes the exact list of these different transforms,
 in the order in which they have been or should be applied to obtain the desired
@@ -999,6 +987,16 @@ A validation process can log any differences and present the results to the user
 of the product/tool processing the EDL+AMF files.
 
 
+References
+----------------
+
+
+The following standards, specifications, articles, presentations, and texts are referenced in this text:
+
+* [Academy S-2019-001, ACES Metadata File (AMF)](https://aces.mp/S-2019-001)
+* [IETF RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace](https://standards.globalspec.com/std/1524451/RFC%204122)
+
+
 
 <!-- Include section numbering -->
 <style>

docs/amf/specification/index.md

@@ -11,20 +11,6 @@ Scope
 This document specifies the ACES Metadata File (“AMF”), a ‘sidecar’ XML file intended to exchange themetadata required to recreate ACES viewing pipelines.This specification supersedes TB-2014-009 – Academy Color Encoding System (ACES) Clip-level MetadataFile Format Definition and Usage (“ACESclip”). TB-2014-009 is now considered obsolete.
 
 
-References
-----------
-The following standards, specifications, articles, presentations, and texts are referenced in this text:
-
-* [Academy S-2014-002, Academy Color Encoding System - Versioning System](https://www.dropbox.com/s/cnrak5pvu4agfk4/S-2014-002.pdf?dl=0)
-* [SMPTE ST 2065-1:2021, Academy Color Encoding Specification (ACES)](https://doi.org/10.5594/SMPTE.ST2065-1.2021)
-* [SMPTE ST 2065-4:2013, ACES Image Container File Layout](https://doi.org/10.5594/SMPTE.ST2065-4.2013)
-* [Academy TB-2014-010, Design, Integration and Use of ACES Look Modification Transforms (LMTs)](https://www.dropbox.com/s/grjoi885tv78e70/TB-2014-010.pdf?dl=0)
-* [ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of datesand times](https://www.iso.org/standard/40874.html)
-* [ISO/IEC 11578:1996, Information technology – Open Systems Interconnection – Remote Procedure Call(RPC)](https://www.iso.org/standard/2229.html)
-* [SMPTE ST 2067-50, Interoperable Master Format — Application #5 ACES](https://doi.org/10.5594/SMPTE.ST2067-50.2018)
-* [SMPTE RDD 47, Interoperable Master Format — Isochronous Stream of XML Documents (ISXD) Plugin](https://doi.org/10.5594/SMPTE.RDD47.2018)
-* [SMPTE ST.2067-9, Interoperable Master Format — Sidecar Composition Map](https://doi.org/10.5594/SMPTE.ST2067-9.2018)
-
 Introduction 
 ----------------
 ### Why is metadata needed for ACES?
@@ -63,13 +49,13 @@ AMFs can also serve as effective archival elements. When paired with finished AC
 AMFs do not contain “timeline” metadata such as edit points. Timeline management files such as EditDecision Lists (EDLs) or Avid Log Exchange files (ALEs) may reference AMFs, attaching them to editingevents and thus enable standardized color management throughout all stages of production.
 
 <figure align="center" markdown>
-  ![amfDiagram](./images/amfDiagram.png){ width="350" }
+  ![amfDiagram](./images/amfDiagram.png)
 <figcaption align="center">
 	<b>Figure1 1.</b>Overall structure of an AMF in simplified form.
 </figcaption> 
 </figure>
 
-Use Case 
+Use Cases
 ----------------
 ACES Metadata Files (AMFs) are intended to contain the minimum required metadata for transferring information about ACES viewing pipelines during production, post-production, and archival.
 
@@ -124,9 +110,9 @@ Data Model
 ----------------
 This section describes the data intended for use within the ACES Metadata file.
 
-All top level structures shall be tagged as being within the \texttt{aces} namespace with urn `urn:acesMetadata:acesMetadataFile:v1.0`
+All top level structures shall be tagged as being within the `aces` namespace with urn `urn:acesMetadata:acesMetadataFile:v1.0`
 
-### UML Diagram
+`### UML Diagram
 The following UML diagrams are segments of the complete UML diagram which is not included in this document due to space constraints.  To view the entire UML diagram in SVG format visit \url{https://aces.mp/amf\_uml}.
 
 #### acesMetadataFile
@@ -140,7 +126,6 @@ The following UML diagrams are segments of the complete UML diagram which is not
   ![amfDiagram ](./uml_diagrams/uml_amfInfo.svg)
 </figure>
 
-
 #### clipId
 <figure align="center" markdown>
   ![amfDiagram ](./uml_diagrams/uml_clipId.svg)
@@ -151,7 +136,6 @@ The following UML diagrams are segments of the complete UML diagram which is not
   ![amfDiagram ](./uml_diagrams/uml_pipeline.svg)
 </figure>
 
-
 #### pipelineInfo
 <figure align="center" markdown>
   ![amfDiagram ](./uml_diagrams/uml_piplineInfo.svg)
@@ -174,17 +158,30 @@ The following UML diagrams are segments of the complete UML diagram which is not
 
 
 ### Types
-
 The following types are defined for use within the AMF XML file and are validated with the XSD schema included in Appendix A.  The types are used as the basis to form the elements listed in section X in the schema.
 
 \input{sec-types.tex}
 
 
 ### Elements (by type)
-
 The following elements are defined for use with the AMF XML file and are validated with the XSD schema included in Appendix A. 
 
 
+References
+----------
+The following standards, specifications, articles, presentations, and texts are referenced in this text:
+
+* [Academy S-2014-002, Academy Color Encoding System - Versioning System](https://www.dropbox.com/s/cnrak5pvu4agfk4/S-2014-002.pdf?dl=0)
+* [SMPTE ST 2065-1:2021, Academy Color Encoding Specification (ACES)](https://doi.org/10.5594/SMPTE.ST2065-1.2021)
+* [SMPTE ST 2065-4:2013, ACES Image Container File Layout](https://doi.org/10.5594/SMPTE.ST2065-4.2013)
+* [Academy TB-2014-010, Design, Integration and Use of ACES Look Modification Transforms (LMTs)](https://www.dropbox.com/s/grjoi885tv78e70/TB-2014-010.pdf?dl=0)
+* [ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of datesand times](https://www.iso.org/standard/40874.html)
+* [ISO/IEC 11578:1996, Information technology – Open Systems Interconnection – Remote Procedure Call(RPC)](https://www.iso.org/standard/2229.html)
+* [SMPTE ST 2067-50, Interoperable Master Format — Application #5 ACES](https://doi.org/10.5594/SMPTE.ST2067-50.2018)
+* [SMPTE RDD 47, Interoperable Master Format — Isochronous Stream of XML Documents (ISXD) Plugin](https://doi.org/10.5594/SMPTE.RDD47.2018)
+* [SMPTE ST.2067-9, Interoperable Master Format — Sidecar Composition Map](https://doi.org/10.5594/SMPTE.ST2067-9.2018)
+
+
 <!-- Include section numbering -->
 <style>
     @import "../../stylesheets/sections.css"

docs/encodings/aces2065/index.md

@@ -0,0 +1,39 @@
+ACES2065-1
+====
+
+## Summary
+ACES2065-1 is linear data that is encoded relative to the AP0 color primaries and ACES white point. 
+
+ACES2065-1 is fully documented in [ST 2065-1:2021 - SMPTE Standard - Academy Color Encoding Specification (ACES)](https://doi.org/10.5594/SMPTE.ST2065-1.2021).
+
+## Technical Specification
+### Color primaries
+The chromaticity values of the RGB primaries (known as AP0) shall be those found below:
+
+<div align="center" markdown>
+|       | **R** | **G** | **B** |   | **CIE x** | **CIE y** |
+|-------|-------|-------|-------|---|-----------|-----------|
+| Red   |  1.0  |  0.0  |  0.0  |   |   0.73470   |   0.26530   |
+| Green |  0.0  |  1.0  |  0.0  |   |   0.00000   |   1.000   |
+| Blue  |  0.0  |  0.0  |  1.0  |   |   0.00010   |   -0.077   |
+</div>
+
+<figcaption align="center">
+    AP0 RGB primaries chromaticity values
+</figcaption> 
+
+### White point
+The white point shall be:
+
+<div align="center" markdown>
+|       | **R** | **G** | **B** |   | **CIE x** | **CIE y** |
+|-------|-------|-------|-------|---|-----------|-----------|
+| White |  1.0  |  1.0  |  1.0  |   |  0.32168  |  0.33767  |
+</div>
+
+<figcaption align="center">
+    AP0 RGB white point chromaticity values
+</figcaption>
+
+
+### Transfer Function

docs/acescg/index.md → docs/encodings/acescg/index.md

@@ -3,15 +3,16 @@ title: ACEScg Specification
 ---
 
 
-ACEScg – A Working Space for CGI Render and Compositing
-========================================================================================
+ACEScg - A Working Space for CGI Render and Compositing
+=======================================================
+
 
 
 Introduction 
 ----------------
 SMPTE ST 2065-1:2012 defines a common color encoding method using half-precision floating point corresponding to linear exposure values encoded relative to a fixed set of RGB primaries. These primaries were designed to encompass the entire visual gamut. However, the algorithms commonly used to synthetically render imagery (CGI) have long used certain optimizations that are different than in typical color management scenarios and sometimes do not work well with very wide-gamut primaries. For example, in CGI rendering calculations, the RGB values of materials typically represent the percentage of light reflected. This is a different interpretation than in color science based on CIE colorimetry, where the RGBs are interpreted as tristimulus values with respect to a certain primary set. In other words, in CGI the RGB values often are used to describe a property of a material rather than the resulting color stimulus received by an observer.
 
-This document describes the AP1 color primaries and their use as the basis of a 16-bit or 32-bit floating point working space for CGI rendering and compositing. These primaries are also the basis of the ACEScc working space, which was developed to better support color grading in the ACES workflow. They do lie slightly outside of the visual gamut - in order to be able to encompass both the Rec-2020 gamut and the DCI-P3 gamut for a range of white points.
+This document describes the AP1 color primaries and their use as the basis of a 16-bit or 32-bit floating point working space for CGI rendering and compositing. These primaries are also the basis of the ACEScct working space, which was developed to better support color grading in the ACES workflow. The primaries plot slightly outside of the visual gamut - in order to be able to fully encapsulate both the Rec-2020 gamut and the DCI-P3 gamut for a range of white points.
 
 
 Scope
@@ -30,7 +31,6 @@ The following standards, specifications, articles, presentations, and texts are
 
 Specification
 -------------
-
 ### Naming convention
 The encoding of ACES specified in this document shall be known as ACEScg.
 

docs/encodings/overview.md

@@ -0,0 +1,45 @@
+ACES Encodings
+====
+
+## What encodings are available in ACES
+While the linear and wide-gamut attributes of ACES2065-1 are ideal as an encoding space for archival, in practice, many existing production tools are designed to work with data that has non-linear encoding characteristics. Therefore, depending on the present use case within a workflow, a reversible conversion from one encoding representation to another will lead to more optimal results when working within that context.
+
+There are three primary color spaces recommended for use in an ACES-based workflow:
+
+* ACES2065-1 - linear, AP0 primaries
+* ACEScg - linear, AP1 primaries
+* ACEScct - non-linear, AP1 primaries
+
+!!! note
+    There _are_ actually two other encodings previously defined - ACEScc and ACESproxy - but they are considered outdated and their use is only recommended in specific use cases or for legacy workflows.
+
+
+## Why different spaces?
+It may seem like the logical method for creating such a uniform framework would be to have one single color space that every input device transforms to and every output device transforms from. The reason why there are 5 spaces is that real-world implementations of a complete color pipeline rely on steps where there are systemic architectural differences like, for example, the capability of internally handling floating-point color code values instead of purely integer maths. These color spaces were designed to be interoperable to maintain ACES’s consistent color appearance while making it easier to perform transformations and operations on the encoded color of images.
+
+ACES colorimetry (e.g… after any mapping by Input Transforms) is always scene-referred. It only becomes output-referred after mapping by an Output Transform (actually just after the “RRT part” of it).
+For ACES color spaces, whitepoint chromaticity is (x, y) = (0.32168, 0.33767) and two different gamuts are alternatively used: determined by the primaries AP0 or AP1.
+
+Primaries are used to define the extent of colors in an x,y space utilizing metamerism. AP0 was designed to encompass the entire visible spectral locus and AP1 is much more akin to rec. 2020.
+
+This is just a review of the color spaces and common situations where they should be used in an ACES pipeline.
+
+### ACES2065-1 
+ACES2065-1 is photometrically linear and uses the ACES (or AP0) primaries. It is the primary ACES encoding colorspace, sometimes also referred to as “Linear ACES”, "ACES2065"“SMPTE2065-1” or just “ACES". ACES2065 is the desired space for any file write-outs for interchange between facilities or archival purposes. 
+
+### ACEScg
+ACEScg is photometrically linear like ACES2065-1, but is encoded relative to the AP1 primaries. This space is preferred by VFX as it works better with existing CG rendering, compositing, painting and other VFX processes. Tools used to synthetically render imagery (CGI) have long used certain optimizations that are different than in typical color management scenarios and sometimes do not work well with such wide-gamut primaries AP0.
+
+### ACEScct
+A variant of ACEScc color space, except that it adds a “toe” to make it more akin to traditional “log” curves to generate a distinct “milking” or “fogging” of shadows under lift operations, which is typical of some film looks. This comes from requests to provide colorists with a grading environment more similar to that of traditional legacy log film scan encodings when grading using a working space from the “ACES” family of color spaces.
+
+### ACEScc 
+Also known as “Log ACES”, ACEScc uses AP1 wide-gamut set of primaries and a logarithmic transfer characteristics, which means the control representation is more proportional to visual perception —a desire of traditional color-correction operators. This encoding can be internally used for color grading/correction. Many colorists have preferences to use log color spaces for how the controls of color correction boards operate. The parameters of Color Decision Lists (CDLs) implemented in ACES workflows are meaningful when generated and/or interpreted on top of ACEScc code values.
+
+
+### ACESproxy 
+ACESproxy is ACEScc encoded with integer code values in the AP1 gamut. It is another encoding related to design constraints by certain video transport systems, like the SDI infrastructure, that are used for either real-time and color-grading operations. Code values employ integer arithmetics (either 10- or 12-bits/channel), but with the same logarithmic transfer characteristics as ACEScc.
+
+ACESproxy has been designed to place scene details into the SMPTE “legal range” of video systems. Scene detail from about 7 stops under mid-gray to 10 stops over mid-gray should be visible within normal legal-range monitor setups. No rescaling of the device output signal should be needed for direct viewing, but is required before applying color grading transforms
+
+*Always remember that ACESproxy is a video-legal signal in order to be correctly displayed by compliant broadcast equipment. ACESproxy is a temporary colorspace, and is just for transports like camera feeds and LUTs on reference monitors for real-time colour evaluation. The parameters of CDLs implemented in ACES workflows may be generated on top of ACESproxy code values, to be later (re-)interpreted on top of ACEScc.