Skip to content

Commit

Permalink
merge branch 'v2-dev-release-3' into dev
Browse files Browse the repository at this point in the history
  • Loading branch information
scottdyer committed Sep 4, 2024
2 parents fc18980 + 8d571b6 commit 5a788b7
Show file tree
Hide file tree
Showing 1,028 changed files with 2,689 additions and 60,657 deletions.
66 changes: 66 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,69 @@
**Version 2.0 Developer Release 3 (Sept 2, 2024):**
* Bugs
* Change lower hull gamma approximation from a constant value to a value determined using the log of the peak luminance. For SDR outputs, the value reduces to the former value but this change minimimizes some clipping artifacts that could occur at edge values at higher luminance outputs.s
* Enhancements / simplifications
* Replace calculation method for Mnorm used in the chroma compress function and remove REACH_GAMUT_TABLE
* Make clamp to peak luminance active on forward and inverse direction (previously only active in forward direction) - helps avoid errors on inverse when users send in values outside the invertible range
* Add extra clamp to PQ and HLG (derived from PQ 1000) EOTF options to protect against rare reintroduction of negative values. Though data is clamped from [0-peakLuminance] in a prior step, occasionally very small negative components can be reintroduced from precision errors during the XYZ to display primary matrix. Therefore, negative values are clamped as an extra protective step to avoid NaN errors from negative values which are undefined in the base PQ encoding.

**Version 2.0 Developer Release 2 (August 19, 2024):**
* Bugs
* Correct a mistyped value used in pre-calculation of r_hit in the tone scale function init
* Add a clamp to range [0 - peakLuminance] and remove explicit clamp in inverse EOTF function
* Enhancements / simplifications
* Set upper limit clamp value in AP1 clamping step to a value equal to 3 stops (8x) the minimum value required to reach maximum output from the tone scale function
* Update table generation and lookup code to assure that hue values falling in the "wrap-around" hue region are handled correctly
* Add two extra table entries in gamut cusp and upper gamma hull approximation tables that are duplicates of the first and last entries
* Update indexing and lookup functions to expect a baseIndex offset to maintain proper indexing where 360 entries are assumed
* Add a bool to determine whether white scaling should be applied - This allows the user to control when the white is or isn't applied, and is clearer and more robust than relying on a mismatch in the white point chromaticities. For example, a DCDM P3D65 ODT already has white point fitting handled by a 48/52.37 scale factor, so wouldn't need that additional white scaling that would otherwise be applied because the encoding white and limiting white would differ.
* Remove unused smoothJ value
* Simply compressFuncParams and compressPowerP function
* Unused values in the 4-element compressionFuncParams were removed, retaining the one value that is used and renaming it to compressionThreshold to better describe what it controls
* The compressionFuncParams related to power equaled 1, so the compressPowerP function was simplified where many of the pow() functions could be solved out when power=1
* Rename REACH_CUSP_TABLE as REACHM_TABLE, because it represents the M value for the reach gamut at limitJmax. Also reduce REACHM_TABLE to only 1 column (M) since M is the only value that needs pre-computation (i.e. J is constant and always equal to limitJmax and hue is uniformly spaced and corresponds to row index)
* Refactor the white scaling step as a discrete operator before display encoding on forward (plus a clamp) and immediately after display decoding on inverse
* Reorder the enum values for EOTF encoding/decoding to be less haphazard
* Remove unused parameters from display encoding/decoding function
* Remove unused functions for applying surround parameter - The implementation was unvalidated and would need to be changed anyway if implemented in a future release, so the inactive code and supporting functions were removed to avoid any confusion for implementers.
* Other minor refactorings of code for improved readability
* Other ACES repos
* Output Transforms
* Update all TransformIDs to be more verbosely defined from transform parameter settings
* Change default list of transforms
* Add:
* HLG 1000 nit
* DCDM 48 nit and 300 nit
* Rec2020 500 nit
* D60 limited / sim versions of all provided transforms, organized in a separate d60 directory
* Remove:
* Rec2020 100 nit
* P3-DCI
* Input and Color Space Conversion Transforms
* Set name space in Panasonic IDT to Panasonic
* Update Sony Venice TransformIDs to be more consistent
* Add a few missing transforms to provide to/from conversion to provided inputs
* Add "Unity" transform



**Version 2.0 Developer Release 1 (April 19, 2024):**
* Reorganization of code:
* This repository (`aces-dev`) will be renamed (`aces-core`) and houses the main rendering algorithms for ACES.
* Output Transforms moved to [aces-output](https://github.com/ampas/aces-output)
* Input Transforms moved to [aces-input-and-colorspaces](https://github.com/ampas/aces-input-and-colorspaces)
* Look Transforms moved to [aces-look](https://github.com/ampas/aces-look)
* AMF schema and example files moved to [aces-amf](https://github.com/ampas/aces-amf)
* Documentation tracked at [aces-docs](https://github.com/ampas/aces-docs) and published using mkdocs to [ACEScentral](docs.acescentral.com)
* All TransformIDs have been conformed to the v2 TransformID specification
* New core rendering algorithm:
* New tonescale function with a lower default contrast and adaptability to produce output for any peak luminance between 100-10000 nits.
* A hue-preserving rendering transform, applying luminance mapping mostly independent of color adjustments.
* Gamut mapping to mostly avoid undesirable clipping but still allow for reaching the edges of the display gamut volume.
* Invertibility up to at least P3 gamut
* Reference images have been moved to be tied to their respective transform repositories



**Version 1.3 (April 30, 2021):**

* New Features:
Expand Down
45 changes: 45 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
# Contributing to ACES

We're thrilled that you're interested in contributing to ACES. To maintain the legal integrity of the project's codebase, we require all contributors to sign a Contributor License Agreement (CLA).

## Signing the CLA

- Before we can merge any of your contributions, you must sign our CLA.
- The process is simple. When you submit a pull request for the first time, you will be prompted to sign the CLA online.
- If you are contributing on behalf of your employer or if your contributions are owned by someone other than yourself (e.g., your employer), please make sure you have the right to submit the contributions under our project's CLA.

By signing the CLA, you assure the project and its users that your contributions do not infringe upon the rights of any third parties and that the project can use your contributions without legal repercussions.

If you have any questions about the CLA process, please feel free to contact a member of the ACES Team via ACESCentral.com.

## Requirement for Signed Commits

As part of our commitment to security and the integrity of our codebase, we require all commits to be signed. This helps us ensure that contributions are actually made by the account they come from and not altered by a third party.

### Why Signed Commits?

Signed commits provide an additional layer of security by guaranteeing that the commits are from a verified source. This is crucial for maintaining the trustworthiness of our codebase.

### How to Sign Commits

To sign commits, you'll need to use a GPG (GNU Privacy Guard) or S/MIME (Secure/Multipurpose Internet Mail Extensions) key. If you haven't already set up a GPG key, you can follow [GitHub's guide on generating a new GPG key](https://docs.github.com/en/github/authenticating-to-github/generating-a-new-gpg-key).

Once you have a GPG key, you can add it to your GitHub account. For instructions on how to do this, see [GitHub's documentation on adding a new GPG key to your account](https://docs.github.com/en/github/authenticating-to-github/adding-a-new-gpg-key-to-your-github-account).

When you have your GPG key added to your GitHub account, you can start signing your commits. If you're using the command line, you can sign commits with `git commit -S -m "Your commit message"`.

### Verifying a Signed Commit

You can verify that your commits are signed by looking for the "Verified" label on GitHub's commit interface.

### What if You Cannot Sign Your Commits?

We understand that in some scenarios, you might not be able to sign commits. If you find yourself in this situation, please reach out to the project maintainers for assistance.

For more detailed instructions on signing commits, you can refer to [GitHub's documentation on signing commits](https://docs.github.com/en/github/authenticating-to-github/signing-commits).

---

We appreciate your contributions to ACES, and we thank you for adhering to our signed commits policy. This policy helps us maintain the security and integrity of our codebase.

If you have any questions about this process, please feel free to contact the project maintainers.
Loading

0 comments on commit 5a788b7

Please sign in to comment.