openexr-devel
[Top][All Lists]
Advanced

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

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


From: Jeff Clifford
Subject: Re: [Openexr-devel] Speed issue reading multi-channel EXRs
Date: Fri, 18 Sep 2009 10:34:44 +0100
User-agent: Thunderbird 2.0.0.18 (X11/20081105)

Thanks for your answers Florian & Jeremy.

To answer your question Florian I was indeed comparing the 48-channel image with an RGBA one.

I am guessing then that one way to avoid the slowness is to load the entire channel into a framebuffer in one go with just one readPixels call and cache it for shake to use. The downside of this of course is memory consumption goes up.

Cheers,

Jeff.


Florian Kainz wrote:
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







reply via email to

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