VideoHelp Forum
+ Reply to Thread
Page 4 of 4
FirstFirst ... 2 3 4
Results 91 to 102 of 102
Thread
  1. Member
    Join Date
    Jul 2016
    Location
    USA
    Search Comp PM
    Originally Posted by jagabo View Post
    That crushing of brights is not expected with TFM().TDecimate(). Can you upload a short sample of the source? You can use DgIndex to mark and demux a short segment (no reencoding). Then upload the m2v file.
    Sure thing, I'll cut a bit of the source up for you around that section.
    Quote Quote  
  2. Member
    Join Date
    Jul 2016
    Location
    USA
    Search Comp PM
    Originally Posted by jagabo View Post
    That crushing of brights is not expected with TFM().TDecimate(). Can you upload a short sample of the source? You can use DgIndex to mark and demux a short segment (no reencoding). Then upload the m2v file.

    Here you go. Thanks for taking a look at it
    Image Attached Files
    Quote Quote  
  3. manono was right, the problem is your source has brights over Y=235 and those are being crushed upon display with some editors/players. The black level doesn't look right either -- but I don't want to judge just from this short clip (which maybe wasn't meant to have deep blacks). If you add ColorYUV(gain_y=-20) or ColorYUV(off_y=-20) you will tame those bright areas. But what you really need to do is capture again with video proc amp settings that don't blow out the brights. Original and ColorYUV(gain_y=-20):

    Image
    [Attachment 40231 - Click to enlarge]


    I recommend you learn to use AviSynth's Historgram() function to check your levels.
    Quote Quote  
  4. Originally Posted by CED View Post
    Originally Posted by jagabo View Post
    That crushing of brights is not expected with TFM().TDecimate(). Can you upload a short sample of the source? You can use DgIndex to mark and demux a short segment (no reencoding). Then upload the m2v file.

    Here you go.
    No, here we don't go. He said to use DGindex to cut out an M2V.

    Edit: jagabo used the MKV but surely you have DGindex on your computer? And it's just as easy to do it the way he asked as to cut a piece into an MKV. And we have to demux (I do, anyway), adding an extra step before working with it.
    Quote Quote  
  5. Member
    Join Date
    Jul 2016
    Location
    USA
    Search Comp PM
    Originally Posted by jagabo View Post
    manono was right, the problem is your source has brights over Y=235 and those are being crushed upon display with some editors/players. The black level doesn't look right either -- but I don't want to judge just from this short clip (which maybe wasn't meant to have deep blacks). If you add ColorYUV(gain_y=-20) or ColorYUV(off_y=-20) you will tame those bright areas. But what you really need to do is capture again with video proc amp settings that don't blow out the brights. Original and ColorYUV(gain_y=-20):
    Hmm, not much I can do on the capture with that one. The source is a commercial VHS tape and the capture device was the ES15 set to Darker input on the composite. I agree it appears hot, and that's true throughout the video. Also, in this particular case, the tape was ripped when it rewound, so... that's probably the last time it will be captured.

    Originally Posted by jagabo View Post
    I recommend you learn to use AviSynth's Historgram() function to check your levels.
    Sure, I can use that. Do you have any thoughts on why that video I sent you displays fine within VLC, regardless of the number of copies opened? It doesn't seem to be an overlay issue. However, the output from AVISynth/VDub seems to be the only file that has the display issue. (Note there are 3 copies of the file I sent you and 1of the TFM/Decimate version in the image).

    Image
    [Attachment 40232 - Click to enlarge]


    The issue is also present in VEGAS if rendered side by side (didn't take time to correct their size/aspect ratio):

    Image
    [Attachment 40233 - Click to enlarge]
    Quote Quote  
  6. The difference in display with different programs has to do with how the programs and graphics drivers are set up. Basically, all YUV video uses a limited range where Y=16 is full black, Y=235 is full white. At playback that range is expanded to RGB=0 for black, RGB=255 for white. Y values below 16 all become the same shade of black, Y values over 235 all become the same shade of white (ie, your video isn't supposed to have those out-of-range values). You need to make sure your players and graphics card are set up to make this conversion correctly.

    https://forum.videohelp.com/threads/374734-Superblacks-and-superwhites-question?p=24145...=1#post2414529
    Quote Quote  
  7. Member
    Join Date
    Jul 2016
    Location
    USA
    Search Comp PM
    I've looked at the histogram in AVIsynth and I've also pulled the video into Resolve and looked at the channel histograms. It does seem that the birghtness is getting clipped. I'm curious what's causing that though as reducing the gain causes the crushed brights to separate out, which seems to point to there being different data for them in the file (it's not completely crushed out in the file, e.g., those pixels that are displaying maximum intensity aren't all set to the same value). Also, since VLC and VEGAS can display the original capture without crushing the brights... what's pushing them up in VirtualDub/AVIsynth/Resolve?

    Just trying to understand what's happening there. What's causing the same data to be displayed differently depending on the program and file format?

    Image
    [Attachment 40234 - Click to enlarge]


    Image
    [Attachment 40235 - Click to enlarge]


    Also, I noticed that the AVIsynth output has the crushed brights burned in - reducing the gain will no longer fix them after the video's been processed by AVIsynth:

    Image
    [Attachment 40236 - Click to enlarge]
    Quote Quote  
  8. Member
    Join Date
    Jul 2016
    Location
    USA
    Search Comp PM
    This first Resolve image in my post should have been this. The first and second are duplicated above. The clip as it appears without applying the Gain reduction node:

    Image
    [Attachment 40237 - Click to enlarge]
    Quote Quote  
  9. Member
    Join Date
    Jul 2016
    Location
    USA
    Search Comp PM
    A good summary of what I'm seeing:

    Image
    [Attachment 40238 - Click to enlarge]
    Quote Quote  
  10. Your graph of AviSynth's output isn't directly from AviSynth -- you saved the video with an editor and that crushed the brights.
    Quote Quote  
  11. Member
    Join Date
    Jul 2016
    Location
    USA
    Search Comp PM
    Originally Posted by jagabo View Post
    Your graph of AviSynth's output isn't directly from AviSynth -- you saved the video with an editor and that crushed the brights.
    Ah, that would be VirtualDub.

    I'll work on getting the gain within acceptable levels across the video and redo the processing on it. Thanks again for your insights
    Quote Quote  
  12. Originally Posted by CED View Post
    Originally Posted by jagabo View Post
    Your graph of AviSynth's output isn't directly from AviSynth -- you saved the video with an editor and that crushed the brights.
    Ah, that would be VirtualDub.
    By default VirtualDub will convert incoming YUV to RGB with a rec.601 matrix, crushing the superbrights and superdarks. Adjust levels in your AviSynth script before giving the video to VirtualDub to avoid the crushing. Or Use VirtualDub in Video -> Direct Stream Copy mode to get around that. Of course, if you do that you can't filter with VirtualDub.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!