Re: [Openexr-devel] keycode

[Ken McGaugh]

Thanks for responding Florian.  I made a mistake in my first email
in that the 8-bit fields needed to be signed, not unsigned (according
to the DPX spec).  But using "char" and "unsigned int" sounds good too.

>
>   * Is there a SMPTE keycode standard, other than the DPX specification?

There is SMPTE 254 which specifies the actual method by which keycode 
information
is encoded onto the edge of the film.  I don't have access to that doc yet
so I cannot say more about it.  Otherwise, the only way I've seen keycode 
information
stored is either as an ASCII burn-in on video footage, or in the cineon header
(which looks very similar to the DPX one).


>   * Should slateInfo really be a field in the key code?  Somehow this feels
>     more like a separate attribute.

No, slateInfo really isn't a part of the keycode, but it is a part of the
SMPTE DPX Motion Picture Information header.  One of my questions to the list
is should we include everything from the DPX header, or should we just include
those necessary to track the keycode?  I only need keycode myself right now,
but I'd like to choose something which is both standard and future proof.

If we leave off the slateInfo and reserved fields, we still have the ability to
just do a memcopy from our data structure into a DPX one, which is nice.  I
don't have any major objections to leaving them out.  But on the other hand
they only add 156 bytes.


>   * In C++, having a default constructor for the keycode information would
>     be useful.  Do you have suggestions for suitable default values for
>     the fields in the struct?

The SMPTE DPX spec says that any non-core fields that are not set by the
writer should use the following values to designate "undefined":

     unsigned 8-bit integer:    0xFF
    unsigned 16-bit integer:    0xFFFF
    unsigned 32-bit inteber:    0xFFFFFFFF
         32-bit real number:    0xFFFFFFFF
                      ASCII:    0x0

And I believe that all the fields we are discussing are considered non-core.

--Ken