begiin reorganization and start adding content

docs/amf/specification/index.md

@@ -8,7 +8,7 @@ ACES Metadata File (AMF) Specification
 
 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.
+This document specifies the ACES Metadata File (“AMF”), a ‘sidecar’ XML file intended to exchange the metadata 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.
 
 
 Introduction 
@@ -113,7 +113,7 @@ This section describes the data intended for use within the ACES Metadata file.
 All top level structures shall be tagged as being within the `aces` namespace with urn `urn:acesMetadata:acesMetadataFile:v1.0`
 
 `### 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}.
+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 [https://aces.mp/amf\_uml](https://aces.mp/amf\_uml).
 
 #### acesMetadataFile
 <figure align="center" markdown>

docs/output-transforms/technical-details/chroma-compression/index.md

@@ -17,8 +17,10 @@ flowchart LR
   E["Gamut 
   Compression 
   (J & M)"] --> 
-  F[Display 
-  Encoding] --> 
+  H["White
+  Limiting"] --> 
+  F["Display 
+  Encoding"] --> 
   G(Display 
   RGB 
   Output);

docs/output-transforms/technical-details/display-encoding/index.md

@@ -0,0 +1,37 @@
+Display Encoding
+========
+
+``` mermaid
+flowchart LR
+  A("ACES 
+  RGB 
+  Input") --> 
+  B[ACES 
+  to 
+  JMh] --> 
+  C["Tonescale 
+  (J Only)"] --> 
+  D["Chroma 
+  Compression 
+  (M Only)"] --> 
+  E["Gamut 
+  Compression 
+  (J & M)"] --> 
+  H["White
+  Limiting"] --> 
+  F["Display 
+  Encoding"] --> 
+  G(Display 
+  RGB 
+  Output);
+  style F stroke-width:4px
+```
+
+## Overview
+
+The display encoding step prepare the colorimetry from the rendering portion of the Output Transform for the expected decoding operators of a given display. Colorimetry is encoded relative to the selected color gamut (i.e. color primaries and white chromaticity) of the display and using the inverse EOTF.
+
+## Primaries and White Chromaticities
+[Graphics of primaries]
+
+## Inverse EOTF

docs/output-transforms/technical-details/gamut-compression/index.md

@@ -21,8 +21,10 @@ flowchart LR
   E["Gamut 
   Compression 
   (J & M)"] --> 
-  F[Display 
-  Encoding] --> 
+  H["White
+  Limiting"] --> 
+  F["Display 
+  Encoding"] --> 
   G(Display 
   RGB 
   Output);

docs/output-transforms/technical-details/index.md

@@ -4,12 +4,113 @@ Overview
 
 Introduction
 ------------
-The Output Transform is a display rendering transform essential to consistently and predictably rendering scene-referred ACES2065 image data to a rendered state suitable for display on a particular output device. The Output Transform is applied using a simplified version of the [Hellwig 2022](https://doi.org/10.1002/col.22792) Color Appearance Model (CAM). Like most CAMs, the model helps produce a number of different color correlates. Three specific correlates are used for the purposes of applying the display rendering of the ACES 2.0 Output Transform, specifically:
+The Output Transform is a rendering transform essential to consistently and predictably transforming scene-referred ACES2065 image data into a rendered state suitable for display on a specific output device.
+
+Transforms in `aces-output` are provided from ACES2065-1 to a state ready for display on devices calibrated to common display standards. The provided presets do not attempt to support all possible combinations of parameters because, A) this would make the list of transforms inordinately long, and B) all combinations don't make sense as user options. The options provided are expected to provide fairly comprehensive coverage for all common present-day deliverable needs.
+
+Inside the Output Transform, is two separate operators, the rendering and display encoding. The rendering is dictated by the limiting primaries and white chromaticities as well as the luminance of peak white. The display encoding is determined by the encoding primaries and white point chromaticity of the display and the EOTF of the display.
+
+``` mermaid
+flowchart LR
+  id1((("ACES
+  2065-1")))-->id2{{"Rendering
+  Transform"}}
+  subgraph box1 ["Output Transform"]
+    id2 -->|"CIE
+    XYZ"|id3["Display
+    Encoding"]
+    end
+  id3 -->|"Code
+    values"|id4(Display)
+```
+
+For a few of these output transforms, the rendering targets are identical and the only difference is in how the intended colormetry is encoded for display. 
+
+The limiting gamuts and peak luminances provided are as follows:
+
+  * Rec.709 48/100 nit
+  * P3 48/100 nit
+  * P3 108 nit
+  * P3 300 nit
+  * P3 500 nit
+  * P3 1000 nit
+  * P3 2000 nit
+  * P3 4000 nit
+  * Rec.2100 500 nit
+  * Rec.2100 1000 nit
+  * Rec.2100 2000 nit
+  * Rec.2100 4000 nit
+
+(Each are provided for D60 and D65)
+
+The encoding gamuts included as presets are as follows:
+
+  * Rec.709 / sRGB
+  * P3
+  * Rec.2100
+  * XYZ
+
+The inverse EOTF options included as presets are as follows:
+
+  * Linear
+  * ST. 2084 (PQ)
+  * HLG
+  * Gamma 2.6
+  * BT.1886 (Gamma 2.4)
+  * Gamma 2.2
+  * sRGB IEC 61966-2-1:1999 (sRGB Piecewise)
+
+Other outputs and presets can be added if and when the need arises.
+
+Fundamentally, there are two main decisions to be made by the user: first, what device is being used to display the images; and second, how are the images to be viewed. As is the goal in UX design, the first decision, the display, is something that is intuitively obvious and expected.
+
+By splitting the decision-making process into two steps, rather than requiring the user to select from a long list with M x N choices, they are able to make two separate choices, each from a much shorter set of options (of length M and N). (This is an over-simplification of the system, but hopefully the concept is clear.)
+
+This particular decomposition into Viewing and Display Transforms allows ACES to fit into some color management UX models that are already in common use. For example, OpenColorIO already structures its viewing pipeline into View and Display choices.
+
+
+``` mermaid
+flowchart LR
+  id1[/Camera 1/] --> id4["Input 
+  Transform"] --> id7(((ACES)))
+  id2[/Camera 2/] --> id5["Input 
+  Transform"] --> id7
+  id3[/CGI/] --> id6["ACEScg
+  to
+  ACES"] --> id7
+  id7 --> id8{{"Output
+  Transform"}} 
+  id8 --> id9["Display 
+  Encoding"] --> id12[/"HDR 
+  Video"/]
+  id8 --> id10["Display 
+  Encoding"] --> id13[/"Cinema 
+  Projector"/]
+  id8 --> id11["Display 
+  Encoding"] --> id14[/"SDR 
+  Video"/]
+  ;
+```
+
+
+
+ ## ACES 2
+
+ The ACES 2 Output Transform is applied using a simplified version of the [Hellwig 2022](https://doi.org/10.1002/col.22792) Color Appearance Model (CAM). Like most CAMs, the model helps produce a number of different color correlates. Three specific correlates are used for the purposes of applying the display rendering of the ACES 2.0 Output Transform, specifically:
 
 - **J** : perceived lightness
 - **M** : perceived colorfulness
 - **h** : perceived hue
 
+
+ACES 1 defined a Reference Rendering Transform and an Output Device Transform. In ACES 1.1 and beyond, the concatenation of the RRT and ODT were designated an Output Transform. The conceptual split between the two modules still existed but in practice, the combination of the two simplified some steps such as tone scale mapping.
+
+ACES 2 maintains the Output Transform as a the name of the overall transformation from ACES2065-1 to a particular output. Looking inside the Output Transform one can see a conceptual split between the target rendering or limiting gamut and the display encoding to prepare the intended colorimetry for a particular display. This is intentional and there are distinct benefits to maintaining this segmentation when porting the CTL to native implmentations. Let's explore.
+
+ACES 2 also includes the choice of the adapted white point (creative white) as part of the target rendering. This defines what chromaticity is assumed as the "neutral" white point for an observer. 
+
+
+
 ### Overview of the rendering steps
 ``` mermaid
 flowchart LR
@@ -37,3 +138,19 @@ flowchart LR
 
 Design Goals
 ------------
+
+
+
+
+Implementers
+
+Which Transforms Do We Need to Support?
+
+That's up to you
+
+
+
+Minimal set of rendering transforms to implement
+These are the same rendering transform but only the display encoding is different
+
+If you enumerate pre-computed LUTs at varous peak luminances, then you should provide a provisiion for a user to add a custom LUT generated externally.

docs/output-transforms/technical-details/tone-mapping/index.md

@@ -17,8 +17,10 @@ flowchart LR
   E["Gamut 
   Compression 
   (J & M)"] --> 
-  F[Display 
-  Encoding] --> 
+  H["White
+  Limiting"] --> 
+  F["Display 
+  Encoding"] --> 
   G(Display 
   RGB 
   Output);
@@ -27,9 +29,62 @@ flowchart LR
 
 ### Tone-mapping
 
-After the data is in JMh space, the J channel is sent through the tone scale function.
+After the data is in a JMh representation, the J channel is sent through the tone scale function. 
 
 ### Tone-mapping Function
-The tone mapping function is based off a Michaelis-Mentin curve, with a flare and parameterized so that certain values can be determined. 
+The tone mapping function is based off a Michaelis-Mentin curve, and parameterized so that certain values can be calculated automatically based on the peak luminance value. 
 
-### Values
+
+
+
+
+### Values
+
+<table>
+    <tr>
+        <th></th>
+        <th colspan="4" style="text-align:center">ACES value</th>
+    </tr>
+    <tr>
+        <th style="text-align:center">Peak Luminance<br>(nits)</th>
+        <th style="text-align:center">0</th>
+        <th style="text-align:center">0.18</th>
+        <th style="text-align:center">1.0</th>
+        <th style="text-align:center">2.0</th>
+    </tr>
+    <tr>
+      <td>100</td>
+      <td>0.000</td>
+      <td>10.000</td>
+      <td>45.757</td>
+      <td>63.988</td>
+    </tr>
+    <tr>
+      <td>500</td>
+      <td>0.000</td>
+      <td>13.193</td>
+      <td>89.098</td>
+      <td>158.949</td>
+    </tr>
+    <tr>
+      <td>1000</td>
+      <td>0.000</td>
+      <td>14.512</td>
+      <td>106.564</td>
+      <td>205.783</td>
+    </tr>
+    <tr>
+      <td>2000</td>
+      <td>0.000</td>
+      <td>15.747</td>
+      <td>121.664</td>
+      <td>248.779</td>
+    </tr>
+    <tr>
+      <td>4000</td>
+      <td>0.000</td>
+      <td>16.824</td>
+      <td>133.883</td>
+      <td>284.433</td>
+    </tr>
+</table>

docs/output-transforms/technical-details/white-limiting/index.md

@@ -0,0 +1,28 @@
+White Limiting
+==================
+
+``` mermaid
+flowchart LR
+  A("ACES 
+  RGB 
+  Input") --> 
+  B[ACES 
+  to 
+  JMh] --> 
+  C["Tonescale 
+  (J Only)"] --> 
+  D["Chroma 
+  Compression 
+  (M Only)"] --> 
+  E["Gamut 
+  Compression 
+  (J & M)"] --> 
+  H["White
+  Limiting"] --> 
+  F["Display 
+  Encoding"] --> 
+  G(Display 
+  RGB 
+  Output);
+  style H stroke-width:4px
+```

docs/specifications/index.md

@@ -0,0 +1,3 @@
+Specifications
+====
+

docs/system-components/whats-new/index.md

@@ -0,0 +1,46 @@
+What's New In ACES 2.0?
+===
+
+ACES 2.0 was designed based on collected feedback and requests from ussers of ACES 1.x.  The changes are designed to improve on many known issues or to complete previously unfinished pieces of the system that help make ACES 2.0 a more complete, robust, and consistent product.
+
+Highlights of the changes in ACES 2.0 are as follows:
+
+* New output transforms, including:
+    * A less aggressive tone scale
+    * More intuitive controls to create custom outputs to non-standard displays
+    * Robust gamut mapping to improve perceptual uniformity
+    * Improved performance of the inverse transforms
+* Enhanced AMF specification
+* OpenEXR compression recommendations
+* Updated tools for generating Input Transforms and recommendations for characterizing prosumer cameras
+* Look Transform Library
+* Expanded documentation
+
+## Rendering Transform
+The most substantial change in ACES 2.0 is a complete redesign of the rendering transform. 
+
+ACES 2.0 was built as a unified system, rather than through piecemeal additions. Different deliverable outputs "match" better and making outputs to display setups other than the provided presets is intended to be user-driven. The rendering transforms are less likely to produce undesirable artifacts "out of the box", which means less time can be spent fixing problematic images and more time making pictures look the way you want.
+
+## Key design goals
+* Improve consistency of tone scale and provide an easy to use parameter to allow for outputs between preset dynamic ranges
+* Minimize hue skews across exposure range in a region of same hue
+* Unify for structural consistency across transform type
+* Easy to use parameters to create outputs other than the presets 
+* Robust gamut mapping to improve harsh clipping artifacts
+* Fill extents of output code value cube (where appropriate and expected)
+* Invertible - not necessarily reversible, but Output > ACES > Output round-trip should be possible
+* Accomplish all of the above while maintaining an acceptable “out-of-the box” rendering
+
+##  
+Once the $M x N$ factorial combinations are a number of preset combinations.
+
+Providing all of the same outputs with a D60 creative white automatically doubles the number of presets. The common workflow would seem to be that a user would decide their creative white point at the start of their show and use transforms with that white point throughout their project's lifetime. Therfore, the D60 and D65 transforms are divided at the top level into their own directories, with the same list of targeted displays for each.
+
+### Notes to implementers on UI Presentation
+If implemented blindly, users would be required to select "the right transform" from a long list of very similar looking but very subtly different names. In many instances the differences between two different outputs are solely in the signal encoding step while the intended rendering appearance is identical. The presets listed in the "aces-output" directory 
+
+A list of outputs that we believe should be minimally supported are identified on the list, with all parameters that when combined and put into the Output Transform and Display Encoding functions would produce an output as intended for that rendering/device combination.
+
+How you implement the selection of these is up to your team to determine the best was to fit it into your software's color management menus or otherwise.
+
+For example, a trasnform labeled `Rec709-D65_100nit_as_Rec709-D65_BT1886` would be a typical 100-nit SDR video rendering inteneded for display on a device configured to Rec.709 primaries with the BT.1886 transfer function. Another transform such as `Rec709-D65_100nit_as_Rec2100-D65_ST2084` targets the same rendering characteristics and so would produce a matching rendering. The only difference here is that the intended Rec.709 colorimetry is the display encoding, i.e. the RGB is encoded relative to the Rec.2100 primaries and using the PQ encoding function.