Agreed on need for speed. But this seems to be an implementation issue, and not inherent in EXR.
When we spec'ed the ACES headers at the Academy, we looked at the header read time in consideration of EndOfHeaderOffset. We didn't use the std sdk for this testing. A lightly optimized image reader can spend very little time parsing/skipping over attributes. In our test, the header was read in far less time than the image data (excluding time for decompression). Our conclusion was that even with 50 attributes, the EndOfHeaderOffset was not meaningful. 50 attributes were read in a total of ~90 microseconds. (2700 header bytes & 12461691 file bytes on a MacPro) Big headers (1MB) with 50 attributes were read 3x faster than small headers (4KB) with 150 attributes. Recall that you have to read every byte of name and type, but only size of value, to skip an attribute. At 1000 attributes, the header read time would become significant (10%), regardless of header size. This of course assumes you don't need to analyze every attribute value during playback.
The single XMP attribute is very fast to skip over, as name and type are short. The length of the XMP block matters little as you skip it.
Lars
The zipped attributes aren't so much about total filesize, more about trying to get Imf::InputFile etc run as fast as possible.
The library needs to extract all the attributes from the header(s) before it gets to the image data, so the smaller the header, the less work there is to do.
Those looking for realtime EXR playback are usually unhappy to see large amounts of data getting dumped into headers!
Also, using zipped attributes to store chunks of XML does make the header objects much lighter in memory, and is certainly far better than a whole heap of separate attributes.
Peter On 18/07/13 15:24, Lars Borg wrote:
XMP packets are much smaller than the image data. I've never seen a real case where that's not the case. Wait with compression until it solves a real problem.
Lars
There's support for zipped string attributes in a feature branch at github, and should make it into an upcoming official release.
If the data gets quite big, maybe the XMP attribute could be a zipped string. This keeps down file size, but also helps read speed and memory usage, since the zipped strings are not uncompressed until the contents of the string are queried. On 18/07/13 11:12, Larry Gritz wrote:
+1
As XMP, it's just an ordinary string (though potentially a big one) and the naming conventions are already decided by others. Though it does beg the question of a portable, compact, nicely licensed parser for XMP. (I rolled my own but am not especially
happy about it. Does anybody have a good recommendation?)
As an alternative, what I do in OIIO when saving EXIF data into OpenEXR files is simply to name it all "Exif:Foo" or "IPTC:Foo", with Foo being the official Exif or IPTC names, and the prefix making it pretty easy to distinguish from ordinary exr user
metadata.
On Jul 17, 2013, at 10:09 AM, Lars Borg wrote: Thomas,
Why not use XMP instead? XMP includes all of EXIF + Dublin Core ++
Lars
Hi,
I'm resurrecting that thread after 7 years, I basically wanted to know if there has been more discussions about that matter in the recent years.
The fact there is no standard attributes for common camera data prevents a bit the format to be used as a solid input container for photo processing applications or anything relying on EXIF data. For instance if you want to stitch EXR files with PTGui
you will have to enter your data manually.
I think it would be really important trying to establishing a standard list of attributes as suggested by Thomas Lock, the exrstdattr already provides a list of them, maybe completing / updating this one?
Cheers,
Thomas
_______________________________________________
Openexr-devel mailing list
address@hiddenhttps://lists.nongnu.org/mailman/listinfo/openexr-devel
|