[Bf-committers] Blender and Scanline OpenEXR files
Ton Roosendaal
ton at blender.org
Sat Nov 27 14:54:54 CET 2010
Hi,
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-
------------------------------------------------------------------------
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:
> 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
>>
> _______________________________________________
> 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