<p>You are indeed right about shades of grey. You're encoding in 8-bit 4:2:0 (standard h.264 settings) which means that there are only 256 possible shades of grey. Think about it. If your RGB* values go from <strong>[0, 0, 0]</strong> to <strong>[255, 255, 255]</strong> and the red green and blue channels are equal, because grey, then your pixels will be one of these values: <strong>[0,0,0], [1,1,1], [2,2,2]… [255,255,255]</strong>. Meaning 256 possible colours. </p>

<p>If your gradient went from full black to full white and was 256 pixels across there would be one pixel per colour, so you'd be fine. But if it was say, 1024px wide, then there would have to be four pixels of each colour next to each other, meaning bands. And that's a gradient going from full black to full white—a subtle gradient from 45% grey to 55% grey might only have 25 possible values available–it's going to be banding city.</p>

<p>And just to explain what is going on in your image–especially in the middle–there's an <a href="https://en.wikipedia.org/wiki/Mach_bands" rel="nofollow noreferrer">unfortunate optical illusion</a> that makes those bands super obvious, by making the squares where the same colour is repeated look like gradients going the opposite way.</p>

<p>Two possible workarounds:</p>

<ul>
<li><p>You can <a href="https://video.stackexchange.com/questions/13164/encoding-422-in-10-bit-with-libx264">encode using 10 bit h.264</a>, but a lot fewer people will be able to play it back, and you'll need to get a <a href="https://sourceforge.net/projects/ffmpeg-hi/" rel="nofollow noreferrer">10 bit build</a> of ffmpeg or x.264 (I don't know of any other 10-bit h.264 software)</p></li>
<li><p>You can add some noise. Sounds crazy, but it will break up the bands into fuzz so they'll be less noticeable. Justify it to yourself by believing it gives it a more filmy look. It's called dithering, it was a big thing back in the days of 8-bit colour.</p></li>
</ul>

<p>*Actually it's <a href="https://en.wikipedia.org/wiki/YUV" rel="nofollow noreferrer">YUV</a>, but that's not important right now.</p>

CC BY-SA 3.0
2017-08-11T08:08:22.650Z
Thanks for a detailed answer. I plan to use this clips on youtube, which uses h.264 encoding. I haven't been able to identify how many bits they use for color encoding https://support.google.com/youtube/answer/1722171?hl=en. I am using cinema 4d to redner this clips. There is a checkbox: enable 8-bit dithering, and it is already turned on.
sanjihan
CC BY-SA 3.0
2017-09-23T05:02:08.133Z
Youtube will be 8-bit. Browsers don't yet support 10-bit  h.264. I'm not sure about the cinema4d thing, but you might want to try extra noise in post.
stib
CC BY-SA 3.0
2017-08-11T04:41:25.303Z
2017-09-23T04:58:17.867Z
2017-09-23T04:58:17.867Z
stib
<p>I am using handbrake to compress 250mb of 3d animation stored in .mov. This is how the mov looks:</p>

<p><a href="https://i.sstatic.net/STGkO.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/STGkO.png" alt="enter image description here"></a></p>

<p>The compressed version has some artifacts. Like it doesn't have enough shades of grey:</p>

<p><a href="https://i.sstatic.net/2kKVN.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/2kKVN.png" alt="enter image description here"></a></p>

<p>How can I avoid that? Should I render in a .mov file in the first place? </p>

CC BY-SA 3.0
2017-08-08T07:20:42.737Z
You need to remember that compressing is "Lossy" and you are removing information to make it smaller.
Adam Mann Pro
CC BY-SA 3.0
2017-08-08T07:25:04.797Z
Is there some compression method for video that would be suitable for what I am trying to achieve?
sanjihan
CC BY-SA 3.0
2017-08-08T07:26:58.880Z
well the best quality is going to be what you export from. have you tried exporting using a different codec from the app you are using ? Otherwise you can play with the settings (bit rate mainly I believe) in handbrake to achieve a better result
Adam Mann Pro
<video-quality><compression>
mov to mp4 conversion produces grainy results
sanjihan
# mov to mp4 conversion produces grainy results

(Asked by: username_0 on 2017-08-07)

I am using handbrake to compress 250mb of 3d animation stored in .mov. This is how the mov looks:

[![enter image description here](https://i.sstatic.net/STGkO.png)](https://i.sstatic.net/STGkO.png)

The compressed version has some artifacts. Like it doesn't have enough shades of grey:

[![enter image description here](https://i.sstatic.net/2kKVN.png)](https://i.sstatic.net/2kKVN.png)

How can I avoid that? Should I render in a .mov file in the first place?

**Tags:** video-quality, compression

> **Comments:**
> **username_1**: You need to remember that compressing is "Lossy" and you are removing information to make it smaller.  
> **username_0**: Is there some compression method for video that would be suitable for what I am trying to achieve?  
> **username_1**: well the best quality is going to be what you export from. have you tried exporting using a different codec from the app you are using ? Otherwise you can play with the settings (bit rate mainly I believe) in handbrake to achieve a better result  

---

## 1 answers

### Answer by username_2 on 2017-08-11. Score: 1 | Accepted answer

You are indeed right about shades of grey. You're encoding in 8-bit 4:2:0 (standard h.264 settings) which means that there are only 256 possible shades of grey. Think about it. If your RGB\* values go from **[0, 0, 0]** to **[255, 255, 255]** and the red green and blue channels are equal, because grey, then your pixels will be one of these values: **[0,0,0], [1,1,1], [2,2,2]… [255,255,255]**. Meaning 256 possible colours.

If your gradient went from full black to full white and was 256 pixels across there would be one pixel per colour, so you'd be fine. But if it was say, 1024px wide, then there would have to be four pixels of each colour next to each other, meaning bands. And that's a gradient going from full black to full white—a subtle gradient from 45% grey to 55% grey might only have 25 possible values available–it's going to be banding city.

And just to explain what is going on in your image–especially in the middle–there's an [unfortunate optical illusion](https://en.wikipedia.org/wiki/Mach_bands) that makes those bands super obvious, by making the squares where the same colour is repeated look like gradients going the opposite way.

Two possible workarounds:

* You can [encode using 10 bit h.264](https://video.stackexchange.com/questions/13164/encoding-422-in-10-bit-with-libx264), but a lot fewer people will be able to play it back, and you'll need to get a [10 bit build](https://sourceforge.net/projects/ffmpeg-hi/) of ffmpeg or x.264 (I don't know of any other 10-bit h.264 software)
* You can add some noise. Sounds crazy, but it will break up the bands into fuzz so they'll be less noticeable. Justify it to yourself by believing it gives it a more filmy look. It's called dithering, it was a big thing back in the days of 8-bit colour.

\*Actually it's [YUV](https://en.wikipedia.org/wiki/YUV), but that's not important right now.

> **Comments:**
> **username_0**: Thanks for a detailed answer. I plan to use this clips on youtube, which uses h.264 encoding. I haven't been able to identify how many bits they use for color encoding https://support.google.com/youtube/answer/1722171?hl=en. I am using cinema 4d to redner this clips. There is a checkbox: enable 8-bit dithering, and it is already turned on.  
> **username_2**: Youtube will be 8-bit. Browsers don't yet support 10-bit  h.264. I'm not sure about the cinema4d thing, but you might want to try extra noise in post.  

---

