[Openexr-devel] Re: Speed issue reading multi-channel EXRs

[Jeremy Selan]

Jeff,

I'm on 'digest mode', so forgive me if some has already answered this.


To the best of my knowledge, openexr is not efficient at reading a small 
number of
channels from multi-channel images. More specifically, even if you're 
only interested in 3 channels
(such as Nworld.rgb), due to channel interleaving in exr format, data 
from ALL the channels must be read
to access even one. Of course, if you're reading from networked storage 
this takes on a greater significance.
When one considers a comp that actually uses all of these AOVs, the 
amount of data unnecessarily transferred is massive.

Please see this previous thread:
http://www.mail-archive.com/address@hidden/msg00480.html
for more info on this topic.

To the best of my knowledge, this still holds true today, though I'd 
rejoice if someone confirmed otherwise!

-- Jeremy


> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 17 Sep 2009 16:59:51 +0100
> From: Jeff Clifford <address@hidden>
> Subject: [Openexr-devel] Speed issue reading multi-channel EXRs
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> We've recently stumbled upon an issue with the shake OpenEXR reader 
> where if we use a multi-channelled EXR file the time taken to read the 
> file drops considerable from <1 second to about 10 seconds for a 2k image.
>
> Tweaking the reader source it looks like the speed hit is occurring at 
> the readPixels call.
>
> Reading the docs I am wondering if a file seek is occurring that was not 
> occuring before with just RGBA files?  Does anyone know if doing 
> multiple readPixels calls with an openEXR file with channels such as:
>
> channels (type chlist):
>     __Nworld.x, 16-bit floating-point, sampling 1 1
>     __Nworld.y, 16-bit floating-point, sampling 1 1
>     __Nworld.z, 16-bit floating-point, sampling 1 1
>     __Pobject.b, 16-bit floating-point, sampling 1 1
>     __Pobject.g, 16-bit floating-point, sampling 1 1
>     __Pobject.r, 16-bit floating-point, sampling 1 1
>     __Pworld.x, 16-bit floating-point, sampling 1 1
>     __Pworld.y, 16-bit floating-point, sampling 1 1
>     __Pworld.z, 16-bit floating-point, sampling 1 1
>     __ambOcclMix, 16-bit floating-point, sampling 1 1
>     __ambUnoccl.b, 16-bit floating-point, sampling 1 1
>     __ambUnoccl.g, 16-bit floating-point, sampling 1 1
>     __ambUnoccl.r, 16-bit floating-point, sampling 1 1
>     __colourbleed.b, 16-bit floating-point, sampling 1 1
>     __colourbleed.g, 16-bit floating-point, sampling 1 1
>     __colourbleed.r, 16-bit floating-point, sampling 1 1
>     __depth.b, 16-bit floating-point, sampling 1 1
>     __depth.g, 16-bit floating-point, sampling 1 1
>     __depth.r, 16-bit floating-point, sampling 1 1
>     __diffuse.b, 16-bit floating-point, sampling 1 1
>     __diffuse.g, 16-bit floating-point, sampling 1 1
>     __diffuse.r, 16-bit floating-point, sampling 1 1
>     __incandescence.b, 16-bit floating-point, sampling 1 1
>     __incandescence.g, 16-bit floating-point, sampling 1 1
>     __incandescence.r, 16-bit floating-point, sampling 1 1
>     __objId.b, 16-bit floating-point, sampling 1 1
>     __objId.g, 16-bit floating-point, sampling 1 1
>     __objId.r, 16-bit floating-point, sampling 1 1
>     __occlusion.b, 16-bit floating-point, sampling 1 1
>     __occlusion.g, 16-bit floating-point, sampling 1 1
>     __occlusion.r, 16-bit floating-point, sampling 1 1
>     __opacity.b, 16-bit floating-point, sampling 1 1
>     __opacity.g, 16-bit floating-point, sampling 1 1
>     __opacity.r, 16-bit floating-point, sampling 1 1
>     __reflOcclMix, 16-bit floating-point, sampling 1 1
>     __reflUnoccl.b, 16-bit floating-point, sampling 1 1
>     __reflUnoccl.g, 16-bit floating-point, sampling 1 1
>     __reflUnoccl.r, 16-bit floating-point, sampling 1 1
>     __shadowMask, 16-bit floating-point, sampling 1 1
>     __specular.b, 16-bit floating-point, sampling 1 1
>     __specular.g, 16-bit floating-point, sampling 1 1
>     __specular.r, 16-bit floating-point, sampling 1 1
>     __texture.b, 16-bit floating-point, sampling 1 1
>     __texture.g, 16-bit floating-point, sampling 1 1
>     __texture.r, 16-bit floating-point, sampling 1 1
>     __uv.b, 16-bit floating-point, sampling 1 1
>     __uv.g, 16-bit floating-point, sampling 1 1
>     __uv.r, 16-bit floating-point, sampling 1 1
>
> is worse than for when we have say just RGBA?  Is the seek time 
> proportional to the number of channels?
>
> I should mention that we have things set up so that the exr files are 
> decreasing_y order so that we can read files quickly with multiple 
> readPixel calls as the docs suggest to avoid unwanted seeks.
>
> Anyone else noticed this problem or have any suggestions?
>
> Thanks,
>
> Jeff Clifford.
>
>  Double Negative.
>
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>
> End of Openexr-devel Digest, Vol 77, Issue 4
> ********************************************
>
>