Attendance:

Guests:

• Orde Stevanoski

• Piotr Stanczyk

Discussion:

• J Schulte: 

•  

  • The Academy asked me for general recommendations about exr usage as part of an ACES-based workflow. ACES files are too bloody big. But the standard say “There should be no compression”.

  • I followed Aras’s work, Zip improvements great to see.

  • Not looking to add new compression options.

  • Are we going to start standardizing compression?

  • I want to find combinations of user experiences and stories that work better/work.

  • Timeline: I don’t have months. A thought exercise. Write something up.

• Larry: We’ve settled on piz compression. 

• Resolve shows significant improvement in performance.

• Best practice is Zip single scanline.

• Peter: zip internally, but output out of Nuke is piz.

• Our CG renders are not single-scanline. 

• Nuke still likes single scanlines.

• Kimball: I have a patch from Phil at FL that improves the performance of piz.

• Can we add new compression types to EXR?

• Make it GPU friendly, stream blocks to the GPU.

• Microsoft compression scheme, graphics cards handle them.

• Peter: Best practice for benchmarking the system.

• “Here’s how we did the test.”

• Finishing space  is UHD 24fps playback.

• Peter: is there a way of saying to the DCC’s here’s a load of uncompressed EXRs, make it go fast.

• It’s up to the tool that ingests it to make sense of it.

• We shouldn’t have to deliver things in 5 different formats

• Joseph: One question is, “Do you know what apps are doing upstream conversions for you?” Most have no idea. That’s why metadata gets lost. I’d encourage you to bring those people into the conversation.

• If a renderer is generating data, is there recommendation for what settings to use.

• Larry: Multiple axes to evaluate these:

•  

  • Speed of playback. 

  • Storage. Layers of AOVs. 

• Orde: 

•  

  • exploration of using lossy compression out of Katana. 

  • Never done before. Last 10 years, turn it to zip, let it go.

  • Data footprint is troubling. Reduce IO footprint 

  • Pxr24 handles float exr really well.

  • DWA seems to excel.

  • Most exploration has been done in terms of data footprint. Not on speed of reading and decompressing. Next step is to see how things trickle down.

• J: We had done the same thing.

• Larry: there are things that are visually indistinguishable but numerically different, and the denoiser treats them very differently.

• We treat all AOVs as separate.

• Piotr: ability to leverage structure? Images coming out of the camera at Apple, there's a lot of relationship between layers that compress really well. At a cost.  Can you compress a multi-part that way?

• Zip already recognizes correlation between layers. But not so much that you’re willing to take the performance hit.

• But that’s why you say the layout of channels and parts. 

• Piotr: The 99% use case at Apple is read and playback.

• We want to get into the world where the file can get schlepped onto the GPU and expanded there.  Not a place we’ve explored. Steve Parker has done some experiments, but don't know where he’s at.

• Piotr: With the current crop of displays it’s invigorating to look at exr’s. It’s really exciting what you can see. 

• J: FPGA compression is an option? 

• You could specify one of the block systems. 

• Piotr: Multicore reading?

• Kimball: that’s the biggest change in 3.1: remove interlocking. At Weta we often read 10Tb of texture per frame. 64 cores reading from the same texture file. Spending 70% of time waiting for file lock. Allows us to read from multiple tiles at once.

• Orde: everything is a separate file, but can you do different compression for different parts. You can choose by part.

• Larry: In OIIO, you can do it from c++ and python, but not from the command line in oiiotool. But we don’t have extensive use of multipart.

• Larry: another use case, what’s the right thing to do for texture if you’re storing in exrs? How much dwaa and lossy could we tolerate in texture? But the performance of using exrs at all was prohibitive, but with Kimball’s changes, I’m re-investigating. 

• Peter: Would it make sense to have tiled formats for playback? 

• Kimball: Wave said you had some patches. Piotr has been looking at performance modifications. 

• Piotr: have you pitched projects to GSoC?

• Larry: Nobody’s heard anything. I’m begging to fear we could miss

• Kimball: I’m going to submit pr’s to expose some attributes hooks. The C implementation of the attribute storage and the registration of attribute types. Separate branch? Yes, for now. I haven’t done anything about the standard attributes.

• Joseph: I’ll send the 80-question questionnaire. Things like “Where do you measure focal distance from?”

• The 3.1.5 release is staged, ready for release on Monday.