OpenEXR developer list

headers Alan Walford | 4 Oct 22:27

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel

The file format is exactly the same in versions 1.2.1 and 1.4.0
of the library.  The changes we made to the library code include
multi-threaded I/O, a couple of bug fixes, and increased portablity
of the code.  None of those code changes affect the on-disk file
format.

Florian

Alan Walford wrote:
>  
> Are there differences between exr images written by these versions of 
> the library - 1.2.1 and 1.4.0a?
>  
> Or if an exr image is written by a program using the 1.4.0a library, 
> will there be any issues with a program compiled with the 1.2.1 library 
> loading it?  In this case we are concerned mostly with rgba and scanline 
> imagery.
>  
> Thanks
> Alan
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel

--- darby johnston <darbyjohnston <at> yahoo.com> wrote:

> When compiling OpenEXR under Solaris 10 6/06 with
> Sun
> Studio 11, I got an error about missing math
> symbols:

...

> Solaris isn't listed in your supported platforms,
> but
> maybe it would be easy enough to add a "-lm" to the
> configure?

Sorry, meant to get back to this earlier but have been
super busy...

Maybe this could be added to "configure.ac":

AC_SEARCH_LIBS([floor], [m])

That will add an "-lm" to the linker line, making
solaris happy and hopefully not unduly affecting
anything else. It looks like on other platforms libm
is  automatically pulled in from libstdc++.

I just tried this on Solaris, FreeBSD, and Fedora 4,
and it seemed to work ok.

Thanks, Darby

On 10/13/06, darby johnston <darbyjohnston <at> yahoo.com> wrote:

> Maybe this could be added to "configure.ac":
>
> AC_SEARCH_LIBS([floor], [m])
>
> That will add an "-lm" to the linker line, making
> solaris happy and hopefully not unduly affecting
> anything else. It looks like on other platforms libm
> is  automatically pulled in from libstdc++.
>
> I just tried this on Solaris, FreeBSD, and Fedora 4,
> and it seemed to work ok.

I'll try it, and if it works on our other platforms, I'll check it in.

thanks
d

I would like propose a new "framesPerSecond" standard attribute
for OpenEXR:

The attribute defines the frame rate at which an OpenEXR image
sequence should be played back.  All frames in a sequence should
have this attribute, and the attribute's value should be the same
for all frames.  If no frame rate is specified for a sequence,
then playback software should assume 24 frames per second.

The attribute's value could be represented either as a floating-
point number or as the quotient of two integers.  A floating-point
number would be easier to use, but it cannot represent NTSC frame
and field rates exactly.  A quotient would be slightly less
convenient, but all commonly used frame rates, including NTSC,
can be represented exactly.

     frame rate                  float           quotient
     --------------------------------------------------------

     35-mm film                  24.0            24 / 1

     PAL video,                  25.0            25 / 1
     50 Hz HDTV frames

     NTSC frames                 29.97003        30000 / 1001

     60 Hz HDTV frames           30.0            30 / 1

     50 Hz HDTV fields           50.0            50 / 1

     NTSC fields                 59.94006        60000 / 1001

     60 Hz HDTV fields,          60.0            60 / 1
     Showscan

If you have comments or opinions, I'd like to hear them.

Thank you,

Florian

Hi Florian,

On Sat, 14 Oct 2006 06:05:52 +0200, Florian Kainz <kainz <at> ilm.com> wrote:

> I would like propose a new "framesPerSecond" standard attribute
> for OpenEXR:
>
> The attribute defines the frame rate at which an OpenEXR image
> sequence should be played back.  All frames in a sequence should
> have this attribute, and the attribute's value should be the same
> for all frames.  If no frame rate is specified for a sequence,
> then playback software should assume 24 frames per second.
>
> The attribute's value could be represented either as a floating-
> point number or as the quotient of two integers.  A floating-point
> number would be easier to use, but it cannot represent NTSC frame
> and field rates exactly.  A quotient would be slightly less
> convenient, but all commonly used frame rates, including NTSC,
> can be represented exactly.

Very good idea and it makes a lot of sense.
I'd prefer the quotient as well, however, some host applications only return a floating point number for
the frame rate.

Would it pollute OpenEXR too much to allow for both, or a single attribute which by default stores the
floating point number, but also may containe the quotient? (a value of 0/0 would in that case mean only the
floating point fps is valid).

Cheers,
Mike

P.S. Thanks for all the work put into OpenEXR!

--

-- 
db&w GbR
Seyffer Str. 34
70197 Stuttgart

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

On Fri, 13 Oct 2006, Florian Kainz wrote:

> I would like propose a new "framesPerSecond" standard attribute
> for OpenEXR:
>
> The attribute defines the frame rate at which an OpenEXR image
> sequence should be played back.  All frames in a sequence should
> have this attribute, and the attribute's value should be the same
> for all frames.  If no frame rate is specified for a sequence,
> then playback software should assume 24 frames per second.
>
> The attribute's value could be represented either as a floating-
> point number or as the quotient of two integers.  A floating-point
> number would be easier to use, but it cannot represent NTSC frame
> and field rates exactly.  A quotient would be slightly less
> convenient, but all commonly used frame rates, including NTSC,
> can be represented exactly.

The SMPTE DPX format uses your 'float' scheme.  It certainly does not 
hurt to be aligned with an existing industry standard.

A more exotic approach is to represent the rate as a frame delay 
instead.  This allows for frame playback at varying rates, with the 
possibility to hold one frame for a long time.

Bob
======================================
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

>>>>> "Florian" == Florian Kainz <kainz <at> ilm.com> writes:

Florian> The attribute's value could be represented either as a
Florian> floating-point number or as the quotient of two integers.

A rational is definitely the better choice.

-JimC
--

-- 
James Cloos <cloos <at> jhcloos.com>         OpenPGP: 0xED7DAEA6

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel

On 10/14/06, James Cloos <cloos <at> jhcloos.com> wrote:
> >>>>> "Florian" == Florian Kainz <kainz <at> ilm.com> writes:
>
> Florian> The attribute's value could be represented either as a
> Florian> floating-point number or as the quotient of two integers.
>
> A rational is definitely the better choice.

I agree.

d

6	February 2012
2	January 2012
2	November 2011
8	September 2011
12	August 2011
5	July 2011
2	June 2011
18	May 2011
15	April 2011
15	January 2011
9	November 2010
9	October 2010
6	September 2010
34	August 2010
4	June 2010
6	May 2010
31	March 2010
5	February 2010
12	December 2009
2	November 2009
2	October 2009
11	September 2009
11	July 2009
18	June 2009
4	May 2009
23	March 2009
5	February 2009
7	January 2009
4	December 2008
6	November 2008
18	October 2008
10	September 2008
11	August 2008
4	July 2008
19	June 2008
9	May 2008
8	April 2008
11	March 2008
12	February 2008
11	January 2008
30	December 2007
13	November 2007
9	October 2007
3	September 2007
26	August 2007
2	July 2007
11	June 2007
33	May 2007
11	April 2007
47	March 2007
9	February 2007
35	January 2007
49	December 2006
22	October 2006
23	September 2006
19	August 2006
17	July 2006
27	June 2006
11	May 2006
15	April 2006
29	March 2006
23	February 2006
55	January 2006
22	December 2005
17	November 2005
17	October 2005
10	September 2005
15	August 2005
48	July 2005
18	June 2005
14	May 2005
20	April 2005
91	March 2005
51	February 2005
27	January 2005
13	December 2004
54	November 2004
45	October 2004
57	September 2004
74	August 2004
17	July 2004
52	June 2004
58	May 2004
21	April 2004
35	March 2004
34	February 2004
112	January 2004
39	December 2003
31	November 2003
45	October 2003
9	September 2003
25	August 2003
25	July 2003
18	June 2003
16	May 2003
57	April 2003
116	March 2003
16	February 2003
58	January 2003
2	March 2002

EXR Image File Compatibility when written by different versions of library?

Re: EXR Image File Compatibility when written by different versions of library?

Re: Couple of minor things...

Re: Re: Couple of minor things...

New framesPerSecond Attribute?

Re: New framesPerSecond Attribute?

Re: New framesPerSecond Attribute?

Re: New framesPerSecond Attribute?

question about the tone mapping in OpenEXR

Re: New framesPerSecond Attribute?

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31