AcademySoftwareFoundation / AcademySoftwareFoundation/openexr
[Usage recommendation request] Decompressing large EXRs in real-time.
- Dominant language
- C
- Stars
- 1.8k
- Forks
- 700
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 29
Description
Hi,
We're doing a virtual production based research project at Foundry. As part of that, we're investigating OpenEXR based solutions that meet the following criteria:
1. High resolution (8k, 16k, and beyond), HDR, RGBA image sequences (deep data and other channels not necassary).
2. File sizes as small as possible.
3. Real-time (24Hz+) playback.
It's fine to presume we have the PCIe bandwidth to perform transfers at rate, as well as good processing power on both the CPU and GPU front.
We're aware that this is very much "having one's cake, and eating it", however lots of OpenEXR-based options seem close, and we're wondering if the EXR experts can see a trick we've missed.
We're fine with lossy compression, which opens the doors to B44[A] and DWA[A/B]. B44 satisfies `1.` & `3.`, but produces relatively large files when compared to DWA. DWA satisfies `1.` & `2.`, but we would need better performance on the decompression.
With 16 threads, for 8k (8192x4096) scanline DWA I'm seeing around 60ms to read a frame, and for 16k I'm seeing around 230ms. Are there any missed tricks on either the encoding or decoding side which could be used to speed up this process? We've thought about a GPU implementation of DWA decoding, but from what we can tell, a combination of Huffman, RLE, deflate and zip are used for DWA's entropy encoding, none of which are particularly GPU friendly, and all together they sound very GPU unfriendly.
Alternatively, are we missing a trick with regards to any of the other compression methods which could help us meet our criteria?
Many thanks,
George
Contributor guide
Research direction
The issue names DWA scanline decoding and the B44[A] and DWA[A/B] compression methods, but no repository file, test, or entry point. Begin by locating the relevant compression and decompression paths and reproducing the stated 8k and 16k timings; done would require a validated optimization or compression choice that reaches 24Hz+ playback.
Written by the indexing model from the issue text.
Assessment
- Domain
- computer-graphics, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100