[Bf-committers] Proposition: Multilayer EXR support
j.bakker at atmind.nl
Fri Jan 29 15:34:59 CET 2010
* Problem statement
Multilayer EXR files are used in 2 places.
1. to temporarily store the render buffers to reduce the memory
footprint between the render pass and the composition pass.
2. to store the final output image as a multilayer exr.
the problem is that multilayer exr's are stored upside down. For 1 it is
not a problem as the file is temporarily and used by blender renderer.
for 2: the output image makes the file's not easilly usable. You first
have to flip the image, before you can use it.
the temporarily file must still be stored in the current form (upside
down) for performance reasons.
the output file must not be stored upside down, but still have all
render layers available. (open file with exrdisplay -C
RenderLayer.Combined.R filename.exr to see problem)
Identifying the problem.
both accesses the same function in openexr_api.cpp and both are
triggered from the pipeline.c (blender renderer), but both have
there are several options how we can solve this:
1. leave all the same, but just before writing the multilayer exr output
image, flip all render buffers. The implementation of the multilayer
does not use the imbuf API, so will not effects other file formats and
is easilly doable
2. update the imbuf api, to support multilayer images. more work, but
more futureproof to possible other (professional, non existing) output
3. use the exr tiles to save the image upside down (is something in
between solution 1 and 2)
I would have chosen for option 1 as it is not that much work, and I
don't know what the requirements are for other professional output
formats. Solution 3
Other issues in this area: the multilayer has is no default image/layer;
all images are default black in other applications like nuke or exrdisplay.
What do you think what is the wise thing to do?
@Brecht, Campbell, is it OKE to patch pipeline as you are restructuring
More information about the Bf-committers