[Bf-committers] Blender and Scanline OpenEXR files

[Xavier Thomas]

Hi Ton,

Matt and I fixed the upside down issue. It was only in multilayer EXR
(both tiled or not).
The problem is that it introduce a random crash due to multi-threading.

I spend a great deal of time trying to figure it out and seems to
comes from the render code. Basically the render results gets freed
before it is totally written to the file and induce a segfault.

I assigned the bug to Brecht a few weeks ago when he corrected a fews
bugs that seemed similar.


Xavier



2010/11/27 Ton Roosendaal <ton at blender.org>:
> 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>