Skip to content

Conversation

@scottdyer
Copy link
Contributor

This branch begins to address Issue #18.

There are a few points that need discussion, highlighted below:

  1. These transforms copy the parameterized base transform and set a Transform ID and User Name for each EI value, rather than using the v3_IDT_maker.py.
    • This duplicates a lot of code, but lets the transforms run independently without adding another import to utilize the parameterized transform. However, there are imports of Utilities and Colorspaces, so maybe another import isn't so bad?
    • Any preferences one way or the other on how to construct these - copy/paste explicit code or import to keep more compact?
  2. I opted to use a hyphen (LogCv3-EI###) vs an underscore (`LogCv3_EI###) in the filename
    • Any preference here?
  3. I kept the filename as LogCv3 to match the other files in the directory, but inside the functions we call it LogC3 (no 'v').
    • Is there a preferred syntax?
      • (need to consider compatibility implications of changing filenames - maybe plan for a future release?)
  4. I left the parameterized form alongside the specific EI transforms. This is because some implementations of ACES v2 have already built off the generalized transform.
    • Anybody see any harm in leaving both?
  5. Transforms for the ACES to LogC direction for EIs 1600, 2000, 2560, 3200 are not provided because they're not defined with the formulaic implementation.
    • Ok to omit? Or do we alter the structure for these and try to provide LUT based inverses?

@scottdyer scottdyer force-pushed the feature/add-LogC3-EI-presets branch from 2697c8a to 8c1f434 Compare October 7, 2025 20:00
@KevinJW
Copy link

KevinJW commented Oct 14, 2025

I would avoid the copy paste and add the import to call the function to minimise duplication. Imagine what the change looks like if an inverse solution was proposed for the higher EI values, on the whole you only want one file to be changed.

File name wise the hyphen is fine,

I think it is OK to only provide a partial solution for the inverse unless people have some overriding case.

@scottdyer
Copy link
Contributor Author

scottdyer commented Oct 15, 2025

3363cd9 extracts most of the copy/paste code into an import function

This presented me with some additional decisions about which I ask for opinions:

  1. File placement: This change requires the location of Lib.Arri.LogC be on the user's CTL_MODULE_PATH. Should the transform be put in the ARRI directory alongside the transforms that call it? It seems a bit strange to add it in with the other Lib files in the aces-core/lib directory, although I suppose that we have already done that with the Lib files used by the Output Transforms being tracked in a separate repo. Maybe putting this also in the lib directory makes sense since it is presumably already on the user's CTL_MODULE_PATH? Any thoughts one way or the other?
  2. Parameterized version: Do we want to update the already-published parameterized version to use the import? The output of the transform would be identical, I just wonder if an additional dependency would break anything for OCIO or other implementations that may rely on the CTL?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants