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
|