Letters

Thanks for publishing the interesting article about "Threading & the .NET Framework," by Douglas Reilly (DDJ, August 2001). The article mentions the lack of context passing to threads using the standard Thread.StartThread method. However, the .NET Framework actually supports passing context to threads using the concept of Delegates. Delegates are run time-aware objects that invoke methods on other objects. A synchronous invocation through a delegate is done as in Example 1.

The interesting thing about delegates is, however, that they support asynchronous invocation with parameter passing using the BeginInvoke method. Example 1(a) can be implemented as Example 1(b). This example also has a race condition on the shared aCounter resource, since it is passed by reference to the threads. Using delegates is probably the simplest way to use threads in CLR, although as demonstrated earlier, it also easily introduces race conditions.

Kim Reidar Lantz
krz@techwise.dk

Compiling Perl/Tk Scripts

Dear DDJ,

I read Cameron Laird's article "Compiling Perl/Tk Scripts" (DDJ, May 2001) with a lot of interest. There is one point that he just skimmed but I would like to emphasize. Perl does actually compile the source into bytecode. Once this is done, according to my understanding (and please correct me if I am wrong), the source code is never revisited again in the duration of the current run. Why is that necessary to distribute the source code form that time on? Just change the Perl engine so it may save the bytecode as a file and then, in the next run, just start executing that bytecode file. If that is done, and I would assume that this should be pretty easy to implement, then a compiled version should be no more than a packaging of the Perl and Tk engines with some necessary modules and the said bytecode. More over, the Perl and Tk engines could be thought of as a prerequired run-time module (like the famous VBRUNxxx.DLL) and all you need to distribute is your bytecode, packaged with the small .EXE header that would invoke that run-time module. I am not sure as to why that was not done yet!

Ze'ev Atlas
z.atlas@verizon.net

Standing by Al's Principles

Dear DDJ,

Regarding Al Stevens's piece on "Yet Another Programming Platform" (DDJ, October 2001), I'd like to say he is right on target. Having yet to delve into GUI programming in Linux, I enjoyed his overview of the available toolkits. And while other programmers may get "squarely in his face," I would like him to know I appreciate him standing by his principles. I've never understood the Visual Basic crowd's assertion that coding in C or C++ invariably causes memory leaks. Poor programming causes memory leaks, and disciplined memory management is all that is needed to prevent them. A programmer without discipline has much more to worry about than mere memory leaks.

Pete Nelson
petie@writeme.com

Understanding Photomosaics

Dear DDJ,

Even though, as Manuel Lopez Michelone and Marcelo Perez Medel point out in their article "Understanding Photomosaics," (DDJ, November 2001), photomosaics is credited to Robert Silvers (and the pathetic patent awarded to him). I was developing photomosaic software when Mr. Silvers was still trying solid foods for the first time. I do grant him the position of being the first one to market it — and quite successfully at that. Still, this whole subject should be put in perspective. Especially when someone obtains a patent on something that was not only nonoriginal work, it was something developed using public funds.

Overall, the article is interesting. The approach I used was a bit different though. At the time I was developing software for target matching. The ability to identify and follow a given target in moving pictures. Once I was done, I figured I could use that same code for some rather more entertaining objectives (too much free time I guess). The algorithm wasn't that complicated. I would compute not only the color but also an overall vector (the type of code used now for autofocus lenses). This would separate the image database into blocks of "good candidates" for any given cell. That would be the equivalent of your "index." When time came to compute a cell, I would look for actual pixel-by-pixel similarities along with vectors. By that I mean a heuristic algorithm looking for contrast patterns. That produced a value of "confidence" for a match. The highest value would be used for each cell. Given a good database of images, you can produce an image so perfect the effect was somewhat lost. I would add some "noise" to it to "humanize" it. The quality of the images was a function of the target output. For most cases, I used very small images (128x128 pixels max). If you think in terms of printing, you would compute how large you want the cell to be and scale it based on the resulting dpi. Those I did print were printed on film using an arcane film printer (circa mid '80s).

A few years ago I ported this to Irix (from Unicos). In the process I did some enhancements such as blending. The best result was when only high values were mixed proportionally to their value (a hyperbolic function with zero at a set high value). That gave the best "blend" notion without affecting too much the "integrity" of the replaced cell. Your article gave me a chuckle. I now feel compelled to port this to something like Linux and let it loose...(though gone are the days I had "free time").

By the way, NASA keeps an enormous database of pictures. Although most of them are obviously related to aerospace, they are all public domain by definition.

Gus J. Grubba

DDJ