View Profile
View Forum Posts
Private Message
You said you saw a problem or difference. That was between the input cineform AVI, and output MKV . So it stands to reason to upload those, or at least provide a better description of what the problem/difference isOriginally Posted by ziggy1971
But if that difference isn't there between the input cineform AVI, and output cineform AVI , then you've narrowed the problem to something you did with avisynth /megui/ x264 is causing the problem . Not vegas
This is how you problem solve, you go step by step and work your way backwards to see where/when the problem was introduced
+ Reply to Thread
Results 31 to 60 of 64
-
Last edited by poisondeathray; 7th Dec 2014 at 16:49.
-
The input avi and output mkv are the same (at least very similar)
The source avi and output avi are significantly different (ie. settings in Vegas too extreme), which I would guess is because I use the Computer RGB.
I've re-created a small portion of my timeline/Vegas project, perhaps you can take a look at it. -
Originally Posted by ziggy1971
Then that's all that really matters. How you get there isn't as important -
what is "S01-E12 - Vegetative State.avi" ? The black level isn't "black", it's about Y=30 if you look at the "black" screen at the beginning. This gives a washed out look. It looks like data has been clipped as well, or maybe the original, original source was like that ?
"_Spacer 23.976.avi" is correct for black, y=16 -
I don't know what/where you are looking to see a "y" level.
The source is from an mp4 converted with a "FFVideoSource("C:\yourfolder\yourfile.mp4")" script to avi with the CineForm codec. No other filters were used inside the avs script, to preserve as much of the original as possible.
I've read and watched several color correction tutorials on the net and none of them have described how to measure the "y" values, always RGB and Histogram.
When I said the final/output avi and mkv were the same, I meant that they were equally off the charts (both black and white extended into the brown areas of the histogram) -
Originally Posted by ziggy1971
What is "yourfile.mp4" ? You used avs script with ffms2, but then what ? How was it converted to cineform exactly? Because if that's the input file, and it was converted correctly, the levels are already messed up
You can use waveform monitor in vegas, but you have to understand that there is a switch for all the scopes in vegas, a studio RGB setup switch. This changes how it looks. So you have to understand how to use it and in what scenario
The histogram() in avisynth is turned on the side, If you use turnright().histogram().turnleft(), it will be oriented in the "usual" fashion. There are no ticks are gradations, except for the 16 and 235 markings in brown. You can use coloryuv(analyze=true) to get rough number values as well
The actual numbers aren't that important. The fact that the levels are "squished", and you're not using the 16-235 range is. You'd have to expand the range by doing a "TV to PC" conversion to make it look "normal" . Even with just histogram() you can see on "S01-E12 - Vegetative State.avi" that the levels are messed up because "black" on the first few frames isn't near the 16 mark -
This is the script:
LoadPlugin("D:\Applications\_Music-Video\Video Converters\MeGUI 2507 x86 - 2014-06-29\tools\ffms\ffms2.dll")
FFVideoSource("D:\My Videos - Originals\Everwood\Season 1\S01-E12 - Vegetative State.mp4")
#deinterlace
#crop
#resize
#denoise
Open the avs file in VirtualDub, Fast Recompress, Compression -> GoPro CineForm Codec -> Save As avi
Open resulting avi in Vegas -
So the "S01-E12 - Vegetative State.avi" was direct output from vdub ? Because it doesn't say virtualdub blah blah.. in the metadata . I'm guessing that is exported from vegas, hence the problem with the levels .
There looks to be some clipping (e.g. the shadow details in the flowers are gone, it just looks like 1 big shade of black, on the histogram() or waveform it looks like a line) - normally you'd be able to see the gradations in shades and details. This is by definition "low dynamic range" . It might have been broadcasted like that or someone messed it up -
Just for the sake of arguement, are you willing to try a sample clip?
Here is an mp4 file I got off of Youtube.
I don't know how good the color is in this video, but can we use it as a sample to go through the steps you would take to analyze it and correct the issues?
The same avs script can be used for it and I know it's quality isn't the best, but it's publicly available. -
Poor choice, because
1) this hasn't been IVTC'ed (29.97 but should be "film" rate 23.976)
2) music videos are intentionally graded a specific way, for artistic reasons . This milky washed out look is often done on purpose (but sometimes it's not because someone goofs up) . So "correcting" it might be going against what the artist or director wanted -
For Youtube the quality is pretty good.Originally Posted by ziggy1971
Check the Vevo site:
http://www.vevo.com/watch/lady-antebellum/Just-A-Kiss/USCN21100014Last edited by newpball; 7th Dec 2014 at 19:03.
-
I'll render out a good portion of the original, it just won't be 720-24p anymore; file size too big
-
Give this a try (and yes, it does say VirtualDub...)
-
Did you notice the levels on this recent one were different ? This is normal legal range, and what it should be. Interestingly those shadow areas are clipped to begin with. If this is representative of the original, that's poor production values.
I'm not sure what you're expecting ? The bottom line - just get the values in between the "goal posts" . Between Y' 16-235. So that "black" is around 16, "white" is around 235. You know how to check with histogram(). Those are general guidelines. That's the end deliverable whether it be some computer file, youtube, web, DVD, blu-ray. All have the same rules in terms of levels. If you did that, and it doesn't look right, then something is not calibrated with your display(s). If you're going for some artistic look or have other specific reasons to deviate, then of course go ahead . How you get there isn't as important, as long as you don't clip values or discard data unnecessarily
You said that you had lots of values in the "brown" area with histogram() (this indicates values less than 16, greater than 235). If you did that using a ConvertToYV12 with a PC matrix, that means you expanded the levels to become "illegal", and likely it was ok to begin with. Likely a Rec matrix would work in that scenario. If that was a YUV export, you can adjust the levels with coloryuv or smoothlevels PC to TV preset (to compress the levels back to 16-235). You can also make final fine tune adjustments with the Levels() or Smoothlevels() filter; you don't have to do it by presets -
After re-rendering some samples, adding the lines you suggested to the avs script and transcoding to mkv with x264 I have noticed some pretty big changes, probably ones that will affect the render times, for which this thread was started in the first place.
I agree that, with the video tools you've mentioned in Vegas and avs scripts, the final product does look much better, although not perfect.
Clearly the video preview window in Vegas leaves a lot to be desired. Even with the best settings the video still looks very washed out. Adjusting a secondary monitor has helped a lot also.
When I was doing research some time ago on how to do color correction, I don't understand is why so much emphasis was placed on pushing the levels (especially in the RGB Parade scope) towards the outer limits 0-255 instead of 16-235. I guess that's one of the drawbacks of trying to learn on your own, reading or watching things that are clearly inaccurate.
As for the youtube video I uploaded, I did some checking with the histogram and other scopes, it's actually not bad at all considering file size, source and so on.
Enough said, thanx for being patient and taking the time to help me understand this better.
Much appreciated...
-
Generic color correction tutorials want you to push 0-255 in RGB , because they want you to maximize the concept of "tonal range" - they want you use all the available "slots" for expression
The potential areas of confusion are the things vegas does "under the hood" . Especially YUV<=>RGB conversions, and how it handles different formats differently
Arguably the end result is the most important, so checking with histogram() . Because within vegas, even though the RGB levels might be correct, depending on the format you export, vegas often does it's own correction for what it "thinks" it should be (not only input formats, but different export formats get treated differently upon export) . So often you might have to apply a studio to RGB or vice versa before exporting. Some people also do that for the preview (depending on how you have it set up)
Cineform is supposed to get studio RGB treatment, but some versions and setups actually get computer RGB treatment in vegas. All lossless codecs get computer RGB treatment in vegas -
Thing is that a lot of footage does not have pitch black elements in scenes so why introduce them?Originally Posted by poisondeathray
Grey is beautiful!
-
I agree - That's why they are "generic" . I haven't seen the specific ones he's referring toOriginally Posted by newpball
Thing is that a lot of footage does not have pitch black elements in scenes so why introduce them?Originally Posted by poisondeathray
Grey is beautiful!
-
Now, I have another question.
When I open the Vegas rendered avi in VirtualDub the color is correct and uses the CineForm codec. However, when I make an avs script and open that in VirtualDub the colors are out of whack and the codec (File Information) says Internal DIB decoder (YUY2).
Is there any way to get the script to use the CineForm decoder instead or how do I correct this color issue? -
One trick you can do if you are in an NLE and you are a bit lost, drop a SMPTE bar diagram.
-
vdub uses 601 for the RGB conversion for the preview. Remember, you're looking at an RGB representation of the YUV data, not the actual YUV data. How that gets converted to RGB affects "what you see" . So if it looks correct with the file loaded directly, that suggests something is wrongOriginally Posted by ziggy1971
If you open up in avisynth, using AVISource, it should return YUY2, with the cineform VFW decoder . If you want to preview how it should look for the HD version , add ConvertToRGB(matrix="Rec709") temporarily -
^And that assumes that your export was the correct levels in the first place. You might have to use a PC or Rec matrix, or adjust the levels
Can you describe what "colors are out of whack" means ? is that a levels issue? Or colors shifted ? Or something else entirely ?
What you see in vegas, isn't necessarily what you get on export, expecially since you're using a YUV export, not RGB format export
Or, if you can't figure it out, upload a sample from vegas export. Use vdub in direct stream copy & cut a segment -
That's a good idea, to use test charts , internally generated bars etc...Originally Posted by newpball
One trick you can do if you are in an NLE and you are a bit lost, drop a SMPTE bar diagram.
But in Vegas it's a bit more complicated because of this Studio/ Computer RGB business. Moreover, cineform is supposed to get Studio RGB treatment, but it gets Computer treatment on some setups . So his use of cineform complicates this, because it's not necessarily consistent across all systems -
One of my computers has vegas 8 installed, and that gets computer RGB treatment with cineform. Vdub directly decodes it as RGB as well, not YUY2 , which is unexpected (you can select "null filter" in the filter list and "show image formats"). So if cineform is doing the RGB conversion using 709, before vdub touches it, then it might be ok for the HD case, that would explain why it might look ok with the file loaded directly.
This is why its better to use avisynth IMO - you can identify and control the colorspace conversions precisely and are less prone to unexpected suprises -
Sorry, don't know what this is.Originally Posted by newpball
One trick you can do if you are in an NLE and you are a bit lost, drop a SMPTE bar diagram.
On the Video Bus Track (assuming this affects all video events on the timeline) in Vegas, I added a Color Corrector FX and selected the Computer RGB to Studio RGB preset and did a test render. Checked the histogram of the resulting avi file, then encoded the clip to x264/mkv and checked the histogram again. According to this, all the histograms and "coloryuv(analyze=true)" results are very similar.
I made a minor change on the Vegas timeline because the transition from the spacer video to the clip, the 5 frame fade in at the beginning of the actual clip (after the spacer) and reset it to have no fade in. At the end (top) of the fade in the color scale matches the spacer, but because the bottom of the fade in starts at 0 it fades in from 0 up to the video levels (235).
Another way to explain it: the spacer is 1 second long (24 frames); during that first 24 frames/1 second the levels are at 16 (like you mentioned earlier) then the next frame, which is the transition to the next clip, the level drops to 0 and slowly increases for the duration of the fade in (5 frames in this case)
Now that I changed that transition and added the Color Corrector setting "Computer RGB to Studio RGB" on the Video Bus Track I get the results I'm looking for (I hope). As stated earlier, the histograms and other color monitoring values seem to fit the 16-235 range.
Unless, of course, someone can suggest something that I'm missing or should do differently. -
I guess I could keep editing in Computer RGB, render it, then use the Avisynth "ColorYUV(levels="PC->TV")" setting before encoding the final x264/mkv. Or is this not a good idea? Doing it this way would ensure the correct color space for the final product.
I did some trial runs and it seems to be very similar to the other way I explained earlier. I compared the videos with the histograms and "coloryuv(analyze=true)" numbers. -
Either way should work, it looks like cineform is decoding to computer RGB on your setup
If you edit in computer RGB, then export an RGB format, then all you should need is ConvertToYV12(matrix="Rec709")
If you export in cineform again, there is another RGB=> YUY2 exchange where vegas might change the levels so you have to double check what is happening
You know what to look for , so test it at each stage -
By this statement, do you mean render to x264 with Frameserver -> MeGUI?Originally Posted by poisondeathray
This is what I've figured out.
If I setup the project as Studio RGB and render it to CineForm, I need to add the following to Avisynth:
ConvertToRGB(matrix="rec709")
ConvertToYV12() -> MeGUI adds this...
If I setup the project as Computer RGB and render to CineForm, I need to add the following to Avisynth:
ColorYUV(levels="PC->TV")
ConvertToRGB(matrix="rec709")
ConvertToYV12()
Do I really need all this? Or can I remove some of the items?
Do I need this line at the end of each script for x264?
ConvertToYV12()
I don't know what this means as to what CineForm is decoding to. It just looks like whatever I have on the timeline is what gets rendered now. To me it sounds like it's a good thing. (WYSIWYG -> What you see is what you get)
I just gotta remember to check the results frequently, it seems that the smallest error can do a lot to the final result.
I'm interested in opinions on rendering directly to mkv with the following path:
Vegas -> Frameserver -> MeGUI
Instead of Vegas rendering to an intermediate file for encoding to mkv. -
Possibly, but it could mean any RGB format (it measn NOT the "regular" version of cineform, which is 10bit YUV 422) . e.g. Lagarith RGB, UT video RGB, or debugmode with the RGB switchOriginally Posted by ziggy1971
By this statement, do you mean render to x264 with Frameserver -> MeGUI?Originally Posted by poisondeathray
Don't convert between YUV<=>RGB unnecessarily. At each conversion you incur quality loss, and the loss compounds each timeThis is what I've figured out.
If I setup the project as Studio RGB and render it to CineForm, I need to add the following to Avisynth:
ConvertToRGB(matrix="rec709")
ConvertToYV12() -> MeGUI adds this...
If I setup the project as Computer RGB and render to CineForm, I need to add the following to Avisynth:
ColorYUV(levels="PC->TV")
ConvertToRGB(matrix="rec709")
ConvertToYV12()
Do I really need all this? Or can I remove some of the items?
Do I need this line at the end of each script for x264?
ConvertToYV12()
If you've exported Cineform, You've already converted from RGB in vegas to YUY2 (YUV 422) in cineform. You just have to check how the levels and colors and if it was done correctly. If the matrix used was correct , the colors should be correct and all you need is ConvertToYV12(). If the colors were shifted (as if Rec601 had been used), then you might need to use Colormatrix filter
Yes, important to check, that' s the key . On that setup (and Vegas 8 that I have), cineform is decoded with Rec709 to RGB before anything touches it. (It looks like the only way to access YUV cineform, what it's supposed to be, is through avisynth at least on that computer) . RGB doesn't have a problem in vegas, it's only YUV input in to vegas that causes all these issues. So what you see is what you get if you stay in RGB.I don't know what this means as to what CineForm is decoding to. It just looks like whatever I have on the timeline is what gets rendered now. To me it sounds like it's a good thing. (WYSIWYG -> What you see is what you get)
I just gotta remember to check the results frequently, it seems that the smallest error can do a lot to the final result.
If you do what you're currently doing, just frameserve in RGB. The script will be ConvertToYV12(matrix="Rec709") . Rec709 instead of PC.709 because cineform is decoded to Computer RGB in your vegas setup . If it had be using Studio RGB, then you do the same thing, except use PC.709 insteadI'm interested in opinions on rendering directly to mkv with the following path:
Vegas -> Frameserver -> MeGUI
Instead of Vegas rendering to an intermediate file for encoding to mkv.
This observation is unexpected. Are you sure of the accuracy? Because ConvertToYV12 (without any arguments) will be using Rec601. How are you previewing the final output (how are you converting to RGB for display, what matrix) ?
If I setup the project as Computer RGB and render to CineForm, I need to add the following to Avisynth:
ColorYUV(levels="PC->TV")
ConvertToRGB(matrix="rec709")
ConvertToYV12()
If you've exported cineform, find out what the levels are. You don't need to convert back to RGB and then back to YUV again. You can change the color (709 vs 601) vs. in YUV by using Colormatrix without having to go to RGBLast edited by poisondeathray; 8th Dec 2014 at 10:45.
-
Yes, MeGUI only adds this:This observation is unexpected. Are you sure of the accuracy? Because ConvertToYV12 (without any arguments) will be using Rec601.
ConvertToYV12 ()
I have no idea what matrix (or even how to check it)How are you previewing the final output (how are you converting to RGB for display, what matrix) ?
I create an avs script with FFVideoSource("E:\Videos\Pilot-muxed.mkv", threads=1)
Open it in AvsPmod and add the following:
Histogram()
coloryuv(analyze=true)
I open the avs in VirtualDub and do a quick scan of the file to check the values/histogram.
-------------If you've exported cineform, find out what the levels are. You don't need to convert back to RGB and then back to YUV again. You can change the color (709 vs 601) vs. in YUV by using Colormatrix without having to go to RGB
I am now using the following script:
ColorYUV(levels="PC->TV")
ConvertToYV12(matrix="Rec709")
After encoding to mkv, I open the file as listed above in AvsPmod using a script, and have noticed that the "Luma Y" values dip below 16 occasionally, is this normal after conversion?
Quote