This all started with a JPG picture of the back of a standard shotgun target, taken by Chet. This picture was converted to a BMP file by the simple expedient of saving it in Paint. No sophisticated image processing was done. And we have our completely synthetic picture, which is one that we drew using the data we had gleaned from the BMP file. Small versions of these are seen below: you can click on each one to see or download the full file. <table border="1">
</table> Clicking back and forth between these, you’ll see that they are quite similar. However, you’ll also notice that there are visible shot holes on the original JPG that are not in the BMP, and that therefore do not show up in the synthetic picture either.
For example, in the large JPG, if you’ll look on the right side of the second fold rectangle from the left, in the top row, you’ll notice a white artifact. There’s another one two rectangles down below. These are discernibly shot holes when you look at the paper. The paper has torn a little round flap, and then been pushed back, and the little caps somehow caught the light in the photography.
When the picture was converted to BMP – Chet just told Paint to make it a B/W picture – these little white marks converted to white. Since our program looks for black dots … these hits are invisible to us.
You’ll also notice some relatively insignificant specs. There are some in the neighborhood of the upper white one, for example. These are shot hits, but they were too small for the BMP conversion to find them, so they are absent from the BMP and of course from the synthetic picture as well.
We haven’t noticed any black spots in the picture that shouldn’t be there, but when you see how clear the creases in the paper are, it’s not hard to imagine that there could be some. You can even see a circle that’s on the front of the target, through the paper, in the JPG.
What To Do?
Some folks are thinking that we need to do more sophisticated image processing on these pictures. There are surely all kinds of nifty mathematical operations that could be performed.
We have something simpler in mind: using better target paper, and taking better pictures. Perhaps dark colored paper, on top of a light box, resulting in white holes on black. We also have in mind using a camera with a non-lossy format available, since JPG loses information before you ever get to see it.
I'm not sure whether this has been mentioned before: Our product vision is that a kit is sent out, consisting of a strong tube containing a few target sheets of our own design. The shooter blasts them, rolls them back up, and sends them back. The mailing tube ensures that we won't have as many fold artifacts, and we'll choose the paper to give the best shot pattern possible. The sheets are photographed and processed on our site, and we send the shooter a comprehensive report, describing the results and observations, with words, numbers, and graphs. (And perhaps, eight by ten color glossy photos with circles and arrows and a paragraph on the back of each one, saying what each one is.)
As for improving the image, I was fiddling with PhotoShop today, and there’s a lot you can do with it to increase the visibility of things. There’s an example below.
Our approach therefore, will be to improve the quality of the paper targets we get, and of the pictures we take. If that still isn’t good enough, we’ll use PhotoShop or ImageReady, or some such tool, to increase contrast and visibility a bit. We will very likely not try to do any sophisticated mathematical work on the files.
In an important sense, this is probably our main point:
No Actual Humans Were Harmed in the Making of This Program
We are envisioning this program being built by actual humans. Some guy who knows about shotguns and trap shooting gets an idea for a product / service that other shooters might buy. He digs up a programmer or two, and they set out to build the software.
We’re trying to show how we think these people should proceed, by showing how we would proceed, working as simply and directly as possible. In particular, we’re assuming that the shotgun guy isn’t quite lucky enough to find programmers with dual advanced degrees in math and computer science, lots of experience in at least some aspects of graphics, and awesome connections like you, our readers, all willing to help, available on the Internet. Furthermore, even if Chet and I did have those things, we would still be recommending proceeding as we are proceeding. We’re not being intentionally stupid or ignorant – we are being intentionally simple and direct.
This product probably doesn’t need advanced image processing. It’s trying to figure out things like where the shooter aimed relative to his point of aim, and whether there are any interesting anomalies in the pattern his gun throws. This program isn’t trying to do sophisticated analysis of the shot pattern, it’s trying to do interesting and useful displays of what is going on, from which the shooter can profit regarding his aim, and improving his gun.
When it comes down to it, this is lead shot, fired from the barrel of a gun by an explosion, flying through the air for 100 feet or so, ripping into a piece of paper. We don’t need to simulate the pellet interactions, or a host of other things that would be really interesting to do. We need to produce a series of reports and graphs that will appeal to the target market1, and that will be useful enough, and interesting enough, that they’ll tell their friends, so that our entrepreneur can sell lots of reports.
We do need to improve the uptake of information from the picture. A slightly better camera and a slightly better process of recording the picture into a file will, very likely, do the job. If it doesn’t, then maybe it’ll be time to bring in the bigger “guns”. By way of example, in ten minutes with PhotoShop, I produced this JPG, which you can click on to get the full-sized one: <table border="1">
</table> There’s a lot more information visible in the processed picture than in the original, and I’ve just scratched the surface of what can be done. I’m confident that given better starting photos, on better paper, we’ll do fine.
Therefore, we’ll not be addressing much more in the way of sophisticated – or even naive – image processing. Instead, we’ll be addressing getting good-looking analytical information out of our ShotPattern + Hit abstraction, assuming, I think righteously, that we can get the abstraction good enough to do the job for us, at reasonable price.
This will give us a look at what the product really is, what it feels like, and how it will appeal to potential buyers. It will give our customer a much better sense of what he really wants his product to be. We’ll be up front about how good the raw data is, and what the next steps will be in improving it, but right now, the issues appear to us to be the need for features, not the need for deep technology.
Frankly, I want to generalize this experience a long way. Mind you, this isn’t the first time we’ve thought about simplicity, nor the first time we’ve spoken about it. But I do thik that this kind of thinking leads to the real sweet spot in software development.
Focus on the features, on what makes the product desirable to the users and visible to the customer. Do enough technical work to be sure that your code is good and changeable, but don’t go all crazy implementing the latest and greatest stuff down at the bottom. Maybe you’ll need it someday, but maybe you won’t. For sure, however, you’ll need visible features, and the customer’s happiness, to keep on going.
We’d love to hear your thoughts and questions about this – and based on the record so far, we will. If you’re not sure you’re on my email whitelist, either respond on one of the Yahoo! lists, or include [ron] as part of the subject line on any emails to me.
So … that’s the picture as we see it from here … how does it look from where you are?
- sic. npi.
And Happy Holidays. Did you know that Halloween == Christmas? Sure does. After all, 31[OCT] == 25[DEC].