Persistent "error loading file" with any CTL script using LUTs (@ART-lut or embedded)

Hello ART community,

I’m hoping to get some help with a very stubborn issue. I can successfully load a basic “passthrough” CTL script, but the moment I try to load any kind of LUT, either via an external CLF file or by embedding the data in the script, I get the generic “error loading file” message.

I’m currently running ART version 1.25.5 on Windows 11 24H2.

Here’s a summary of my testing, which has been a long process:

What Works: A minimal, “passthrough” CTL script with no includes or LUTs loads and works perfectly. This confirms my basic environment (script path, permissions, file encoding) is correct.

`// This script loads successfully
// @ART-label: “1 - Passthrough Test”
// @ART-colorspace: “rec2020”

void ART_main(
varying float r, varying float g, varying float b,
output varying float rout, output varying float gout, output varying float bout
)
{
rout = r;
gout = g;
bout = b;
}`

What Fails: The error appears as soon as I introduce any form of LUT. I have tried:

  1. Loading an external CLF file with @ART-lut: This fails even when using a known-good, professionally made ACES CLF file (Example CLF files - VWG – Common LUT Format (CLF) - Community - ACESCentral). The script below fails with “error loading file”.

`// This script fails
// @ART-label: “3 - Test ACES CLF”
// @ART-colorspace: “aces2065-1”

// @ART-lut: “ACESConvert.clf” // This is a standard ACES 1.3 CLF file

void ART_main(
varying float r, varying float g, varying float b,
output varying float rout, output varying float gout, output varying float bout
)
{
float out_rgb[3];
out_rgb[0] = r; out_rgb[1] = g; out_rgb[2] = b;
lut(0, out_rgb);
rout = out_rgb[0]; gout = out_rgb[1]; bout = out_rgb[2];
}
3. **Using an embedded const float` array**: I also tried embedding the LUT data directly into the CTL file to avoid external files. This also fails, even when following the advice in the “ART CTL Development Guide” to access the array as a global from the helper function.

Environmental Checks Performed:

  • CTL Scripts Path: Confirmed I am using the correct user ctlscripts folder.
  • File Permissions: Confirmed read/write permissions are correct.
  • Simple Path: Tried moving the scripts to a simple path (e.g., C:\art_test) and pointing ART’s preferences there; the issue persisted.
  • ART Version: I have updated to the latest stable version of ART.
  • File Format: Using Notepad++ to save files as .ctl with UTF-8 encoding, and have confirmed there is no hidden .txt extension.

Since the most basic script works, but any attempt to introduce a LUT fails (even with a known-good ACES file), it seems the issue is not with the script content, but with the LUT-loading mechanism itself in my ART installation.

Has anyone encountered this specific behavior before? I am out of ideas for what to try next.

Thank you for any help you can offer!
Best Regards,
John

Hi,
You don’t need to go through ctl scripts to load a clf lut, they are supported directly by art. You just need to make sure they take linear aces ap0 in and produce linear aces ap0 out, like explained here. Did you try that?

Best

2 Likes

Hi Alberto,

Wow, you were fast to respond, thank you for that.

Mea culpa, my squirrel brain went down the CTL loading of CLF files rabbit hole. Tested a sample CLF file and it worked like a charm.

Have a great weekend,
John