Magnus Wrenninge | 1 Sep 04:53
Picon

Compilation warning in Iex using Intel compiler v11

We're currently using Imath as our default math library for the
Field3D project (http://code.google.com/p/field3d/). The following was
submitted as a bug to us, so I thought I would forward it along in
case it's something you want to fix in Iex. Seems to be an Intel
compiler-only warning (I'm not getting it using gcc).

The original submitter's ticket is at:
http://code.google.com/p/field3d/issues/detail?id=3

Cheers,
Magnus

---

A lot of compilation warnings like one below in IexBaseExc.h .

warning #811: exception specification for implicitly declared virtual
function "Iex::ArgExc::~ArgExc" is incompatible with that of overridden
function "Iex::BaseExc::~BaseExc"

#define DEFINE_EXC(name, base)				        \
    class name: public base				        \
    {							        \
      public:                                                   \
	name (const char* text=0)      throw(): base (text) {}	\
	name (const std::string &text) throw(): base (text) {}	\
	name (std::stringstream &text) throw(): base (text) {}	\
	virtual ~ name () throw () { } \  ///<<< this was added to solve this
    };
(Continue reading)

Piotr Stanczyk | 1 Sep 18:44
Gravatar

Re: Compilation warning in Iex using Intel compiler v11

Thanks for forwarding ... I'll try it out with the Intel compiler here.

Piotr

Magnus Wrenninge wrote:
> We're currently using Imath as our default math library for the
> Field3D project (http://code.google.com/p/field3d/). The following was
> submitted as a bug to us, so I thought I would forward it along in
> case it's something you want to fix in Iex. Seems to be an Intel
> compiler-only warning (I'm not getting it using gcc).
>
> The original submitter's ticket is at:
> http://code.google.com/p/field3d/issues/detail?id=3
>
> Cheers,
> Magnus
>
> ---
>
> A lot of compilation warnings like one below in IexBaseExc.h .
>
> warning #811: exception specification for implicitly declared virtual
> function "Iex::ArgExc::~ArgExc" is incompatible with that of overridden
> function "Iex::BaseExc::~BaseExc"
>
>
> #define DEFINE_EXC(name, base)				        \
>     class name: public base				        \
>     {							        \
>       public:                                                   \
(Continue reading)

Paul Miller | 8 Sep 18:31
Gravatar

converting from standard 8 bit to Half?

Is there a typical conversion from normal 8 bit images to half that will 
properly linearize the image so it looks "right" once displayed using 
the half display conversion? I'm finding my images look too dark once I 
to through my current process.

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?
Joseph Goldstone | 8 Sep 18:37

Re: converting from standard 8 bit to Half?

I'll be impressed if anyone can answer this without asking what  
"normal 8 bit images" are.

--joseph

On Sep 8, 2009, at 12:31 PM, Paul Miller wrote:

> Is there a typical conversion from normal 8 bit images to half that  
> will properly linearize the image so it looks "right" once displayed  
> using the half display conversion? I'm finding my images look too  
> dark once I to through my current process.
>
> -- 
> Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
Paul Miller | 8 Sep 19:28
Gravatar

Re: converting from standard 8 bit to Half?

Joseph Goldstone wrote:
> I'll be impressed if anyone can answer this without asking what "normal 
> 8 bit images" are.

I didn't think it was necessary to be too pedantic, but in my case I'm 
referring to images that have a 2.2 (or close) gamma curve baked in. 
Pretty much any image you'd find on the web for example.

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?
Adrian Paul | 9 Sep 06:30
Favicon

Re: converting from standard 8 bit to Half?

2009/9/9 Paul Miller <paul <at> fxtech.com>

Is there a typical conversion from normal 8 bit images to half that will properly linearize the image so it looks "right" once displayed using the half display conversion? I'm finding my images look too dark once I to through my current process.

Are you currently using an sRGB transfer function to go from 8-bit to half?
http://en.wikipedia.org/wiki/SRGB#The_reverse_transformation 
(a = 0.055 and ignoring the XYZ matrix)

--
Adrian Paul
Dr. D Studios
www.drdstudios.com
_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Paul Miller | 9 Sep 15:02
Gravatar

Re: converting from standard 8 bit to Half?

Adrian Paul wrote:
> 2009/9/9 Paul Miller <paul <at> fxtech.com <mailto:paul <at> fxtech.com>>
> 
>     Is there a typical conversion from normal 8 bit images to half that
>     will properly linearize the image so it looks "right" once displayed
>     using the half display conversion? I'm finding my images look too
>     dark once I to through my current process.
> 
> 
> Are you currently using an sRGB transfer function to go from 8-bit to half?
> http://en.wikipedia.org/wiki/SRGB#The_reverse_transformation 
> (a = 0.055 and ignoring the XYZ matrix)

My results look like what they would if I wasn't, which I'm not. Lemme 
give that a try!

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?
Jeff Clifford | 17 Sep 17:59
Favicon
Gravatar

Speed issue reading multi-channel EXRs

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.
Jeremy Selan | 17 Sep 19:31
Favicon

Re: Speed issue reading multi-channel EXRs

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/openexr-devel <at> nongnu.org/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 <jbc <at> dneg.com>
> Subject: [Openexr-devel] Speed issue reading multi-channel EXRs
> To: openexr-devel <at> nongnu.org
> Message-ID: <4AB25CF7.8040502 <at> dneg.com>
> 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
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>
> End of Openexr-devel Digest, Vol 77, Issue 4
> ********************************************
>
>   
Florian Kainz | 18 Sep 02:11

Re: Speed issue reading multi-channel EXRs

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
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
> 
> 

Gmane