This is a long post, sorry about that! Its purpose is to provide some encoder settings to preserve color fidelity. The correct settings to use depend on the source, the application doing the encoding, and the application you want to play the video. Reading the background stuff is optional. If your encoding application is listed here, you can use the suggested settings. If you aren't sure how this works, or if your encoding application is not listed, post a reply and I will help you with it.
What color space is Fraps? *
What settings should you use to encode with, if you want correct colors? Why do we sometimes get faded or exaggerated colors with StaxRip, or VirtualDub, or Vegas, or Premiere or other encoding programs? Over the past couple of weeks, I did a lot of testing to try to answer these questions.
The first problem is, what is normal? What are the colors supposed to be? Can we know what the game designer intended? There are so many variables that can affect the color on a game - game settings, video card settings, even driver versions. I had to start with known colors, and to get that, I cobbled together the Fraps Test Pattern program. The program simply puts an image on the screen in a way that Fraps can record. It's made as simply as possible, both because I don't know much about DirectX programming, and because I didn't want the added features (especially lighting) of a more 'advanced' program to affect the color of my source image. Now I could put an image of my choice on the screen and record it with Fraps (or any other DirectX capture program).
Playing the video on most (not all!) players showed there was no color shift between the original image and the Fraps video. Great! (I wasn't sure that was going to be true at all). I always check the colors on screen with the excellent ColorPic program, to confirm my eyeball evaluation. Then I started compressing the Fraps videos with different encoders to compare the quality. I was shocked when I compressed a video with my favorite program, VirtualDub, with x264vfw (H.264), uploaded the result to YouTube, and found the reds were exaggerated and the greens were weak. What - how can this be!? Well, that started a marathon testing session of every encoder and video editor I had available, and guess what - there were problems like that everywhere I looked. The good news is, if you know what's happening, you can easily correct for it - most of the time.
First, what kind of errors are we talking about? What do they look like?
Here's a cropped version of my test image:
Here's the image with "red push;" over-saturated reds and weak greens:
Here's the image with "green push;" over-saturated greens and weak reds:
The color errors are are subtle with normal, not-very-colorful source material, but they're easy to spot with color bars - or any highly saturated feature with known color.
What causes these errors? I can't pretend to know why exactly for every situation, but in general, "green push" is due to a video which has been converted to YUV (and sent to the encoder) in the Rec.709 (or HD) color space, but converted back to sRGB (and sent to the monitor) in the Rec.601 (or SD) color space. "Red push" is due to the reverse: stored as Rec.601, displayed as Rec.709. I think. The internal machinations don't matter too much, for me; the important thing is to check for errors at each stage of the signal chain and correct for them. I will explain how that's done down-thread.
You can get away with a color space error, and most people won't notice (some of you do, because you've been posting about it: here, here and here); however, if you get multiple color errors in your signal chain (eg, boost the reds, then re-encode and boost them again), the video quality will fall apart very quickly. The results of my tests should be helpful, but if you use any tools or settings I haven't listed below, you need to test for yourself.
Luma range errors were seen in my testing as well. More on luma range errors on the "Fraps Dark" thread, here. They need to be caught and corrected at each stage of the signal chain too.
To review, here's the test image with "blowout" or exaggerated luma range:
(sometimes called "too dark", but it's also "too bright" - detail is lost at both ends of the scale)
And here is the image with "washout" or low luma range:
* What color space is Fraps? Short answer, Rec.709, full range; but in practice, the color space you see is whatever the decoder spits out. If you use the Fraps decoder, the output is RGB, full range. Other decoders may return something else. That's why it's important to test.
What color space is Fraps? *What settings should you use to encode with, if you want correct colors? Why do we sometimes get faded or exaggerated colors with StaxRip, or VirtualDub, or Vegas, or Premiere or other encoding programs? Over the past couple of weeks, I did a lot of testing to try to answer these questions.
The first problem is, what is normal? What are the colors supposed to be? Can we know what the game designer intended? There are so many variables that can affect the color on a game - game settings, video card settings, even driver versions. I had to start with known colors, and to get that, I cobbled together the Fraps Test Pattern program. The program simply puts an image on the screen in a way that Fraps can record. It's made as simply as possible, both because I don't know much about DirectX programming, and because I didn't want the added features (especially lighting) of a more 'advanced' program to affect the color of my source image. Now I could put an image of my choice on the screen and record it with Fraps (or any other DirectX capture program).
Playing the video on most (not all!) players showed there was no color shift between the original image and the Fraps video. Great! (I wasn't sure that was going to be true at all). I always check the colors on screen with the excellent ColorPic program, to confirm my eyeball evaluation. Then I started compressing the Fraps videos with different encoders to compare the quality. I was shocked when I compressed a video with my favorite program, VirtualDub, with x264vfw (H.264), uploaded the result to YouTube, and found the reds were exaggerated and the greens were weak. What - how can this be!? Well, that started a marathon testing session of every encoder and video editor I had available, and guess what - there were problems like that everywhere I looked. The good news is, if you know what's happening, you can easily correct for it - most of the time.
First, what kind of errors are we talking about? What do they look like?
Here's a cropped version of my test image:
Here's the image with "red push;" over-saturated reds and weak greens:
Here's the image with "green push;" over-saturated greens and weak reds:
The color errors are are subtle with normal, not-very-colorful source material, but they're easy to spot with color bars - or any highly saturated feature with known color.
What causes these errors? I can't pretend to know why exactly for every situation, but in general, "green push" is due to a video which has been converted to YUV (and sent to the encoder) in the Rec.709 (or HD) color space, but converted back to sRGB (and sent to the monitor) in the Rec.601 (or SD) color space. "Red push" is due to the reverse: stored as Rec.601, displayed as Rec.709. I think. The internal machinations don't matter too much, for me; the important thing is to check for errors at each stage of the signal chain and correct for them. I will explain how that's done down-thread.
You can get away with a color space error, and most people won't notice (some of you do, because you've been posting about it: here, here and here); however, if you get multiple color errors in your signal chain (eg, boost the reds, then re-encode and boost them again), the video quality will fall apart very quickly. The results of my tests should be helpful, but if you use any tools or settings I haven't listed below, you need to test for yourself.
Luma range errors were seen in my testing as well. More on luma range errors on the "Fraps Dark" thread, here. They need to be caught and corrected at each stage of the signal chain too.
To review, here's the test image with "blowout" or exaggerated luma range:
(sometimes called "too dark", but it's also "too bright" - detail is lost at both ends of the scale)
And here is the image with "washout" or low luma range:
* What color space is Fraps? Short answer, Rec.709, full range; but in practice, the color space you see is whatever the decoder spits out. If you use the Fraps decoder, the output is RGB, full range. Other decoders may return something else. That's why it's important to test.
Some of my test images - compare:
