All a TIFF file is is a standardized format for storing bitmapped
images, as well as whatever tags you like. The thing with RAW is that it's
not a color model, it's a monochrome image. It's understood that the
monochrome image should be interpretted according to a RGBG Bayer pattern.
I think you can argue that this does indeed make it a colour model, or rather
- the data is just data of course, the "RGBG Bayer pattern" interpretation
would be the colour model. The actual data in a normal RGB TIFF file is after
all also indistinguishable from monochrome image data...
I suppose one could call it a color model. The color models I was
thinking of is more like Lab, YUV, xyY, that sort of stuff (icc profiles,
color management, etc). The "RGB" in the Bayer data is only monochrome
and doesn't have any meaning until one defines exactly what "red is red",
"green is green," and "blue is blue." Those are all relative, depending
on the dyes of the sensor. Some cameras even use CYM dyes, IIRC. None of
that info is in the RAW TIFF... it's just monochrome.
... but one can call it a color model if you want... it's got
assumed RGB values.
Probably...
I've looked at the files a fair bit with linux libtiff utilities.
The only significant tweaking they've done is pack 12 bits into 12 bits...
the tiff format does not allow 12 bit data. The other stuff (exif info,
jpeg thumbnails, lens info, etc) is all stored as TAGS and DIRECTORY info
within the TIFF file structure.
I've also been thinking that they should not really call it RAW, by the way.
A "raw" image file is traditionally a file containing the pixel data and
nothing else.
... true, but then it would confuse the issue as compared to
everyone else. Since it's TIFF, it does have RAW pixel data in the
open... just has some fuzz of other data on either side of it... :)
Somewhat smaller, but not much I wouldn't think. The standard TIFF
supports only a few types of compression, most of which aren't all that
great. It's similar to taking a document, copying it three times, making
small changes in each one, and then compressing the three. Chances are it's
going to be a fair bit bigger than the original compressed.
I must admit I haven't tried this, but isn't some of the "extra" data
introduced by interpolation duplicate date that might easily be reduced in
size by traditional compression algorithms.
Yes, it's duplicated, but I'm not sure how intelligent the
compression algorithms in TIFF are. I know two of them are simple RLE and
LZW (zip-style) encodings. I doubt either of them check for
compressibility along the minor axis (e.g. vertically if image is written
in horizonal stripes). A photo will have spacial compressibility in that
direction as well. I also doubt either of them try to be clever between
multiple image planes (R, G, B)... you end up with three separate,
independently compressed images.
I've played with gzip (zip-style) and bzip2 on my RAW files to see
if I can have them take up less space for archival to DVD. They really
don't compress very well with that. I think I got a minimum of about 80%
of the original size... even when the compression parameters were cranked.
Basically, one needs to be more clever in compressing images than a simple
zip or it doesn't help much. Zip doesn't know it's an image or anything
special... just tries to compress the binary data. Similarly for music.
Zipping a WAV file doesn't get it very small, but using something like
FLAC (fully-lossless audio compression) or MonkeyAudio or whatever does a
pretty good job.
The way it's typically done in-camera (8-bit, white-balanced,
gamma-corrected), it does have almost no advantages over minimally
compressed JPEGs, and the disadvantage of being much larger...
It has the advantage that you know you have lossless compression. Even
"minimal" JPEG is lossy, isn't it? Unless you use JPEG-2000, which also
allows lossless compression, as far as I understand. And has several other
features making it a generally much more usable image format, but the article
of course dismisses it without any discussion...
Lossless *compression*, yes... but you've already thrown away
1/3 of the data that was captured by the sensor, and posterized the colors
to only 1/16 of their original accuracy. Add to that the fact that you've
taken this image data which has only 2/3 of the sensor data, and
interpolated (duplicated) it three times (R, G, B instead of the Bayer
RGBG). It's just not an efficient means of storage, and it *is* lossy
(unless it's 16-bit linear, which I doubt any cameras do). It may not
have JPEG artifacts, but those are fairly minimal unless repeated multiple
times or have the compression level turned way up.
-Cory
--
*************************************************************************
* Cory Papenfuss *
* Electrical Engineering candidate Ph.D. graduate student *
* Virginia Polytechnic Institute and State University *
*************************************************************************
