One of the issues I’m having to confront in the autohalftoning work has come up before in my image-processing programming, but I’ve always sidestepped it. When I write an image-manipulation program, I try to parameterize all of the options, rather than change the code to invoke them. It makes it a lot easier to go back to a set of procedures that’s worked well, and use that as a starting point for further explorations. The problem has been keeping track of what parameters are associated with any particular processed image.
Up to now, I’ve dealt with the issue by manually assigning file names that indicate the processing. There are several problems with that approach. First, I don’t always remember to include all the parameters, or think that a few will be obvious to me when I look at the file later. Also, the parameter descriptions get pretty cryptic because I’m trying to keep the file names short. And the file names get awkwardly long anyway.
Inspired by the way that Adobe Camera Raw keeps track of the processing the user has picked for a particular raw file, I came up with a better approach than arcane, manually-created file names: sidecar files. ACR doesn’t store the output images, and uses sidecar files so that it can perform the earlier processing in their absence. That’s not quite my problem. I am perfectly happy to store the output files, I just want to be able to look at a summary of the processing steps.
I wrote a method to write sidecar files with the same names as the processed images, but in Excel format, so that they have an .xls extension instead of a .tif one. Here’s the code:
There’s another advantage of this method. I can set up the autohalftoning code to do ring-arounds on any parameter or parameters I want. Then I can go through the images, find the ones I like, and look at the sidecars to see what the process was.
I recommend this approach to anyone rolling their own image processing code.
Leave a Reply