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 <pstanc...@ilm.com> > 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=ilm....@nongnu.org[openexr-devel-bounces+pstanczyk= > ilm....@nongnu.org] on behalf of Lars Borg [b...@adobe.com] > *Sent:* 30 July 2013 01:17 > *To:* Thomas Mansencal > *Cc:* openexr-devel@nongnu.org > > *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 <thomas.mansen...@gmail.com> > Date: Thursday, July 18, 2013 11:52 PM > To: Brendan Bolles <bren...@fnordware.com> > Cc: "openexr-devel@nongnu.org" <openexr-devel@nongnu.org> > 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 <bren...@fnordware.com> > >> 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 >> Openexr-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> > >
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
