10
$\begingroup$

I rendered a 80 frame test animation in jpeg format. Used Blender to create the movie. The output format is mp4. The bottom image shows the first of the rendered image on the left extreme. The image at the center in the snapshot from the video rendered using those frames. The last one on the right is the snapshot of the video rendered as another video (did it to combine multiple videos).

enter image description here

How to avoid these gradient bands?

PS:This is regarding rendering of video using video sequence editor. I tried out increasing dithering value till 2, but still the bands are appearing in the rendered video

Improve this question
$\endgroup$
  • $\begingroup$ @RayMairlot-I am getting the problem after rendereing the images through the video sequence editor. Not while rendering. And then importing the video in the sequence editor makes it even more stronger $\endgroup$ – karthikeyan May 1 '15 at 12:27
  • $\begingroup$ @RayMairlot Will try out the suggestions given in the question you have mentioned... $\endgroup$ – karthikeyan May 1 '15 at 12:28
  • $\begingroup$ @RayMairlot tried out increasing the dithering value but still the same result. And please check out the edits... $\endgroup$ – karthikeyan May 1 '15 at 12:53
  • 1
    $\begingroup$ You are rendering using a highly compressed, lossy, 8 bit format (jpeg). Try rendering the image sequence a 16bit lossless format the first time (like PNG or TIFF). 8 bits (256 tones per color channel) is not enough when it comes to subtle gradients. With 16bit images you get 56 536 tones. Also increasing the bitrate for your output file might make a big difference. $\endgroup$ – user1853 May 1 '15 at 15:29
  • 1
    $\begingroup$ See if my dithering answer solves your question. $\endgroup$ – David Jan 3 '16 at 23:40
11
$\begingroup$

Sadly, there isn't enough information in your post to provide you with a conclusive answer. However, the following should help to illuminate some of your issues.

Background

When you are rendering to a codec, the codec shifts the color encoding scheme from RGB to another format typically. In most instances this is a YCbCr schema, which provides one channel for luminance, and two channels to describe the color, or chromaticity, of the pixel value.

Most codecs are designed for low bandwidth and small file sizes. In order to achieve this, they will compress and scale portions of the data to make the result fit into the designed constraints. Within the realm of YCbCr, our visual systems have learned to pay more attention to luminance over chrominance. In codecs where data size is an issue, engineers leverage this perceptual trick and more greatly compress the chrominance, or the Cb and Cr planes, as compared to the luminance plane, or Y.

Knowing that typically all three planes are compressed in a codec, and coupling that with understanding that the Cb and Cr planes are even more greatly compressed, we can begin to understand why posterization occurs in encoded formats. The more greatly compressed the stream, the greater degree of posterization.

Ultimately, even when given a well encoded RGB image at eight bits per channel, an encoded motion picture format will more often than not degrade this acceptable level of encoding to a point where it may be unacceptable given some contexts. Gradients are one example that will exacerbate this phenomena.

So how to avoid posterization? The most ideal way is to encode to an uncompressed RGB display referred still image format, and then leverage an external encoding tool that permits you to control the YCbCr stream details. With a decent set of encoding parameters including bitrate and compression level, you should be able to pull the posterization into acceptable levels for eight bit motion picture presentations.

Enough of that, what damn codec?

So even if someone is telling you to try a "lossless" encode, while it will try to maintain accuracy, will still include a conversion to YCbCr and likely some scaling at the very least, which will not be lossless when comparing to the source RGB format. If you use a codec that remains in the RGB domain, you are avoiding one transformation, but even then, you will be likely quantizing your image.

Remember too that not all codecs may be decoded at all or correctly when your content arrives at the destination you choose, so use caution. This includes middle layer services such as YouTube, Vimeo, etc., that will more than likely re-encode your material yet again, subject to another entire set of mistakes and encoding problems.

With the above caveats, the following options direct out of Blender will likely be closer to what you were hoping:

  • HuffYUV. HuffYUV can deliver both YCbCr and RGB formats. I actually patched this portion of the code to remain in the RGB domain and as such, it will be closer to what you are seeing in the 8 bit display buffer output from Blender.
  • FFv1 will be a lossless encode, with the above caveats of YCbCr transforms and quantization. Test to be sure.
  • H264 lossless should be a losseless encode, with the above caveats of YCbCr transforms and quantization. Test to be sure.

If anyone would like help on how to test if an encode went correctly, it would be useful if a new question was posted. This would allow for a proper response.

Improve this answer
$\endgroup$
  • 2
    $\begingroup$ So what codec and what video format to use in video sequence editor to prevent the gradient banding? Thanks a lot for explaining the video compression effects $\endgroup$ – karthikeyan May 3 '15 at 11:16
  • $\begingroup$ @karthikeyan Regarding codecs and encoding, there is no one - size - fits - all solution. Some encodes are done shot per shot. In the end, BINAE; Blender Is Not An Encoder. Render to RGB stills and use an external encoder to control the quality. $\endgroup$ – troy_s May 17 '15 at 16:53
  • $\begingroup$ Check also the dither value, under post processing. When set to 0, it produces color banding, and for 1, color banding are gone. $\endgroup$ – Samih EL SAKHAWI Jul 29 '20 at 17:01
  • $\begingroup$ Not gone. Dithered. Different issue. $\endgroup$ – troy_s Jul 29 '20 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.