np - I think the truncation seems like a sensible option here.
Piotr
From: Ben Woodhall address@hidden
Sent: 15 May 2013 09:42
To: Piotr Stanczyk; Dalai Felinto; Thorsten Kaufmann
Cc: address@hidden
Subject: Re: [Openexr-devel] OpenEXR 2.0 backwards compatibility
Thanks Piotr, Dalai and Thorsten,
Since we're jumping straight from 1.6.1 to 2.0 then we can probably truncate channel names for single part files. I'm glad there aren't any other gotchas. Sorry about the version confusion. I failed to notice that we'd skipped 1.7.x. :-/
Cheers, Ben
On 15 May 2013, at 17:17, Piotr Stanczyk wrote:
Hi,
Yes, if you are making a single part, flat image, then you will be able to read it with 1.7.x without any issues.
If your channels names are longer than 31 characters then you will have issues reading those with code built against 1.6 and earlier. This is also true if you are using 1.7.x to write out the files.
I think that came up before around 2010 when we released 1.7.0.
If you are seeing different behaviour then please let me know.
Piotr
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
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
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
--
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
The Foundry Visionmongers Ltd.
Registered in England and Wales No: 4642027
|