user25860: Unless I'm bad at reading, this page states that colormatrix is only good for 8 bpc.
From Colorspace support in FFmpeg:

... colormatrix produces horrible quality for anything > 8bpc (8-bit per component)

Backstory.  One of my typical workflows is to convert 16bit tiffs and 10bit DPX frames into 10bit prores.  However, I think the input colorspace of the frames is assumed to be bt601 and I would always get encodes that looks just slightly off from my originals.  I solved this by adding:
-vf colormatrix=bt601:bt709
And it looks fine visually.  The difference between the source and encode I always just assumed was the lossy compression.
So can someone chime in on if the colormatrix=bt601:bt709 operation is 'supposed' to be bad when the source and encode are >10bpc?  Or is the info on that page outdated?  Or should I be doing it a different way?

user1871: Yes, as it says a couple of lines above, colormatrix supports only 8bpc (8-bit per component) pixel formats. So, when a 16-bit input is filtered with colormatrix, it will be converted to 8-bits. And won't get converted back to 16-bit unless manually done or auto-converted due to output encoder limitations. But that's pointless anyway, as the precision has been lost.
Use the colorspace filter.
-vf colorspace=all=bt709:range=tv:format=yuv422p10:iall=bt601:irange=tv

Depending on your use case, format may need to be yuv444p10. Depending in your input, irange may need to be pc.

25860: <p>Unless I'm bad at reading, this page states that colormatrix is only good for 8 bpc.</p>

<p>From <a href="https://trac.ffmpeg.org/wiki/colorspace" rel="nofollow noreferrer">Colorspace support in FFmpeg</a>:</p>

<blockquote>
  <p>... colormatrix produces horrible quality for anything > 8bpc (8-bit per component)</p>
</blockquote>

<p>Backstory.  One of my typical workflows is to convert 16bit tiffs and 10bit DPX frames into 10bit prores.  However, I think the input colorspace of the frames is assumed to be bt601 and I would always get encodes that looks just slightly off from my originals.  I solved this by adding:</p>

<p><code>-vf colormatrix=bt601:bt709</code></p>

<p>And it looks fine visually.  The difference between the source and encode I always just assumed was the lossy compression.</p>

<p>So can someone chime in on if the <code>colormatrix=bt601:bt709</code> operation is 'supposed' to be bad when the source and encode are >10bpc?  Or is the info on that page outdated?  Or should I be doing it a different way?</p>
 1871: <p>Yes, as it says a couple of lines above, <code>colormatrix supports only 8bpc (8-bit per component) pixel formats</code>. So, when a 16-bit input is filtered with colormatrix, it will be converted to 8-bits. And won't get converted back to 16-bit unless manually done or auto-converted due to output encoder limitations. But that's pointless anyway, as the precision has been lost.</p>

<p>Use the colorspace filter.</p>

<pre><code>-vf colorspace=all=bt709:range=tv:format=yuv422p10:iall=bt601:irange=tv
</code></pre>

<p>Depending on your use case, format may need to be <code>yuv444p10</code>. Depending in your input, irange may need to be <code>pc</code>.</p>
