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

[Luc-Eric Rousseau]

>> 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.
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.

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.

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