Answers.Body: <p>I believe the problem lies in how FFMPEG does the RGB->YUV conversion by default.  This option specifies the use of the bt709 color space for the conversion, instead of the default of bt601.  This fixes it for me - though please let me know if I'm doing something bad here!</p>
  
  <pre><code>-vf scale=out_color_matrix=bt709
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-24T16:28:01.523Z
Answers.Text: 709 is default for HD, 601 for SD.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-24T15:42:12.807Z
Answers.LastActivityDate: 2016-03-24T15:42:12.807Z
Answers.UserDisplayName: Bryan Fordney
Body: <p>I am attempting to encode "ProRes 4444" movies with ffmpeg.  Some research led me to the "prores_ks" encoder, which is the only one of ffmpeg's prores encoders that supports "4444".</p>
  
  <p>I used this command to test it out (input excluded):</p>
  
  <pre><code>-c:v prores_ks -f mov -profile:v 4444 test.mov
  </code></pre>
  
  <p>This produces a ProRes 4444 movie.  However, the colors appear darker than the original input.  After some research I came upon this option:</p>
  
  <pre><code>-vf colormatrix=bt601:bt709
  </code></pre>
  
  <p>Adding this filter seems to fix the problem.  However, the file size is for some reason considerably bigger.  Also, I do not like the idea that a filter has to be performed during this encoding, as I want the highest possible quality.  Does anyone know of a way to overcome this "color shift" without a video filter?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-29T22:31:50.740Z
Comments.Text: The input is a PNG sequence.
Comments.UserDisplayName: Bryan Fordney
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-01T17:15:51.140Z
Comments.Text: I've tried both 8 and 16 bit, out of After Effects.  Here's a PNG and a MOV made with ffmpeg, using command `ffmpeg -r 24 -i colorbars_8bit.png -c:v prores_ks -profile:v 4444 colorbars_prores_ks.mov`: https://file.io/SeKH8I
Comments.UserDisplayName: Bryan Fordney
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-01T18:01:47.153Z
Comments.Text: Interestingly, Natron's "WriteFFmpeg" module does not seem to have this problem.
Comments.UserDisplayName: Bryan Fordney
Tags: <ffmpeg><quicktime><prores>
Title: FFMPEG prores_ks 4444 color shift
UserDisplayName: Bryan Fordney
ThreadText: # FFMPEG prores_ks 4444 color shift
  
  (Asked by: username_0 on 2016-02-18)
  
  I am attempting to encode "ProRes 4444" movies with ffmpeg. Some research led me to the "prores\_ks" encoder, which is the only one of ffmpeg's prores encoders that supports "4444".
  
  I used this command to test it out (input excluded):
  
  ```
  -c:v prores_ks -f mov -profile:v 4444 test.mov
  
  ```
  
  This produces a ProRes 4444 movie. However, the colors appear darker than the original input. After some research I came upon this option:
  
  ```
  -vf colormatrix=bt601:bt709
  
  ```
  
  Adding this filter seems to fix the problem. However, the file size is for some reason considerably bigger. Also, I do not like the idea that a filter has to be performed during this encoding, as I want the highest possible quality. Does anyone know of a way to overcome this "color shift" without a video filter?
  
  **Tags:** ffmpeg, quicktime, prores
  
  > **Comments:**
  > **username_0**: The input is a PNG sequence.  
  > **username_0**: I've tried both 8 and 16 bit, out of After Effects.  Here's a PNG and a MOV made with ffmpeg, using command `ffmpeg -r 24 -i colorbars_8bit.png -c:v prores_ks -profile:v 4444 colorbars_prores_ks.mov`: https://file.io/SeKH8I  
  > **username_0**: Interestingly, Natron's "WriteFFmpeg" module does not seem to have this problem.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2016-03-24. Score: 1
  
  I believe the problem lies in how FFMPEG does the RGB->YUV conversion by default. This option specifies the use of the bt709 color space for the conversion, instead of the default of bt601. This fixes it for me - though please let me know if I'm doing something bad here!
  
  ```
  -vf scale=out_color_matrix=bt709
  
  ```
  
  > **Comments:**
  > **username_1**: 709 is default for HD, 601 for SD.  
  
  ---
  
  