Example CLF files

Discussions - ACESNext VWG – Common LUT Format (CLF)
1

I’m starting a thread for us to share example CLF files. I’ll start it off with three:
– ACES2065-1 to ACEScg
– ACES2065-1 to ACEScct
– CIE XYZ to CIELAB

<?xml version="1.0" encoding="UTF-8"?>
<ProcessList id="ACEScsc.ACES_to_ACEScg.a1.0.3" name="ACES2065-1 to ACEScg" compCLFversion="3.0">
    <Info>
        <ACEStransformID>ACEScsc.ACES_to_ACEScg.a1.0.3</ACEStransformID>
        <ACESuserName>ACES2065-1 to ACEScg</ACESuserName>
    </Info>
    <Description>ACES2065-1 to ACEScg</Description>
    <InputDescriptor>ACES2065-1</InputDescriptor>
    <OutputDescriptor>ACEScg</OutputDescriptor>
    <Matrix inBitDepth="16f" outBitDepth="16f">
        <Array dim="3 3">
 1.451439316146 -0.236510746894 -0.214928569252
-0.076553773396  1.176229699834 -0.099675926438
 0.008316148426 -0.006032449791  0.997716301365
        </Array>
    </Matrix>
</ProcessList>


<?xml version="1.0" encoding="UTF-8"?>
<ProcessList id="ACEScsc.ACES_to_ACEScct.a1.0.3" name="ACES2065-1 to ACEScct" compCLFversion="3.0">
    <Description>ACES2065-1 to ACEScct Log working space</Description>
    <InputDescriptor>Academy Color Encoding Specification (ACES2065-1)</InputDescriptor>
    <OutputDescriptor>ACEScct Log working space</OutputDescriptor>
    <Info>
        <ACEStransformID>ACEScsc.ACES_to_ACEScct.a1.0.3</ACEStransformID>
        <ACESuserName>ACES2065-1 to ACEScct</ACESuserName>
    </Info>
    <Matrix inBitDepth="16f" outBitDepth="16f">
        <Array dim="3 3 3">
 1.451439316146 -0.236510746894 -0.214928569252
-0.076553773396  1.176229699834 -0.099675926438
 0.008316148426 -0.006032449791  0.997716301365
        </Array>
    </Matrix>
    <Log inBitDepth="16f" outBitDepth="16f" style="cameraLinToLog">
        <LogParams base="2" logSideSlope="0.05707762557" logSideOffset="0.5547945205" linSideBreak="0.0078125" />
    </Log>
</ProcessList>


<?xml version="1.0" encoding="UTF-8"?>
<ProcessList id="5ac02dc7-1e02-4f87-af46-fa5a83d5232d" compCLFversion="3.0">
    <Description>CIE-XYZ D65 to CIELAB L*, a*, b* (scaled by 1/100, neutrals at 0.0 chroma)</Description>
    <InputDescriptor>CIE-XYZ, D65 white (scaled [0,1])</InputDescriptor>
    <OutputDescriptor>CIELAB L*, a*, b* (scaled by 1/100, neutrals at 0.0 chroma)</OutputDescriptor>
    <Matrix inBitDepth="16f" outBitDepth="16f">
        <Array dim="3 3">
1.052126639 0.000000000 0.000000000
0.000000000 1.000000000 0.000000000
0.000000000 0.000000000 0.918224951
        </Array>
    </Matrix>
    <Exponent inBitDepth="16f" outBitDepth="16f" style="monCurveRev">
        <ExponentParams exponent="3.0" offset="0.16" />
    </Exponent>
    <Matrix inBitDepth="16f" outBitDepth="16f">
        <Array dim="3 3">
 0.00000000  1.00000000  0.00000000
 4.31034483 -4.31034483  0.00000000
 0.00000000  1.72413793 -1.72413793
        </Array>
    </Matrix>
</ProcessList>
4 Likes
2

These are great but I notice you have put the Autodesk-style Array dim="3 3 3" declaration into one of them. Is this a slip-up or did you do this to indicate that this shouldn’t matter? Also, given that the BitDepth declarations are only used for scaling, isn’t it true to say that there is no functional difference between “16f” and “32f”? And in this case, why do we have these two floating point options?

3

Hi John, thanks for your comments.

You are correct, there is no functional difference between “16f” and “32f”. Those were both allowed in the v1 specification and there was no strong argument to remove them in v2 or v3 since it’s pretty trivial for a parser to support both.

Regarding the matrix array dimensions, indeed I have been occasionally adding the third number (both above and in the test suite). The v3 specification states that parsers should allow (though ignore) a third value. This was done since the v1 and v2 spec used three values and the group felt it would be more user-friendly to allow that as a deprecated variant. Again, it is quite trivial for parsers to do that.

But in cases where we are showing reference examples, you are quite right that the preferred two-value syntax should be used. And in fact, when we included the example from the top of this thread in the actual spec (pg 30), we cleaned it up to use the preferred two-value syntax.

Doug

1 Like