ImageCooker is a set of open source utilities for
manipulating raw images from digital cameras (currently Konica Minolta DiMAGE
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
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
For more about ImageCooker, I
have provided some information in the form of Q&A:
What utilities are provided?
Currently there are four utilities for
use with Minolta Raw (MRW) files:
- mrwinfo: extracts
and displays the metadata (camera model,
aperture, shutter speed, white balance mode, etc.) of a MRW file
interpolates the raw sensor data contained in a MRW file
and writes the output in PPM format
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
In addition, there are two utilities that
perform Bayer-related operations on PPM files (these are useful for
experimentation but not much else):
"Bayerizes" a PPM file by stripping color data to leave
only the information which would be recorded by a Bayer sensor--that
each pixel in the output image contains only a red, green or
blue value, arranged in a Bayer pattern; writes the output in PPM
- bayer2tiff: performs
Bayer interpolation on a PPM file, treating
the image as if it came from a Bayer sensor, and writes the output in
Why another set of such utilities?
Don't we have enough already?
Yes, there are other utilities out
there that do the same thing (most of them actually do more, such as
perform color space conversion, profiling, etc.). But I had a few
specific goals in mind when writing these. I wanted to
- 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
There are a lot. This is, after all, a
work in progress, and my development priorities may differ from yours.
:-) (Having said that, I'm willing to prioritize my development efforts
to some degree based on feedback about what features are important to
users--that is, if there are any users.) Here are some current
limitations that come to mind:
- 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
- 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
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
standard C++ though, so it should compile with little or no
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?
The background features "pixels" of
exaggerated proportions, fading from a full-color image to its RGB
constituents, reminiscent of a Bayer pattern. (Actually the bayerize utility was used in the
creation of this effect.) The camera body is a Minolta DiMAGE 7Hi, the model
I owned and used when writing the early versions of ImageCooker.
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
recognized interpolators when invoked with no parameters (or too few
parameters). So it's no longer necessary to look in the source code to
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"
- to adopt a camera-agnostic name, as support for raw image
formats other than Minolta MRW is expected eventually.
- Implemented Chuan-kai Lin's
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
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
Threshold-Based Variable Number of Gradients or Laplacian Color
- Refactored to reduce duplicated code (particularly bilinear
- 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?
There are a number of sites from which
I gathered valuable information. Here are a few:
- 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
- A number of pages have information on Minolta's MRW raw image
- Other utilities for interpolating digital camera images exist as
well (some free-as-in-speech, some free-as-in-beer, some shareware,
- 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
- 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
- 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.?
Don't hesitate to e-mail Jeremy
Rosenberger at firstname.lastname@example.org
I'd be interested in knowing who's using this stuff!
All product names (e.g. DiMAGE) are trademarks of their respective
manufacturers (e.g. Konica Minolta). Everything else ©2003-2007 Jeremy L. Rosenberger. All rights
This page was last modified on 14 April 2005.