Hi, > Not sure if this helps too much, I guess following what the DPX format does > would be good for consistency.
My problem with that is that the DPX reader presently converts the uint32 into a string (ignoring dropframe information / userbits) And because it only has one metadata slot for timecode, it is able to just convert back from string when writing the file. In EXR, there could be many timecode attributes, (not to mention other rich types like keycodes), And there is no way for me to determine whether a user wants to write said attribute as a string or convert it to an actual timecode type. I have a timecode class frankensteined from Imf and combined with some nicer toString / fromString methods, which I am proposing we add to OIIO and use in each of the DPX, EXR and CinemaDNG readers/writers. (I would also like to add a similar KeyCode class). They are modified from the original Imf classes so as not to introduce a dependency on OpenEXR. My current pickle is that the ParamValue wants to describe the attribute with a TypeDesc, and these new classes seem at odds to the current architecture of the TypeDesc BASETYPE. I am currently thinking of shoehorning them into the enum as TIMECODE and KEYCODE. I can probably keep the behaviour of writing DPX's consitent (and determine whether the dpx:TimeCode attribute is a string or the new TimeCode type) but reading should probably return the TimeCode type (perhaps with an explicit conversion to string defined). My final goal is to be able to read all EXR metadata via OIIO, and write the same metadata out again to a new EXR, preserving the attribute types. _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
