I'm quite sure that I don't want to clutter TypeDesc with a growing number of non-POD types. TypeDesc is meant as a simple description of the basic C types, arrays thereof, and the common aggregates (like how a "point" is 3 floats).
But I'm very flexible about how we want to encode SMPTE timecodes. For example, it's fine with me to store it as a string if there's a standard convention already for how to write out an SMPTE timecode. (Similarly to how we store 'DateTime', though SMPTE may include other useful parts that don't match the way we store normal dates from images. If you truly want to be so general that there could be any number of SMPTE timecodes buried in the metadata, then we can agree on a convention for naming either the metadata itself, or the formatting of the string, to make it relatively unambiguous that it's encoding an SMPTE timecode specifically. On Oct 9, 2013, at 6:57 AM, Mark Boorer wrote: > Looking further into this, are we sure that timecode doesn't warrant a > new type? EXR's can contain many metadata fields in Timecode format > (not just one) and I don't think we can just give users 2 unsigned > ints and be done with it. Users will probably want their timecode in > string format (as is presently done in the DPX header) or at least > have an easy way for converting to/from strings. > > Further more, I don't think it's particularly intuitive to assume that > any TypeDesc of 2 UINT32 should be written as timecode, especially > where I would expect a TypeDesc of 2 INT32s to be written as an > ImfVecAttribute "v2i". > > Thoughts? > > Cheers, > Mark > > On Sun, Oct 6, 2013 at 9:27 PM, Pete Black <[email protected]> wrote: >> Hi All, >> >> DPX definitely supports timecode - and inside the DPX file, this is stored >> as a uint32 for the timecode data and a uint32 for the user data, by the >> looks >> >> Retrieving timecode from the DPX files we have using OIIO involves reading >> the metadata attribute 'dpx:Timecode' which returns the 'TV Industry >> specific' timecode formatted as a string e.g. '00:00:00:05'. >> >> -Pete >> >> >> >> I believe this maps to the >> >> On 7/10/2013, at 6:58 AM, Andrew Hunter <[email protected]> wrote: >> >>> I believe that DPX also supports SMPTE time code as well as CinemaDNG. >>> >>> -- >>> +1 416 567 9514 >>> [email protected] >>> http://aehunter.net >>> >>> On 3 Oct 2013 13:14, "Larry Gritz" <[email protected]> wrote: >>> I would welcome a pull request with this fully fleshed out and tested. >>> >>> Two more things... >>> >>> 1. Just to future-proof it, I might add this in there: >>> >>> ASSERT(sizeof(Imf::TimeCode) == 2*sizeof(unsigned int)); >>> >>> 2. If there are other formats that have full SMPTE timecodes, we might want >>> to instead change the attribute to "SMPTE:TimeCode" (making it not be >>> exr-specific) and dictate that any other formats follow the same encoding >>> if they have an SMPTE timecode. >>> >>> >>> On Oct 3, 2013, at 10:07 AM, Larry Gritz wrote: >>> >>>> I don't think this merits a new core type. >>>> >>>> I would add it to the metadata as an array of two unsigned ints, which is >>>> how it's encoded in Imf::TimeCode. You'd want something like this in >>>> exrinput.cpp: >>>> >>>> static TypeDesc TwoUints (TypeDesc::UINT, 2); >>>> Imf::TimeCode tc = ...; // get the timecode from the EXR file >>>> spec.attribute ("openexr:TimeCode", TwoUints, &tc); >>>> >>>> And then to extract it (including in exroutput.cpp): >>>> >>>> ImageIOParameter *f = spec.find_attribute ("openexr:TimeCode", >>>> TwoUints); >>>> if (f) { >>>> Imf::TimeCode tc = *(const ImfTimeCode *) f->data(); >>>> ... do your thing with tc ... >>>> } >>>> >>>> >>>> >>>> On Oct 3, 2013, at 8:56 AM, Mark Boorer wrote: >>>> >>>>> Hi, >>>>> >>>>> Was just looking to access timecode metadata from some EXR files, and >>>>> noticed that timecode keys aren't extracted by the reader. >>>>> >>>>> I then found this rather old issue >>>>> https://github.com/OpenImageIO/oiio/issues/337. Is it possible for me to >>>>> add this in? A simple class based on ImfTimeCode.h (or even just this >>>>> class directly) and a new enum added to TypeDesc? >>>>> >>>>> Cheers, >>>>> Mark >>>> >>>> -- >>>> Larry Gritz >>>> [email protected] >>>> >>> >>> -- >>> Larry Gritz >>> [email protected] >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
