VirtualDub and color space of filters?
 

VirtualDub and color space of filters(about noise: temporal smoother etc.)

Regarding VirtualDub 1.9.11 (called the version of LordSmurf) with pre-loaded filters.

Is there a list somewhere or it's possible check somehow in what color space (eg whether RGB or YUV) are working individual of these probably 51 filters ?
Some filters work on many color space ? Then it's neccessary to set it up(color space) manually or these filters doing this automatically according to source and checked output format ?

How it's working ?

For example, I have a file in YUV (YUY2 4: 2: 2), and the filter is (works only?) In RGB - and what then ? This filter simply will not work on this material will it work, but will break it (colors) ? (Ultimately, the file would be saved in YUY2 4: 2: 2.)

VirtualDub filters are RGB filters.


If you want to use VirtuaLDub filters but also want to save your output file in a different colorspace or compression, set "color depth" and "compressor" before saving the file. You should be making those output settings in any case because VDub's default output is uncompressed RGB24 unless you specify otherwise.

Since the filters are in RGB, and the recording is in a different format(and saved file) then there is some deterioration in the image quality when the color of the filter is converted ...?

How it's work ?

Current versions of VirtualDub convert YV12 and/or YUY2 input files to RGB along required lines that are perfectly safe.


If you really want to get involved in doing it the kosher way, use Avisynth to convert your YV12 or YUY2 file to RGB and open the script in VirtualDub. When you complete your VDub processing set your output "color depth" and output "compression" to the desired lossless values.


Interlaced or telecined YV12:
Non-Interlaced YV12:
Interlaced or telecined YUY2:
Non-Interlaced YUY2:
Or you can stop worrying about it and do what most people do, which is to let VirtuaLDub do it internally using its own background methods similar to those above.


If you don't intend to apply VirtuaLDub filters to your video, you don't have to do any of this. Open your Avisynth processing script or your YUV video file in VirtualDub,
- set "Video.." -> "color depth" to your desired output colorspace,
- set "Video..." -> "compression..." to your desired output compressor,
- set "Video..." -> to "fast recompress",
- and save your file. There is no RGB conversion.

People open YUV files in VirtuaLDub every day all day long all over the world without problems. In many ways, VirtualDub and Avisynth use similar conversion methods, but Avisynth can be more explicitly precise. If you want to know more about what's involved under the hood, go here: http://avisynth.nl/index.php/Convert. Or just let VirtualDub figure it out for you.


If you want to know exactly how VirtualDub works this out internally, you'll have to wait for someone with a knowledge of C++ and assembler language to walk through VDub's internal source code with you. The internal programming code for 32-bit VDub v.1.9.1.1 is free open-source media and can be downloaded from https://sourceforge.net/projects/vir...rc.7z/download. The files will be in a .7zip package that requires the free 7Zip decompressor from https://www.7-zip.org/. 7zip is a handy program to have and it has a GUI that interfaces with Windows.

So if the filters are in RGB(enable to saving file), and the recording(source) is in a different format(for example: YUY2) and saved file is set up in YUY2 color depth then there is some deterioration in the image quality when the color of the filter is converted or not ?
Is there any conversion? Or maybe there is only imperceptible (we do not lose anything on the quality of the image)?
--------------------------------------------------------------------------------------------------------------------------
[Source, file in YUY2.]
If most filters in VirtualDub work in RGB: RGB32, then for best image quality it is best to save after editing, applying filters, video file:

1. In the color space: 32 bit RGB (888) (dummy alpha channel)
whether
2. In the color space: 4:2:2 YCbCr (YUY2) ?

I think maybe it would be best to save this video file in the RGB32 color space (option: 1). Why do I think so ? Because then we avoid the conversion: YUY2 - RGB32 - YUY2. There will be: YUY2 - RGB32 - RGB32 (no conversion at the final stage from RGB32 to YUY2). I'm wrong or right ?
--------------------------------------------------------------------------------------------------------------------------
Finally comes the issue of converting this file from, for example, the HuffYUV codec to the codec: H.264.
From what I know, it is possible to encode the H.264 file by probably the program: Hybrid - giving it the interlacing setting: UFF (TFF). But for playing this final file on as many devices as possible without problems: TV, computer, etc. it is best that what color depth was the file: RGB32 or YUY2 ? I guess RGB32 probably, but would YUY2 have playback problems(more problems than RGB32) ?

When I use VirtualDub processing it is usually the last step in my workflow. I convert to RGB32 for VirtualDub using Avisynth. I also convert to RGB32 for processing in AfterEffects Pro. The next step after any RGB work is to encode the final version in either MPEG2 or h.264 -- therefore I save the RGB work in final form as YV12 using Lagarith lossless compression.

DVD = MPEG2 = YV12
BluRay/AVCHD = MPEG2 or h.264 = YV12
Internet posting = YV12.
Encoding for external media players, servers, and smart-TV = YV12.

Huffyuv is a lossless codec. h.264 is almost always encoded as lossy, especially for BluRay, AVCHD, or
mp4/internet/external player.

If you would like to encode to lossless and/or RGB or YUY2 you can do so if your encoder allows it -- but your external players will strongly disagree. Most players will tell you that they can't read the video.

Millions of people throughout the world over many years have converted colorspace with no problems. However, you want to avoid jockeying back and forth between colorspaces unnecessarily, because doing it too often involves accumulative interpolation errors. Virtualdub and Avisynth perform conversions with high precision. Most NLE editors such as Adobe, Vegas and others use RGB filters and are somewhat sloppy about their colorspace conversion work. Avisynth and VirtualDub are more careful about it.

If you want to get into the details of Avisynth colorspace conversion, use the Avisynth documentation at .http://avisynth.nl/index.php/Convert

Lagarith and its free, automatic installer are at https://lags.leetcode.net/codec.html. Lagarith can losslessly compress RGB, YUY2, and YV12. Huffyuv is RGB and YUY2 only. There is no problem with compressing a Huffyuv video with Lagarith -- they are both lossless. Lagarith outputs slightly smaller files than Huffyuv.

What H.264 (x264) codec (and specifically the codec version) do you recommend using VirtualDub where I can specify, for example: interlaced image field (is it TFF or BFF) and color depth (for example: YV12) ?
x264vfw ?

I don't use VirtualDub as a final output encoder. I use other encoders such as TMPGEnc Mastering Works, AviDemux, and AfterEffects for final DVd and BluRay encoding.

"x264" is not a codec. it is one of several h.264 encoding engines and is used by several encoding apps. The codec is "h.264". Most h.264 encoding apps encode to YV12 by default. You usually have to tell your encoder whether you want interlaced/TFF or some other configuration.

x264vfw is an h.264 encoder that uses the x264 encoding engine. I can't advise you on how to set up x264vfw because I don't use it. Other readers should be able to give you more details.

I have an additional question: Is there another external program (other than Hybrid that does not work for me) that would allow such file conversion: from YV12 (HuffYUV) to YV12 (H.264), able to determine which interlaced field is first. It's nice that it can also set the best quality (e.g. bitrate) of this final file for playback on media such as TV sets.

TMPGEnc Mastering Works it's not free if I good know. In AviDemux Can I easily do what I write about ? I need some external codec(H.264) in Avidemux ?

'Note that Huffyuv does not work with YV12. Use Lagarith, which is usually the choice for intermediate working files in RGB, YUY2, and YV12. Lagarith has been referenced earlier: https://lags.leetcode.net/codec.html.

Most h.264 and MPEG encoders automatically encode using YV12. As for Avidemux, you can specify the bitrate, encoder, field order, etc., in its interface dialogs.

Almost every VHS tape in the world uses TFF. You can test it by loading asn AVI capture in Virtusaldub and loading the yadif deinterlace filter. Set the yadif filter for top field firwt (TFF). Look for frames with motion of some kind and scroll through the video one frame at a time. Observe the image in the output pane. If the image moves back-and-forth and jumps, the field order is not TFF but is BFF. If the output image moves normally, the field order is TFF.

Notre that not all VHS video is true interlace. Many film movies on vhs are telecined or use other forms of pulldown, especially film-based NTSC editions. Most PAL movies at 25fps that are film-based are simply speeded up from 24fps to 25fps. Non-film PAL 25fps is usually interlaced TFF.

Here is a classic html page that explains different ways to analyze frame structure: Neuron2: how to analyze video frame structure. This question about field structure was previously answered in post #43 of this Guide in answer to your query.

VHS has no TFF/BFF.

TFF/BFF is determined by capture hardware.
- DV is BFF
- and almost everything else is TFF

sanlyn
Ok, now I see. Yes I can use then Lagarith or UTCodec.
--------------------------------------------------------------
For example, I have a source file loaded into VirtualDub that has been captured in the HuffYUV(YUY2)(AVI) codec.

1. Now I think about filters and interleaving(interlaced, interlacing)...
Do filters such as temporal smoother, HSV Adjust(it's only an example) in VirtualDub, change interlaced film to progressive after selecting them and processing with them(saving the movie) or do they not touch or change this matter ?

2. Depth of colors from what I guess does not affect the change of the source signal of the file (e.g. interlaced - its change). Yes ?

Each VirtualDub filter dialog allows you to set parameters for its use. Some require that you specify whether interlacing is present, some do not. Each filter makes its own adjustments. If a video enters a VirtualDub filter as interlaced, it is returned as interlaced unless the filter is a deinterlacer. Color depth and interlace ordinarily don't affect color correction, but the way a colorspace stores its data does affect the way color correction works --YUV levels and color controls don't work the same way that RGB controls do, because these two color systems store their data differently. There are very few filters that can be set to work in multiple colorspaces, but VirtualDub's gradation curves filter is one example . Most after-capture, highly detailed color correction is performed in RGB. Avisynth filters generally work in YUV, but there are several RGB functions.

For serious restoration work with analog sources, VirtualDub is essential but limited. You should learn to work also with Avisynth filters and functions, which are far more thoroughly documented than most VirtualDub features. VirtualDub source code for VDub itself and for many of the add-in filters is not available in the pre-loaded VirtuaLDub package (which I don't recommend, but it's OK for novices who want a quick start). The best way to learn what VirtualDub and Avisynth filters are doing is to use them.

Maybe you know from experience whether filters: temporal smoother(no selection in filter settings: interlace or progressive), HSV Adjust(no selection in filter settings: interlace or progressive), resize(can be choosen in filter settings: interlace) - change interlacing to progressive in VirtualDub?

I think that for example some of them can do it, but not all and I'm curious about the effect of the final file. And probably even one filter among the many used for editing that will change interlacing to progressive - "breaks" the image ... No matter how it will be set(is it going to be used as the first working filter or as the next one in turn). I think so. I might be wrong. I will probably have to check it myself in practice. But I ask because maybe you already know from experience how they behave and work these three filters about which I write.

To sum up: even if one of them will replace the image from the original (source) interlaced to a progressive image, it will lose the image quality and it makes no sense to use it in this case - if I do not want to lose the image quality. I think so. I might be wrong.

I read the guide on what to do to properly do cropping without deinterlacing.

They won't change interlacing. Not ever. Can't happen.

No, they can't.

You are. But if you feel that way, don't use ever use VirtuaLDub filters for anything.
And by the way, DO NOT USE VIRTUALDUB FILTERS DURING CAPTURE.

VirtualDub capture doesn't deinterlace. Deinterlace operations are performed after capture. Always. And you should have a good reason for doing so. Software deinterlacing is a destructive process that is used only when necessary, such as required for special filtering, repair, or web posting. The best deinterlacer is Avisynth's QTGMC. It is much higher quality than VirtualDub's yadif.

I don't want use filters during capture.
I know that VirtulDub capture doesn't deinterlace and that it's possible to do after capturing(deinterlacing).

I meant about it:

"[...]
^ Enter the Cropping function on the Filters page, and alter the X and Y dimensions. Always select in multiples of 2. Otherwise you'll mess up the interlacing.

The X is left and right, and Y is top and bottom. Ideally you hide 8 pixels removed from each side.
At 352x resolutions, you don't really want to hide more than 12 on the Y (24 total) or 12 on the X (24 total).
At 704/720x resolutions, you don't want to hide more than 12 on the Y (24 total) or 20 on the X (40 total).
Hiding more pixels may show black edges on the screen, as you've left the overscan, and are now within the TV image area.
Note: You do NOT have to select the same numbers for each box, as sometimes the picture is shifted badly within the signal. This is where you can not only hide the overscan noise, but fix the image offset at the same time. Also understand that it's the total number that counts when hiding pixels. If you remove only 4 pixels on a Y side, you can remove 20 from the other side, and the picture will re-center itself, with a net overscan hidden of 12 pixels per side.
[...]"

Source of quote: http://www.digitalfaq.com/forum/vide...html#post20820
----------------------------------------------------------------------------------------------------
It's good news that these (three)filters are unlikely to change progressive to interleaving.
But, for example, filter: "resize" works in the color space: YV16 as far as I know(I dont' know is it possible to change it - I tried but I couldn't). [Yes, can choose options in the filter settings: "Interlaced" - but does it really work - I do not know.].

A "YV16 is a planar YUV image format with 4:2:2 sampling. YV16 is the planar equivalent of YUY2.[...]"
And "planar" means that:
"Planar image format is a format for storing images where each color component needed to represent a pixel is placed at a separate place (block) in memory. This is in contrast with how interleaved images are stored in memory. [...]"

Source of quotes:
http://avisynth.nl/index.php/YV16
http://avisynth.nl/index.php/Planar

Also, I don't know if it will only change the color space or too interlacing (the original file is interlaced (YUY2)) ?

[When changing for example: from YUY2 to RGB, does the color space change work like in the case described above ?]

EDIT:

Now I see that it's possible to change this YV16 color depth in the filter: "resize"... This color space changes depending on the setting: Video - Color Depth - Output format to compressor/display(and: Decompression format)...

I don't use VirtualDub for cropping or resizing. Someone who uses that method will probably be able to answer your questions about it.

I checked the "operation" of these filters with different codecs and settings and if captured, the original file (HuffYUV, YUY2, AVI) is shown as interlaced through MediaInfo, so this file after attempting different passes through VirtualDub: no (does not show is it is interlaced or it is progressive).
I know this doesn't have to mean that the file is not interlaced, but...

You can't always go by MediaInfo, especially with processed lossless AVI which does not have interlace flags in its data. You have been given tips and instructions on how to inspect the frame structure of videos in several earlier posts.

This thread is starting to feel like this: :wall2:

PAL = 720x576
NTSC = 720x480

Capture that.
No further discussion needed.
Resize post-capture, if needed, noting interlace resize concerns if you adjust the x480/576 axis.

Only that, as I wrote, the original captured file(raw) in HuffYUV(AVI; YUY2)(and for example: raw DV AVI - Type 2; YUV 4:2:0 - even with data which field is first) is shown in MediaInfo as interlaced material.
Files "converted" again even in the same codec(through VD for example) probably do not have this information in MediaInfo anymore (maybe I checked it "all situations"; I can't remember for sure). At least the ones I remember didn't have it.

It's been mentioned before, but I'll present it again:

DV = BFF.
Everything else is almost always TFF.

MediaInfo doesn't always show interlace information. Also, most un-encoded lossless Avi files do not not have interlace information embedded in its internal data. Learn to analyze video yourself if you are uncertain. Neuron2_How To Analyze Video Frame Structure.zip

I know that. I didn't ask about it. But thanks for repeating this information for record.
Ok, thank you for information.

Sorry to revive old post but I was looking for this questions and wanted to ask some doubts I got or I might have forgotten along the time.

First, the source:
VHS captures should be done using YUV, correct? or should I set the Pixel format to YV12 too? (either for PAL or NTSC)

Minidv transfers are YV12, correct?

Avisynth:
Some scripts prefer YV12, others YUV, so conversion is done as necessary. That's clear.

My doubt comes here.
I see sanlyn posted he converts to RGB in the last step of the script to then work with the file in VDub.

Question: In the case I dont need to apply Vdub filters, should I convert it to RGB still? or should I convert it to YUV or YV12 in the last avisynth's step and then do the final export?

Final export: regarding the final export. I export using lagarith.

Question: In Compression -> Configure I need to change the MODE to RGB, or whatever the color space I am using at the end of the Avisynth script, correct?


In my particular case I already exported a file in YUV 4:2:2.
I need to convert it to YV12, to do the final conversion to MP4, right?

Question: Should I make a avisynth script like sanlyn mentioned, to open the file in the correct color space?:
And change the Compression settings to
Configure->RGB and Pixel Format to YV12. ?


Sorry for the mess and the moronic questions :o

Ofesad.

I think you might be confused about some aspects of YUV and RGB. You might want to browse two links to get a better idea of how YUV and RGB work:

YUV: https://en.wikipedia.org/wiki/YUV
RGB: https://en.wikipedia.org/wiki/RGB_color_space

Meanwhile, to avoid the heavy mathematics and to simplify matters for readers with further concerns:

YUV is a video data storage and broadcast system that stores video data in three channels: Y, U, and V. The "Y" channel stores luminance (brightness) information. The "U" ("blue") channel stores blue/green chroma information. The "V" ("red") channel stores red/yellow chroma information. Each data channel can be processed separately, meaning that luminance can be manipulated without affecting color, and vice versa.

YV12 is a specific type of YUV colorspace. There is more than one type of YV12 storage scheme (4:2:0 and 4:1:1), depending on how U and V chroma databits are stored. For every 4 units of luminance data, YV12 contains 1 unit of U data and 1 unit of V data. YV12 is the type of YUV colorspace used for DVD (MPEG). BluRay and AVCHD, both of which can be encoded using MPEG, h264, or VC-1, are encoded as YV12. Web streaming formats use various codecs and are usually encoded as YV12.

NTSC video tape uses a YPbPr analog color system whose nearest digital equivalent is YUY2. YUY2 is another specific type of YUV colorspace. YUY2 has twice the color resolution of YV12. For every 4 units of luminance data, YUY2 stores 2 units of U data and 2 units of V data. PAL video tape is basically a YV12 system but for restoration work it is captured at YUY2 for initially higher chroma resolution in the capture.

Consumer DV (as in MiniDV, etc.) is a lossy format that uses YV12. It is already a digital format for which "capture" is not recommended. Instead, DV is copied 1:1 via Firewire to DV-AVI. There is no colorpace change and no recompression of the source. Lossy DV-Avi itself is a noisy, inferior choice for restoration work, so it is not recommended for VHS capture.

RGB is a system that stores video data in three channels: Red, Green, and Blue. Rather than storing brightness data separately, brightness values are stored together with each color. Each of the three RGB channels can be adjusted separately, but adjusting color also adjusts a color's luminance at the same time, and vice versa.

RGB has 2 times the color resolution of YUY2 and 4 times the color resolution of YV12. For every 4 units of RGB brightness data in each color channel there are 4 units of chroma data. That is, each of the three RGB channels contains 8 data units (4 brightness units and 4 chroma units) for a total of 24 data bits for all three channels. In addition, some RGB formats can attach an additional 8-bit alpha (transparency) channel to form a 32-bit color system. Mainstream consumer video such as DVD and Bluray contain no alpha channel.

What do you mean by "YV12 too"? YV12 is a YUV colorspace. So is YUY2. VHS is better captured as YUY2, whether PAL or NTSC, which offers a higher initial chroma resolution for further processing.

Not quite. You haven't seen all of my scripts. I convert to RGB if I intend to apply RGB filters to Avsisynth's outpout. If I don't plan further work in RGB I don't make the conversion in the script.

No. Why would you?

YV12 is YUV.

I guess you refer to outputting a file from VirtualDub. You set the colorspace and compression for whatever colorspace you want to use for the output file. If the next step in your processing after Virtualdub is RGB, save the output as RGB. If the next step is encoding to MPEG or h264, set the output for YV12. If the next step in your output will be another script that uses YUY2, set the output for YUY2.

If you are not applying filters in VirtualDub, you do not need a conversion to RGB and you should not be using "full processing mode". Full processing mode involves an automatic conversion to RGB whether or not Virtualdub filters are used and regardless of how you set the output configuration -- so, in this particular case, the input would be converted to RGB and then go thru an additional conversion to whatever you configure as your output colorspace. To avoid that unnecessary RGB conversion, set your desired output colorspace and compression, then set the video mode to "fast recompress". When you fail to set a custom output configuration, VirtualDub's default output format is uncompressed RGB24.

Your encoder will convert to YV12.

If you don't trust the way your encoder does the YV12 downsampling from 4:2:2, you can change it with an Avisynth script, then save it out of VirtualDub as a new file by setting VDub's output for YV12 and Lagarith and using "fast recompress" mode. If your encoder software can accept input directly from Avisyhth, make the colorspace conversion in Avisynth without creating another new Avi file. More than likely your encoder will probably be OK unless you're using junk software such as Cyberlink.