Adobe are looking into it, but I think the actual bug is at the Adobe end. Basically, if you have a sequence (as opposed to a single frame) then After Effects reads the header information in the EXR more frequently than it needs to. EXRs can have large headers depending on the number of channels and so this can add up to lengthy delays - even worse over a network.
Brendan’s clever workaround is to cache the header of the EXR in memory, so this behaviour becomes much faster. In one case I had an EXR sequence that was originally rendering at 2 1/2 mins per frame (150 seconds per frame) and with Brendan’s latest patch this came down to a about 3 - 5 seconds per frame. Obviously that is a MASSIVE improvement, and this is before the actual bug itself has been fully investigated and fixed.
EXRs under a certain size don’t seem to show the problem, which is why it may not have been identified before. The EXRs I am using have Cryptomattes, which bump up the header size significantly.
Unfortunately I am on a strict NDA for this project but if I can find a suitable unrestricted demo sequence I’ll post an article / tutorial on it.
-Chris
Just for my own future ref, were there any other details about the disfunctional exr sequences to share? They were multichannel - any certain flavor (piz, etc) or anything else to be aware of?
Hopefully whatever it was is fixed in short order.
|