Quantcast Identifying causes of a capture artifact? - digitalFAQ Forum
  #1  
04-09-2019, 04:41 PM
puleddu puleddu is offline
Premium Member
 
Join Date: Jan 2019
Location: Berlin, Germany
Posts: 20
Thanked 0 Times in 0 Posts
Hello Everyone,

After about a month of fiddling around, I managed to make my first capture.
Since December, when I started this adventure and heard about capture cards for the first time, I improved the quality of the import considerably, but I'm now stuck with the following.

There are little lines, like tiny ones when the camera makes horizontal pans.
I took a sample from the capture. I'll upload it here. Could you help me give a name to this "disease" so I can do some research on how to fix it?

Attached to this message you can find a frame capture. The effect I mentioned is obvious when looking at the leaves in the frame. I'll be uploading here a sample following the guidelines suggested in the reply to this post. Thanks for providing guidance on how to do that.

Much appreciated.


Attached Images
File Type: jpeg lines0039.jpeg (293.0 KB, 13 downloads)

Last edited by puleddu; 04-09-2019 at 05:20 PM. Reason: typo, remove external link
Reply With Quote
Someday, 12:01 PM
admin's Avatar
Ads / Sponsors
 
Join Date: ∞
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #2  
04-09-2019, 05:13 PM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,381
Thanked 1,058 Times in 883 Posts
Quote:
Originally Posted by puleddu View Post
The video can be downloaded from here https://jmp.sh/lTiQuWf as it was too big to be uploaded despite being just a few seconds long.
It's oversized because it's uncompressed RGB24. If you are capturing to uncompressed RGB, I strongly suggest that you stop doing it. Capture to YUY2 using lossless huffyuv or Lagarith compression.

If you captured to lossless compression other than RGB, avoid RGB conversion in VirtualDub by clicking "Video..." -> "Direct stream copy" before saving your sample. When using "full processing mode", VirtualDub converts to uncompressed RGB by default.

Please don't post off-site if you can post in the forum. Most members will not go to off-site posts. When your off-site post disappears, this thread will be useless.
Reply With Quote
  #3  
04-09-2019, 05:42 PM
puleddu puleddu is offline
Premium Member
 
Join Date: Jan 2019
Location: Berlin, Germany
Posts: 20
Thanked 0 Times in 0 Posts
It seems like the conversion was happening on exporting the piece I wanted to upload. The capture was actually made in a lossless compressed format thank you.

Please find a few seconds of the video attached.


Attached Files
File Type: avi lines-on-pan.avi (34.08 MB, 6 downloads)
Reply With Quote
  #4  
04-09-2019, 08:02 PM
dpalomaki dpalomaki is offline
Free Member
 
Join Date: Feb 2014
Location: VA
Posts: 776
Thanked 171 Times in 147 Posts
Looks like interlace artifacts. Your viewing system may not properly understand the file/codec.
Reply With Quote
  #5  
04-09-2019, 08:32 PM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,381
Thanked 1,058 Times in 883 Posts
Thanks for the new sample.
To add to dpalomaki's notes, the "lines" are excessive interlace combing -- common with many consumer cameras usually due to the way their shutters are designed (they had CRT's in mind). There are various fixes. I'll have a longer look and report back later.

I didn't find capture gear info anywhere, but it would be a good idea to let us know what player, tbc, and capture device you're using.
Reply With Quote
  #6  
04-10-2019, 03:00 AM
puleddu puleddu is offline
Premium Member
 
Join Date: Jan 2019
Location: Berlin, Germany
Posts: 20
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by dpalomaki
Looks like interlace artifacts. Your viewing system may not properly understand the file/codec.
I'm not sure about what you mean by 'viewing system'.
If you refer to the player, this might not be the issue, as I can see those artifacts in the VirtualDub preview window, while capturing. It isn't limited to playback. But you might be using this terminology with a wider meaning, please let me know if that's the case.

Quote:
Originally Posted by sanlyn
I didn't find capture gear info anywhere, but it would be a good idea to let us know what player, tbc, and capture device you're using.
I'm using the following setup:

Panasonic NV-FS200 -> [ Panasonic DMR-ES10/15 ] -> ATI HD 600 USB -> VirtualDub 1.9.1 on Window XP Pro SP3

The DMR-ES10 and -15 (I tried both) I put between brackets because I also tried not to have them in the chain. I didn't do to troubleshoot this issue, as I didn't think it could be the case, but to check if I'd spot any differences in general; I didn't notice any.

If any more details are needed, I'd be happy to look into the specific settings.

One thing I noticed, by exploring VirtualDub's properties, is that the property Video Format › Video Standard under the Capture pin... menu, reads NTSC_M. It sounds off, considering I'm in a PAL Country and I'm using PAL equipment. Again, this might not be relevant at all, but I thought I'd mention that.

Last edited by puleddu; 04-10-2019 at 03:07 AM. Reason: Add VirtualDub version information.
Reply With Quote
  #7  
04-10-2019, 07:56 AM
dpalomaki dpalomaki is offline
Free Member
 
Join Date: Feb 2014
Location: VA
Posts: 776
Thanked 171 Times in 147 Posts
The issue with viewing system is how it deals with interlaced material when displayed on a progressive system (e.g., a PC is normally progressive). For example VLC media player's video tab has several options as to how it displays interlaced material.

If the player simply combines two adjacent interlaced field into one progressive frame it will have the jaggies on all frames with horizontal motion.
Reply With Quote
  #8  
04-10-2019, 11:06 AM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,381
Thanked 1,058 Times in 883 Posts
Thanks for the additional capture info.

High levels of interlace noise are not unusual. In this particular case the excessive combing is mostly a result of the properties of the original camera and recording. It's made worse by equally excessive camera motion, which ultimately eats up bitrate and accentuates residual noise. It's one of many problems with with amateur video. You can't blame the player or video editors for consumer error.

Another common problem with beginning captures is invalid luminance levels. Sometimes this can be repaired, sometimes it can't. In this case the camera helped somewhat because the light levels being photographed exceeded the camera's capacity to record some of the overly bright data, resulting in some clipping of brights at the outset. During capture there was overly bright material that managed to survive the camera's exposure system, but the brights still exceed valid YUV digital video levels.

The image below is a YUV levels histogram of a typical frame from your second sample:



The #1 arrow in the histogram's upper-right corner points to out-of-spec bright values that exceed the safe video range of 16-235. The portion that exceeds the acceptable range is shown in the right-hand shaded border of the top (white) band. The histogram measures a brightness range exceeding 255. YUV values of 16-235 are expanded in RGB to 0-255. If brights in YUV already exceed 255, an RGB 0-255 display (such as a monitor or TV) cannot accept those values. So excess data values are clipped (destroyed). In a broadcast system, out-of-spec YUV values are rejected. Those values will appear distorted and can damage pro systems.

The #2 arrow in the above histogram shows that your capture device will not accept black values lower than y=16. Black clipping occurs before the signal gets into VirtualDub. In this case the clipping doesn't create much harm, but in an underexposed, night-time or interior shot the clipping would affect the dynamic contrast range of the image.

When I examined the lines-on-pan.avi sample I used Avisynth functions to correct the luminance range and contract YUV values into y=16-235, thus retrieving some of the bruight data and avoiding loss when the video is converted to RGB for display. The Avisymnth coded I used was:

Code:
ColorYUV(cont_Y=-15,off_y=-8)
Levels(16,1.0,255,16,250,dither=true,coring=false)
The resulting histogram is shown below, with all values within the y=16-235 safe zone:



In the same sample there appear to be one or more missing frames between frames 61 and 62. I was unable to locate the same problem in the larger off-site .avi, but the larger sample was unworkable anyway because of strong luminance clipping in RGB.

Quote:
Originally Posted by puleddu View Post
I'm using the following setup:

Panasonic NV-FS200 -> [ Panasonic DMR-ES10/15 ] -> ATI HD 600 USB -> VirtualDub 1.9.1 on Window XP Pro SP3

The DMR-ES10 and -15 (I tried both) I put between brackets because I also tried not to have them in the chain. I didn't do to troubleshoot this issue, as I didn't think it could be the case, but to check if I'd spot any differences in general; I didn't notice any.
Those elements aren't related to the combing effects. However, those effects and other glitches would look much worse with lesser gear. Your setup should produce very good results, far beyond average. The NV-FS200 does have a line tbc, but you might still need the pass-thru to help with outlaw tapes that refuse to track cleanly. The ES10 and Es15 aren't completely transparent but they do help to make outlaw tapes look smoother. I have an ES10 and ES15 myself and have posted samples of their use.

Quote:
Originally Posted by puleddu View Post
the property Video Format Video Standard under the Capture pin... menu, reads NTSC_M. It sounds off, considering I'm in a PAL Country and I'm using PAL equipment.
Match the video standard setting to the tape's format. Your VCR does play NTSC properly.

My basic approach for filtering the sample was to deinterlace with QTGMC to producve a 59.94fps progressive video that I saved as a YV12 lossless Lagarith file for further processing into various output formats. Note that deinterlacing, even with QTGMC, is a destructive process and isn't always required for cleanup or color work. In this case I first used SeparateFields() to clean up some edge halos and slightly fuzzy edge ringing, something you'd see with just about any tape on just about any VCR but which are very mild with your Panasonic. I followed that with QTGMC and a couple of filters to smooth combing and buzzy edge effects (vInverse2 and santiag). One side effect of QTGMC's motion compensated algorithms is that it does tend to ameliorate some source interlace shimmer and other problems. It isn't perfect, but it's better than any other deinterlacer.

From this 59.94fps progressive file (I refer to it as the "60p") I was able to produce the following:

a) I opened the 60p video in Avisynth and reinterelaced the progressive frames back into the original 29.97fps interlaced format. This was done for producing a standard DVD final delivery version. The result is attached as Lines_On_Pan_29.72i_standard_interlace_DVD.mpg. You'll see that playback is cleaner than the original, but excessive camera motion really works against us. Combing on erratic motion isn't altogether subdued, although it looks smoother on TV than on a PC. How it fits in with the rest of your movie depends on other segments that don't have so much frantic motion.

b) One method for smoothing the excess combing effect is to avoid interlace altogether -- although there are negatives attached to that. First, if you want DVD or standard def BluRay for output, you can't use progressive video or double-rtate 59.94fps. You don't want to upscale to double-rate 720p because that never looks good with low-resolution VHS and is a dead giveaway that a newbie did it -- the average HDTV can upscale much better than you can.
But a common trick for getting this 59.97fps video into DVD or SD-BluRay format is to discard alternate frames. That restores the 29.97 frame rate. The next trick is to tell your MPG or Bluray encoder to add interlace flags to the final encode, thus tricking your players into thinking your video is interlaced (many of them would play it as interlaced anyway). Besides, if this trick is good enough for the pro mastering labs it's good enough for us.

I opened the "60p" video in Avisynth and discarded all odd-numbered frames to get 29.97fps playback. Then I told my encoder to encode it as 29.97fps with embedded interlace flags and a DAR (Display Aspect Ratio) of 4:3. The big negative here is that the method discards 50% of the movie's temporal resolution. Some of the motion won't look as smooth as the interlaced version. On some playback systems this might not be seriously noticeable, on systems that aren't so smooth to begin with you might see some motion judder with all those kamikaze camera movements. But there are no combing remnants. The result is attached as Lines_On_Pan_29.97p_interlace_flags_DVD.mpg.

c) For PC or network display or for internet mounting, I opened the 60p file and resized the frames to square-pixel 640x480 (which is a 4:3 frame size). The actual playback speed is 59.94fps progressive. Audio was reduced to the typical internet rate of 44.1k. The result is attached as Lines_On_Pan_60p_4x3.mp4.

d) Alas, some setups don't make so nice with 59.94fps video even at standard definition and will balk at playing it. And some websites are still slowpokes about that frame rate. So I opened the 60p file, discarded odd-numbered frames, resized to 640x480 using Spline36resize, and encoded a 29.97fps square-pixel video. The result is attached as Lines_On_Pan_29.97p_4x3.mp4.

All of this work was done in Avisynth. It might be possible to do it in VirtualDub, but the results won't look the same. If you need some Avisynth help or details, ask here. Meanwhile the same filters might not work for other segments, but we only have only one short one to work with, so if you feel that posting more samples would be helpful, go right ahead.


Attached Images
File Type: jpg illegal luminance levels.jpg (120.6 KB, 28 downloads)
File Type: png corrected YUV levels.png (14.6 KB, 27 downloads)
Attached Files
File Type: mpg Lines_On_Pan_29.72i_standard_interlace_DVD.mpg (2.85 MB, 3 downloads)
File Type: mpg Lines_On_Pan_29.97p_interlace_flags_DVD.mpg (2.76 MB, 2 downloads)
File Type: mp4 Lines_On_Pan_60p_4x3.mp4 (2.24 MB, 2 downloads)
File Type: mp4 Lines_On_Pan_29.97p_4x3.mp4 (2.22 MB, 2 downloads)
Reply With Quote
The following users thank sanlyn for this useful post: captainvic (04-12-2019)
  #9  
04-10-2019, 11:38 AM
puleddu puleddu is offline
Premium Member
 
Join Date: Jan 2019
Location: Berlin, Germany
Posts: 20
Thanked 0 Times in 0 Posts
This is incredibly helpful information for me. I do really appreciate the time you devoted to working on this short sample and to posting such detailed explanation of the result.

I'll be trying to read and digest all this. There is a lot I need to understand before moving forward. I'll be certainly back with more questions.
For now, your post gives me a lot to work on. I'll let you know how it goes.

Thanks!

P.S. The cameraman was the 11-years old me. The kamikaze camera movements were probably performed with pride and self-satisfaction The parts where my dad was operating the camera aren't much better though video making wasn't supposed to be our path I guess
Reply With Quote
  #10  
04-10-2019, 12:55 PM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,381
Thanked 1,058 Times in 883 Posts
Don't worry too much about the wild motion and other goofs, you should see my old stuff! And some of it has even been posted in this forum, including my sister's big mistakes. In many cases it can be made to look better -- and when not, well, the overall finished product will usually turn out well with a little attention.

Don't hesitate to ask questions or post samples. You should also browse the restoration area for ideas on how some of the most horrible nightmare videos are made fit to watch.
Reply With Quote
  #11  
04-10-2019, 09:55 PM
lordsmurf's Avatar
lordsmurf lordsmurf is offline
Site Staff | Video
 
Join Date: Dec 2002
Posts: 8,211
Thanked 1,350 Times in 1,192 Posts
I've not read the thread in-depth yet, but something that always enters my mind, in terms of analog camera/VCRs for VHS, where interlacing issues appears, where PAL is the region, is that PAL/NTSC issues can cause issues. You must carefully follow the lineage/history of the footage, as well as re-verify the capture settings. For example, I'll see where somebody bought a cheap camera that was actually NTSC (example: from neighboring U.S. Army base), to use in PAL lands. Or vice versa. I've dealt with this many times, and at the studio/pro level.

Something to keep in mind.

- Did my advice help you? Then become a Premium Member and support this site.
- Find television shows, cartoons, DVDs and Blu-ray releases at the TVPast forums.
Reply With Quote
  #12  
04-11-2019, 06:01 AM
dpalomaki dpalomaki is offline
Free Member
 
Join Date: Feb 2014
Location: VA
Posts: 776
Thanked 171 Times in 147 Posts
Quote:
...video making wasn't supposed to be our path I guess...
Keep in mind that "content is king." A compelling story beats camera technique every time, and in some cases poor technique may actually add to the story. Consider the Rodney King tapes, and Blair Witch Project.
Reply With Quote
The following users thank dpalomaki for this useful post: sevarre (04-11-2019)
Reply




Tags
artifact, lines, panning

Similar Threads
Thread Thread Starter Forum Replies Last Post
Help identifying JVC VCR model? fourbanks General Discussion 2 04-25-2016 06:26 AM
Help identifying VHS/VCR artifacts? Mr.We General Discussion 9 03-17-2016 07:10 AM
Need help identifying when a CD-R was burnt shbroos Blank Media 1 09-07-2015 03:39 AM
Two VirtualDub questions: cropping artifact, file splitting start/end points ashworth080142 Restore, Filter, Improve Quality 5 07-23-2014 07:05 AM
Identifying DVD media on Macs / OSX l0.5 Leopard crescent.cal Blank Media 1 12-30-2008 04:09 PM

Thread Tools



 
All times are GMT -5. The time now is 03:39 PM