[Bf-committers] Blender and Scanline OpenEXR files

[Xavier Thomas]

I forgot to say that the crash only occurs with tile-based files that
are mainly used internally as temporary files. So yes they is surely a
way to get only the non tiled files corrected and keep the tile-based
upside down. This would satisfy most users I guess.

But if I am true about the source of the crash, I think it can occur
with the actual code also, it is just much more difficult to
reproduce.



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
>