When I render in Solaris with Karma both CPU and XPU, my EXR files are always 16bit float. How do I change it to 32 bit. I looked everywhere I can think of.

The bit depth is specified by the format attribute on the rendervars. For 16 bit use half precision, (half3, half, color3h, color4h). For 32 bit use full precision, (float, float3, color3f, color4f)

With the karma render properties or karma standard vars nodes, the bit depth made accessible in a dropdown by each var. Unfortunately, the all-in-one Karma node doesn't expose the bit depth selection.

Thanks for the reply.
So I created an edit_Beauty node below the Karma node where I changed it to float3. When I inspect the image in DJV (which I use to review EXR) it still says F16 so seems like float 16 to me.
Did I do something wrong?
Cheers

So the only way I have managed to solve this is to add an Extra Render Vars, for example in the Render Node. Then I have to name a new var, for example I can call it Color, then I switch to color4f. This will result in 32bit float.

But why on EARTH do they render in 16bit by default. That is pretty much NEVER something you want when you render an image.

Is it possible to instead of adding a new render var Color I can actually change C to be 32bit instead. I could not replace it even though I tried.

Why? Because in production, 16bit hlaf float contains more than enough range to store rendered images.
Using 32bit is absolute overkill for the RGB, not sure where you got the NEVER something you want impression from, as
pretty much as the exr standard was released, it was recommended, and tested, to use 16 bit half float for rendered images.

That's been the default output in every studio, zero benefit to wearing the cost of 32bit. You keep 32bit for Data AOVs
such a position, Z-depth, ones that will cause issues when used in Comp due to accuracy, but your component AOVs of your
Beauty, Diffuse, Ref, Refract, SSS, etc are all fine at 16 bit.

I would assume they made it the default, because that is what everyone in the Industry is outputting.

Hi Tinyhawkus.
Thanks, I did not know that, I was just a bit frustrated Myself I sometimes have very bright fire or very thin alpha on volumes, and for 16bit the data will actually not be enough in compositing. Also we render quite short sequences so the data size is not such a big problem.

Do you know how to setup Karma so the C is actually 32bit? As I mentioned I have to create a new Color to make it possible but seems a bit wasteful. It complains that I have multiple image planes called C if I add it and I cannot find a way to overwrite it.

Edit. I think I cracked it, just disable the beauty pass. Then there seems to be no collision when I create the C. Should I use Color4f? as the type for 32bit?
Thanks,
Andreas

AndreasOberg
Thanks, I did not know that, I was just a bit frustrated Myself I sometimes have very bright fire or very thin alpha on volumes, and for 16bit the data will actually not be enough in compositing. Also we render quite short sequences so the data size is not such a big problem.

float 16 has a max value of 65504 and a minimum normal value of ~6.1e-5, with 1024 subnormal values going down to 5.96e-8. Is that not enough range for a beauty render?

Edit: fyi karma clamps to 10 by default, so you'll never see values that high unless you turn off the primary ray clamping.

jsmack
float 16 has a max value of 65504 and a minimum normal value of ~6.1e-5, with 1024 subnormal values going down to 5.96e-8. Is that not enough range for a beauty render?

Edit: fyi karma clamps to 10 by default, so you'll never see values that high unless you turn off the primary ray clamping.

Just rendering out a test with 32 bit so will compare the results to the 16 bit and see what difference there is.
I do a lot of compositing afterwards and sometimes we can have extremely thin alpha values or very bright fire values, but we actually want to change it a lot in post. Without even looking at the bit depth when i was comping I actually noticed that changes were not responding as well as I was used to. I though "hmm, this fire does not behave that well when I reduce the gamma, I see some posterisation, what is going on" and then "ah, its 16 bit and not 32".

So after the test has finished rendering I can see how this smoke behaves.

Andreas,

You'll find almost every VFX Studio uses 16bit. We certainly do at Method Studios, and have never had an issue compositing fire,
smoke, and all manner of other things pushing high values. If you are generating insane values, then I'd be looking at your shader
setups in Karma/Mantra because you shouldn't be spitting out things that crazy.

L

I tested on this smoke that I rendered, and I cannot see any change at all. 16bit and 32 bit looks completely identical even after they have been graded. So no point for that texture. It also makes me wonder if 32bit really has more data in these files since they are completely identical looking.

And yes you are right if the values are extreme then the materials are setup the wrong way. I had a case in Mantra where I rendered out a fire and it looked fine in Houdini, but it was extremely bright in Fusion. So something must have happened there, normally that is not the case but I'm quite new to Karma.
I can say one case where 32bit HAS mattered and that was when we render skyboxes in Terragen. The sun and the highlights of the sky did not do well in 16bit.

I will do some more tests, maybe render that fire out again.
Cheers,

Hi there;

I would like to render an image where pixel value represents absolute LUX in my scene. I'm running into odd apparent clamping issues that led me to this thread. @andreas, I'm curious where you landed with this, and/or what the most direct path to getting unclamped 32-bit float images is? I don't, for example, see a parameter called "Primary ray clamping", and it's not clear to me how to disable this behavior.

dhemberg
I would like to render an image where pixel value represents absolute LUX in my scene. I'm running into odd apparent clamping issues that led me to this thread. @andreas, I'm curious where you landed with this, and/or what the most direct path to getting unclamped 32-bit float images is? I don't, for example, see a parameter called "Primary ray clamping", and it's not clear to me how to disable this behavior.

The clamp is called 'color limit' and it affects both direct and indirect sampling. There is an option to set the indirect limit independently. I'm not sure it can be disabled, but the color limit can be set arbitrarily high.

Thank you! Confirming, for any intrepid explorer who might chance across this thread in the future, that raising the Color Limit parameter indeed fixed my issue (which had the appearance of a 16-bit/32-bit problem, but was in fact this clamping thing in my case).