Re: [Openexr-devel] EXIF meta data attributes in headers

[Piotr Stanczyk]

Hi Thomas

Yes, there has. Most of it in the legal capacity.  There are still a few technical angles that need to be explored also.

I'll post out more once we have more clarity on this.

Thanks for following up.

- Piotr

---

From: Thomas Mansencal address@hidden
Sent: 06 September 2013 06:21
To: Piotr Stanczyk
Cc: Lars Borg; address@hidden
Subject: Re: [Openexr-devel] EXIF meta data attributes in headers

Piotr: Not wanting to sound like the annoying guy or anything like that but I was talking with one of my coworker ( Michael Pa... that you may know actually ) and he asked me if there has been any progress regarding those conversations.

Cheers,

Thomas

Thomas Mansencal | thomasmansencal.com
[  thomasmansencal.blogspot.com  |  github.com/KelSolaar  ]

2013/8/1 Thomas Mansencal <address@hidden>

Lars: Excellent stuff! Very insightful again. I see what you mean, the second approach just really push the problem further down, doesn't really solve it.

Piotr: Thanks a lot looking into that!

Thomas

Thomas Mansencal | thomasmansencal.com
[  thomasmansencal.blogspot.com  |  github.com/KelSolaar  ]

2013/7/30 Piotr Stanczyk <address@hidden>

Very useful, thanks Lars.

I'll be checking in with our legal team to see what the implications might be .. stay tuned.

- Piotr

---

From: openexr-devel-bounces+pstanczyk=address@hidden [openexr-devel-bounces+pstanczyk=address@hidden] on behalf of Lars Borg [address@hidden]

Sent: 30 July 2013 01:17
To: Thomas Mansencal
Cc: address@hidden

Subject: Re: [Openexr-devel] EXIF meta data attributes in headers

Thomas, 

My colleagues on the XMP team gave the following feedback. Hopefully you find this helpful:

If they take the first approach they will run into the known problem of ambiguity known from not using namespace associations. The second approach is a bit better as it allows that association. We currently use the same approach when storing metadata in the Cloud because the underlying DB does not support namespaces. But then you have to make sure to use standard prefixes and that is in theory also dangerous because prefixes are per definition not standardized but just recommended best practices. How about extensibility in the future? What if EXIF adds new properties, they would need new code to handle those attributes while with XMP they could add them without the need to change anything. Is it also possible in the OpenEXR SDK to ask for all properties for a given namespace, like give me all EXIF or IPTC attributes? That would also be possible with XMP.

If they use XMP the only dependency for the OpenEXR SDK would be on XMPCore (available as part of the SDK under BSD license), which offers parsing/serializing of the data model. If they want they could even take the code from XMPFiles that does the EXIF/XMP mapping and offers parse/serialize of the IFD stuff. It can be used stand-alone. 

Lars

From: Thomas Mansencal <address@hidden>
Date: Thursday, July 18, 2013 11:52 PM
To: Brendan Bolles <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Openexr-devel] EXIF meta data attributes in headers

Hello,

Trying to summarize what as been said so far, correct me if I'm wrong:

- Everybody here seems to like / want EXIF support in Open EXR.

- Four methods:

[1] Extending the current specification camelCase attributes with new attributes: Looks like to be an easy way for implementation. This is assuming we have a well defined set of attributes / tags. Problem may be that it can take time to construct a list that makes everybody happy.

[2] Like above but the OIIO way which is creating custom prefixed attributes derived from the official exif naming convention (  "Exif:Foo" or "IPTC:Foo" ): Should be relatively easy to implement also.

[3] Supporting XMP: Doesn't looks like complicated either, have a growing worldwide support but will most likely rely on dependencies in order to serialize / parse the data whereas filling existing attributes would be very easy using exrstdattr for example. Adobe is behind the format and provides a very complete SDK, the format itself is an ISO standard which makes it kind of future proof. http://en.wikipedia.org/wiki/Extensible_Metadata_Platform

[4] Extending current specification using either method 1 or 2 and supporting XMP. Best of both world although subject to discrepancies between the attributes and XMP data.

- Adding support for ICC profile attribute.

Larry's way in OIIO is quite cool actually and very similar to what we are doing at MPC actually.

I'm not a huge fan of the current specification set of camelCase attributes because they don't take their name in any other existing specification ( Again correct me if I'm wrong ).

XMP way is although very good but serializing the data while being sure you have propagated the needed EXIF data requires a bit of massaging.

What do you guys prefer? Any other methods?

Thomas

Thomas Mansencal | thomasmansencal.com
[  thomasmansencal.blogspot.com  |  github.com/KelSolaar  ]

2013/7/19 Brendan Bolles <address@hidden>

On Jul 18, 2013, at 5:58 PM, Peter Hillman wrote:

> What extra info do you get from the ICC profile?
>
> Allowing ICC profiles worries me. Aren't EXRs supposed to store pixel values in "input scene referred linear-light" encoded with the chromaticities specified? That means images must be linearised before storing in an EXR.

I think I'll let Lars answer this one.  I guess if there's nothing in a scene referred linear ICC profile that can't be represented by Chromaticities, then there's no need for an official ICC profile attribute.

But I'll freely admit that I allow users to write EXR files off-spec.  Not that I really have any control over it - I get pixels from After Effects and I write those pixels.  If a user wants to store Rec709 data in an EXR, I'm not going to stop them.  I know of at least one major studio that does this.


BTW, I'd love for someone to look over my ICC profile to Chromaticity code.  It seems to work pretty well, except for the XYZ.exr sample file.

https://github.com/fnordware/openexrAE/blob/master/src/FrameSeq_Color.cpp

Brendan


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