Not sure if this is a limitation of OExr, Houdini's interface to it, or me.

I'm trying to output Pz(Depth) to OExr format - I am able to successfully output vector P to OExr, but I can't get Pz to work. I'm setting the ‘ray_aux#’ parms for the ROP to:

type float
depth float
no filtering

and I get blank images. For the same pass I can run ‘P’ with ‘vector,float,no filter’ and it's fine, in OExr. I've also tried setting the depth to half, just for kicks, no go. I can change the above setting to tiff - and it all works fine. ‘iinfo’ on a typical Pz file gives me:

File: ./Test.torus1.Pz.0004.exr (OpenEXR format)
Image Count: 1
Resolution: 720 x 486
Data: 16 bit float
Color Model: rgba
Channel Depth: 16


Obviously a vector comes out just fine, I wonder if it's just the single float channel type of the variable is causing a problem when outputting to OExr, and mplay isn't parsing it properly?

Btw, that problem with mplay not showing alpha's in OExr images is still there in 7.0.217…related? I'll bet…

Cheers,

J.C.

Huh, I thought that Deep Rasters were not yet supported in Side Effects' implementation of EXR. This must've been because I first tried with Pz, got no joy and assumed that the EXR support was limited to RGBA.

Well, that would explain my results - but I guess pumping out a 3-vector will map nicely over to RGB, support or not. I do know the problem with displaying the OExr alpha in mplay has been there for some time, and is a bug. That would seem related to what I'm trying to do - a single float channel.

Cheers,

J.C.

OpenEXR has a somewhat odd ‘simple’ RGBA interface. Basically, if the slices are named R,G,B or A, it'll pick them up. If the slices are named anything else, (like Pz) even if there's no R, G, B or A, it ignores them. This seems a little strange to me, but I guess it's a form of consistency.

Anyways, to support loading these other slices (planes or channels), I'd need to use the generic interface, which can query what slices are in the OpenEXR file, and either auto-load them (ie, try to figure out what it should load) or allow an image option to specify the slices to load. (Slices: )

The ideal solution is to have OpenEXR files load like deep raster pics. This requires a substantial amount of changes to the file loading code, which is why it wasn't included in H7.

Interesting, thanks Mark. Almost seems like the “hack” approach, maybe just stuffing blank RGBA channels in there or as you said, might be good enough. Even auto-channelling, say, a float layer like Pz into RGB would be fine, if a bit inconsistent.

At least I understand what's going on, though…

Cheers,

J.C.

You know what'd be really cool? It'd be great to be able to access any deep raster layer from any image field with some fancy syntax like:


mypic.exr
mypic.exr
mypic.exr