[Bf-committers] Blender and Scanline OpenEXR files

[Ton Roosendaal]

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