ImageCooker is a set of open source utilities for manipulating raw images from digital cameras (currently Konica Minolta DiMAGE cameras, though support should expand eventually). These are certainly not the only raw processing utilities available, nor are they even the only such open source utilities available, but they may prove to be useful somehow.

April 2005 update: I "jumped ship" from the Minolta DiMAGE 7Hi to the Canon EOS Digital Rebel more than a year and a half ago, and recently upgraded again to the Rebel XT. I am keen to add Canon CRW and CR2 support to ImageCooker, but my day job tends to interfere with my plans at times. :-) I also have Nikon-using friends, so perhaps Nikon support will find its way in eventually... Also, there were some generous contributors over the past months who submitted patches to fix various issues, or to add some feature or another. Unfortunately I haven't been a very active maintainer, but I will revisit the patches that I still have and try to apply them.

For more about ImageCooker, I have provided some information in the form of Q&A:

What utilities are provided?

• mrwinfo: extracts and displays the metadata (camera model, aperture, shutter speed, white balance mode, etc.) of a MRW file
• mrw2ppm: interpolates the raw sensor data contained in a MRW file and writes the output in PPM format
• mrw2tiff: interpolates the raw sensor data contained in a MRW file and writes the output in TIFF format
• gimp_mrw: a GIMP plugin that creates a new image by interpolating the raw sensor data contained in a MRW file

In addition, there are two utilities that perform Bayer-related operations on PPM files (these are useful for experimentation but not much else):

• bayerize: "Bayerizes" a PPM file by stripping color data to leave only the information which would be recorded by a Bayer sensor--that is, each pixel in the output image contains only a red, green or blue value, arranged in a Bayer pattern; writes the output in PPM format
• bayer2tiff: performs Bayer interpolation on a PPM file, treating the image as if it came from a Bayer sensor, and writes the output in TIFF format

Why another set of such utilities? Don't we have enough already?

• learn the ins and outs of writing certain categories of software that I haven't dabbled in before: GIMP plugins and processing of device-specific output files;
• play around with (by implementing myself) different Bayer interpolation algorithms; and
• produce such a set of utilities with the explicit goal of producing source code that is well-documented enough to be understandable to others (at least to others with knowledge of C++ and/or object-oriented programming).

The Bayer interpolation algorithms I chose to implement were (most of) those described by Ting Chen in his Study of Spatial Color Interpolation Algorithms for Single-Detector Digital Cameras. A number of these (e.g. Nearest Neighbor, Bilinear) aren't particularly sophisticated and probably wouldn't be used in the real world (at least for still image applications), but I implemented them for completeness (part of my purpose, after all, was to play around).

For fun, I added a "No Interpolator" algorithm which doesn't interpolate color values at all, but instead produces each pixel in the output image having only the red, green or blue color component that that corresponds to the (single) color of the corresponding pixel in the camera sensor. It doesn't produce particularly useful images, but when zoomed in, such images reveal exactly what is "seen" by the Bayer sensor.

What are the limitations of the utilities?

• No color space conversion of any kind is performed. That is, the utilities have no knowledge of ICC profiles, sRGB, AdobeRGB, and that sort of thing. In fact, the utilities don't do anything other than interpolate (except for white balance correction); gamma correction, sharpening, etc., if desired, must be done in post processing. Because of this, images from ImageCooker will appear dark and will require some sort of levels adjustment.
• Even though the DiMAGE cameras record 12 bits of color information, the GIMP plugin and mrw2ppm always output 8-bit color. mrw2tiff is capable of producing 8-bit or 16-bit color, although currently the value can only be changed by editing the source code and recompiling. In all cases, internal calculations use all 12 bits of color information; the data is only truncated to 8 bits in the final output stage.
• EXIF tags in the MRW file are not processed. (The MRW file stores some metadata in the file structure itself; other metadata is stored as embedded EXIF tags.) In any case, there's no way to embed this information into a PPM file or into a GIMP image anyway, but the mrw2tiff utility could eventually implement EXIF tags.
• There is no way to override the white balance settings; whatever is encoded in the MRW file is what will be used.
• The GIMP plugin has no configurability at all; it is hard-coded to use the "Pixel Grouping" algorithm (currently the best all-around interpolator available in ImageCooker).
• Very little optimization has been attempted. I have tried to code the interpolation strategies as efficiently as is (naively) possible, but I'm sure there's a whole lot that could be optimized. In particular, the memory requirements are probably higher than they need to be. (At least the GIMP plugin uses tiles for a modicum of efficiency.) However, one important optimization that has been made is that the interpolation routines can take advantage of multiple CPUs.
• Some of the code isn't as "generic" as it could be. Specifically, some of the code makes assumptions that color samples are always 12-bit. As another example, a sensor is assumed to use the "RGGB" pattern; there is no support for "BGGR" pattern sensors. (However, the Bayer interpolation logic is pretty much decoupled from the raw file processing, so the processing utilities could be adapted for use with other cameras without requiring too much cleanup work.)
• I haven't even tried to compile the utilities on anything other than a couple of Linux machines (one of them is Red Hat 7.3 with gcc 2.96; the other is Red Hat 8.0 with gcc 3.2). Things seem to compile on Fedora Core 2 and 3 as well; I'm currently in the process of updating the build to work with the latest GIMP versions. The code is all pretty much standard C++ though, so it should compile with little or no modification almost anywhere (as long as your C++ compiler supports templates). So far one user has had some success compiling and using the utilities under MacOS X, so that's encouraging.

What's the deal with the logo?

Enough of your jabber; how do I get my hands on the stuff?

Please note that the utilities are distributed under the terms of the GNU General Public License, but I haven't yet added the source code comments, etc. to that effect. Chuan-kai Lin has also made his "reference implementation" of Pixel Grouping available under the GNU GPL. It has been suggested that perhaps the LGPL would be a more appropriate license; I am open to making ImageCooker available under the LGPL, but I need to contact Lin to find out if he's OK with that, given that he holds the copyright to the Pixel Grouping implementation.

If you're a little curious about what to expect from ImageCooker in the future, you can check out the TODO list.

A little version history:

0.4 (8 April 2003)

• Implemented support for multiple CPUs. ImageCooker determines how many CPUs are available, and creates one thread per CPU, dividing the processing work among them. ImageCooker is one of few such utilities to offer multiple CPU support!
• The command line utilities (e.g. mrw2tiff) now will output the list of recognized interpolators when invoked with no parameters (or too few parameters). So it's no longer necessary to look in the source code to see what interpolation algorithms are supported. :-)
• Renamed to ImageCooker for the following reasons:
• to avoid trademark issues that will inevitably arise if the previous name was kept (DiMAGE is a Konica Minolta trademark);
• to reflect the purpose of the application: to process or "cook" raw images;
• to adopt a camera-agnostic name, as support for raw image formats other than Minolta MRW is expected eventually.
• Implemented Chuan-kai Lin's Pixel Grouping algorithm (actually he provided the implementation) and made it the default (since it's so good).
• Made COMPRESSION_NONE the default compression scheme for TIFF files, as a number of applications had trouble with Deflate compression.
• Made 48 bits the default depth for TIFF file generation.
• Fixed divide-by-zero and boundary condition issues with Smooth Hue Transition and Smooth Hue Transition Log interpolators (thanks to Dalibor Jelinek for pointing this one out).
• Fixed incorrect coefficients in Color Correction 1 interpolator (thanks to "Vector" for tracking down this problem, which is actually a bug in Ting Chen's description).

• Added the mrw2tiff utility, which does just what its name suggests. The ability exists to create 8- and 16-bit TIFFs, although currently it requires a source code change and recompile to change from 8 to 16 (yuck). Currently only image data is converted; EXIF tags are not added to the generated TIFF file. This does require libtiff to build.
• Implemented some optimizations suggested by Frank Driesens to speed up access to CCD data. Simple benchmarking suggests this is good for a 5-10% speed improvement.
• Speaking of optimizations, added "-O3 -march=pentium3" compiler options to the Makefile, resulting in significant performance gains. Obviously "pentium3" should be replaced by the appropriate CPU type when compiling on other machines.
• Fixed a bug or two in RifBlock.cpp which misreported sharpness values (or possibly segfaulted while attempting to do so). Thanks to Mark Rubin for pointing me on the trail of this one.

• Completed implementing the "Threshold-Based Variable Number of Gradients" interpolation algorithm. Of the algorithms presented in Ting Chen's study, Variable Number of Gradients is considered to produce the best images, but is not suprisingly the most computationally expensive. This is now the default strategy for the GIMP plugin (it still can't be changed without recompiling).
• Added the "Pattern Recognition" interpolation algorithm. Pattern Recognition tends to smooth out noise; it deals with edges subjectively better than the Edge Sensing algorithms while being slightly cheaper computationally. It does, however, produce softer edges and details than Threshold-Based Variable Number of Gradients or Laplacian Color Correction.
• Refactored to reduce duplicated code (particularly bilinear interpolation calculations).

• Released initial version. Implemented basic functionality in mrwinfo, mrw2ppm and the GIMP plugin, with half a dozen or so Bayer interpolation algorithms available.

Is there any related material that I should look at?

• Bryan Biggers has a Web site that provides not only a lot of useful information not only about the DiMAGE 7-series cameras, but a lot of other digital camera-related information besides.
• A number of pages have information on Minolta's MRW raw image format:
  • Dalibor Jelinek's page on the MRW file format was my primary source of information.
  • Jack's Digital Camera Pages have MRW information as well as other stuff.
  • Paul Hansen put together this description of the MRW format.
• Other utilities for interpolating digital camera images exist as well (some free-as-in-speech, some free-as-in-beer, some shareware, some commercial):
  • Adobe's Camera Raw Photoshop plugin
  • Phase One offers the Capture One line of raw processing tools, which are the highest quality I've seen
  • Dave Coffin's dcraw, an amazing little utility that processes raw files from 150+ (!) camera models
  • the GIMP DiMAGE color plugin
  • Patrick Porlan's Image Shifter
  • IrfanView, a popular image viewer that now supports the MRW format
  • Paul Hansen's mrw2tif (seems to be a popular name for a utility!)
  • Bradley Broom's mrwtoppm
  • Russell Bozian's OpenMAW
  • Vector's RAW Deal
• The Little Color Management System, a.k.a. LittleCMS, is an open source color management engine. ImageCooker doesn't use it yet, but it probably will before long.
• Of course all the MRW information in the world would be of little use without the ability to interpolate the Bayer pattern image data. This is where Ting Chen's Study of Spatial Color Interpolation Algorithms for Single-Detector Digital Cameras proved invaluable.
• Inspired by Ting Chen's study is Chuan-kai Lin's Pixel Grouping Bayer interpolation algorithm, which he implemented on top of the ImageCooker infrastructure. (I find that flattering ;-)

Almost forgot--who do I contact if I have problems, suggestions, patches, etc.?