<p>The colorspace and colormatrix filters don't handle alpha pixel formats, so those get stripped off. The workaround is to extract the alpha and then reattach it.</p>

<p><code>ffmpeg -f image2 -framerate 24.0 -i tif_w_alpha.%3d.tif -filter_complex "[0]colorspace=all=bt709:range=pc:format=yuv444p10:iall='bt601-6-625':irange=pc[main];[0]alphaextract,format=gray10le[alpha];[main][alpha]alphamerge" -c:v prores_ks -profile:v 5 -pix_fmt yuva444p10le -alpha_bits 16 this_has_no_alpha_channel.mov</code></p>

<p>BTW, The Quicktime specification doesn't accommodate output range <code>pc</code>. Consumers should expect to treat range as always <code>tv</code>. If your software allows to override that, nice, but other software may not.</p>

CC BY-SA 4.0
2019-08-06T14:32:15.930Z
Thanks.  Not using quicktime for this data.  The software I will be using handles it fine.  Not sure you can even do anything with alpha inside the quicktime app.
Shao Zhang
CC BY-SA 4.0
2019-08-06T16:26:49.800Z
Got it working, thanks!
Shao Zhang
CC BY-SA 4.0
2019-08-06T16:38:06.873Z
Why did you change the filter ordering?
Gyan
CC BY-SA 4.0
2019-08-06T17:19:17.527Z
The ordering you originally posted caused my encode to hang on the last frame.  Killing the process just produced a corrupt file.  Switching the ordering fixed it and produced a correct color and alpha prores file.
Shao Zhang
CC BY-SA 4.0
2019-08-06T17:54:59.923Z
That should not make a difference. Share full log.
Gyan
CC BY-SA 4.0
2019-08-06T19:25:22.197Z
If you can, share the images.
Gyan
CC BY-SA 4.0
2019-08-06T19:33:17.567Z
Here are full logs of a successful encode and a hung encode as well as a single source frame (they're heavy) on [google drive](https://drive.google.com/open?id=14ilVwS6nT9buUTgszYWd4G3McR7pkRmR)
Shao Zhang
CC BY-SA 4.0
2019-08-07T11:51:10.877Z
Can't reproduce hang here. Version is N-94391. Upgrade and check.
Gyan
CC BY-SA 4.0
2019-08-07T18:11:44.383Z
Thanks for checking.  Not a blocking issue on my end so I'll check and update once I upgrade.
Shao Zhang
CC BY-SA 4.0
2019-08-06T08:13:55.447Z
2019-08-06T16:37:38.177Z
2019-08-06T16:37:38.177Z
Gyan
<p>So I've figured out how to convert images to prores with no colorspace shifts using either:</p>

<p><code>-vf colormatrix=bt601:bt709</code> filter for 8bit material</p>

<p>and</p>

<p><code>-vf colorspace=all=bt709:range=pc:format=yuv444p10:iall='bt601-6-625':irange=pc</code> filter for 8bit or 10bit material.</p>

<p>However, whenever I use <code>colormatrix</code> or <code>colorspace</code> filters the output file contains no alpha channel.  As soon as I remove these filters the alpha channel is present but now I've got a color shift.</p>

<pre><code>#this generates no alpha
ffmpeg -f image2 -r 24.0 -i tif_w_alpha.%3d.tif -c:v prores_ks -profile:v 5 -pix_fmt yuva444p10le -vf colorspace=all=bt709:range=pc:format=yuv444p10:iall='bt601-6-625':irange=pc -alpha_bits 16 this_has_no_alpha_channel.mov

#this has alpha but also a color shift
ffmpeg -f image2 -r 24.0 -i tif_w_alpha.%3d.tif -c:v prores_ks -profile:v 5 -pix_fmt yuva444p10le -alpha_bits 16 this_has_alpha.mov
</code></pre>

<p>This behavior is the same in both -profile:v 4 and 5 which are the only 2 that support alpha.  How can I get the color filter to work without losing the alpha channel?</p>

<ffmpeg><prores><colorspace><alpha>
ffmpeg prores alpha channel not present when colormatrix and colorspace operations are performed
Shao Zhang
# ffmpeg prores alpha channel not present when colormatrix and colorspace operations are performed

(Asked by: username_0 on 2019-08-06)

So I've figured out how to convert images to prores with no colorspace shifts using either:
-vf colormatrix=bt601:bt709 filter for 8bit material
and
-vf colorspace=all=bt709:range=pc:format=yuv444p10:iall='bt601-6-625':irange=pc filter for 8bit or 10bit material.
However, whenever I use colormatrix or colorspace filters the output file contains no alpha channel.  As soon as I remove these filters the alpha channel is present but now I've got a color shift.
#this generates no alpha
ffmpeg -f image2 -r 24.0 -i tif_w_alpha.%3d.tif -c:v prores_ks -profile:v 5 -pix_fmt yuva444p10le -vf colorspace=all=bt709:range=pc:format=yuv444p10:iall='bt601-6-625':irange=pc -alpha_bits 16 this_has_no_alpha_channel.mov

#this has alpha but also a color shift
ffmpeg -f image2 -r 24.0 -i tif_w_alpha.%3d.tif -c:v prores_ks -profile:v 5 -pix_fmt yuva444p10le -alpha_bits 16 this_has_alpha.mov

This behavior is the same in both -profile:v 4 and 5 which are the only 2 that support alpha.  How can I get the color filter to work without losing the alpha channel?

**Tags:** ffmpeg, prores, colorspace, alpha


---

## 1 answers

### Answer by username_1 on 2019-08-06. Score: 1 | Accepted answer

The colorspace and colormatrix filters don't handle alpha pixel formats, so those get stripped off. The workaround is to extract the alpha and then reattach it.

`ffmpeg -f image2 -framerate 24.0 -i tif_w_alpha.%3d.tif -filter_complex "[0]colorspace=all=bt709:range=pc:format=yuv444p10:iall='bt601-6-625':irange=pc[main];[0]alphaextract,format=gray10le[alpha];[main][alpha]alphamerge" -c:v prores_ks -profile:v 5 -pix_fmt yuva444p10le -alpha_bits 16 this_has_no_alpha_channel.mov`

BTW, The Quicktime specification doesn't accommodate output range `pc`. Consumers should expect to treat range as always `tv`. If your software allows to override that, nice, but other software may not.

> **Comments:**
> **username_0**: Thanks.  Not using quicktime for this data.  The software I will be using handles it fine.  Not sure you can even do anything with alpha inside the quicktime app.  
> **username_0**: Got it working, thanks!  
> **username_1**: Why did you change the filter ordering?  
> **username_0**: The ordering you originally posted caused my encode to hang on the last frame.  Killing the process just produced a corrupt file.  Switching the ordering fixed it and produced a correct color and alpha prores file.  
> **username_1**: That should not make a difference. Share full log.  
> **username_1**: If you can, share the images.  
> **username_0**: Here are full logs of a successful encode and a hung encode as well as a single source frame (they're heavy) on [google drive](https://drive.google.com/open?id=14ilVwS6nT9buUTgszYWd4G3McR7pkRmR)  
> **username_1**: Can't reproduce hang here. Version is N-94391. Upgrade and check.  
> **username_0**: Thanks for checking.  Not a blocking issue on my end so I'll check and update once I upgrade.  

---

