[Bf-committers] Blender and Scanline OpenEXR files
xavier.thomas.1980 at gmail.com
Mon Jul 5 18:09:15 CEST 2010
This is a known bug. A patch is availabale here:
Unfortunately it as some multi threading issues, still unresolved. Lot of
time have already been spend trying to isolate the bug but unsuccessful yet.
Any help is welcome.
2010/7/5 Jeroen Bakker <j.bakker at atmind.nl>
> 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.
> 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?
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers