[Bf-committers] Proposition: Multilayer EXR support

[Fabian Fricke]

I'm just thinking out loud here but it's vaguely the same topic:
I always wondered why the temp FSA samples are only being stored temporally
and not in coherence with the rendered frames, thus allowing compositing
after all frames were already renderd. Maybe as additional layers in the
same file, or in a folder alongside the frames.

I don't know if there has been any discussion about this when the feature
was first introduced but I would think it's a desirable option.

2010/1/29 Ton Roosendaal <ton at blender.org>

> Hi,
>
> 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-
>
> ------------------------------------------------------------------------
> 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
> > 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
> > formats
> > 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
> > the renderer?
> >
> > Greetings,
> > Jeroen Bakker.
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>