Re: [Openexr-devel] KeyKodes (a recap)

[Tom Dilligan]

On Thu, 2004-09-30 at 15:38, Ken McGaugh wrote:
> On 30 Sep 2004, at 22:53, Tom Dilligan wrote:
> >
> > Things I'm not clear on:
> >
> >    In the KeyCode structure: The perfOffset is in perforations
> >    or in frames? I think that it should be in perfs, I've
> >    observed that cineon files store the perfOffset in frames,
> >    and dpx files store perfOffset in perfs. If the cineon
> >    convention is chosen an additional field  will need to be
> >    used to denote the perf offset to the actually align
> >    the images.
> >
> 
> I too feel the perfOffset should be in perfs, not inn frames.  One 
> thing I'm unclear on is if the perfOffset stored in a dpx includes
> the frame's perf alignment (ie. "p1"), or is it merely just the
> cineon-style frame offset multiplied by the number of perfsPerFrame? 
> Unfortunately I don't have access to any dpx sequences here to test
> this, just cineons.

The two dpx sequences that I have here both have the perfOffset where
perfOffset mod 4 == 0, which might indicate that it's just taking the
cineon number and multiplying it by four. It's a 1 in 8 chance for this
to happen randomly. Not impossibly remote.

I know that on the filmlight, our experience is that the current version
is not terribly accurate in assigning the keycode. It can be off by up
to two frames in either direction. 

I don't have any dpx scans from another scanner manufacturer, so I
really can't comment further. I think this is a real 'your mileage may
vary' sort of thing. My feeling is that the intention of the dpx way was
that it handles offsets in perfs, so you might have a frame that started
at perf 2 (or whatever).

I have made that assumption in some keycode manipulation software that
we use around here.

I've got a keyence keycode scanner running loose around here somewhere,
I'll try to figure out how accurate the thing is.

> If it is the latter, then we might need an additional member to store 
> this.

I think that it's a safe assumption that the perfOffset should be the
actual start of the frame (i.e. the former assumption). If we're already
in the state where no scanner gives a perfectly accurate perfOffset then
this whole conversation is quite moot and we should just say: This is
what is logical, in the future when film scanners are perfect, we know
this is what will work.

> >
> > Am I missing anything?
> >
> 
> A few more things from me.  I think it would be nice if the IlmImf
> library supplied routines (or methods) for looking up the film
> manufacturer code and  film type characters from the numbers stored
> in the keycode.  I would also like a  routine to to build a human
> readable string of the keycode.  And I imagine it would be handy to
> have routines to do keycode math.

One problem that I have had is just finding a complete list of film
manufacturers / filmstocks. I have attached a table that I found on a
website which is the most complete list I have found today.

I do agree with Florian that IlmImf is probably not the best place for a
keycode handling library. I have a bunch of stuff already written to
handle this (as well as doing human readable strings). I'll ask if I can
supply it under something like LGPL.

>>>Tom

keycode
Description: Text document