I keep seeing these weird lines that I can't seem to remove. How Do I get rid of them? I tried DAA3 already.
+ Reply to Thread
Results 1 to 26 of 26
Please don't post bitmaps, use something like PNG instead (lossless compression) , or if you use BMP, at least zip them up
How was this processed ? Maybe something you did caused it ? More information on the source and what was done with it. You should provide original source samples
For the 1st & 2nd, if you mean the horizontal lines you can basically get rid of it with vinverse()
The 3rd one might not really there, it might be the method of taking screenshots (poor chroma upsampling) - another reason to provide a source sample . How did you take the screenshots? What software ?
I don't have the original source for the first 2 shots. The third shot I will post.
Original DVD shot.
How is anyone supposed to help you without knowing what you did?
I don't know if this will help.
I don't know why you think the less information you give us the better help you'll get. You've already been asked for a sample of the source, not a screenshot. What are you doing after the script? Encoding with something? Where did the screenshots come from? The script loaded into VirtualDub? After encoding with some codec? A media player?
I suspect DAA3() is the source of the problem -- it's creating jaggy edges, exacerbating something later, during encoding. But since we don't know what you're doing that's just a guess. Going through an YV12 to RGB to YV12 cycle is also causing a little blur in the colors.
Last edited by jagabo; 24th Feb 2013 at 19:49.
To be honest, I'm trying to fix the source from shots 1 and 2. I'm not sure how to cut a mkv file, without losing quality. I don't have a vob file for the source either, as I am re-encoding a bad 10-bit H.264 encode.
Last edited by mmbwdpnz; 24th Feb 2013 at 21:10. Reason: Never mind, I found a way to cut the mkv.
Our inventions are wont to be pretty toys, which distract our attention from serious things. They are but improved means to an unimproved end. -- Henry David Thoreau
As you can see, there are many small, but irritating things in this footage. I see a weird, blue, tint and vertical lines. I cleaned up some of the grain with dfftest(sigma=20). However, I am scared that I might be over blurring, or washing-out the footage.
I also, detect some color banding on the moving pillars in the second sample. I need to convert back the original aspect ratio of 720x480 4:3 as well.
Here is a sample:
Last edited by mmbwdpnz; 24th Feb 2013 at 21:33.
The original videos were 704x480, a valid DVD frame size for 4:3 DAR image playback (although someone has removed 2 pixels from the top and bottom borders, but they can be replaced).
I'm sorry, but you keep handing out mixed information. You wrote:
I don't see any weird lines, nor any color imbalance or tint other than the usual anime exaggerations and conventions. If you don't like the original tinting, change it. I don't see anything weird about the colors in these samples, and no banding either, but I do see some visible and sometimes severe luma and chroma clipping.
BTW, 720x480, 704x480, etc., are not aspect ratios. They are frame dimensions, and in this context they are made up of non-square pixels. Seen as 4:3 images in VLC player, the video displays correctly when played.
Ed: Referring to your earlier images in post #1:
Grain1.bmp matches frame 25 in your "001" mkv. Except for 2 black spots that you might be able to clean away, do you refer to the thin horizontal lines? These often appear in form or another during fade-ins ands fadeouts. You can smooth them away with medium-powered NeatVideo, or some very high-powered MCTemporalDenoise. Sometimes TTempSmooth or FluxSmoothT at default settings will smooth them.
Grain2.bmp matches frame 37 in your "001" mkv. If you mean the central figure looks out of focus, you're correct. It looks like an intentional effect to me. Isn't this supposed to be some sort of cathartic earth-tremor scene? The same effect occurs over and over for dozens of frames afterward.
Grain3.bmp. I don't know what that image is about. It's not in your samples, and I don't see anything wrong with it.
Last edited by sanlyn; 24th Feb 2013 at 23:11.Our inventions are wont to be pretty toys, which distract our attention from serious things. They are but improved means to an unimproved end. -- Henry David Thoreau
I accidently closed the window before the files loaded, so it did not appear in my post. I fixed that now, can you see the samples?
Yes, that has happened to me as well. I often curse that upload window. My post is above yours.Our inventions are wont to be pretty toys, which distract our attention from serious things. They are but improved means to an unimproved end. -- Henry David Thoreau
The samples I uploaded are untouched. In other words, absolutely no filtering has been done on them. They are the original source I am trying to fix. If you look closely you can see some grain in places with lots of motion. those weird lines are definitely there. Look at the fade in at the beginning of the first sample, that's where you can see it the most. Sorry for posting this sample as an uncompressed bitmap, it is the same screenshot from the first post.
Last edited by mmbwdpnz; 24th Feb 2013 at 23:00.
The effect you mention isn't grain. It's motion smear, and is common with lossy compression. You can strongly filter those scenes with NeatVideo, especially its mid- and low-frequency settings with high-frequency filtering turned down somewhat (some would say to use MCTemporalDenoise. Never worked for me with that kind of noise). You will need to increase the encoding bitrate for those scenes. High detail and motion require higher bitrates than scenes with less detail or less movement.
And because your project will be a re-encode, you'll never get it as clean as an original encode from an untouched master. It's not possible.
And line darkeners like FastLikeDarken will help.
Last edited by sanlyn; 24th Feb 2013 at 23:42.
Thankyou! I swear every time I post a new thread here, I learn something new! Hahahaha..... Will toon or toonlite work instead of fastlinedarken? Also, is NeatVideo available for Avisynth?
Last edited by mmbwdpnz; 25th Feb 2013 at 14:51.
There are several line darkeners. FastLineDarken is an older one that requires the old MaskTools 1.5.8 (before the release of MaskTools2), and several other useful plugins use that version. It gives less trouble to users than the newer FastLineDarkenMOD. The "toon" plugins are also older but still popular You can have the old and new MaskTools dll's in your plugins folder -- they work because the functions in each version have different names.
NeatVideo can be loaded in a script, and people do this often with other VDub plugins, but I wouldn't recommend it with NV. For one thing, you have to mount the video in VirtualDub anyway to tweak the filter's settings. Save those settings as a .vcf file, which you can read with Notepad, then copy the settings to the script. You'll see scripts posted using LoadVirtualDubPlugin to run DeFlicker, CamcorderDenoise, and others in Avisynth; NeatVideo and other plugins are loaded in a similar way (their manual has examples). However...NeatVideo is a complex filter, like MCTemporalDenoise or QTGMC. Running it in a script is slower. When run by itself, the latest NV version 3 is pretty fast for a complex heavy-hitter. I should mention that NeatVideo is a bit specialized, can be used as an excellent sharpener, and seems to be very effective on certain types of noise (such as tape noise during camera panning), but you can't just throw it at every video in sight. Most people use high settings that destroy detail. Like MCTD and others, it's a learning process; don't use it at its defaults, it can be too powerful. I find it essential for VHS captures, but I don't use it all the time. Often you can do everything in Avisynth. NV requires 2 external settings files: a noise sample and a noise settings file. There are a couple of complicated Avisynth plugins with similar sampling requirements, but their settings aren't kept in a separate file. NV comes with a PDF manual that is very extensive.
I was able to get clean video in some scenes from your samples, without NeatVideo. Yes, it works only in RGB and has settings for progressive or interlaced source. It's not a problem to reconvert back to YUV, but that would be a last step. Do all your YUV work first, then go to RGB for everything else (if required). Don't change color spaces back and forth when not required. Limit those conversions to as few as possible. If done correctly in a script, it works well. Avoid allowing other apps to make those conversions "automatically"; do it properly in a script.
NV comes in several versions, with free trials. The Home Edition can be used with video up to 1280x720. For bigger frames, you need the Pro version. But since NV is almost always used for analog transfers that wouldn't be upsampled to larger HD frames, the Home Edition is sufficient for most users. And 1280x720 is BD and AVCHD compliant. I can try to post a sample using your videos, but it might take a while -- I am repairing a client's PC for most of today but will try to get to it.
Your sample videos are not in terrible shape. We've seen far worse, so the project should go well. You might have to work some scenes separately and patch them back in, but that's done all the time.
I'm not sure what you're referring to in the last screenshot, but if you meant the obscured lines in the pink hair - that's from oversaturation causing the colors to bleed over the lines in some areas. It's a stylistic choice, but many scenes are not broadcast "legal". I would consider adjusting the saturation before looking at some line darkeners or use some combination
And keep in mind that you're working in YV12 so the colors are encoded at half (both dimensions) the resolution of the luma. So your 720x480 video has colors encoded at 360x240.
The saturation and luma clipping are out of bounds in most of the videos. I've been playing with it and curbing saturation (among other things), but found that messing around with the lines too much makes them ragged -- a typical problem with previously encoded source. Recreating detail that no longer exists isn't possible. This stuff can be "improved", I think, but making it look like an original master with no previous processing/encoding is out of the question. Dehalo_alpha seems to even things up a bit, but adding more line stuff (SangNom, awarpsharp, etc.) very nearly undid the work.
That scene is moving so fast, anyone who could see defects during play is a savant worthy of the biggest-paying talk shows and could work big-time in the space program. And I'm aware that many editor viewing windows (such as VirtualDub) can wreck lines when zooming-in on details.
And on top of that the videos aren't BD or AVCHD compliant for standard disc (I don't think). It seems it was originally 704x480 23.97 + pulldown for DVD. I don't know what the O.P.'s plans are for final output. If it's resized to 720x480 as-is, or borders added to make it so, the video won't display as 4:3 without some work. Or will it?
Sorry to say, I am at a complete loss here. Hahahaha !!! Yes, I too noticed that the video was a little oversaturated. However, I don't understand if I'm suppose to use NeatVideo or not. Sanlyn mentioned something about repairing line and detail damage with SangNom, awarpsharp, and Dehalo_alpha. Exactly what filter settings were you using? Also, I would prefer not to convert the video color spaces at all. I find that doing so will completely destroy my footage; such as it did in earlier encodes of mine. The last time I attempted to convert color spaces was with SmartSmoother1.1. I believe that the script to load the VirtualDub plugin looked something like this:
LoadVirtualDubPlugin("g:\Program files\VirtualDub\plugins\smooth.vdf","SmartSmooth" )
SmartSmooth(5, 25, 0) # diameter, threshold, interlaced
ConvertToYV12() # optional, back to YV12
Sorry for the delay, I was at work. I spent a couple of hours with various filters and encoders, and wondred why everything looked worse. So I took a look at the bitrate of the original encode: 1398 kbps.
Someone must have been joking. 1398 ? ? Your video is bit-starved. If you were working with more databits amd/or a pristine original, that sort of miserly bitrate might work. But not here. Any smoothi8ng you do (for instand, with dfttest) will remove grain, which is all this video has to work with in large, flat color areas. Remove the grain, and banding is all that's left. Add grain to mask the missing color data and you're back where you started, motion noise and all. IMO this video looks about as good as it ever will. I'd leave it as-is.
Meanwhile, the only filter I used that was able to smooth your "lines" in the fade-in/fade-out shots was NeatVideo. But I wouldn't use it or any other strong filters on other parts of the video, unless you enjoy banding and simmering block noise. These are caused by bit-starved compression. I also had results with MCTemporalDenoise on "medium", but the image is softened and banding still resulted when re-encoding.
Because a colorspace change to RGB and back to YV12 wouldn't be worth the effort, I'd suggest MCTemporalDenoise(settings="medium",edgeclean=true ,enhance=true,deblock=true) -- but not for the entire video.
Last edited by sanlyn; 25th Feb 2013 at 20:24.
Thank-you for trying! Haven't been on here in a while!