[Bf-committers] Blender and Scanline OpenEXR files

[Ton Roosendaal]

Hi,

Please try to be 100% exact in this, to my information the multilayer  
files are still upside down.

I don't know why attempts were made to fix tiled exr saving as well,  
that's far more complicated. Fixing regular multilayer is easy, and  
hasn't been done yet.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 27 Nov, 2010, at 15:37, Xavier Thomas wrote:

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