Image sequence - VirtualDUB - HuffYUV - washed colors

[Bucic]

The following sequence:
Image sequence - VirtualDUB - HuffYUV

results in dull/washed out colors. Any thoughts? Here you can find an example http://www.youtube.com/watch?v=H2SIGw8eI9Q

[poisondeathray]

how are you taking screenshots ? what software? and what videos are the screenshot derived from (what is the left side, what is the right side?)

was huffyuv in rgb or yuy2 mode ?

this looks like a levels issue (pc vs. tv levels)

[Bucic]

Thanks for fast response. DCS Black Shark has a frame by frame video recording function for it's replays. Unfortunately the output can only be a sequence of PNGs.

Left: sshot from huff vid taken either from VD or MPC HC. It doesn't matter - the comparison shows what I see.
Right: a piece of original PNG mentioned above.

HuffYUV RGB setting: predict gradient (not 'convert to yuy 2')

[poisondeathray]

If you have used huffyuv rgb, there should be no shift. Did you use any other filters ? other processing ?

e.g. here I cropped your image (crop.png), and used vdub, opened the image directly, saved as huffyuv (fast recompress) , and it looks the same as the original

[Bucic]

No other filters. Just encoding.

I think we'll have to leave it for now as I think I've lost track of things...

A month ago everything made PNG -> VD -> lossless came out in pale colors. Checked in MPC, VLC and on YouTube it was also pale as hell http://www.youtube.com/watch?v=H2SIGw8eI9Q


Today I did PNG -> VD -> huffyuv -> Xvid4PSP ->x264 Q21 Insane Film
and the vid didn't came out in pale colors... but I don't remember if the lossless file used for encoding seemed pale in MPC and VLC. Probbly, because this one plays in pale colors http://www.mediafire.com/?81znkg5tx6g458n

[poisondeathray]

Well x264 will be YV12 , so there will also be a colorspace conversion. How your software converts that YV12=>RGB for playback is where the usual problem is. It will depend on how your software and graphics card is configured

It's more likely a levels issue as mentioned earlier - you graphics card is probably using tv levels 16-235, when it should be using full range 0-255 , or you are using a renderer like vmr9 renderless , or your renderer settings are not set properly

You have to provide more information if you want more help. You have to trace each step and find out where the problem is.

[Bucic]

OK, I'm back. Thanks for the usueful info on on x264 and YV12. What should exactly be my workflow to avoid any colorspace conversions? Should I, for example, always use YV12 lossless codecs like Lagarith?

Could you tell me what tool should I use for a TRUE preview of my vids and screenshots making? VirtualDUB for both? Video -> copy source frame to clipboard? And finally - is it enough to change Video - compression to see the effects on output frame sent to clipboard or do I have to save as avi first?

[poisondeathray]

OK, I'm back. Thanks for the usueful info on on x264 and YV12. What should exactly be my workflow to avoid any colorspace conversions? Should I, for example, always use YV12 lossless codecs like Lagarith?

Could you tell me what tool should I use for a TRUE preview of my vids and screenshots making? VirtualDUB for both? Video -> copy source frame to clipboard? And finally - is it enough to change Video - compression to see the effects on output frame sent to clipboard or do I have to save as avi first?

well x264 is YV12 only, so you will incur at least 1 colorspace conversion

lagarith is lossless , but supports YV12 , YUY2 and RGB . If you feed it YV12, it will output YV12. If you feed it RGB, it will output RGB

If you have a RGB source , like pngs, and keep the same colorspace (RGB) then copying the source frame to clipboard should show the exact same thing in vdub

The answer is not so simple, because when you export a YV12 source, it has to be converted back to RGB for display (if you take a screenshot, it is RGB, your monitor displays in RGB) - so how you do that conversion can affect how a video or screenshot is displayed . It's not enough to only change video=>compression , you have to examine the video, and how you have the decoder, renderer, graphics card settings, what software, how you do the RGB conversion etc...., affects how anything is displayed

Your 1st screenshot is a classic example of a levels issue . TV vs. PC levels.

[Bucic]

I thought the answer will be simple this time. Oh me naive :/

Could you just pretend for a moment that you talk to a moron and propose a good workflow?
Constraints: The game capturing output can be either PNG sequence (please have mercy and prefer this one ) or AVI uncompressed.

Given that we look for a procedure of which final step is exporting to YouTube we have the following color spaces (from last to the first):
[[ RGB (monitor) <- YV12 (YouTube H264) <- YV12 (x264 GUI output) ]] <- ...........???........... <- RGB (PNG sequence) (or UNKNOWN (uncompressed AVI) from game capturing tool

[[ ]] I get it that we have absolutely no control over that part of the process.

[poisondeathray]

You have control over the "???" ; that's where the mistake usually happens. RGB can be converted to YV12 either full range or limited range - that's likely what happened in your 1st screenshot. With avisynth you have control over that conversion.

RGB [0,255] => YV12 [0,255] (full range)
RGB [0,255] => YV12 [16,235] (limited range)

What I would do is use avisynth, imagesource() as outlined in your other thread to import into some x264 GUI; this is the fastest, no intermediates, no hassle. Option #2 is to use vdub, to assemble your images and export either lossless RGB avi (e.g. lagarith, huffyuv) then import into some x264 GUI . Option 3 is to use avidemux (it uses libx264, not the vfw version)

[Bucic]

I feel we're getting somewhere
Would it help if we could get the game recording tool to give us an YV12 output? Or is it not worth the hassle if we could only achieve the full range RGB->YV12 conversion?

[poisondeathray]

Would it help if we could get the game recording tool to give us an YV12 output? Or is it not worth the hassle if we could only achieve the full range RGB->YV12 conversion?

It would save space, and bit easier, but quality is lower (but the lower quality wouldn't matter if your end goal was a YV12 format)

RGB is not subsampled 4:4:4 . YV12 is lower quality, lower bandwidth subsampled 4:2:0. You can see when you examine closely, colors are not as crisp, edges look more blocky

The picture you gave doesn't have isn't full range data; If you examine it in a RGB histogram it doesn't have data that extends 0-255. The "washed out" picture probably had a full range conversion done somewhere in the workflow (when it shouldn't have) , that's probably why it looks washed out. (Another explanation might be you took the screeshot through a renderer like vrm9) .

I suspect if you use a normal TV matrix (rec601, rec709) , that the levels would be fine. Using a full range (pc601, pc709) would stretch the contrast for your source and it would look washed out. Eitherway, you can control it with avisynth to make it look fine on youtube. I suspect the regular converttoyv12() will work (which uses rec601)

The one benefit of youtube , is that it is consistent (it will look pretty much the same everywhere, because it's adobe flash) , as opposed to someone using a media player for playback - which will depend on graphics card settings, renderer, decoder settings, a dozen other things etc...

[Bucic]

I'll be more than happy to be able to stay away from avisynth so I'll wait for the devs response on the subject.

But if it's impossible (YV12 source) than, with our RGB source PNGs I'm supposed to convert them to YV12 using avisynth, right? Could you tell me what should be the output format in that case?

[poisondeathray]

avisynth is a frameserver, the output format is whatever you choose it to be in an encoder that accepts avisynth scripts.

It's really not that difficult. And it will take a few minutes to test it out. If it needs to be adjusted (after reviewing on youtube), you can alter the script. Once you have the process set, it's very easy.

[Bucic]

Apart from avisynth wiki, could you point me to some avisynth for dummies tutorials? Some workflow examples (for primitive single operations like the one before me) would be great too. Something that is not on the wiki but you think I should know of that is.

[poisondeathray]

not really, apart from the wiki. You're not doing anything fancy here, it's just a source filter. 1 or 2 lines.

some gui's will auto generate an avs script for you if you feed a video (e.g. megui, xvid4psp, ripbot)

for image sequence, I gave the code in the other thread

e.g.

ImageSource("picture%04d.png, 0001, 1000, fps=30)
ConvertToYV12()


If your images are from the same game, you can use basically the same script for everything. If you need to adjust for youtube, you might need to do a levels conversion (I doubt you will have to, but the point is if you HAD to make any adjustments, it's super easy, right at your fingertips, as opposed to using a program that assumes all the conversions for you with no control).

[jagabo]

I think you have a playback problem, not an encoding problem. Use the graphics card's setup applet to adjust the video settings. Use the video in this post to adjust your levels:
https://forum.videohelp.com/threads/326496-file-in-Virtualdub-has-strange-colors-when-o...=1#post2022085

[Bucic]

Thanks again! Will report back later.

BTW, ...%04d... what's it called? I'd like to read about it because... I will simply probably need it to modify some examples I'll find in the future.

I think you have a playback problem, not an encoding problem. Use the graphics card's setup applet to adjust the video settings. Use the video in this post to adjust your levels:
https://forum.videohelp.com/threads/326496-file-in-Virtualdub-has-strange-colors-when-o...=1#post2022085

Thanks, but I can't just rush onto my graphics drivers settings when there's plenty of other places that may screw colors on the way (ffdshow, MPC HC renderer settings etc.).

[poisondeathray]

BTW, ...%04d... what's it called? I'd like to read about it because... I will simply probably need it to modify some examples I'll find in the future.

sprintf syntax

I posted the instructions and link to imagesource in the other thread
http://avisynth.org/mediawiki/ImageSource

[jagabo]

I think you have a playback problem, not an encoding problem. Use the graphics card's setup applet to adjust the video settings. Use the video in this post to adjust your levels:
https://forum.videohelp.com/threads/326496-file-in-Virtualdub-has-strange-colors-when-o...=1#post2022085

Thanks, but I can't just rush onto my graphics drivers settings when there's plenty of other places that may screw colors on the way (ffdshow, MPC HC renderer settings etc.).

VirtualDub and HuffYUV do exactly what they're supposed to do when converting an image sequence to an AVI file. RGB 0-255 are converted to YUV 16-235. That is not the source of your problem.

When a media player (including MPC and MPCHC) plays that file the default behavior is to send the YUY2 data directly to the graphics driver. So the graphics driver is responsible for the YUV to RGB conversion to get to the monitor. That is what needs adjusting. Note that there are separate proc amp settings for the Desktop and video. Adjusting the video proc amp will not effect the Desktop.

Some editors will show the YUV video without the usual PC.601 contrast expansion (resulting in the washed out image you are seeing) so that you can see blacker-than-black and whiter-than-white details of the YUV data when present. I think Sony Vegas does this, for example.

Try this in VirtaulDub: Options -> Preferences -> Display -> disable Use DirectX For Display Panes. Exit VirtualDub and restart it. Now open your HUFFYUV AVI. It should look like your original images. That forces VirtualDub to use Windows GDI rather than the graphics card's video hardware and proc amp.

[Bucic]

I don't even know which sliders in nVidia CPL should I harass. Of course it is not the topic here. I don't mind my player colors being slightly off as long as I have VD for a true preview.

Plus throughout the day my monitor brightness and contrast settings vary greatly so I guess I would have to re-adjust the levels every time I re-adjust my monitor settings.

[jagabo]

I don't know if you caught it or not, but I added instructions to my last post on how you can get VirtualDub to bypass the video proc amp.

[Bucic]

I didn't then. Thanks!

[jagabo]

Oh, you can also force HuffYUV to work in RGB (given an RGB source). That will retain RGB 0-255 levels.

[Bucic]

That's a big OH! I'm sure poisondeathray has mentioned it more than once. I just forgot.

[jagabo]

You can also force HuffYUV to output RGB even if it's set to compress in YUY2 internally. That way, it will expand the contrast on output, to match the contrast reduction it did on input. All digital video is supposed to have Y levels from 16-235. Computer RGB is normally 0-255. Almost every program performs the levels conversion by default when converting RGB/YUV.

[Bucic]

DOOH!
Game works in RGB so it makes no difference between:
game RGB -> PNG RGB -> x264 YUV12
OR
game RGB -> x264 YUV12

...

[jagabo]

Yes, and there would be no difference between those and:

game RGB -> HuffYUV (RGB mode, withVirtualDub) -> x264 YV12

and very little difference between those and:

game RGB -> HuffYUV (YUY2 mode, with VirtualDub) -> x264 YV12

[Bucic]

So we get RGB out of the game and we should keep it till the final production to x264 YV12, right?

[jagabo]

So we get RGB out of the game and we should keep it till the final production to x264 YV12, right?

You want to avoid un-necessary conversions. Ie, don't go from RGB to YUY2 to RGB to YV12, to YUY2 to yada, yada, yada. Each of those conversions has the potential to degrade the image a little.

The biggest issue is to avoid going from YUV to RGB with the usual rec.601 contrast stretch when your video has darks below IRE 0 (Y=16) and brights above IRE 100 (Y>235). Once you blow out the darks and brights with the RGB conversion there is no getting them back.

Not every 8 bit (per channel) integer RGB value has a unique equivalent in 8 bit integer YUV. Conversely, not every 8 bit integer YUV value has a unique 8 bit integer RGB equivalent. So when you convert between the two you lose a little precision. A One or two conversion may not be noticeable but repeated conversions may start to accumulate. Say for example you have an RGB pixel who's red component is 147. After converting to YUV and back to RGB you may find that red component is 146 (from rounding errors). If you compare the original image to the converted image you may not even be able to see the difference. If you repeat the conversion again the 146 may come back as 145. Then the 145 may come back as 144. Now if you compare the original to the final conversion you may start to notice the differences.

Converting back and forth between YUV 4:2:2 and YUV 4:2:0 has the potential to blur the colors. From 4:2:2 to 4:2:0 or 4:1:1 necessarily blurs the colors (you're reducing the color information by half). But you may get further blurring by repeatedly converting back and forth.

And, of course, needless conversions are a waste of time.

But, for example, if you have to use a filter that only works in YUY2 it's OK to go from RGB to YUY2 for filtering, then to YV12 for the final encoding. Or from YV12 to YUY2 and back to YV12. Presumably the benefits gained by the colorspace conversions outweigh the losses from the conversions.