[Bf-committers] Blender and Scanline OpenEXR files

[Xavier Thomas]

This is a known bug. A patch is availabale here:
https://projects.blender.org/tracker/?func=detail&aid=21385&group_id=9&atid=498

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.

Xavier.

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.
>
> 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
>