[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-devel] OpenEXR image sequence files...
From: |
E. Scott Larsen |
Subject: |
Re: [Openexr-devel] OpenEXR image sequence files... |
Date: |
Thu, 4 Nov 2004 20:27:31 -0500 (EST) |
You can make two textures and render from one while the other is being
filled in, then swap when the latter is ready. This has worked well for
us in a multithreaded scenario (one thread rendering and one thread
reading the next image and filling the spare texture with it).
//Scott
On Thu, 4 Nov 2004, Drew Hess wrote:
>
> There's been some interest in this, but nothing is being actively
> developed, as far as I know. At SIGGRAPH 2003 I had a few people
> approach me after the OpenEXR sketch asking about using OpenEXR for
> video, but nothing came of it.
>
> We'd certainly be interested in hearing ideas. The major issue for us
> is that it takes about 400MB/s to stream uncompressed HD-res RGBA
> 16-bit OpenEXR images, and that's not very practical for an artist's
> desktop machine. Then again, it's not a Herculean effort, either,
> just takes a stack of maybe 10-12 7200rpm IDE drives; so for other
> markets, like digital cinema, maybe it's not such a big deal.
>
> BTW, you probably want the alpha channel for padding reasons, even
> though it costs you another 100MB/s; otherwise, either your app or the
> OpenGL driver has to reformat the data as RGBA before sending it to a
> 16-bit FP pixel shader, since that's the only native 16-bit FP format
> that current video cards support.
>
> I dunno, maybe if you have a 2nd processor you can be doing that one
> frame ahead and save on some disk bandwidth while still maintaining
> the frame rate to the video card, but it'd be challenging, esp. since
> video cards aren't typically able to render while you're downloading
> the next texture/frame. With a fast Pentium 4 or Athlon 64 and an
> NV40, I can get about 40fps on HD-res OpenEXR image sequences, but
> downloading a texture to the card and rendering it is basically a
> serial process -- you can't overlap it.
>
> d
>
>
>
> "David Kuo" <address@hidden> writes:
>
> > New to the list.
> >
> >
> >
> > Don't think this has been discussed before, but is there any effort
> > underway to extend OpenEXR to image sequences?
> >
> >
> >
> > I am working on displaying real-time HDR video sequences, and would
> > rather not invent yet another file format.
> >
> >
> >
> > David
> >
> > _______________________________________________
> > Openexr-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/openexr-devel
>