openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] OpenEXR on the desktop!


From: Drew Hess
Subject: Re: [Openexr-devel] OpenEXR on the desktop!
Date: Mon, 15 Nov 2004 11:00:27 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux)

One thing you can do is load an image, convert it to its 8-bit
representation ("baking in" the exposure, filmlook, gamma, etc.), and
then throw out the OpenEXR image, leaving only the 8-bit version.
Rinse and repeat.

The problem with that method is that whenever you want to change one
of those baked-in parameters, you have to reload the entire sequence
and do it again.

To do HD-res 24fps playback of 4-channel 16-bit OpenEXR images, you
need about 400MB/s of sustained bandwidth.  You can get that by
building a pretty large RAID-0 array (I'm guessing about 15 disks,
most modern disks are capable of sustaining ~30MB/s of read
performance), and carefully laying out the images, uncompressed, on
disk; OpenEXR's compression methods are too slow for real-time
playback on any CPU I know of... well, maybe you could get RLE working
at real-time.

You'll need a very fast filesystem, like SGI's XFS, which is available
in the 2.6 Linux kernel.

You'll also probably need at least 2 SCSI ultra/wide/blahblah
controllers, unless there's a controller that's capable of pulling
400MB/s on its own.  I haven't kept up with the latest SCSI standards.
Using SATA for this would be harder.  I think SATA-I tops out at 1.5
G*bits*/s and SATA-II doubles that, but I'm sure the real limit of the
chipsets is much lower than that, and even the theoretical limits of a
single controller aren't enough for this application.

Then you'll need something like 64-bit 66MHz PCI-X or PCI-Express to
push this rate across the I/O bus.

Having two CPUs, one for streaming and one for playback, wouldn't hurt
either.  Playback of OpenEXRs on a GPU is not particularly CPU
intensive, but it is latency-sensitive, so it would probably help to
have a CPU free to handle an interrupt when you really need it.

After considering all this, it sounds a lot cheaper and easier to buy
an AMD64 machine and stick 8GB of RAM in there :) That is, assuming
that 8GB is enough.

(And yeah, if you go this route you still have to wait for all the
frames to load, which sucks.)

d


"Mike S" <address@hidden> writes:

> I'm currently trying OpenEXR. One problem for me are the high demands
> for lots
> of RAM when doing playback. The playback application simply stores an
> array of
> OpenEXR images in-memory. When doing a typical HD res playback the
> cache allocates
> almost all available RAM.
>
> Are there are any good alternatives to using lots of RAM when doing
> OpenEXR playback?
> On the desktop, how is it handled at other studios? This isnt just
> about OpenEXR but it would
> be VERY interesting to hear some feedback on how other people have
> dealt with the problem!
>
> Thanks,
>
> // Mike
>
> _________________________________________________________________
> FREE pop-up blocking with the new MSN Toolbar - get it now! 
> http://toolbar.msn.com/
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel

Attachment: pgpFVlJBWSavf.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]