Questions

How do you generate a large-scale and fairly precise image of a PCB, so that you can look at it for hours without straining your eyes, where do you begin?

What happens when you take a series of high resolution images of a PCB while hand-holding a DSLR, then try to stitch them together with Photoshop?

Background

A hardware schematic is a ‘road map’, that shows how all of the components on a PCB are connected.

I occasionally work on projects to create new Linux drivers for hardware that is relatively closed and proprietary, where we don’t have access to hardware schematics.

Having the schematic is ideal but more often than not, the manufacturer is unwilling to provide schematics, datasheets or other support materials without signing highly restrictive Non-Disclosure Agreements.

Developers need a good understanding of the hardware to be able to create useful drivers. The project becomes much more difficult without a schematic and an understanding of how the hardware components are wired together. Occasionally I make a PCB image for a commercial project, other times I’m simply curious so I poke around some random piece of hardware to understand it, to see what we can learn.

In early 2011 I took on a project to create a Linux driver for the AverMedia H727 HD capture card. The project was for a UK customer, it was not funded in any way by the hardware manufacturer. The card itself is now sold in a couple of variations, with and without a DVB-T digital TV tuner/demodulator. Both versions support raw video capture from standard definition 720x480/576 up to 1920x1080i on HDMI and Component inputs, as well as traditional standard definition resolutions via svideo / composite. The card has some interesting capabilities.

To support the project I needed a schematic or something close to it.

This article describes how I generated an image of the PCB along with the tools and processes involved.

While I didn’t end up with a schematic, the final image did contain enough detailed hardware information that I found it invaluable.

Goals

1. Generate an image or floor plan of the PCB top layer, showing the interconnects between the PCIe Controller, the Component Video Decoder and the HDMI Video Receiver.

2. The image should contain enough detail so that I can zoom in to pin-level details. I expected to follow traces all over the board, print, snapshot and comment on routes, marking them up on paper with notes and comments. I’d later archive these paper records along with the other project notes.

3. Avoid using a magnification eyepiece in order to inspect the PCB. Over long periods of time they tend to strain your eyes. This would allow me to look at the PCB in great detail during extended debugging sessions.

The device had some other interesting components, some small analog-to-digital audio sampling devices. I needed to understand how all of these parts were wired, and ultimately how they were being controlled.

The Procedure

Here’s the procedure I used along with commentary from 2011 and 2015. I’ve left it in as you may find it interesting. I’ll close the article by highlighting any mistakes and pointing out any lessons learned.

Step 1: Take a sample picture and see how much detail you get from the camera

I happen to have a Nikon D7000 DSLR. I’d picked up a AF Micro Nikkor 60mm Macro lens from eBay a while before this, mainly for nature photography. I pulled out the camera, hand held it, no tripod or stabilization rig, placed the PCB on the bench and took a shot of a small part of it.

You don’t need an expensive camera but you do need a macro lens to get higher levels of detail.

Here’s an example macro photo, DSC_1803.jpg with a shallow depth of field, blurry cap tops but perfect PCB focus.

This is a 4928 x 3264 (16m pixel) shot of a small part of the PCB. I got to thinking, “what would happen if I took 80 or so similar shots and stitched them altogether?”

I loaded the image into photoshop and looked at the detail. Not Bad, an awkward shallow depth of field was noticable and my light wasn’t perfect. The picture was promising so I continued.

Step 2: Take a number of photos then capture each part of the PCB

I took another 7 shots of the PCB starting from the top right hand side and slowly moving the camera vertically down to the bottom right, imaging a strip of the PCB with a 30% overlap between images.

After I reached the end of the strip, I moved the camera left and back to the top of the PCB, imaging the next strip, making sure that I had roughly 30-40% of the strip to the right hand side inside the shots of this new strip. This over sampling of data would produce useful tracking and reference points when I expected to process the images in PhotoShop. I expected it would correctly align and join the images based on this oversampled pixel data.

All in all I scanned 10 strips, slowly digitizing the PCB from right to left, each with 7-8 images, roughly 80 JPG images for the top layer of the PCB. 6MB per image meant I’d collected approximately 480MB of files.

Did I really need this amount of detail? No, not really. It was a saturday morning, my wife and kids were out of the house so I had a free morning to learn, experiment and make a few mistakes. By this point I was curious to see how the mornings imaging project would turn out.

DSC_1824.jpg - Above image. This is the lower left hand side of the PCIe controller. Pin sharp and looking ok for a hand held image.

DSC_1820.jpg - Above image. Blurry - look at the pin sharp detail at the top right vs the bottom left, a sure sign that I have a very small depth of field. The distance between the top right of the PCB to the cameras focal point, vs the distance of the bottom left to the same focal point was different. I was hand holding the camera. Hmm. If this continued, how would this effect the Photoshop merge? I continued regardless.

Step 3: Image merging in Photoshop

Not every tool I use is free and open source. Life is about choices and also using the right tool for the right job, or simply working with a tool that you’re comfortable with. Photoshop is a world class product that I use for various projects. I’ve used Gimp in the past, I’m simply not interested in using it for these kinds of projects.

I used a 2.8GHz 10GB Ram MacPro, 8 cores which at the time was a lot of CPU and RAM, by todays standards its average.

I started by trying to merge all 80 images simultaneously into Photoshop (CS5). This was a big mistake. It ran for 30 minutes with little feedback, it appeared to have hung. Unhappy, I gave up hope and aborted the process.

I found the best method was to merge the 7 shots from each vertical strip in Photoshop one strip at a time, breaking down the scale of the task into smaller pieces.

Here’s the settings I used, basically the defaults:

From the Menu, select File / Automate / Photomerge, select each image associated with the strip.

I numbered the strips 0-9, where the right most strip is 0 and the leftmost is 9.

Strip #0 took 2 minutes for Photoshop to Merge and the resulting composite image had dimensions of 5886 × 12532.

I saved the merged strip as strip00.psd, it was 540MB on disk. So I’d turned roughly 8 pictures of 5-6MB each into a 540MB collage. Larger than I would have anticipated and I needed to do this 9 more times.

The data Photoshop required in order to digest and produce the final composited image was significantly larger than I’d assumed. I wasn’t sure how well this whole exercise was going to end.

At this point I was committed, regardless of the outcome, so I repeated the process for all 10 strips.

Merging each subsequent strip 1-9 took around 2 minutes. 20-30 minutes later I had 80 images merged into 10 strips, saved to disk with names strip00-09.psd. Each PSD file varied in size a between 450MB and 750MB.

Step 4: Merge the Strips of images together

Then:

1. Merged strips 0+1+2+3 into strip21.psd (output file 1.27GB)
2. Merged strips 4+5 into strip22.psd (output file 720MB)
3. Merged strips 6+7 into strip23.psd (output file 780MB)
4. Merged strips 8+9 into strip24.psd (output file 680MB)

Here’s a screenshot of strip22.psd.

After producing strips 21 to 24 I consolidated again.

with:

1. Merged strips 21+22 into strip31.psd (output file 1.5GB)
2. Merged strips 23+24 into strip32.psd (output file 1.16GB)

After this I started the final merge, bringing strips 31 and 32 together to produce the final image. I Merged strips 31+32 into strip40.psb (output file 2.48GB)

PSB is apparently Adobe’s “Large Document” Photoshop document file format.

I don’t have the exact merge timing information but I’d budget 90 minutes to complete a similar merge in the future.

I took the approach of a small ‘divide and conquer’ approach with Photoshop. It wasn’t able to merge all 80 images in one session, but by slicing the problem into smaller chunks, I got photoshop working reliably, I guess much of the overlapping pixel data was being discarded after use by Photoshop, so breaking the problem into smaller chunks helped with the overall size of the dataset and thus processing requirements.

I also suspect that with more accurate camera placement I could have reduced the oversampling of pixels down from 30-40% to 10%, reducing the overall image data and therefore expediting the overall process.

Step 5: Load the final image and review

It took 38 seconds for Photoshop to load and display the final image. That’s a long time and it’s certainly the largest image I’ve ever needed to process.

Here’s a screenshot of the final image inside Photoshop. It was taken using the latest version of Photoshop (CC 2014) during Feb 2015. It took 25 seconds to load, a considerable improvement, thank you Adobe Engineering.

If you’re curious, the final image had pixel dimensions of 30448 x 16251, otherwise known as 494M/pixels. The PSB file on disk was 2.5GB.

Here’s a movie showing some basic zooming and navigation around the final Photoshop image. Not bad. Clearly some room for improvement but a great first attempt at this process.

Lets put this into perspective, a microscope could have easily improved on the resolution but by goal was to show these images on a large monitor over a period of weeks. While this project took and entire morning, the alternative was to stare at a PCB under a microscope for weeks at a time - not good for my eyes and impractical in terms of switching between the desk and bench.

How did the final image influence my work?

As the driver project progressed I referred to the PCB imagery literally hourly.

In terms of understanding the hardware, I used a mixture of debugging devices, such as affordable logic analyzers, a multi-meter and an oscilloscope. I was quickly able to deduce all of the important pins and routing information on the PCB. I could easily follow the traces between the front and rear of the board following the VIAs.

In practise, I’d zoom into small parts of the PCB and print specific areas for my paper notes. I’d scrible down thoughts and ultimately created a collection of notes about various aspects of the signalling and design. I’d find the datasheets for the analog audio encoder, look for the I2S digital audio signals and follow those through the traces into the PCIe controller. Once you’ve done this for all of the major audio, video and control buses, you start to get close to re-inventing that missing schematic.

Given the significant lack of components on the rear side of the PCB I had no need to image that side, everything I needed was generally available on the top. I did have to follow a couple of I2C traces via VIAs to the bottom and back, but that was simple enough using a traditional eyepiece.

The bottom side of the PCB was generally used for power routing, I had no immediate need to document or understand those.

Closing thoughts and Lessions Learned

My first mistake, see image above. I wish I’d taken greater care with the cameras depth of field and used a fixed camera rig to position the camera and the PCB at a fixed distance, keeping everything in focus and perfectly aligned. I held the camera by hand, which introduced too much vibration and motion. A minor mistake that lead to slightly blurry imagery, or parts of the imagery blurred.

For my next PCB scan project I’ll probably build a small rig on wheels so I can maintain a fixed focal length and aperture (to keep the images pin sharp). I’ll keep the camera on the rig and leave the PCB perfectly lit and completely parallel to the focal plane.

$30 on wood, screws and a cheap set of rollars should be enough to construct something.

My second mistake, see image above. While I said I tried to keep a 30% image overlap while photographing the board. Clearly I made a mistake and ended up with a small amount of missing (although ultimately) non-critical pixel data. This was once again the result of hand-holding the camera and not enough of an overlap between slices 0 and 1.

I don’t want to repeat this mistake in the future, as the missing pixels may be more problematic.

My next PCB scan will almost certainly use a homemade jig to help contain this kind of issue.

Note to self: I wish I could find a PCB house that would xray the board and give me a visual image of any PCB in the New York area.

It may also be possible to produce a better final merge by experimenting with Photoshops ‘Collage’ or ‘Reposition’ Photomerge modes, instead of assuming ‘Auto’ was good enough. Certainly some room for further experimentation. [Update: Its also possible that since CS5 Adobe has improved their merging technology further.]

Have you ever taken on a project like this? If so I’d love to hear from you.