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
