deepEXR integer ID range

[re:FORM]

Does anyone know what the usable range of values you can store in the objectID channel when used as integer values in a deepEXR?
I received an error attempting to set larger than 10 digits, but 9 appeared to work until the values that were returned in the render didn't match the object ID's
I'm curious to know what the actual limit is.
Thanks
p.

[vlado]

They are 32-bit integers, so the go from about 2 billion negative to 2 billion positive.

Best regards,
Vlado

[re:FORM]

Thanks Vlado,
That's what I thought, but when I've applied a VRay ObjectID with a value of, say, 431002022, to one object and an ID of 431002025 to another, when I open the deepEXR in nuke and inspect the relevant pixels with a deepSample node, there is only an ID of 431002016 applied to both objects.
I can't think of any setting that I might have set that might cause this issue, and none of the parent groups of these objects have any objectID attributes.

I've checked that my VRST output is set to 32-bit. Image format is set to exr(deep). Deep merge mode = z-depth. zDepth Threshold = 0.5 (I also tried 0.1)

The only unusual thing I am doing is setting the objectID via python script :

cmds.vray("addAttributesFromGroup", obj, "vray_objectID", 1)
obj.vrayObjectID.set(objID)

The ID is being applied to the object shape node.

Any ideas what the problem might be?
Unfortunately I can't send you a scene easily due to the network restrictions here.
Thanks again,

[re:FORM]

The only other curiousity is that the value that deepSample returns appears to be a float rather than integer; eg 431002016.0.
If there was another way to inspect the deepEXR to find out what the raw objectID value was in the file, then I could rule out if it's a nuke bug.

[t.petrov]

This is the default. If you want V-Ray to store integers in the openexr files you need to enable this in the image format options.
The setting is named 'Write Integer IDs'. It probably won't work for multi channel exr files.

[t.petrov]

This means that it won't work for deep exr files, because they are always written to multichannel exrs.

[re:FORM]

Hi t,
Thanks for the reply.

I thought "Write integer IDs" was a disregarded parameter if writing to a multi-layer EXR.... and as deepEXRs are by default multilayer, then I assume this parameter is ignored.

When you say "this is the default", do you mean that objectID is saved as float, and that you cannot save integer values to deepEXR?

If so, is the range then +200,000,000.0 to -200,000,000.0 not +- 2 billion as Vlado suggested?

[t.petrov]

Yes, the default is to store object_ids as floats.

The precision of 32bit floats is rather limited. You have something like 22 of precision. This means that you should be able to store numbers in the range of +-4194304 without loosing precision (the exponent will be 1).
But as far as I can see nuke still shows this values in scientific notation (4.1943e+06), so they are not very useful.

[re:FORM]

Thanks,
Yes, that begins to suggest I'm hitting that limit.

For your reference, in nuke, you can get the full ID without scientific notation using deepSample(); eg
objID = theNode.deepSample('objectId.deepObjID',x,y,-1))
where "objectId.deepObjID" is the name of the renderelement and channel of your objectID pass.
x and y are the coordinates to sample.
-1 specifies to return the sample closest to the camera.
theNode is a reference to the node calling this code.

[t.petrov]

Thanks for the hint, I've been using the deepsample node, but I'm only looking at the ui, which uses scientific notation.

[t.petrov]

The person that is familiar with our image writer code is at siggraph at the moment,
but when he comes back I'll make sure to find an explanation why we have this restriction.
Probably it is nuke/openexr restriction, we couldn't do much about, but this is just a guess at the moment.

[re:FORM]

Thanks t,
I'm sure there's a very good reason!
I'll look forward to hearing the details.
Cheers
p.