luma error on VHS restoration

[sanlyn]

I don't know what you're asking with that last question about "write files".

for the colors/brigtness:
how to test the value witout encoding alla the video ?

Most of the time one can see by looking at a video that darks are crushed and highlights are burned away. To work with levels and chroma and to see what is happening, learn to use histograms and vectorscopes. You cannot work without the proper tools -- your eyes can "see" problems but they don't know always "know" the cause.

The image below is frame 21 of your original sample post. At the right of the image are two histograms.


[Attachment 16731 - Click to enlarge]

Left histogram is Avisynth's "Levels" mode, showing the Y (luma) channel at the top, the U (blue-green) channel in the middle, and the V (red-green) channel at bottom. The white arrows indicate the border area where luma and colors will be crushed or clipped in RGB display if data falls into those borders. You can see that luma is creeping into the left-hand border (crushed darks), and luma at the right-hand side is climbing up the right wall (clipped brights). In the middle U channel, oversaturated color is against the left-hand side of the graph.

Right histogram = RGB display from VirtualDub. The graph has a section for Luma (white) and Red, Green, Blue. The luma and all three colors are crammed against the left-hand edge (darks). Red and Green (= yellow) are climbing the right-hand wall (clipped brights). Not only is the video too dark, but the contrast range is beyond the acceptable RGB 16-235 range for RGB display. This indicates crushed darks and clipped brights.

Encoders are not happy with out-of-range data values and tend to make them look worse than the original.

Below, (left) the Avisynth Levels histogram for the YUV correction in the script, and (right) the RGB histogram for colors corrected in VirtualDub. The YUV histogram shows luma and chroma brought within an acceptable range inside the borders, but look at the luma (white) channel: it is within the borders, but there is a sharp peak and cutoff at the right-hand side. This indicates a range of brights that are permanently clipped and can't be recovered. The RGB histrogram shows some blacks just outside the left-hand border, but this includes the black borders and some dark detail that can't be recovered.

[Attachment 16732 - Click to enlarge]

I have another problem :
sometime i have 15 or 20 second of bad/video, i can't use ReplaceFramesMC(4,3) for a big number of frame (especially in the soccer)
There is a way to 'correct' (just a little bit perhaps) this ?

I doubt that so many consecutive bad frames could be repaired. I would keep that part of the video in archive, but that much bad data is often dropped from the final project. You could post a short section and someone can take a look. Sadly, some problems are beyond repair.

Another question :
How to know if I need to denoise/degrain ?
visually I can't see grain or noise but the is freeware ? avi script ? that check the noise level for all the video ?

There is so much ugly noise in this video, I wonder how you cannot see it ? ?. Sometimes noise in a single still image is difficult to see, but when the video is in motion the noise changes with each frame and becomes more visible. In this case, noise is obvious. Below, a 2X zoom of the upper left corner of frame 21 of your original. Below that, the same frame after running the first script I posted.

"Grain" is not the only kind of video noise. Most video, especially if it originated as film or as analog tape, has a certain amount of grain. Remove all of it, and you destroy detail and see banding and posterization problems. The white arrows in the top image point to discoloration everywhere, especially in the whites (look at the priest's white collar). There are striations, rips, streaks, rainbows, and there is dot crawl and chroma upsampling errors on edges (look at the candle flame). Look behind the priests head, and you'll see how crushed darks get encoded as noise. Note the man beside the priest: the right edges have a visisble light halo, and a dark ghost effect to his right. Some of this was fixed in the lower iumage, but not 100%. Much of this is MJPG compression artifacts -- never copy dirty, damaged analog tape to lossy compressed formats. Cleaning it destroys much of the original signal, and the results will always have inferior definition.

[Attachment 16733 - Click to enlarge]


[Attachment 16734 - Click to enlarge]

The top original image is somewhat soft, but the bottom image -- although it looks much cleaner -- is somewhat soft as well. Why?
1. MPJPG compression destroys detail.
2. Resizing inferior video.
3. Re-encoding from lossy-encoded captures.
4. Both images have been enlarged from the original, for viewing only.
There is no way to prevent these effect in re-compression. Don't capture analog source to lossy formats.

My dark scene are blue... I think its du to my insufficient crfopping from the right, I'm rigth ?

Cropping has nothing to do with the overall color balance.

BTW, it appears that your player's video heads are worn or need cleaning.

[poisondeathray]

I'm going to take a wild guess that this "write file" business has to do with applying different filters or settings over different frame ranges based on these comments. Can you clarify your questions ?

for the colors/brigtness:
how to test the value witout encoding alla the video ?
I use SelectRangeEvery(2000, 500,2000) to obtain a sample video
but the good correction for the chruch is bad for the familly soccer
-> I understand i need to cut my video by geographical theme and ajust parameter for each theme

.
.
.

it's possible to write in a file between each pulgin ?
something like thins
define file "time.txt"
writefile ('start YUV'+ getime())
ColorYUV(cont_y=-28, off_y=-4, cont_u=-80, cont_v=-80)
writefile ('stop YUV'+ getime())

[sanlyn]

It's possible to process sections of video using AVisynth's Range() command, but it's a dreadful hassle to set up and some filters will not work with it. It's common practice to extract a portion of video with Trim(), process it, and patch it back into the video later. Sounds like trouble, but it's really the easiest way.

Problematic video that needs special attention is not a one-step proposition.

[dan59]

more than clarify , I'm doing this :
filename = ".\time.txt"
WriteFile(filename,""" "before colorYuv" """)
WriteFile(filename,""" time(" %H:%M:%S") """)
ColorYUV(cont_y=-28, off_y=-4, cont_u=-80, cont_v=-80)
WriteFile(filename,""" "after colorYuv" """)
WriteFile(filename,""" time(" %H:%M:%S") """)
WriteFile(filename,""" "before crop" """)
WriteFile(filename,""" time(" %H:%M:%S") """)
Crop(10,0,-12,-12)
WriteFile(filename,""" "after crop" """)
WriteFile(filename,""" time(" %H:%M:%S") """)

I know expert do not need this but for me a beginner, I can understood what is slow and what is fast in my script

[jagabo]

You can't get timings (encoding speed) that way. AviSynth doesn't perform one filter on all frames, then the next filter on all frames, etc. The filter chain is a pipeline, all the filters are running at the same time.

Think of it like an assembly line. Building a thousand widgets start at the first guy, gets passed to the next guy, then next guy, etc. All those guys are working at the same time. It takes all day to build all 1000 widgets. Each guy spends all day producing widgets.

To see how long each filter takes just comment out sections of the script using # at the start of the line. Then compare encoding rates. For example:

WhateverSource()
#ColorYUV(cont_y=-28, off_y=-4, cont_u=-80, cont_v=-80)
#Crop(10,0,-12,-12)

WhateverSource()
ColorYUV(cont_y=-28, off_y=-4, cont_u=-80, cont_v=-80)
#Crop(10,0,-12,-12)

WhateverSource()
ColorYUV(cont_y=-28, off_y=-4, cont_u=-80, cont_v=-80)
Crop(10,0,-12,-12)

Then compare the speed of each. Simple Filters like ColorYUV() and Crop() don't take long at all. The ones that are big killers are all the motion compensated filters like QTGMC(), MCTemporalDenoise(), etc.

If you have a multicore computer you can get speed increases by using a multithreaded build of AviSynth.