Rendering Issue in Rhinoceros 7: Gradient Banding in Dark Areas

I have recently observed significant gradient banding issues within dark areas when using Rhinoceros 7 Rendered and Cycles Render. It appears that in the darkest quarter, there are merely five shades of grey (instead of 50), with the first shade commencing at around 90%, which isn’t utilizing the full spectrum of 256 colors.

Given that I use an OLED TV for display, I’m certain that the problem isn’t linked to monitor limitations, as these devices can portray a broader range of colors. The gradient banding issue is quite apparent and affects the overall visual quality of my renderings as shown in this video.

Does this issue originate from a limitation in Rhinoceros’ rendering system, or could there be some settings that need adjustment? Any insights would be much appreciated.

If it’s an 8 bit panel, it will still have banding issues, you need at least a 10 bit panel. 8 bit panels can only display 256 shades of gray

But what you show is in rendered mode, right, that’s a different issue:
RH-37275 Dark gray and black reflective materials show banding

Additionally, the Render output matches the Rendered display. I was adjusting the background; although this could be done in Rendering, I used a simpler method to demonstrate. While the Linear seems correct, it appears to be computed in a non-linear fashion, exhibiting fewer colors in the darker zones.

There is no banding on the color picker.
In industrial design, Black is often used like a tire, for example.

just to make sure we are talking about the same thing, left is the rendered result, right rendered display.

The OpenGL gets gamma corrected to more or less match the gamma corrected rendered result, and this is the cause of banding, which is most noticeable in dark shaded materials. It’s a known issue for which at present is no solution unfortunately.

Put differently: The banding is a result of gamma correcting an 8 bit linear image. In that linear image there are hardly any shades of gray to choose from, so once gamma correction gets applied, those differences get amplified.

Dear Rhinoceros Development Rendering Team,

Currently, the rendering pipeline uses a linear rendering approach, which is then converted to gamma space and back to a linear.

Buy Default 6bit dark zone

This conversion results in the loss of detail in darker areas of the render. It’s my understanding that this occurs due to the compression of blacks during the conversion process.

Not only does this lead to a reduction in the overall quality of the render (especially noticeable in darker areas), but it also presents a computational inefficiency. This process of double conversion - linear to gamma and then back to linear - could potentially be optimized to avoid unnecessary computing resource expenditure.

Actual 8bit dark zone

Rendering is done in linear color space. Textures, that are in general color corrected to display well on monitors, are gamma corrected.

These textures are converted to linear space during rendering time. This does not take any resources.
When the rendering is finished it’s still in linear space. You can decide to leave it that way, write it out as an hdr and do your color correction in linear space before applying gamma correction.

The banding you see in the viewport is an OpenGL limitation, for which I linked to the open YT item. This issue however does not affect final render quality. If you see banding in your final render, it’s because you’re hitting the limits of 8 bit colors.

And Rendered?

Cycles (Rhino Render and Raytraced) render in linear space with full floats.

In the viewport you’ll see banding, in the render window you’ll see there is no banding. The viewport has a technical limitation that the render window does not. There will be banding also for Raytraced until the technical limitation has been eliminated - that is something that Raytraced cannot do anything about.

Any gamma correction or other tone mapping is done after Rhino Render or Raytraced have done their thing, by Rhino.

Presume you must expand first and then compress instead of compressing and expanding.

I’m talking about rendering inside the viewport perspective.
The banding shown in the screenshot is in the Cycles Render viewport.
And also, with no banding is in the viewport, as shown in the screenshot.

Can it be that,
In your encoding, you are compressing first, you lose color quality cycles rendering quality, and when you expand, you decode the compression, which is visible, showing up as rendering banding?

In that case, taking about there render,
Presume you must expand first and then compress instead of compressing and expanding.

As mentioned, anything that goes into the viewport is bound by the limitations of the viewport.

Cycles renders always in linear space, no compression is going on.

If you need no banding, use _Render and save the results from the render window.

is not

Well, I have no clue what you are talking about then.

For Raytraced you’ll see banding in the viewport. Maybe not as much as Rendered mode. But to have absolute best results use _Render.

Double check this experiment.

I see dark and no gamma in use. No idea what display mode you are using. And what I am supposed to look for.

Whatever you think you are seeing: Cycles always renders in linear mode with full floats. Whatever happens to the results in the viewport (and in render window to be honest) is done by Rhino and is out of my hands.

This pixel buffer is floats coming out of Cycles.

This is the pixel buffer going into Rhino. Any conversion from floats to bytes is done in Rhino for the viewport. And is going to be amplified by any gamma correction. Done by Rhino.

1 Like

I will try to make a video or rhino file

This first image is essentially what Cycles gives, quite closely. Converted by Rhino to Bytes.

Gamma correction in viewport - applied by Rhino. Notice banding. Bytes.

Gamma correction in viewport - applied by Rhino. Notice banding. Bytes

Gamma correction in render window - applied by Rhino. Notice no banding. Floats.

1 Like

Exactly! As it is! Your first image is how I use it, because the default has banding.
It is very noticeable when you make a tire, for example.

I was doing the same but using a texture to double-check.


Here is Rhino by default

And here is how I use it (Pure Cycles)

I also, in my small experience, do not use the _render window. Or if the case in Filmic medium

My presumption was wrong; you were correct about this viewport limitation.
It probably is possible to make it darker using the default, and if I level up, I get the same banding. I do not know if that is possible. But get a better result as a workaround than the default.

But when I go to Photoshop and I level up the image (if I need it at all) there are no banding

Also, by the way, there is this issue that is not updating and you get a third option that confuses the user. That is another issue.