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