Example test for preview tier

[doug_walker]

Following up on the discussion at today’s CLF VWG meeting, I’ve created an example test for the Preview Tier.

These may be found on the CLF Implementation DropBox Paper home page:

CLF Implementation Virtual Working Group

In summary, there is a source image, a CLF, and a result image as follows:

• source image: CLF_testImagePrototype_v005_acescct.dpx
• aim result image: CLF_testImagePrototype_v005_rec709.dpx
• test CLF file: acescct_to_rec709.clf

The proposed tolerance for this simple test is +/- two 10-bit code values.

Here is some more detail regarding how I created these:

I created the CLF by using OCIO to bake a transform from ACEScct to the Rec.709 ACES Output Transform into a simple 33x33x33 LUT3D. The steps I used are as follows:

1. Download and build the OCIO master branch from source on GitHub.
   https://github.com/AcademySoftwareFoundation/OpenColorIO

2. Download an ACES OCIO config and set your OCIO environment variable to point to the config file.
   https://github.com/imageworks/OpenColorIO-Configs

3. Use the OCIO command-line tool ociobakelut to bake the CLF using the following command:
   ociobakelut --inputspace acescct --outputspace out_rec709 --cubesize 33 --format "Academy/ASC Common LUT Format" --v acescct_to_rec709.clf

(Note that I used the ACES OCIO 1.0.3 config for this test, because it was easier, although the 1.1 config would be slightly better. In any case, this is just a test and for the real test suite we will use a config that is based on OCIO v2 which will be more accurate.)

4. I edited the CLF in a text editor to add some metadata to the header and add the tetrahedral attribute to the LUT3D.

5. I’m uploading a version of Alex Fry’s CLF test target that I processed from ACES2065-1 to ACEScct and saved as an 10-bit DPX file. This would be the source image for the test. (I was going to use ocioconvert for this, but for reasons that are probably not worth elaborating on, I used another approach.)

6. Use the OCIO command-line tool ocioconvert to apply the baked CLF to the source image using the following command:
   ocioconvert --lut acescct_to_rec709.clf CLF_testImagePrototype_v005_acescct.dpx CLF_testImagePrototype_v005_rec709.dpx

[sdyer (Scott Dyer)]

Following up on Tuesday’s CLF VWG meeting, I’ve created an example test for both the Finishing Tier and the Preview Tier. The files can be found on the CLF Implementation Dropbox Paper home page (linked directly below).

For both tiers, there is a source image, an output image that results from applying the CLF, and the CLF itself.

The Finishing Tier files are as follows:

• Source Image: CLF_testImagePrototype_v006.exr
• Output Image: CLF_testImagePrototype_v006_thruCLF_to_rec709.exr
• CLF file: aces_to_rec709.clf, which includes the following Process Nodes:
  • Matrix: Transforms AP0 to AP1
  • Log: Transforms linear AP1 to ACEScct
  • ASC_CDL: Adds some creative adjustment
  • LUT3D: 33x33x33 spaced 0-1 for ACEScct input. Transforms back to ACES2065-1, then applies the RRT and Rec. 709 ODT.

The Preview Tier files were updated as follows (to be similar to the Finishing Tier):

• Source Image: CLF_testImagePrototype_v006_acescct.dpx
• Output Image: CLF_testImagePrototype_v006_thruCLF_to_rec709.dpx
• CLF file: acescct_to_rec709.clf, which includes the following Process Nodes:
  • ASC_CDL: Adds some creative adjustment (same ASC CDL as in Finishing Tier CLF)
  • LUT3D: 33x33x33 spaced 0-1 for ACEScct input. Transforms back to ACES2065-1, then applies the RRT and Rec. 709 ODT. (same LUT as in Finishing Tier CLF)

[doug_walker]

Thank you Scott! As discussed in the VWG meeting today, the group agrees that this is a great “sample test” that implementers could start with.

We will delete my earlier draft of these test files from the Dropbox Paper site, so there is no confusion.

Doug Walker
CLF Implementation VWG chairperson

[Alexander_Forsythe (Alex Forsythe)]

Attached are AMF files for the Finishing Tier and Preview Tier Pipelines using the CLF files @sdyer posted.

These AMFs conform to the proposed revisions by the AMF Implementation working group and should validate against the schema noted in the AMF files.

Alex

acesTestPreviewTier.amf (1.9 KB)
acesTestFinishingTier.amf (1.9 KB)

[nick (Nick Shaw)]

If it is of interest, I have tested the preview tier files against the experimental CLF 2.0 implementation in Colour Science for Python (CLF 3.0 is not yet fully implemented) and the results match Scott’s reference DPX to within one code value. If I use trilinear interpolation on the LUT3D, the results are considerably different. So it should be very easy to verify if a hardware LUT device is using tetrahedral or trilinear interpolation.

You can see a version my test code in this Google Colab.

[nick (Nick Shaw)]

I have updated the Colab to include baking the CLF into a simple 33^3 cube. The max difference is then far more significant.

It also now displays the mean error as well as max in each case.

[nick (Nick Shaw)]

Updated again to add some investigation into the edge case errors when the CLF is baked into a single 3D LUT (as will often be the case for hardware implementations).

But in fact I think it is simply the result of a negative offset followed by a 0-1 clamp, applied by the ASC CDL node.

A simple 1D illustration:

Negative offset, followed by clamping 0-1 will produce a hard corner in the true output (the green line). Sampling either side of that corner, and then interpolating (the red line) will give an inaccurate result, particularly near the cusp.

(This is obviously an exaggerated example, with a large offset and small number of samples to make the point)

And here is a plot of the actual output of the CLF applied to a green ramp from 0-1 (with red and blue held at zero).

Looking at that it is obvious why there will be interpolation errors in the red channel with a 33^3 LUT3D in the interval above g = 0.75 (the small ticks on the axis represent the intervals of a 33^3 cube).

Here is a plot of the same ramp processed through the baked single 3D LUT:

These errors occur at the boundaries of the cube, so are unlikely to produce visible artefacts in photographic images. The preview tier is intended for situations such as on-set, and the output of a camera is unlikely to produce ACEScct values of either 0 or 1.

UPDATE 2020-10-13
I have added more to the Colab following the last meeting to investigate if clamping the image values to those which could occur in a real image (ACEScct equivalent of 0-100 linear was suggested) improved the situation.

Unfortunately while doing this reduces the magnitude of the max code value error (99 instead of 116) it is still significant. I believe that it is because the CDL is still pushing values negative (and then clamping them to zero) due to the combined effect of the negative offsets and the saturation of 1.2. So you still end up with kinks in the curve either side of a colour which could possibly occur (although the colours which cause the largest errors are still unlikely from a real camera, because they have two channels at zero in linear AP1).

But even for the ColorChecker in the test image, the purplish blue patch has an error of 22 10-bit code values in the red channel with the baked LUT, and the blue patch an error of 12 code values. The difference in the purplish blue patch is clearly visible to the eye when toggling between the full CLF and the baked LUT.