Add GroupTransform::ParseFromBuffer to parse a LUT from memory

[hmms]

Summary

Adds GroupTransform::ParseFromBuffer(const char * buffer, size_t bufferSize), a static factory that parses a LUT directly from an in-memory buffer rather than requiring a file on disk.

Closes #2076

Implementation

Reuses the existing LUT-reading pipeline rather than duplicating parser code. A small internal BufferConfigIOProxy (anonymous namespace in src/OpenColorIO/transforms/GroupTransform.cpp) serves the buffer as LUT data through Config::CreateRaw()->createEditableCopy()->setConfigIOProxy(...), then a FileTransform is resolved through Config::getProcessor(), and processor->createGroupTransform() returns the result.

Because OCIO's internal file caches are keyed by filename/hash strings and a buffer has no filename, the buffer's own content is hashed (CacheIDHash, XXH3-128) and used to form a synthetic filename ("ParseFromBuffer:" + hash, namespaced so it can never collide with a real file's resolved path) and the ConfigIOProxy::getFastLutFileHash value, so two different buffers can never collide in the cache, and re-parsing identical content is a cache hit. Null/empty buffers and unparseable content both throw a clear Exception.

Caching behavior worth flagging explicitly: like OCIO's existing file cache, entries created via ParseFromBuffer are never evicted, only released via ClearAllCaches(). This is fine for the typical case (a bounded set of files/buffers), but an application feeding many distinct, dynamically-generated buffers through this API (e.g. procedural LUTs per-frame) will grow the cache unboundedly unless it calls ClearAllCaches() itself. Happy to discuss whether this API should default to not caching, or take an opt-in/opt-out flag, if that's a concern, didn't want to guess at the right policy and expand scope without your input.

Python bindings

Added GroupTransform.ParseFromBuffer to the Python bindings (src/bindings/python/transforms/PyGroupTransform.cpp), with a corresponding test (tests/python/GroupTransformTest.py::test_parse_from_buffer). Verified with a real OCIO_BUILD_PYTHON=ON build (Python 3.14, pybind11 3.0.4): module imports, ParseFromBuffer is callable and correctly round-trips both text LUT content and produces the expected Lut1DTransform, raises on empty/malformed input, full tests/python suite (400 tests) passes with zero regressions.

Test plan

• OCIO_ADD_TEST(GroupTransform, parse_from_buffer) in tests/cpu/transforms/GroupTransform_tests.cpp covering:
  • a SPI1D fixture parsed from memory (length/value assertions)
  • a CLF fixture parsed as a second distinct buffer in the same process (guards against cache collisions between buffers, verified this test actually catches a collision by temporarily breaking the cache-key logic and confirming it fails)
  • re-parsing the same buffer twice (cache hit path)
  • null/zero-size buffer throwing
  • malformed buffer content throwing rather than crashing
• Full CPU test suite: 1161/1161 passed, 0 failed, 0 skipped, rebuilt clean with zero warnings in the changed files.
• GroupTransformTest.py::test_parse_from_buffer and the full tests/python suite (400 tests): all passing against a real Python build, not just compile-checked.

Notes for maintainers

• Only SPI1D and CLF formats were exercised in tests; other LUT formats should follow the same code path but are untested per-format.
• The method naming/signature (ParseFromBuffer(const char*, size_t) as a static factory on GroupTransform) is a reasonable judgment call but not the literal signature sketched in the issue, happy to adjust if you'd prefer something else.
• See the cache-growth note above, open to feedback on whether that needs an API-level answer in this PR or can stay as documented behavior.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: hmms / name: Muralidhar M Shenoy (da59b5c, e0599b5)