[Bf-committers] Blender and Scanline OpenEXR files

[Xavier Thomas]

This was clarified in IRC, but for the record:
The patch was correcting both tile based and non tile multilayer
images. This was not 2 separated patch and when commit was reverted
both type of images whent back to up side down.

We should work this as 2 separated fixes.


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