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

[Florian Kainz]

Hi Jeff,

I'd expect the overall file reading time to increase linearly with the
number of channels and the number of pixels in the image, at least for
large files.  For small files you may get speedups caused by higher hit
rates in various caches.

When you say that file reading time increases from less than one second
to about ten seconds, what exactly are you comparing?  I assume the file
that takes ten seconds to load contains your 48-channel image, but what's
in the one-second file?  An RGBA-only image?

A 48-channel image has roughly the same size as 16 RGB or 12 RGBA files;
reading the multi-channel image should take about the same amount of
time as reading an equivalent collection of RGB and RGBA files.

Florian


Jeff Clifford wrote:
> 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