Functionality
As a photographers' tool, we rely heavily on color management and the processing of raw files from professional digital cameras. When we contacted Atalasoft about whether they could add color-management support, they were straightforwardthey wanted to, but needed guidance about how the feature set would work and which pieces were essential. Because we'd written our own code for color management, we were delighted to share our expertise in exchange for getting a vendor-supported toolkit we could use, while retiring some of our legacy code. Over time, we developed a similar relationship with raw file support, where by providing sample files and input, we could help make sure Atalasoft's toolkits met our needs. This kind of working relationship is essential for any high-value library or component. Our market evolves quickly and once we commit to using code from a vendor, we need to have a way to work with that vendor to ensure we can stay ahead of the competition.
Performance
Like any developer, we didn't want functionality at the expense of performance. We did extensive benchmarking of dotImage versus several COM-based solutions (including the toolkit we'd been using for several years), and in most tests, it did remarkably well, considering it is a native .NET application. Better yet, when dotImage was noticeably slower, Atalasoft was anxious to learn where the issues lay and resolve them for us. The result was that we got a native .NET library with the performance our customers were used to in COM.
Extensibility
They say you can't teach an old dog new tricks, but after nearly 30 years of programming, I was excited to find that the promise of subclassing seemed to be useable in the .NET languages C# and VB. The development environment provided a combination of powerful, productive languages and an easily extensible class library system. Programming was more fun than it had been in a long time. So when we looked for a compatible imaging toolkit, it was important that it fully support the class library model, letting us extend it simply and in ways consistent with our overall architecture. Libraries using COM components wrapped in .NET are often brittle and do not permit much subclassing. In fact, many were designed as "lowest common denominator" libraries that could be used with anything from C in embedded devices up to servers. While this is an admirable design goal, desktop programmer productivity and eventual web server use were paramount for us. dotImage is great because the team at Atalasoft clearly "got" object-oriented programming and designed the system from the ground up for use with modern IDEs such as Visual Studio. In Figure 1, for instance, the dotImage controls integrate directly into the Visual Studio IDE. Frankly, we wish the procedure for updating control versions in Visual Studio was more intuitive, but that's a general issue with VS. Other than that, using the dotImage controls is as simple as drag-and-dropalthough frequently, we also create instances of their controls in code.
If we needed a new function in an image codec (say, the ability to read large TIFF images in sections while we down-sampled them to reduce the overall memory needed), it was a simple matter to subclass the TIFF codec and provide a decoding function that also scaled as it read. In minutes, we had an optimized decoderwhich might have taken us hours or even days to write from scratch. And because it was a simple subclass, it worked with upgraded versions of dotImage without needing to be recoded. For example, we were quickly able to add image comparison (see Figure 2) when our users demanded it simply by dropping two different viewer controls on the form with a container control. Better yet, when we pointed out the value of most ideas or innovations like this, Atalasoft quickly added them to their "wish list." Then, in the next release, we would find a built-in version of the capability, which meant one less piece of homebrew code to support.