Re: [GMLJP2] NetCDF <--> GML/JPEG2000

NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.

Michael P. Gerlek wrote:

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.

what are the possible "datatypes" ? different size integers ?

* 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


thanks very much, this is quite useful information.

I am thinking about the question of where JPEG 2000 can be effectively used to transmit data. In 
particular I was thinking (in context of using it for Observations) about its use for meterological 
"point data", which typically are collections of time series of tuples, eg Pressure, 
Temperature, Humidity, etc values that are measured every 15 minutes at various 
"stations" around the world.

I see that the "N samples" of each pixel might be mapped to the tuple values at each 
point, something i didnt appreciate before. (I assume these are the same as the "data 
band" ?) It sounds like you are saying that these would compress independently, which would be 
important.

The "2D-ness" of the images does not really map to a collection of time series, 
although i suppose you could treat it as a 1D array. If so, it seems possible that you 
might lose some of the usefulness of the wavelet compression, although as you say the 
arithmetic encoding should be fine.





  • 2005 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the galeon archives: