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 [email protected] 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 <[email protected]> > 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
