Corona Sky Color Banding issue

[JuL]

Hi there,

Is the Corona dev team still investigating about the color banding issue on corona sky map ?
If so, can you share some informations because for now on that feature as become nearly useless (unless a lot of time-consuming post production...).

Thanks for you feedback

(image produced in 3ds max 2025.3 / Corona 13)

[pokoy]

Are you saving to a file that only supports 8 bits? In that case it's expected, as there are too few numeric values to represent a smooth transition in 8 bits. The only thing that'll help in that case is adding some noise. You should see no banding if you save to a format that supports 16 bits or more, e.g. 16 bits TIF or EXR.

[JuL]

Hi and thanks for your reply,
Unfortunately these bandings appears also on 32 bits .exr saved files, the attached jpg was just a lighter way to show the issue.

[pokoy]

I don't think it can be avoided since you're probably going to deliver it in 8 bits anyway. Try adding noise/grain to the image or background, it should help.

[zeropluszero]

Hello, i am facing the exact same issue, and that is very, very, annoying :)
To add some precisions, saving the file in 16/32 bit EXR and then convert it from a software to a 8 bit jpg works, you dont have those "bandings".
But for an unknown reason, while the VFB is in 32bit, saving it directly to the jpg create them ....
Would any dev be able to have a look, hoping the VFB could behave just like a "photoshop's like" program and cleanly convert to 8bit ?
Or maybe we dont understand well the issue there ?
In any case, that is really an issue making procedurals, and especially corona skies, useless.

Thanks in advance !

edit : here's an example, on the left, the image is saved straight to 8bit from the VFB, on the right converted 16bit to 8bit ... so no "8bit" issue there ...

[romullus]

Would any dev be able to have a look, hoping the VFB could behave just like a "photoshop's like" program and cleanly convert to 8bit ?
Or maybe we dont understand well the issue there ?

Actually Photoshop is doing opposite of "clean" convert, the reason you don't see the banding after converting the image from 16 bit to 8 bit is because Photoshop is adding some noise (it's called dither). If you'd adjust levels on converted image, you can see that banding is largely still there, but is masked by noise, which makes the banding almost imperceptible to human eye.

[JuL]

Hi Romullus,

Well PS is doing it quite good as it becomes almost invisible...

However, at the risk of seeming rigid about it i would like to understand the bigger picture behind this banding effect's reason as we are talking of a 32 bits/channel procedural map processed in a render engine with wide RGB gammut if i am correct ?

[romullus]

Well PS is doing it quite good as it becomes almost invisible...

Nobody says it doesn't. Introducing dither to mitigate colour banding effect in smooth gradients is nothing new and it's pretty good at that. Just to be clear that banding is not Corona's fault, it doesn't occur at rendering stage, but it's rather a consequence of converting higher bit depth image to a lower one.

[pokoy]

What romullus says.
Consider this - in the upper part of the image, the gradient goes across a brightness range of let's say about 30 integer steps (in 8 bits) over a distance of 1200 pixels, so you get bands of 30-40 pixels for each value.
For 16 bits, multiply those integer steps by a factor of 256. These 30-40 pixel bands now have 256 steps to represent a value, more than enough.

Not sure how to calculate 32 bits from that because float supports range outside of 0-1, but let's say it'll be even more steps.

[zeropluszero]

Thanks for the information Romullus, but from an artistic point of view, dithering or not, the present behaviour is not satifying at all ! I am quiet surprised that there aren't many users reporting this as it might affect almost everyone.
I sincerly hope Corona's team will work on a solution to provide some clean, smooth skies quickly :)

Cheers

[pokoy]

By that you mean adding dither to the Sky map? Head over to the Ideas portal and create an entry for that, I don't think support people follow every thread closely.

I suggest working in 16 bits at minimum *always*. It'll allow you to produce clean results especially when using high resolutions, fine gradients, contrasts and color shade changes in post production etc as you'll have a much larger numerical resolution to work with. Yes, it's using more disk space, yes, it's a bit slower in PS but if you work in 8 bits you're neglecting basic solutions to a decades old problem. That's one reason why video/comp apps default to 32 bits nowadays and offered full 16/32 bits workflows since 20+ years.

There's an old bit of wisdom in music production that goes 'don't fix in the mix', which applies to basically any signal processing pipeline.