Deadline Version: 7.2.0.16 R
1: I submit an image with all render elements enabled.
2: change one object
3: submits a region of that object
4: uses “Compose Over CUSTOM SINGLE Image”
I end up with an .exr that’s 2x the size (almost) of the original file, and 2 of my elements are “wrong”
VRayRenderID (colored in the original - white in the new)
[VRayObjectID] (colored in the original - white in the new)
here are links to the .exr files:
exchange.cadesignform.dk/Deadlin … iginal.exr
exchange.cadesignform.dk/Deadlin … Region.exr
exchange.cadesignform.dk/Deadlin … Output.exr
hope this makes sense?
Hi there,
I’m very sorry you are experiencing problems. I believe your two issues are related.
The one thing you need to know is that Draft writes all his EXR files using FLOAT pixel type (which corresponds to how Draft handles data internally). So here’s what’s happening in your case. Almost all of the channels in your original image are of pixel type HALF, and two of them are of pixel type UINT (the ID element VRayRenderID and VRayObjectID). Draft is writing them all back to file, after assembly, using FLOAT pixel type. (You can look at both the original and the Draft output in Nuke and you will see that the actual values 1, 2, 3, … are preserved.)
This explains why your file size has doubled and I’m guessing that VRay can’t recognize those ID elements stored in the file as FLOAT, since it is expecting UINT channels.
Handling bitDepth correctly is on our current TODO list. This should happen relatively soon, sometime during Deadline 8 beta cycle…
Again, I’m very sorry for the inconvenience.
Julie
thanks for the quick reply… ill make sure that people use 32bit float if they wish to use this feature, until it works with 16bit 