|
When evaluating imaging toolkits, David considered flexibility, performance, extensibility, and support, in addition to the feature set.
May 04, 2007
URL:http://www.drdobbs.com/windows/net-components-for-image-management/199204018
David is the founder of Pro Shooters, which produces software for organizing and managing digital images, and a wildlife photographer who specializes in North American mammals and birds. He can be contacted at www.cardinalphoto.com.
At Pro Shooters (www.proshooters.com), our primary product is DigitalPro for Windows, an image-management system for digital photographers. We sell to serious photographers who have large image libraries and often need to process hundreds or even thousands of images at a time. As a result, we serve a niche market and can only afford a small programming team. That means we need to be more productive than the competition to stay ahead. So, instead of trying to do everything ourselves, we rely on tools such as third-party libraries in areas where we can find excellent tools that don't compromise on quality and features.
Licensing an imaging library was an obvious candidate for us. After all, image formats are mostly standardized and there is no sense reinventing the wheel. When we were developing in Visual Basic 6, we relied on a set of COM components, but when we moved to .NET, we really wanted to go with a solution that leveraged the .NET Framework. We looked at Microsoft's .NET native imaging classes, but they had limited support for metadata, color management, and many of the image formats we needed. Consequently, we went shopping for a toolkit that included .NET classes and visual controls that we could use to read, display, process, and write image files in a variety of formats. In addition, we have our own libraries for doing specialized processing of vendor-specific formats (such as raw files), so we knew whatever solution we licensed would need to be extensible.
By the time we were ready to evaluate imaging toolkits, we had a checklist of important criteria, including architecture, feature set, flexibility, performance, extensibility, and support responsiveness.
Architecture had become increasingly important to us. Since porting DigitalPro to .NET, we'd been hampered by third-party components that were either only available in COM versions or had (at best) thin .NET wrappers. While they would work, they were difficult to debug and limited in how we could use them. So we were looking for a native .NET toolkit for best results. Of course, we did realize that some of the low-level raster code would be unmanaged, but our hope was to have that be minimal and be transparently integrated into .NET libraries by the vendor.
As you might expect for a new platform, most .NET toolkits had fewer features than their more mature COM-based competitors. Still, we zeroed in on dotImage from Atalasoft (www.atalasoft.com). What we liked about dotImage was that Atalasoft had taken .NET seriously enough to move almost all of its functionality over to .NET, and the company was serious about addressing any shortcomings in the .NET managed code features set, rather than forcing licensees to knit together COM and .NET.
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 straightforward—they 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.
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.
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-drop—although 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 decoder—which 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.
Our customers rely on our software for their day-to-day business operations of managing and processing photographs, and excuses such as, "Oh, we get that code from someone else," are not acceptable. Once we ship a library, we need to stand behind it and ensure it works at the customer site. That means we rely on our vendors not just to support their products, but also to provide workable solutions to customer problems on a timely basis. In fact, I think one of the reasons component vendors continue to thrive despite the increasing functionality built into platform libraries is this support. After all, if the Windows .NET library doesn't read a particular TIFF file at a customer site, we're unlikely to get a Microsoft patch for our customer in real time.
Given the small size of our team, our selection process needed to be efficient and quick. But at the same time, a mistake would be very expensive in terms of customer satisfaction—if we picked and shipped a library that didn't perform as expected. There was no shortage of Windows imaging toolkits on the market, but by going through our checklist of requirements, it was winnowed down to two. Feature for feature, the two looked almost the same. We decided that before committing to one, we needed to do some prototyping to really see how they would work. When we prototyped a portion of our functionality in each, we quickly began to see that it was only the "marketing hype" that was the same. With dotImage, we were able to implement the functionality we needed with a consistent API entirely in .NET. The competitor required us to use three different API sets—.NET, COM objects, and "C" DLLs—to get the functions we needed. This was a huge advantage for dotImage and nearly made our decision for us right there.
One of the most important requirements for professional photographers is accurate color rendering through color management—displaying images tagged with a particular color profile by calculating how they should appear given a second profile for the display, and optionally soft-proofing how they will appear on a printer by using a third printer profile in the display pipeline. We'd implemented our own color-management code, but it required two steps to display each image—render it in the vendor toolkit, then color correct it. We really wanted a toolkit that had this functionality built-in. Unfortunately, Atalasoft did not have color management in its products, while the competitor did.
Because Atalasoft's architecture was so elegant, rather than give up, we contacted the company and asked about plans for color management. Atalasoft said they were open to the idea and that if we were willing to give them a detailed specification on how it should work for photographic applications and test the results, they'd implement it in their next release. Obviously, this was appealing. By contrast, we had asked the competing vendor when they'd have a full .NET solution, but still had not received a solid answer. So we began to work with Atalasoft.
Not only did the original effort to help shape its color-management features work out, it also led to several years of productive cooperation on other topics that were of interest to our customers, including reading/writing metadata and viewing raw files directly from cameras. Atalasoft clearly takes customer requirements very seriously.
And fortunately for us, Atalasoft also takes bugs and software issues very seriously. Any image-rendering toolkit is, by definition, a work in progress. Image formats may appear to be standardized (JPEG, TIFF, PSD, and the like), but all those formats have dozens of variants and varieties of legacy images that may have been poorly constructed or are in some way not adherent to the specification. In addition, vendors continue to work around the formats with slight variants, and committees refine Standards over time. Because many of our customers are professionals, it is important that when they have issues, we are able to address them quickly. And of course, it is also crucial that we not damage their images in any way. Atalasoft has an extensive software-testing program and was happy to add our sample images to its test suite. When we (or a customer) did find an issue rendering an image, Atalasoft was quick to help and provide a workaround or updated code.
When selecting third-party components, it is often tempting to look only at your immediate needs. After all, there is always a release that is urgently needed in the customers' hands. But the real cost of any component—far greater than the licensing fees—is the energy you'll put into integrating, testing, and releasing it as part of your application. The lesson we learned was to start with the architecture and the company, then work through specific product features rather than the other way around.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.