Forum Replies Created

Page 1 of 12
  • Glenn Chan

    April 10, 2009 at 9:41 pm in reply to: color space problems

    I’d also add that I normally don’t read this forum, so if anybody wants something specific answered, they should email me… glennchan [@t] gmail

    http://www.glennchan.info

  • Glenn Chan

    April 10, 2009 at 3:38 pm in reply to: color space problems

    Very simple answer:
    https://www.glennchan.info/articles/vegas/color-correction/tutorial.htm

    Use the curves method described and clip illegal colors. This is appropriate for DVDs if you want consistency in picture between different DVD players and TVs. Some DVD players and TVs will clip illegal colors… others won’t. If you have no illegal colors, then you don’t worry about that.


    What’s happening:
    As far as color spaces go, you can think of them as having a volume… the bigger the color space, the more colors it can represent (*some of these colors may be nonsensical, e.g. anything calling for negative light).

    Anything 32-bit, for practical purposes, is infinitely large.
    Next largest in volume is Y’CbCr (often mistakenly referred to as YUV), then studio RGB (RGB with 16-235 for legal levels @ 8-bit), then computer RGB (0-255).

    Because cameras record in Y’CbCr and many/most/all record some really illegal values (bad design/engineering IMO), then you get clipping occurring when you work in studio or computer RGB. (Studio RGB clips much less.) Also, if you have a cross dissolve, you can run into problems like the one you have if you don’t render both sides of the dissolve.

    In Vegas, the DV codec decodes to studio RGB internally so clipping happens there… a 32-bit project won’t “unclip” that.

    http://www.glennchan.info

  • Glenn Chan

    November 8, 2007 at 6:51 pm in reply to: Video Ref issue? Help before I jump off a bridge!

    [b]This is a great suggestion. I will try this next. When you say the tape needs to be striped to the new reference video source, do you mean I have to black and code the beginning of the tape while the HDCam SDI out is connected to the dbeta VIDEO REF in?[/b]
    Yep.

    2- The error logger can be accessed via:
    Hitting the “entry” and “menu” buttons at the same time.

    It doesn’t report everything but some errors will get reported into the error logger.

    [b]
    So now I am thinking this is a playback issue and not a recording issue. The only way to confirm this is to play the tape on another dbeta deck.[/b]
    I don’t suppose your HDCAM deck has the digital betacam playback option.

  • Glenn Chan

    November 8, 2007 at 9:28 am in reply to: Waveform “ringing” issue in downconvert

    It might be scaling artifacts… the higher-quality filters can introduce overshoot + undershoot / ringing. Maybe this is the cause?

    The Teranex device might give you control over the filtering… extremely soft filtering shouldn’t give you ringing. Although that’s not really what you want… but it might be a way of checking to see that it’s the filtering that’s causing your “problem”. But it’s not really a problem… it’s generally considered the correct way of making high quality video (because the alternatives are blurriness and aliasing, which are more objectionable).

    2- You can always insert edit over your color bars. Though if QC is not dinging you for it then that may not be necessary.

  • Glenn Chan

    November 8, 2007 at 9:19 am in reply to: Video Ref issue? Help before I jump off a bridge!

    Perhaps the video reference signal is not clean/good??? (Though it seems like you checked for that.) The fun thing about that problem is that it tends to be intermittent and take a few to several minutes to rear its ugly head. Your symptoms seem like the deck not liking the reference signal (which gives dropouts and the channel condition flashing).

    One way to check is to use another source for reference video. I think you can use a SD-SDI source with black picture as the reference source… e.g. throw a test pattern on the HDCAM, take SD-SDI off that, cable that into the ref. input on the dbeta.

    Tapes need to be striped to the new reference video source. Make sure the stop button light is not blinking.

    From what I remember, some of the switches on the deck also controls where ref. video is read from. Check the manual… it has a diagram showing the (perverse) logic. When you print to tape, it might be that the deck needs to grab reference from the video/SDI/kona (not the ref. input), and the Kona needs to grab reference from your reference source (e.g. the Aja Gen10 or some other source).

    2- Did you check the error logger? What does it say?

    3- (Maybe this’ll help, maybe it won’t)
    It might be worth taking the legalizer out of the equation. Once you have your master printed to tape, you can enable pre-read and play/record the video onto itself through the legalizer.
    **Pre-read is dangerous!! I would use an extra tape label/sticker and label the deck as having pre-read on.
    **Not legalizing the video right off the bat is also dangerous… you don’t want non-legalized masters going out before you forgot to do this.

    4- Is confidence on or off? That might help rule out tape issues. If confidence is on you can spot problems with bad heads.

  • Glenn Chan

    September 20, 2007 at 9:17 pm in reply to: Edit Decision List Out;ut

    Make sure you export via **Scripting**, not file–>save as.

    FCP may or may not need to re-capture from tape. Not sure about that.
    If you need to re-capture from tape, there are some issues to watch out for (reel naming, timecode breaks, frame accuracy of your deck).

  • Glenn Chan

    September 20, 2007 at 8:34 pm in reply to: 8 bit and 32 render

    There are essentially three modes in Vegas:

    8-bit (always 2.222 compositing gamma)
    32-bit / 2.222
    32-bit / 1.000 (this is the slowest AFAIK)

    The underlying difference is:
    8-bit mode versus 32-bit mode
    2.222 versus 1.000 compositing gamma

    There are four possible combinations, but 8-bit / 1.000 is disallowed.

    More info here:
    https://glennchan.info/articles/vegas/v8color/v8color.htm

    (No point in re-typing my own article.)
    There are some color space conversion issues to watch out for- it’s more complicated in 32-bit.

    2- The biggest difference between 8-bit and 32-bit is that it allows you to do linear light processing. See:

    https://glennchan.info/articles/vegas/linlight/linlight.htm

    But to do linear light processing you (sort of) have to go out of your way to do it.

    2b- Otherwise, the other benefit you will see is improved precision. 32-bit will get rid of banding artifacts caused by not enough bit depth in processing. (Certain other types of banding it won’t get rid of, e.g. if you start with an 8-bit source and go crazy with color curves. You need dithering to fix that.)

    Usually you don’t have problems with banding artifacts if the source is noisy or you don’t have very large gradients in your footage.

  • Glenn Chan

    September 16, 2007 at 8:25 pm in reply to: Masters “Rejected” for choma out of legal

    AFAIK… you should not be looking at the vectorscope to determine legal levels. Look at the waveform monitor with the lpass or low pass filter off. That will let you look at the composite signal (the luma and chroma modulated together).

    There is a limit to how high the composite signal can get. Usually it is 115 IRE, but it can vary from broadcaster to broadcaster and some put the limit lower.

    2- Some people just run their video through a video legalizer. If you have broadcasters that sets the limits differently then you can put different settings in the video legalizer.

    The one thing you really have to watch out for is user error- make sure you patch the video through the legalizer (including when you do insert edits).

    2b- Some NLEs also have legalizers built in. Though they may have bugs… e.g. Final Cut had a bug where the broadcast safe filter wouldn’t render when you actually render the video. So it looks like you have legal video but you actually don’t.
    Software scopes may also be inaccurate (e.g. FCP doesn’t seem to consistently show superblacks).

    I don’t have much experience with this (2b) approach.

  • Glenn Chan

    August 29, 2007 at 5:17 am in reply to: Problem with my deck

    On some DVCPRO VTRs I’ve used, they do a terrible job of playing back mini-DV (and fine with DVCPRO). There are dropouts even if the deck has time to get the tape speed right. Maybe something similar is happening??? Just a wild guess.

    Take a look at the channel condition- is it good?

  • Glenn Chan

    August 10, 2007 at 12:14 am in reply to: 16-235 vs 0-255?

    You are looking at difference color spaces…

    Y’CbCr – this is what’s sent over SDI and recorded onto digital formats like dBeta. Legal black level is always at 16(Y’), and white level at 235(Y’). Note that the unit there is Y’.
    Sometimes mistakenly called YUV. If it’s digital, they are probably referring to Y’CbCr.

    R’G’B’ – lots of computer-oriented programs use this. Legal range is usually 0-255(RGB), but is sometimes 16-235(RGB). This behaviour depends on what codec you are using to convert from RGB<-->Y’CbCr. Some codecs want to see 16-235 levels, most want to see 0-255.

    Y’UV – when the signal gets converted into an analog composite signal, the luma and chroma signals are modulated together. The resulting composite signal has limits on its levels… usually no higher than 115~120IRE and no lower than -20IRE. Some broadcasters set the limit (for max composite IRE) lower.
    For luma alone, it should usually be from 0-100 IRE (for PAL).
    One an analog hardware waveform monitor, toggling the ‘LPASS’ or low pass filter will show you either the luma, or the composite signal.

    Pay attention to the units!

    2- When it comes to composite signals, there are limits to extremely saturated + bright colors. A 255 0 0 RGB red can be illegal (even assuming your Y’CbCr/video codec wants to see 0-255 RGB levels).

Page 1 of 12

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy