[Bf-committers] Proposition: Multilayer EXR support
matt at mke3.net
Fri Jan 29 23:08:51 CET 2010
Hi Ton, I investigated this issue a little while ago.
OpenEXR has a setting - 'line order' which does let you choose the
direction, when saving non-tiled (scan-line) EXR files. This is what
we use normally, and works great.
However when saving tiled EXRs, the line order setting is reused to
mean something different (which I think is strange). For saving tiled
EXRs, it refers to the order in which the tiles are written. For
saving multilayer EXRs, we use RANDOM_Y, rather than INCREASING_Y or
DECREASING_Y, which means the tiles can be added in any order (so we
don't need to wait until we have the entire list of tiles in
sequence). You can see this here  on page 9.
The problem is that this line order setting is reused, and in the
context of tiled EXRs, it doesn't refer to the actual scan line order
any more. For tiled EXRs, it assumes top-to-bottom scan lines, which
is why Blender's multilayer EXR files come up flipped vertically when
loaded into most other applications.
Although this doesn't make a difference for Blender on its own, it is
a problem when trying to work with other applications in a pipeline,
and I think it would be nice if this could be solved. Either:
a) by complaining to the OpenEXR people for a new option in the lib,
and waiting for it to get rolled out in updated versions (could take
years before support is widespread)
b) flipping our multilayer EXR tiles as they're read/written
On Sat, Jan 30, 2010 at 2:05 AM, Ton Roosendaal <ton at blender.org> wrote:
> It's not upside down, it's an accepted & documented option in exr that
> has issues... both directions are allowed, but when i worked on it
> there were weird things in the windows version of openexr or so... too
> long ago to recall. Investige this?
> Ton Roosendaal Blender Foundation ton at blender.org www.blender.org
> Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
> On 29 Jan, 2010, at 15:34, Jeroen Bakker wrote:
>> * 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.
>> * Expectation
>> 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
>> different requirements:
>> * Proposition/alternatives
>> there are several options how we can solve this:
>> 1. leave all the same, but just before writing the multilayer exr
>> 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/
>> all images are default black in other applications like nuke or
>> What do you think what is the wise thing to do?
>> @Brecht, Campbell, is it OKE to patch pipeline as you are
>> the renderer?
>> Jeroen Bakker.
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers