[Solved] Avisynth : colors problems

[Kdmeizk]

Hello,

I use FRAPS to capture videos. But, I would like the results is the same that I can see on the screen.


The first screenshot = a simple screenshot :
https://lut.im/OEw0Gfny/daxubILV


The second = a screenshot of a FRAPS's video :
https://lut.im/hE4yHAyW/z2xlPht4


The third = a screenshot when video is converted by default parameters of Avisynth :
https://lut.im/9TLMdf8x/j2Qk0c1N



There is a little bright problem I think. But the most important that I saw is the color modification, especially on the green.
Even if I used many time to try, I don't know how resolve this. For the conversion, I have Avisynth and I think I should use options in Tweak (http://avisynth.nl/index.php/Tweak).


Do you see others problems ?


Thanks in advance.

[newpball]

...when video is converted by default parameters of Avisynth :

"Converted by default parameters", what does that mean?

- How did you encode in Fraps? YUV, RGB?
- How did you "default convert"?

Best would be to post the mediainfoXP results of both the Fraps generated and Avisynth converted video so we can compare color spaces, Recs and levels.
Also include the avisynth script you used in case you did some 'funky' processing that converted color spaces and things.

[Kdmeizk]

"Converted by default parameters", what does that mean?

It means I don't touch the settings of Avisynth.

- How did you encode in Fraps? YUV, RGB?

FRAPS works in RGB.

How did you "default convert"?

I don't know if this is your expected response but I use Hybrid (http://www.selur.de/) which uses Avisynth to encode this video with VP9 codec (file.webm).

Best would be to post the mediainfoXP

Are you sure you want a rapport with mediainfoXP ? I can send you videos files if you want.

[newpball]

Are you sure you want a rapport with mediainfoXP ? I can send you videos files if you want.

Obviously you have a color conversion issue, if you want people to help you find out where you make the mistake you obviously have to provide information what you have been doing.

Don't use Fraps but I thought you could select YUV or RGB.

[Kdmeizk]

Rapports are attached. In fact, I think mediainfoXP give you a little information about the video, so I suggested videos files for this.

[newpball]

That's not mediainfoXP, if you use the regular mediainfo you need to provide details.

[Kdmeizk]

Oh ok I see.

It's better now.

[newpball]

You need Windows text view.

https://mediaarea.net/en-us/MediaInfo/Screenshots

[jagabo]

You need to post your AviSynth script. You don't need to use Tweak() to keep the original colors. You just need to avoid screwing it up within the script, when viewing it, and when encoding it.

[Kdmeizk]

Done for text view and the script. Files attached.

[LigH.de]

Let me guess ... FRAPS works in RGB 4:4:4 resolution, whereas most modern codecs prefer YUV 4:2:0 in TV range (instead of PC range) of luminance and chrominance?

[Kdmeizk]

FRAPS can works with YUV but I choose RGB because it's the base of colors. YUV results operations to make color if I understood. For this type of work, I can choose RGB I think. Moreover, YUV breaks more colors than RGB I could see it with FRAPS.

[newpball]

If you have something in RGB and you end up with YUV you need to provide provisions for conversion. If you don't you obviously get issues.

So either you encode YUV or you convert.

[Kdmeizk]

I don't want go to YUV or other. If I can stay with RGB I/O, so I will stay with. I don't know if VP9 or Avisynth try to convert to YUV.

[newpball]

I don't want go to YUV or other. If I can stay with RGB I/O, so I will stay with. I don't know if VP9 or Avisynth try to convert to YUV.

VP9 does support sRGB however the problem is conversion, filtering and rendering software.

Many engineers have the "if it ain't YUV it ain't video attitude".

It would be great to have pure sRGB video with PC levels from capturing, encoding, through filtering all the way to rendering. But I fear that die-hard conservationists would not stand for it.

Sad but true!

[jagabo]

I don't want go to YUV or other. If I can stay with RGB I/O, so I will stay with. I don't know if VP9 or Avisynth try to convert to YUV.

MPEG family codecs (MPEG 1, MPEG 2, MPEG 4 part 2, h.264) work in YUV, usually YV12 (if you want compatibility with stand alone media players, TVs, etc.) because it's half as much data as 24 bit RGB. A high definition RGB source should be converted to YV12 in AviSynth with the standard rec.709 matrix: ConvertToYV12(matrix="rec709). It's safest to have the encoder flag it as such too.

[Cornucopia]

The problem is not "conversion", but "poor conversion".

The reason the YUV family is used so often instead of RGB has to do with the fact that RGB makes redundant (and thus inefficient) use of bitrate/quality vs. YUV's.

But again you are mistaken (sad but true): there ARE video workflows which can maintain RGB throughout.

@Kdmiezk, with proper conversion, your result should look quite like your original (barring low bitrate artifacts, etc). However, I see a playback problem looming with your continued use of 90FPS. Many systems will either not be able to play that back at all, or will stutter, or will play too slowly.

Scott

[jagabo]

I see a playback problem looming with your continued use of 90FPS. Many systems will either not be able to play that back at all, or will stutter, or will play too slowly.

Not to mention the cap itself probably dropped a lot of frames.

[newpball]

The reason the YUV family is used so often instead of RGB has to do with the fact that RGB makes redundant (and thus inefficient) use of bitrate/quality vs. YUV's.

I respectfully beg to differ, both historically, technically and also perceptually.

Historically because it was implemented as part of squeezing every single bit of information out of the signal while getting away with it, technically because RGB compression could theoretically be better handled at the codec level and perceptually because it is noticeable.

[Cornucopia]

Wrong again.

You can "get away with it" because it very, very often ISN'T noticeable. So unnoticeable, in fact, that this is why chroma subsampling was put into effect.

Would love to see some examples to back up your wild claims...

Scott

[newpball]

Wrong again.

You can "get away with it" because it very, very often ISN'T noticeable. So unnoticeable, in fact, that this is why chroma subsampling was put into effect.

Would love to see some examples to back up your wild claims...

I know, chroma subsampling, IRE, reduced levels, interlacing, visible compression artifacts, overscanning, fixed video sizes and framerates, those are all brilliant features that should be beyond - blasphemists will be punished - question and be preserved for eternity.

Truth of the matter is that all those old techniques had a valid reason for being in existence. However, it is 2015 and there is no reason to maintain those things for new material! We have grown beyond Nipkov disks you know!

[Cornucopia]

No examples? Thought not.

[Kdmeizk]

A high definition RGB source should be converted to YV12 in AviSynth with the standard rec.709 matrix: ConvertToYV12(matrix="rec709). It's safest to have the encoder flag it as such too.

I don't know the colormatrix of FRAPS (Avisynth asks the source too). I choose VP9 instead of H.265 because settings like quantization afraid me and I think it's more difficult to configure "for the best" than VP9.

The problem is not "conversion", but "poor conversion".

The reason the YUV family is used so often instead of RGB has to do with the fact that RGB makes redundant (and thus inefficient) use of bitrate/quality vs. YUV's.

But again you are mistaken (sad but true): there ARE video workflows which can maintain RGB throughout.

@Kdmiezk, with proper conversion, your result should look quite like your original (barring low bitrate artifacts, etc). However, I see a playback problem looming with your continued use of 90FPS. Many systems will either not be able to play that back at all, or will stutter, or will play too slowly.

Scott

My way is often "FRAPS" -> "Youtube" or "FRAPS" -> "Avisynth" -> "Youtube" (because Youtube converts again videos and down to 60 FPS max at the moment). It's generally for report bugs (VLC, Firefox, Thunderbird). But I can record several moments of video games (useless to up to 90 FPS, 60 FPS max, with GTX 460) and I don't like find colors differences once converted. So, until find a real solution (I hope here), I keep FRAPS's record instead conversions.

[Kdmeizk]

Ok the problem seems to be color matrix. I changed the source color matrix between Rec.709; FCC; Rec.601; SMPTE 240M and don't touch the output color matrix (which is Rec.709). Results :
- Rec.709 -> Rec.709 = colors like screenshots here (bad colors for the green)
- FCC -> Rec.709 = same green like source
- Rec.601 -> Rec.709 = same green like source
- SMPTE 240M -> Rec.709 = colors like screenshots here (bad colors for the green)

[jagabo]

- Rec.601 -> Rec.709 = same green like source

That probably means fraps or the editor/encoder converted the RGB screen capture to YUV with a rec.601 matrix. So to maintain proper colors when uploading to youtube (which assumes rec.709) you need to convert from rec.601 to rec.709.

But be careful. How are you judging the results? When YUV video is displayed on your monitor it has to be converted to RGB. That conversion can take place anywhere from the codec to the monitor.

codec ---> player/editor ---> graphics driver ---> monitor

The YUV to RGB conversion can take place at any of those steps. So you need to make sure each of those components is working properly. For example, VirtualDub always converts YUV to RGB with a rec.601 matrix. So what you see on the screen in VirtualDub will be wrong if the incoming video is rec.709 YUV.

      YUV             RGB                  RGB
codec ---> Virtualdub ---> graphics driver ---> monitor

[Kdmeizk]

FRAPS has an option "Force lossless RGB capture (may be slower)" which is checked for me. I assume without this option, YUV is used because there is colors problems (the blue is bad for example) and the size/bitrate are lower.

I checked with a original screenshot (without video) and a screenshot of videos. With both, I checked the colors palette for the green. The original screenshot has RGB=0,255,0 in the middle top and with Rec.601 -> Rec.709 it's the same. For other, generally, it was RGB=10,220,2.

[jagabo]

I checked with a original screenshot (without video) and a screenshot of videos.

So you don't know where the RGB/YUV/RGB conversions took place. Which means you don't know if your screenshot is truly reflective of the encoded video.

[Kdmeizk]

I don't understand where is the problem. I take screenshots with "Impr. écran" / "Screnshot" on the keyboard. So, problems that you see aren't, no ?

I assume if anybody reproduces same steps that mine (to see a color default), they will have the same result.

[jagabo]

I don't understand where is the problem. I take screenshots with "Impr. écran" / "Screnshot" on the keyboard. So, problems that you see aren't, no ?

No. Your screen shot is RGB copied from the screen. You don't know how your YUV encoded video got to be RGB on the screen. So you don't know if it was done correctly.

I assume if anybody reproduces same steps that mine (to see a color default), they will have the same result.

No. It will depend on how their computer is set up. What codecs they use, what player they use, and what graphics card they use.

[Kdmeizk]

I assume I can't do better than actually to fix colors problems. I think I can only set settings with screenshots comparisons. I don't know how my graphic card convert the image and I'm not sure that will help me to reproduce the same colors that a original screenshot.