[Bf-committers] Blender and Scanline OpenEXR files

Brecht Van Lommel brecht at blender.org
Mon Jul 5 18:09:55 CEST 2010


Hi,

See this bug report for progress on a fix:
http://projects.blender.org/tracker/index.php?func=detail&aid=21385&group_id=9&atid=498

Brecht.

On Mon, Jul 5, 2010 at 6:02 PM, Jeroen Bakker <j.bakker at atmind.nl> wrote:
> Hi all,
>
> I have been working on a project concerning Blender and OpenEXR for
> interchangeability with other software products. To my opinion I have
> detected a flaw to the support of the OpenEXR file format. I would like
> to discuss this.
>
> There are two types of openexr files (scanline and tile). The Tile based
> fileformat is outputted by Blender when selecting OpenEXR as imagetype.
> This file contains color, transparency and optional depth information.
> Also the compression method can be selected. The Scanline based
> fileformat is outputted by blender when selecting MultiLayer as
> imagetype. This file contains all Renderlayer information and is always
> compressed as OPENEXR_ZIP.
>
> The implementation of the Scanline based file is done in the
> render/pipeline.c. The reason for this is that it is used as as optional
> memory optimization between rendering and composing steps. During this
> step the image is saved in the orientation of the blender buffer. The
> blender buffer is bottom scanline first. So the scanline what is shown
> in the bottom of the screen is stored in the file first.
>
> During my research I found out that the scanline OpenEXR fileformat must
> contain a lineOrder attribute (this is stored in the file) but the
> specification of the file format states that the scanline are always
> stored top scanline first.
>
> http://www.openexr.com/openexrfilelayout.pdf
> on page five it states: "The block's y coordinate is equal to the pixel
> space y
> coordinate of the top scan line in the block. The top scan line block in
> the image is aligned with the top
> edge of the data window, that is, the y coordinate of the top scan line
> block is equal to the data window's
> minimum y." My intepretation of this is that scanline based OpenEXR
> files are only stored from top to bottom and does not check the value of
> the lineOrder attribute.
>
> All files stored when selecting the MultiLayer option is Blender is
> quite useless when using in other tools than Blender as the file will be
> read upside-down.
>
> Can someone please react to this?
>
> Greetings,
> Jeroen
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list