Re: [Openexr-devel] keycode

[Ken McGaugh]

Florian Kainz wrote:

>
>
> Personally, I think the slate should be a separate StringAttribute,
> but I don't have a strong opinion about this.
>

Kevin Wheatley wrote:
>
> There is a lot of junk in DPX, so I favour separating the bits out
> that are useful and including them, if something is missed, then
> simply add it to the allowed list of attributes, i.e. have an
> attribute registry kind of like OpenGL has that is separate from the
> main file format, that way you can add things when you need to without
> a major update.
>

I'm more than happy to strip out the bits we need into seperate
attributes, but I do need start encoding keycodes soon.  So why don't
we just have a keycode attribute all by itself.  If we want to retain
some similarity to the DPX standard, it would be a data structure that
looks like:

    struct keyCode
    {
        char        filmMfgCode[2];
        char        filmType[2];
        char        perfOffset[2];
        char        prefix[6];
        char        count[4];
    };

It is a bit wasteful encoding all those numbers as individual
8-bit digits, but the only other way I can think of would be to
use store the actual binary encoding from the film (SMPTE 254?).

Note that the DPX spec encodes the film manufacturer and the film
type as numbers, not the ascii characters that you see burned into
video (as the cineon header stores them).  This means that the Imf
library will need to store a database mapping id numbers to ascii
charactes.  In fact, the struct should probably have a member
function for returning the entire keycode as an ascii string looking
something like

    EH 01 0594 5390 + 12

We will also want to standardize the attributes used to store other
bits of information from the film and tv information headers in the
DPX spec (ie. timeCode, frameRate, etc.).  But for right now I just want
to nail down the keycode.

Thanks.
--Ken