|
| From: | Benoit Leveau |
| Subject: | Re: [Openexr-devel] OpenEXR 1.7 not backward compatible? |
| Date: | Mon, 23 Aug 2010 19:31:33 +0100 |
| User-agent: | Thunderbird 2.0.0.12 (X11/20080213) |
Any (approximate) idea when the 1.7.1 is planned to be released? Thanks! Benoit Piotr Stanczyk wrote:
Sounds like something we might get into 1.7.1 ... I'll add it to the list. Thanks for highlighting this one. Piotr On 08/23/2010 10:23 AM, Benoit Leveau wrote:I was thinking the same, as right now the safest way for us to use the new version is to do that change in the library. Basically my patch is: - in ImfName.h, reverting the SIZE to 32 (instead of 256) - making sure the usesLongName() function in ImfHeader.cpp returns false so the flag is never set If a similar patch makes it to the official library, it will of course be different as it needs to support both modes. Nick Porcino wrote:I wonder if it would make sense for the distro'd library itself to have a 1.6 compatibility mode to aid with the version transition? -----Original Message----- From: address@hidden [mailto:address@hidden On Behalf Of Benoit Leveau Sent: Monday, August 23, 2010 8:11 AM To: address@hidden Cc: address@hidden Subject: Re: [Openexr-devel] OpenEXR 1.7 not backward compatible? I saw that in ImfHeader.cpp, line 117 (version 1.7.0): // If an OpenEXR file contains any attribute names, attribute type names // or channel names longer than 31 characters, then the file cannot be // read by older versions of the IlmImf library (up to OpenEXR 1.6.1). // Before writing the file header, we check if the header contains // any names longer than 31 characters; if it does, then we set the // LONG_NAMES_FLAG in the file version number. Older versions of the// IlmImf library will refuse to read files that have the LONG_NAMES_FLAG// set. Without the flag, older versions of the library would mis- // interpret the file as broken. This means that if you're writing an image with a channel name longer than 31 characters, - the previous behavior was to truncate the name (readable in all versions), - the new behavior is to set the flag and write the long names (readable in 1.7+ only). This will require us to either truncate the channel names manually everywhere we use OpenEXr, or edit the OpenEXR library so it never sets the flag and truncates the names manually. Benoit Jeff Clifford wrote:Ah that would explain it. Glad you found the difference. Cheers, Jeff. Benoit Leveau wrote:Hi, That 0x400 value comes from the following in ImfVersion.h: const int LONG_NAMES_FLAG = 0x00000400; // File contains long // attribute or channel // names which also explains the rest of the diff (i.e., long names). I guess images written with that flag are not supported by old versions of the library. I'll try to see which option controls that flag when writing images, should be easy now. Cheers, Benoit Benoit Leveau wrote:Hi Jeff, Thanks for the feedback! It's good to know it works on your side. We used the configure script that comes with the library, and didn't use any specific option. I just tried to use exrheader to compare files generated with 1.6 and 1.7. A diff of the output gives that interesting result: 4c4 < file format version: 2, flags 0x0 ---file format version: 2, flags 0x40020c20 < prmanExrDriverAddDisplayWindowO (type int): 0 ---prmanExrDriverAddDisplayWindowOffset (type int): 022,23c22,23 < prmanExrDriverDisplayWindowOffs (type box2i): (0 0) - (0 0) < rmanXMLStatisticsFileName (type string): "x+g" ---prmanExrDriverDisplayWindowOffsetValues (type box2i): (0 0) - (0 0) rmanXMLStatisticsFileName (type string): "(XXX" <= 'X' for some non-printable charactersThere's probably something in our code that doesn't initialize that version/flag. Benoit Jeff Clifford wrote:Hi Benoit, It may be worth stating what your configure options are? The reason I say that is that we too rebuilt our internal apps and PRMan driver against 1.7.0 under Linux64. However we've not hit upon that message. We're able to use older OpenEXR lib apps (like Nuke) to read our 1.7.0 images fine. Jeff. Benoit Leveau wrote:Hi, After re-compiling our renderman display driver with OpenEXR 1.7 libraries on linux 64bit, none of the images we generate can be loaded into applications that link with older versions of OpenEXR (e.g. Nuke, in-house tools). The error I get with our in-house player is: OpenEXR input exception:: >> Cannot read image file "xxxxx.exr". The file format version number's flag field contains unrecognized flags. << I get the same exact error message in Nuke 6.0. If I compare a file generated by 1.7 and 1.6.1 (or 1.4.0), the two files indeed differ, even in the first few bytes. It seems that the 1.7 libraries add new header flags, and this is not safely ignored by old versions. IMHO, if files generated by 1.7 can't be loaded by current versions of Nuke, that may greatly affect its widespread usage. Thanks for your help, Benoit _______________________________________________ Openexr-devel mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/openexr-devel_______________________________________________ Openexr-devel mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/openexr-devel_______________________________________________ Openexr-devel mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/openexr-devel_______________________________________________ Openexr-devel mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/openexr-devel_______________________________________________ Openexr-devel mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/openexr-devel
| [Prev in Thread] | Current Thread | [Next in Thread] |