[Openexr-devel] KeyKodes (my two cents)

[Tom Dilligan]

Sorry that I'm coming to this party a bit late, but I had a couple of
comments / questions:

Ken McGraugh wrote:
> 
> Daniel A. Fort wrote:
> > 
> > I'm referring to Florian's KeyCode class. Once again, an example key 
> > number would be something like:
> > 
> > FN 12 3456 7890 + 00 p1
> > 
> > where p = perfOffset
> > values ranging from p1 to p(number of perforations per frame)
> >
> 
> Your description is excellent and I think I'm starting to understand
> this.  But I think there is conflicting terminology going on and I'm
> trying to get it straight.
> 
> The DPX spec, the KeyKode doc, and SMPTE 254 all refer to the "perf offset"
> as the "00" part of your example above, which is the number of perfs since
> the last valid barcode.  You are referring to "perf offset" as the "p1"
> bit at the end of the example, which is the relative position of the 
> zero-frame
> with respect to the zero-frame reference mark, correct?

Quick note (which might explain some of the confusion here): I've
observed that cineon files tend to treat the perf offset as a *frame*
offset, and dpx handles perf offset as an actual perf offset. I think
that we should use the dpx convention (which I think eliminates the need
for the p<n> field). Converting from this convention to a frame offset
is trivial (simply divide perf offset by perfs per frame).

As another aside note. USS-128 (the barcode format that is used for
KeyKode) can be used to store either ascii (variants A and B) or
exclusively numeric data (variant C). Variant C encodes 2 digits into
every barcode 'character' requiring that the number represented be an
even number of digits. It appears that KeyKode using the C variant so we
don't have to worry about non-digits in the barcode, but other people
may choose other things (does this mean that we should have a field of
our keycode data be the raw barcode?)

>>>Tom