NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi, There are two different issues combined here. 1. Integer vs floating values. 2. Dimensionality of the coverage Integer vs floating values: JPEG 2000 offers support for integers only. It is not clear that this is a serious constraint since any observation must have only finite precision and hence can be scaled. This may be a pain, but it is common in all measurement systems. Dimensionality of the coverage: In general a coverage can be seen as a function X = f(Y). The dimension of X can be some N (N=0,1,2, 3, 4 .. ). With the current GMLinJP2K specification, the dimensionality of Y is 2 - that is at each point p on a 2D surface (e.g. surface of the earth) we can have vector quantities X(p) (X1, X2, .. Xn) where each Xi will be in a different JPEG 2000 codestream. So for representation of measurement information the restriction of GMLJP2K is that it does not allow the points p to be in a volume - note that the surface on which p lies can be in 3-space however. This is not really a restriction of JPEG 2000, however, and I think we can extend the GML description to allow the description of functions (as above) over multi-dimensional "volumes". Please note that in GML and O&M (=GML) an Observation is not the values but the act - so an observation can be coverage-valued - like when I take your picture. Cheers Ron
-----Original Message----- On Behalf Of Michael P. Gerlek Sent: May 12, 2005 8:38 AM 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: