Re: [Openexr-devel] OpenEXR 2.0 backwards compatibility

[Dalai Felinto]

If the new file you are making is single-parted it should be compatible with 1.6 readers, no?

I'm interested on that as well. I was under the impression/assumption that single-parts exr2.0 files are full backward compatible (assuming the name size doesn't give you array overflow).

Dalai

On May 15, 2013 8:58 AM, "Ben Woodhall" <address@hidden> wrote:

Our previous version was 1.6.1.

Thanks,  Ben

On 15 May 2013, at 16:51, Ben Woodhall wrote:

Darn.  I must be comparing with 1.6.x.  I shall check which version.

We'll probably want to maintain compatibility with the old software though, so I guess my question remains the same but for maintaining compatibility between 1.6.x and 2.0.

Sorry for the confusion.

Thanks,  Ben

On 15 May 2013, at 16:43, Piotr Stanczyk wrote:

Hi Ben,

I think that behaviour was present in the 1.7.x release. Which version were you building against previously?

Piotr

________________________________________
From: Ben Woodhall [address@hidden]
Sent: 15 May 2013 08:36
To: address@hidden
Subject: OpenEXR 2.0 backwards compatibility

Hello,

We found an issue when upgrading our EXR libraries to 2.0.  The new libraries automatically use "long names" for the channels if channels are added with names longer than 31 characters.  They set a bit of the version integer in the file header to switch to 255 character channel names.  In earlier EXR libraries these channel names were automatically truncated to 31 characters.  This is perfectly sensible but it means that saving single part images with channel names of more than 31 characters produces EXR 2.0 only images (as previous versions don't support "long names").

We can fix the compatibility by truncating channel names when writing single part files, however we're concerned that there may be other compatibility issue that we should be aware of.  Could you let me know if there are any other compatibility issues?  Is truncating names the right thing to do for backwards compatibility is there a better way to deal with this?

Any help appreciated.

Many thanks,  Ben

-- 

Ben Woodhall

Software Engineer

The Foundry, 6th Floor, The Communications Building,

48 Leicester Square, London, UK, WC2H 7LT

Tel: +44(0)20 7968 6828 - Fax: +44(0)20 7930 8906

Web: www.thefoundry.co.uk

Email: address@hidden

The Foundry Visionmongers Ltd.

Registered in England and Wales No: 4642027

-- 

Ben Woodhall

Software Engineer

The Foundry, 6th Floor, The Communications Building,

48 Leicester Square, London, UK, WC2H 7LT

Tel: +44(0)20 7968 6828 - Fax: +44(0)20 7930 8906

Web: www.thefoundry.co.uk

Email: address@hidden

The Foundry Visionmongers Ltd.

Registered in England and Wales No: 4642027

_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel