TSC Meeting Notes 2025-02-06
Attendance:
Guests:
Pierre-Anthony Lemieux, Sandflow Consulting
Carol Payne, OCIO
Doug Walker, OCIO
Alyssa Alexis
Discussion:
HTJ2K:
OpenEXRCore should be a C-only implementation
Can replace OpenJPH with any JPEG2000: Kakadu, OpenJPG
Might produce different files, but will read.
Mapping between channel order between OpenEXR and encoder stream. Channel order is now written at each chunk.
Kimball:
Goal: get to OSs don’t have to recompile w/OpenEXR Security patch
Goal: ability to run in an environment where you want to control the allocators.
Goal: can run on embedded devices
Issue with PR: it’s not using the OpenEXRCore allocator, it’s allocating via std lib.
Disappointing OpenJPH is not C, since it’s mostly C code
OpenJPH: it’s the highest performance and most actively maintained.
It does only Part 15.
Carol/Doug - Color Interop Forum
Color metadata management
Would like metadata to be the next topic in the interop meeting, Feb 24, noon Pacific.
Larry: We’re the ones to bless the names. Where can people count on the meaning? Correct the decades old confusion about chromaticities.
Larry: we don’t have a dog in the fight.
Foundry involved? Yes, Mark Titchner
Custom metadata? You’d need support before you could rely on it. The advantage is that you have a better chance of getting it right.
It would be good to have some guidance about what channels should be color managed and which should not.
Peter: It was Piotr’s idea to lock down the chromaticities.
Peter: There are carefully written rules that are completely ignored.
Idea is to have a standard set of names, independent of OCIO.
Color Interop Forum published a list of names last year.
Texture Asset Color Spaces: https://docs.google.com/document/d/1IV3e_9gpTOS_EFYRv2YGDuhExa4wTaPYHW1HyV36qUU/edit?usp=sharing
Don’t like the ability to lie. Can we definite a dozen things that cannot be overridden.
Biggest issue is the Chromaticities