Re: [Openexr-devel] Re: New framesPerSecond Attribute?

[Michael Wolf]

On Thu, 19 Oct 2006 05:27:10 +0200, Luc-Eric Rousseau <address@hidden> wrote:

Hi Luc-Eric,

>>> You could have a class (or operator) that converts the two integers
>>> to double only  (is this common & error-prone?), but someone will probably 
>>> ask
>> the reverse, and perhaps more.
>
>> I would ask the reverse, since my host app (over which I have no control) 
>> only uses doubles ;)
>
> If your host app (Lightwave?) doesn't give you the exact rational number to
> set in an OpenEXR header you should be able to figure it out, or avoid 
> setting the field.

Bingo (the Lightwave part). I'm not sure if I'd be the only one with the issue. 
I don't mind figuring it out myself, but it surely would be nice to have 
pre-canned code for it, especially if it already exists.

> It's best to not set meta data that could be incorrect. The client of that 
> data could
> be some kind of DI app, an Avid, a codec, someone that really understands 
> this stuff.

I see you excluded Quicktime from this list ;)

> In the specific case of full frame 3D animation, it's totally valid to round 
> up and write
> the frame rate of a sequence as 30 fps rather than NTSC (29.97..).  They mean 
> the same thing.
> What's wrong is saving some number that is not quite NTSC rate, due to 
> floating point
> errors, then it looses some of its usefulness.  (Should it be retimed to fit 
> or is it an error in
> the exporter?  What is the exact length of the sequence in time code?)  Or 
> even a double
> slightly off 24fps when the user meant 24.

So basically, if the host app only provides a double, don't write the fps at 
all? I assume that would be the "proper" thing to do then, but would also 
decrease the usefulness of having standard metadata.

> If the guys want to code this conversion to a rational number in OpenEXR, 
> that's ok;
> in that case I would suggest hard-code specific rounding cases for common 
> video
> frame rate (29.97,59.94,23.976) to snap them to use the industry-standard 
> ratios.
> It sounds like even if there were standard constants, people might not use 
> them (because
> it takes extra work)  The API could also always round any double it gets the 
> closest integer, forcing
> people who really want to specify rates like NTSC 29.97 to use a predefined 
> constant
> or specify the two integers.  Which coerces people to do the right thing.:D

Well, that is basically what I was thinking. And since the reading apps will be 
very likely to have an option to override the fps setting upon import (if just 
for legacy reasons), it should be an o.k. thing to do.

Cheers,
Mike
-- 
db&w GbR
Seyffer Str. 34
70197 Stuttgart

http://www.db-w.com
http://www.infinimap.com