Hi.
I am forwarding to you the following email exchanges between me and
Jennifer Ball,
a Sun tech writer 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 sorely deficient, in my opinion. 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/
