I kind of agree with Brendan on that one, in a same way nothing would prevent having conflicting EXIF XMP data in a tif file with the EXIF data of that very same file. It actually happens quite often, a lot of attributes are redundant and are not formatted the same way, I think about the lens names or shutter speed for instance.
Hombre: I actually posted the initial thread on RT forum for EXR :) Glad to see you on that here! KS *Thomas Mansencal | thomasmansencal.com *[ *thomasmansencal.blogspot.com* | *github.com/KelSolaar* ] 2013/7/19 Brendan Bolles <bren...@fnordware.com> > On Jul 18, 2013, at 3:08 PM, Larry Gritz wrote: > > > If you think any of these are supposed to represent the same data, you > can get into problems when an app reads the EXR file, just copies XMP to > output, but changes one of the related OpenEXR fields. Then you end up with > an output file that has metadata that in some sense contradicts itself. > > > In most cases I imagine they'll only have one form of metadata coming in > and any other EXR attributes they add will be parsed from that source. > > For example, I currently get ICC profiles from the Adobe apps, which I > then parse out to make Chromaticity attributes. But an ICC profile can > have information that can't be reconstructed from chromaticities, so that's > why I embed the whole thing as well. > > Anyway, let's not let perfect become the enemy of good. The benefit of > getting more metadata outweighs the risk of getting conflicting metadata, > which I would call a bug for the app developer. > > > 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
