Hi. Being a litle short on time, I am simply forwarding to you the following email exchanges between me and Jennifer Ball, a Sun engineer working on improving the .image documentation. The part where I try to make my main point is surrounded by rows of asterisks, in case you are too pressed for time to read the whole thing. Regards, David Janszen >Date: Mon, 7 Jun 1999 15:12:45 -0700 (PDT) >From: Jennifer Ball <[EMAIL PROTECTED]> >Reply-To: Jennifer Ball <[EMAIL PROTECTED]> >Subject: Re: SampleModel description in 1.2 API docn is unclear or wrong >To: [EMAIL PROTECTED] > > >Hi again, > >Sorry for the delayed response and thanks for your nice complement. I know that >the engineers worked with Kodak to produce some of the Color and Imaging API. >Perhaps the terminology comes from them. You might want to pose your questions >to the java2d-interest list. All of the 2D engineers read the messages posted >here. Go to this page to find out how to subscribe to the list: > >http://java.sun.com/products/java-media/2D/forDevelopers/interest_group.html > >Or, you can just post your message by sending mail to: [EMAIL PROTECTED] > >An engineer will respond to you and the list. You can also view recent posts >here: > >http://java.sun.com/products/java-media/mail-archive/2D/index.html > >I hope they are able to help you. > >thanks, >Jennifer > >> X-Sender: [EMAIL PROTECTED] >> Date: Tue, 01 Jun 1999 09:53:01 -0400 >> To: Jennifer Ball <[EMAIL PROTECTED]> >> From: David Janszen <[EMAIL PROTECTED]> >> Subject: Re: SampleModel description in 1.2 API docn is unclear or wrong >> Mime-Version: 1.0 >> X-MDaemon-Deliver-To: [EMAIL PROTECTED] >> X-Return-Path: [EMAIL PROTECTED] >> >> Hi, Jennifer. >> >> I would say by the clarity of your explanation that Sun is lucky to have >> you working on doc cleanup and gap filling. >> ***************************************************************************** ***************************************************************************** >> Unfortunately, I'd have to say that the terminology you are stuck >> explaining is deficient in every imaginable way. Banded is a terrible >> word for decomposed, especially given that band already means something >> intuitively suggestive in imaging jargon, namely a row of pixels or a set >> of contiguous rows of pixels in a bitmap. Band can not have been the only >> word left after whatever more appropriate words were used up, but if it >> was, then a new word should have been made up from scratch, because the >> word band has absolutely nothing to do with its Java meaning. And, if band >> is going to be the word for a set of like components of a decomposed set of >> pixels, then "pixel-interleaved" is the wrong term for the storage case >> where fragments of pixels that are normally kept together in standard >> bitmap file formats are in a sense what are actually interleaved, not the >> pixels themselves, which is what the term inplies, even though that would >> make no physical or analytic sense. And there is absolutely nothing sample- >> like about samples. >> >> On a soft note, it is easy to imagine how a group working on terminology >> hard and long enough could fry their brains to the point that just about >> anything seems to make sense, and because this seems to be the case, here, >> a second look is warranted. And any new terms should be tried out on a >> number of people from "the outside" before casting the type. >> >> On a harder note, I think it is some kind of an offense to try to get >> completely new and non-suggestive meanings into circulation for existing >> words; it is a considerable affront to our language, and works against >> the promotion of shared understanding . . . never mind that is it juvenile >> and demented. >> >> I had a couple of ideas that I would like to pass on in the hope of >> restarting the terminology selection process for the imaging classes: >> "sub-pixel", "bitzle", or "pixelette" instead of "sample"; "sub-map" or >> "bitzleset" instead of "band"; and "decomposed" and "full-pixel" for the >> "banded" and "interleaved" storage cases. ***************************************************************************** ***************************************************************************** >> >> Anyway, thanks for the gracious and useful help. Now at least I have a map >> from the demented to the explicable. >> >> - David J. >> >> At 03:35 PM 5/28/99 -0700, you wrote: >> > >> >Hi David, >> > >> >Pixels do actually consist of samples. An example of a sample would be >> the red >> >component of a pixel in the RGB color model. >> > >> >A band is the set of all samples of one type in a particular image. For >> >example, all the red samples could be in a band. >> > >> >The DataBuffer class contains pixel data in the form of an array. The >> data is >> >stored as primitive types called data elements. Each data element is a >> member >> >of the array. The way the data is stored in the array is independent of >> the way >> >the SampleModel interprets the data as pixels. >> > >> >SampleModel translates the data from DataBuffer and presents that data in >> terms >> >of individual pixels or rectangular ranges of pixels. >> > >> >There are two ways to store pixel data: Banded and Pixel-interleaved. In >> banded >> >storage, the image data is organized by bands and a pixel consists of the >> sample >> >data at the same position in each band. In pixel-interleaved storage, image >> >data is organized by pixels. One array contains all pixels. Bands >> contain the >> >set of samples at the same index position in each pixel. >> > >> >I hope this information is helpful to you. I know the docs for some of the >> >imaging classes could be clearer. It is one of my goals to clean up this >> >documentation. >> > >> >Thanks for the question, >> >Jennifer >> > >> > >> >> >> >> Date: Wed, 19 May 1999 18:03:09 -0400 >> >> To: [EMAIL PROTECTED] >> >> From: David Janszen <[EMAIL PROTECTED]> >> >> Subject: SampleModel description in 1.2 API docn is unclear or wrong >> >> >> >> In the 1.2 API doc, the following text is presented: >> >> >> >> "public abstract class SampleModel >> >> extends Object >> >> >> >> "This abstract class defines an interface for extracting samples of pixels >> >> in an image. All image data is expressed as a collection of pixels. Each >> >> pixel consists of a number of samples. A sample is a datum for one band of >> >> an image." >> >> >> >> Although the first two sentences imply that a sample is a way of storing a >> >> set of pixels, of which images are a collection, the rest of the paragraph >> >> seems to mean: >> >> >> >> 1. a pixel is a collection of samples >> >> 2. a sample consists of a single datum for a band, which is a part of an >> >> image, which must then itself be a collection of pixels! >> >> >> >> So, a pixel is a collection of pixels by way of samples and bands, i.e., a >> >> sample is a subunit of a pixel, a sample is also a subunit of a band, and a >> >> band is subunit of an image presumably larger than a pixel. >> >> >> >> If a sample consists of a number of pixels, and not the other way around, >> >> the thing begins to make sense. Then perhaps the last sentence indicates >> >> that a band is the particular allowable type of collection of pixels that a >> >> sample can be. But what is that? What is a band? A row, column, or block of >> >> pixels? >> >> >> >> Please try to fix this up, and let me know when, because I think I can make >> >> some use of this class. >> >> >> >> Regards, >> >> >> >> David Janszen >> >> Software Engineer >> >> >> >> >> >> ------------- End Forwarded Message ------------- >> >> >> >> >> > >> > >> > >> >> > > > ===================================================================== To subscribe/unsubscribe, send mail to [EMAIL PROTECTED] Java 2D Home Page: http://java.sun.com/products/java-media/2D/
