NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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
galeon archives: