git.sesse.net Git - nageru-docs/blob - analyzer.rst

   1 The frame analyzer
   2 ==================
   3
   4 Maintaining signal integrity throughout a chain can be surprisingly tricky;
   5 a number of quite devices, even expensive ones, do not properly pass
   6 input pixels unchanged to the output even when no processing is requested.
   7 (Commonly, this is due to misunderstandings of how Y'CbCr is to be calculated,
   8 or that one end or the other is doing something wrong in the HDMI handshake.)
   9 This means that it can be useful to verify that there are no subtle color shifts,
  10 and that the entire 0–255 brightness range is both being input and output.
  11
  12 The **frame analyzer**, new in Nageru 1.6.0 and available from the video menu,
  13 can help with this.  It allows you to look at any input, grab a frame (manually
  14 or periodically), and then hover over specific pixels to look at their RGB
  15 values. When you're done, simply close it, and it will stop grabbing frames.
  16
  17 Synthetic tests and common problems
  18 -----------------------------------
  19
  20 If your input is synthetic, such as from a computer, you may want to use an
  21 image such as this one as your test source (simply right-click and save):
  22
  23 .. image:: images/wedges.png
  24
  25 This contains both whites/grays evenly spaced across the entire range
  26 (0, 13, 27, 40, 54, 67, 81, 94, 107, 121, 134, 148, 161, 174, 188, 201,
  27 215, 228, 242, 255), and the same for red, green and blue (although
  28 with slightly fewer steps: 255, 238, 221, 204, 187, 170, 153, 136,
  29 119, 102, 85, 68, 51, 34, 17, 0). (You can also use any other picture
  30 where you know the right pixel values, of course.)
  31
  32 Using the frame analyzer, you can simply look at each value to see if the input
  33 matches the expected values. Being off-by-one (or even occasionally two)
  34 is normal due to Y'CbCr rounding errors, but more than this indicates that
  35 something in your chain is doing something wrong with the pixel values.
  36 Common errors include:
  37
  38   * Dark values becoming entirely black (crushed blacks), and similarly
  39     with light values becoming entirely white (blown-out highlights).
  40     This indicates full-range input being interpreted as limited-range.
  41   * Black becoming some non-black dark (e.g. 16) or white becoming some
  42     non-white light (e.g. 235). This indicates the opposite problem,
  43     i.e., limited-range input being interpreted as full-range. Nageru
  44     never defaults to full input range, so this should be rare
  45     unless you set full range yourself.
  46   * Pure-color inputs no longer being pure-color (e.g. a pure red
  47     getting some green and blue). This indicates wrong choice of Y'CbCr
  48     coefficients.
  49   * Black and white coming through correctly, but midtones being too
  50     light or too dark. This indicates a wrong gamma ramp.
  51
  52 Nageru cannot correct arbitrary input problems, but the most common ones
  53 can be fixed by selecting a different *input interpretation* for the card in question.
  54 Simply right-click the input, and you can choose from a variety of
  55 different ones. Optionally, check the settings on your sending device
  56 to see if they can be corrected, as this is usually a better choice
  57 than forcing Nageru to interpret the output in a nonstandard way.
  58
  59
  60 Non-synthetic inputs
  61 --------------------
  62
  63 If your input is non-synthetic, like a camera, it is harder to spot
  64 problems. However, the *RGB histogram* can sometimes be of help,
  65 especially when it comes to spotting range problems. For instance,
  66 limited range being wrongly interpreted as full range will look
  67 something like the picture on the right, where the lower and upper
  68 ranges are unused (although sometimes, it only affects the lower
  69 part):
  70
  71 .. image:: images/rgb-histogram.png
  72
  73 (Note that even side-by-side, it's not that easy to spot how much duller the
  74 image on the right is without looking at the histogram. However, when switching
  75 back and forth, for instance between multiple cameras of the same scene,
  76 the difference can be quite dramatic.)
  77
  78 Similarly, if your scene is over- or underexposed, you may see values piling up
  79 near the one of extremes (0 or 255). If this persists, it usually means you
  80 should adjust the exposure on your camera if possible. If the exposure is
  81 correctly set, or you see values piling up on *both* 0 and 255 at the same
  82 time, it may either mean that the scene has too much dynamic range for your
  83 camera to handle, or that it sends full-range Y'CbCr when it should have been
  84 sending limited-range.
  85
  86 Finally, note that the section on :ref:`measuring HDMI/SDI latency <measuring-latency>`
  87 describes another useful trick (looping) you can use to verify correctness, assuming
  88 you have a card capable of HDMI/SDI output.