Now here is a little protocol for definition testing: Get his first: http://www.graphics.cornell.edu/~westin/misc/ISO_12233-reschart.pdf
Print it 350 dpi min, 600 recommended.
Place it in a well lit spot, in the sun for example, fixed to the wall. Use a spirit level. Place your camera with the optical axis perpendicular to the plane of the testchart (measure hight, use spirit level).
You should not see the white triangles on the underscanned image. No white triangle pointing into the image, the black triangles should ideally be pointing to the perfect edge of the screen.
To test the resolution/definition on the full breadth of the lens, do a test at wide angle, mid, and full tele, placing camera/testchart at the right distance for the scale to be right.
It would be equally important to test each focal at iris values 1.6, 2.8, 4, 5.6, 8, 11 to have a good idea of how definition rises and falls when you stop down.
To do this, use the “aperture prioriy” or “Av” program mode on your camera for correct exposure.
The definition of your camera, horizontal & vertical being distinct, is read by following the lines along the higher numbers ; the number where you cannot distinguish them from one another is your definition, in n x 100 lines. (Make sure you zoom into digitalised footage to measure the image, and not your screen !)
Now I have to admit that I didn’t quite go through with all of the different angles and apertures, and I’m not entirely certain that the resolution chart was printed to the correct size, but it doesn’t matter, as the difference between different shooting modes is obvious, even without meticulous shooting and calibration.
The images created by this process are reasonably large (1920×1080 to be precise), so I’m going to offer some small crops to discuss, and then offer up the full size images for download and examination at the end of the piece, if the mood takes you.
First up, a couple of 1:1 crops taken from the uncompressed HDMI output of the camera. This is with no HDV compression, so apart from JPG compression for the web these are the pixels as seen by the sensor. Obviously the lighting is a little low, but you can see that the resolution goes down to around 800 lines before it starts getting difficult to distinguish. All of the numbers and markings are easy to distinguish, and there aren’t any hugely obvious compression artifacts.
Now to a 3-second burst from the Smooth Slow Record function. Once again this is taken from HDMI (an aside, Smooth Slow Record outputs through HDMI as well as to tape, so you can record it direct to disk with an input card such as the Blackmagic Decklink), so this is just the camera’s CMOS resolution squashing to get those extra FPS. It’s quite a marked difference, Numbers are almost illegible, and it looks like there’s around 200 lines of resolution, or 1/4 the uncompressed version. Makes sense really, as we’re getting 4 times as many frames per second, but it’s very interesting to see just how much details is lost. This should still give around 480×270, which is definitely fine for web video (as we’ve seen in previous slow-mo posts) but not really enough for SD. I think if you chose your subject well and spent some time in post-production you could take this to an SD project, but HD is out of the question without some serious effecting.
So obviously this CMOS buffering takes away some resolution. Next I tested the 6 and 12 second bursts, to see if any further resolution was lost by the longer shooting time.
As you can see, the difference is marked. Although I feel these images probably initially contained a similar pixel count from the sensor as the 3 second burst, they seem to have undergone drastic compression to fit all of those extra frames in the buffer before they’re written out to tape. These compressed frames are then upsized to 1440×1080 before they’re written to tape, which is why those compression artifacts are so prominent.
To me this isn’t really saying much we didn’t already suspect. Getting 4 times more frames per second results in losing 3/4 of the pixels per frame. It definitely doesn’t invalidate the Smooth Slow Record mode, but it does give us some parameters in which we can use it, and it’s nice to get some reasonably qualitative data on what happens in these modes.