[Bf-committers] Blender and Scanline OpenEXR files
ton at blender.org
Sat Nov 27 14:54:54 CET 2010
I've assigned the bug report to myself, but I repeat my request to
update information here too.
We have two types of OpenEXR files for load/save:
1) RGBA with optional Z
2) Blender MultiLayer
Both are saved scanline.
Is the upside down error only in saving multilayer?
The tile-based temp files we can leave outside this discussion, these
are for internal usage only.
Ton Roosendaal Blender Foundation ton at blender.org www.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 5 Jul, 2010, at 18:09, Brecht Van Lommel wrote:
> See this bug report for progress on a fix:
> On Mon, Jul 5, 2010 at 6:02 PM, 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
>> to discuss this.
>> There are two types of openexr files (scanline and tile). The Tile
>> fileformat is outputted by Blender when selecting OpenEXR as
>> This file contains color, transparency and optional depth
>> 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
>> 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
>> memory optimization between rendering and composing steps. During
>> step the image is saved in the orientation of the blender buffer. The
>> blender buffer is bottom scanline first. So the scanline what is
>> in the bottom of the screen is stored in the file first.
>> During my research I found out that the scanline OpenEXR fileformat
>> 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
>> 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
>> 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
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers