Attendance:

Community:

Discussion:

• Mathieu M - working on new product, trying to bring VFX artist pipeline tools into virtual production

  • Using USD and EXR, can override USD materials with EXR materials for example, play sequence back and overrides are done through a nodegraph system, mimic one-for-one those in Nuke, read node that reads EXR sequence and then output to point at for example Hydra renderer, challenge is that USD animated textures don't worked easily. Best we could do with EXR to push it, accelerate tiled v44, decode performance good, size is problematic.

  • Read bandwidth is tricky. SSD RAID array needed. File sizes really large. Moving things around is problematic.

  • Looked at DWA as alternative but not really GPU friendly. Difficult to accelerate.

  • Starting clean slate, possibly proposing new compression format. May build and just support in Nuke shot term but goal is to work with this group as early as possible so makes sense when take steps to move it into the library.

  • Want to understand long term what it 

  • Nick: more than just faster compression format, correct?

  • Kimball: maybe change sort order of attributes in header such that if a bit set you know the metadata you are going to need to read, something is there you can read in header. Have discussed previously.

  • Nick: don't have anything for multi-frame. More facilities bumping in Linux file handle limit. So much software opens file handle for every frame.

  • Kimball: we had USD scene with 77K mmapped files recently

  • Nick: option to open just one file and hold one handle.

  • MM: current strategy is to read ahead.

  • Peter: we made one for streaming (missed something here) ... go back and fill it in at the end. Wrote it to be eventually open-sourced. Didn't get as far as having fast lookup tables but did think about how to do that. Simplest way ... all files have to have the same channel layout. End up reading the file using the custom stream API for EXR, use that to get to the data. Open container file, then say "want to open frame 7". Kept file handle internally. Could change core library to allow this.

  • Peter: index table that says where scan lines are is relative to the entire stream, not just local.

  • Nick: MXF doesn't solve problem in general, not an accessible or easy-to-use.

  • Peter: another thing needed, container doesn't carry any metadata so kind of opposite approach to MXF

  • Cary: other obstacles?

  • MM: none currently aware of.

  • MM: 2 developers able to look at it, 1 will work on it later this year. Also reached out to folks at Epic since they did work in this area. A few things weren't clear - why their work had not made it into the library.

  • Nick: it needed direct-write, only MS compatible. Also coupled to MDME extensions so only ran on microsoft so wasn't a general solution.

  • Cary: should check back with Rod Bogart . it was presented as experiments they were doing. Haven't heard more about it since they presented to us over a year ago.

  • Kimball: they continued to work on the direct storage part, he is aware.

  • MM: haven't gone down the path of direct storage yet, do have hopes of being multi-platform. Currently it's on Linux. Can bring this back to team.

  • Cary: release deadline is at end of the month. Will have limited bandwidth to do much more. Happy to embrace this but do take a conservative approach to any format changes. No proprietary dependencies. On cusp of adding a new compression type ETA by end of year. Want to be careful with backwards compatibility.

• OpenImageIO issues

  • Kimball: able to repro one issue, working on fixing it

  • Larry: can rerun all the CI tests against any fixes.

  • Kimball: I can run all the CI tests locally.

  • Kimball: will move C core changes into main as soon as OpenImageIO is working.

  • Cary: more experience building against changes, the better.

• Dev Days

  • Cary: suggestions for one day projects? Was thinking of benchmarking new Zstd compression.

  • Peter: not sure if format is stable enough. 

  • Li: shared slides comparing compression using various types of EXR layouts, has students running some tests. Has a way to do benchmark data and to investigate various experiments.

  • Peter: need to look at single vs multiple scanlines as well.

  • Li: collected test data set 30 images. Not using deep images yet.

  • Kimball: where Philippe started with this was intended for having tests for deep.

• Peter: colleague having a Mac installation issue OpenEXR and OpenImageIO together

  • May need to test this on Mac and Windows prior to Dev Days.

  • Cary: no longer trying to auto-generate the image gallery (was one of worst issues) last year

  • Larry: some discussion on OpenColorIO slack, some github feature lets you have a VM based workspace

  • Li: gives you a kubernetes container to run python on it. You can edit directly on codespace, don't need to download your fork. Have a lot of Windows experience, can help with that.

  • Peter: might be good for across all platforms, on any platform instructions for how do you get to the point where you can compile code

  • Cary: cmake setup boost and pybind11 are woven together, would like to separate them out. So can work on pybind11 without installing boost. Objective is get to point to compile pybind11 bindings without boost on your system.

  • Kimball: have Mac work laptop with dev environment, can help with testing that.