Wednesday, June 11, 2014

Automated testing of rendering code

In my blog post "TDD and 3D visualization", I wrote about a somewhat complex scenario: how to do TDD on 3D visualization. That blog post focused on visualization using high-level toolkits like Open Inventor or VTK. In that case, we don't test the rendered result. Instead, we test that the state of the scene graph is correct, and we trust the 3D toolkit to do the rendering correctly for us.

What if we write the rendering code ourselves? This may be the case if we write our own ray tracer or GPU shaders. In that case, we actually need to verify that the rendered pixels are correct.

Bitmap-based reference tests

TDD-style test-first development is not easy to do in this case, and it may not even be possible. The test result itself is much more complex than a trivial number or string result. How can we write a test that validates a complex image without having the rendered image up front?

In this case, it may be more convenient to write the rendering code first and then use a rendered image as a reference image for the test. We will loose some of the benefits of doing proper TDD, but those tests will still act as regression tests that verify that future enhancements do not introduce defects.

The production code and tests will thus be written like this:

  1. Write production code that renders to a bitmap
  2. Verify the reference image manually
  3. Write a test that compares future rendering results with this reference image
  4. Fail the test if they differ

Allow for slight differences

This may sound fairly trivial, but reference image-based tests have one major challenge: the rendered images may differ slightly because of different graphics cards and different graphics card drivers:


For example, different drivers may apply shading differently so that the colors vary between driver versions. Furthermore, antialiasing may offset the image by one pixel in either direction, and the edges may be rendered differently. We certainly don't want the tests to fail because of this, because then we stop trusting the tests.

Hence, we need to allow for small differences between the rendering result and the reference image. More specifically, we need to allow for
  • Single pixel offset
  • Small differences in color or intensity
I have been using this approach with good success:
  1. Render image
  2. For each pixel in the rendered image, find the pixel in the 3x3 neighbouring pixels in the reference image with the lowest deviation in RGB pixel value. Add this deviation to a list.
  3. Create a histogram of all the pixel deviations so that you can calculate the distribution of the errors.
  4. Decide on an error threshold for acceptable differences. For example, say that
    • A maximum of 0.1% of the pixels can have a larger RGB deviation than 50
    • A maximum of 2% of the pixels can have a larger RGB deviation than 10
    • A maximum of 20% of the pixels can have a larger RGB deviation than 3
You should start with a fairly strict tolerance. If you find that you get too many false positives, increase the tolerance slightly.

By defining a deviation distribution tolerance like this, you will allow for small variations while still catching rendering defects that cause rendering errors.

Render to bitmap, not to screen

If possible, render to an offscreen buffer in the tests. This is more robust than rendering to a window and then doing a screenshot, because the tests will not be obstructed by other windows, screensavers, locked computer, etc. This might be a good idea architectural idea anyway, as it separates rendering from display.


8 comments:

  1. I prefer to write unit tests against the intermediate code (X3D, webgl, ...) that I generate from my DSL.
    Of course, I still need some eyeball proof that the intermediate code produces the desired result.

    I guess I would need to write a regression test framework where I show the expected result from a prior image/screenshot on a separate pane/window and ask the tester: "Do you see ...?"

    ReplyDelete
  2. Not sure what DSL is. Is it a 3D modelling languange that you use to create X3D and then use it in an application?

    ReplyDelete
  3. Thanks for your informative post on selenium automation testing tool. Your article helped me a lot in understanding the future of automation testing tool and its career prospects. Selenium Training | Best Selenium training institute in Chennai

    ReplyDelete
  4. Thanks for sharing such informative article on Loadrunner Automation testing tool. This load testing tool will provide most precise information about the quality of software. Loadrunner Course in Chennai | Loadrunner training institute in Chennai

    ReplyDelete
  5. I agree with your post, the Introduction of automation testing product shortens the development life cycle. It helps the software developers and programmers to validate software application performance and behavior before deployment. You can choose testing product based on your testing requirements and functionality. QTP Course in Chennai | QTP training

    ReplyDelete
  6. Hi, this is Yasmin from Chennai. I have read your blog. Its very informative and useful blog. You have done really great job. Keep update your blog. Thanks..
    Regards.
    Selenium Training in Chennai | Selenium Training in Chennai

    ReplyDelete
  7. Awesome article to nice sharing Training and certification on courses helps you to study this technology in feature selenium training in chennai

    ReplyDelete
  8. This TDD and 3D visualization techniques are very useful and is easy to understand to read the contents.
    SAP ABAP Training in Chennai

    ReplyDelete