John wrote:
Im wondering if its fair to think of JPEG as inherently 2D arrays of
integers (perhaps floats in the future) ?. I assume that the wavelet
compression is optimized for 2D ?
If so, it may not be the right data structure for representing
observations, which may be thought of as lists of tuples, more like a
database table ?
Some background that might help (or just muddle things further...):
* JPEG 2000 considers an image to be a 2D array, where each array
element is a tuple ("pixel") which can contain N samples. In the
usual case, the samples are 3 uint8's ("red", "green", "blue").
However, the standard allows N to be very large (2^16 or so, I'd have
to check), and futhermore the N samples need not all be of the same
datatype.
* Additionally, you can have M images ("codestreams") per file. This
is how they do movies/video, among other things; each frame is a
separate codestream. In general, of course, the M images need not all
be of the same shape (width, height, number of samples, etc).
* The wavelet is indeed a 2-D construct. There was some work on an
extension for 3-D, but this has been abandoned (and that project also
included the floating point support, unfortunately).
* While the wavelet is 2-D, the "compression" part is not. Under JPEG
2000, the main compression win comes from the arithmetic encoder --
this mechanism operates deep down in the bit domain, and so is
agnostic as to number, type, etc of the samples.
* Early on in the encoding process, there is a colorspace transform
that is done to improve compression ratios for RGB data: the data is
(losslessly) mapped into the YCbCr domain, which essentially
decorrelates the color bands better than RGB does. If your data is
not RGB, this transform can be skipped -- or, indeed, if you know
something about the properties of your data's bands, with one of the
extensions you can supply your own decorrelating transformation...
-mpg
