Re: [Openexr-devel] OpenEXR image sequence files...

[Rodrigo Damazio]

       Only now getting back to old msgs...busy times...

Drew Hess wrote:

> 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.
>  
      The problem with the 400Mb/s is definitely not displaying it, as 
you said, any good disk array will do that - the problem is real-time 
processing it...what I've been having to do is have a cluster, and I've 
studied a few job division techniques for this....depending on the kind 
of processing I want to do, it's btter to slice up each frame and have 
each node process that slice, then compose them back together (the 
concept of the data window helps a lot here).
       In other cases, specially when one portion of the input image 
affects other portions of the output image, what I do is to split on a 
per-frame basis - whenever frames are completely independent, this also 
works well, since I can have each node processing a different frame and 
thus have a contiguous stream at the output. I've also tried slicing up 
the fourier transform of the original image, but the performance gain 
was marginal.
      For processing that depends on previous or future frames (such as 
adaptative exposure control), I've also used the image-slicing 
technique, guaranteeing that each node always gets the same slice.
      Also, since there's no HDR broadcasting system (or is there?), 
it's often possible to do HDR processing and then output in LDR after 
that, which significantly reduces bandwidth requirements on both hard 
drives and networking equipment.
      One of my next steps will be looking into a hardware architecture 
to accelerate HDR processing in hardware...

Rodrigo