Awesome! Thanks a lot for this :) Thomas
*Thomas Mansencal | thomasmansencal.com *[ *thomasmansencal.blogspot.com* | *github.com/KelSolaar* ] 2013/9/6 Piotr Stanczyk <pstanc...@ilm.com> > 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 [thomas.mansen...@gmail.com] > *Sent:* 06 September 2013 06:21 > *To:* Piotr Stanczyk > *Cc:* Lars Borg; openexr-devel@nongnu.org > > *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 <thomas.mansen...@gmail.com> > >> 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
