java awt imaging.htm

是一部关于java高级图像处理的的一本入门书

  rendering-independent parameters. These operators can be linked to form 
  <EM>chains</EM>. The layer is essentially synchronous in the sense that it 
  "pulls" the image through the chain whenever a rendering (such as to a display 
  or a file) is requested. That is, a request is made at the sink end of the 
  chain that is passed up the chain to the source. Such requests are 
  context-specific (such as device specific), and the chain adapts to the 
  context. Only the data required for the context is produced. 
  <P><A name=51366>
  <H4>2.2.3.2 <IMG src="Java AWT Imaging.files/space.gif">Rendered 
  Layer</H4></A>Image sources and operators in the parallel <EM>Rendered 
  layer</EM> (the interfaces and classes have <CODE>rendered</CODE> in their 
  names) are context-specific. A <CODE>RenderedImage</CODE> is an image that has 
  been rendered to fulfill the needs of the context. Rendered layer operators 
  can also be linked together to form chains. They take context-dependent 
  parameters. Like the Renderable layer, the Rendered layer implements a 
  synchronous "pull" model. 
  <P><A name=51375>
  <H4>2.2.3.3 <IMG src="Java AWT Imaging.files/space.gif">Using the 
  Layers</H4></A>Structurally, the Renderable layer is lightweight. It does not 
  directly handle pixel processing. Rather, it makes use of operator objects 
  from the Rendered layer. This is possible because the operator classes from 
  the Rendered layer can implement an interface (the 
  <CODE>ContextualRenderedImageFactory</CODE> interface) that allows them to 
  adapt to different contexts. 
  <P>Since the Rendered layer operators implement this interface, they house 
  specific operations in their entirety. That is, all the intelligence required 
  to function in both the Rendered and Renderable layers is housed in a single 
  class. This simplifies the task of writing new operators and makes extension 
  of the architecture manageable. 
  <P><A 
  href="http://java.sun.com/products/java-media/jai/forDevelopers/jai1_0_1guide-unc/J2D-concepts.doc.html#51378">Figure 
  2-1</A> shows a renderable chain. The chain has a sink attached (a Graphics2D 
  object), but no pixels flow through the chain yet. 
  <P><A name=51377>
  <HR>

  <CENTER><IMG src="Java AWT Imaging.files/J2D-concepts.doc.anc.gif"></CENTER>
  <HR>
  </A><A name=51378>
  <CENTER><FONT size=-1><B><I>Figure 2-1 </I><IMG 
  src="Java AWT Imaging.files/sm-blank.gif" border=0> A Renderable 
  Chain</B></FONT></CENTER></A>
  <P>You may use either the Renderable or Rendered layer to construct an 
  application. Many programmers will directly employ the Rendered layer, but the 
  Renderable layer provides advantages that greatly simplify imaging tasks. For 
  example, a chain of Renderable operators remains editable. Parameters used to 
  construct the chain can be modified repeatedly. Doing so does not cause pixel 
  value computation to occur. Instead, the pixels are computed only when they 
  are needed by a specific rendition obtained from a 
  <CODE>RenderableImage</CODE> by passing it defined <EM>render contexts</EM>. 
  <P><A name=51446>
  <H3>2.2.4 <IMG src="Java AWT Imaging.files/space.gif">The Render 
  Context</H3></A>The renderable layer allows for the construction of a chain of 
  operators (<CODE>RenderableImageOps</CODE>) connected to a 
  <CODE>RenderableImage</CODE> source. The end of this chain represents a new 
  <CODE>RenderableImage</CODE> source. The implication of this is that 
  <CODE>RenderableImageOps</CODE> must implement the same interface as sources: 
  <CODE>RenderableImageOp</CODE> implements <CODE>RenderableImage</CODE>. 
  <P>Such a source can be asked to provide various specific 
  <CODE>RenderedImage</CODE>s corresponding to a specific context. The required 
  size of the <CODE>RenderedImage</CODE> in the device space (the size in 
  pixels) must be specified. This information is provided in the form of an 
  affine transformation from the user space of the Renderable source to the 
  desired device space. 
  <P>Other information can also be provided to the source (or chain) to help it 
  perform optimally for a specific context. A preference for speed over image 
  quality is an example. Such information is provided in the form of an 
  extensible hints table. It may also be useful to provide a means to limit the 
  request to a specific area of the image. 
  <P>The architecture refers to these parameters collectively as a <EM>render 
  context</EM>. The parameters are housed in a <CODE>RenderContext</CODE> class. 
  Render contexts form a fundamental link between the Renderable and Rendered 
  layers. A <CODE>RenderableImage</CODE> source is given a 
  <CODE>RenderContext</CODE> and, as a result, produces a specific rendering, or 
  <CODE>RenderedImage</CODE>. This is accomplished by the Renderable chain 
  instantiating a chain of Render layer objects. That is, a chain of 
  <CODE>RenderedImage</CODE>s corresponding to the specific context, the 
  <CODE>RenderedImage</CODE> object at the end of the chain being returned to 
  the user. 
  <P><A name=51549>
  <H2>2.3 <IMG src="Java AWT Imaging.files/space.gif">Renderable and Rendered 
  Classes</H2></A>Many users will be able to employ the Renderable layer, with 
  the advantages of its rendering-independent properties for most imaging 
  purposes. Doing so eliminates the need to deal directly with pixels, greatly 
  simplifying image manipulation. However, in many cases it is either necessary 
  or desirable to work with pixels and the Rendered layer is used for this 
  purpose. 
  <P>The architecture of the provided classes is discussed in this section. 
  Extending the model by writing new operators or algorithms in the Java 2D API 
  is discussed. Details of how the Rendered layer functions internally within 
  the Renderable layer are also covered. 
  <P><A name=51574>
  <H3>2.3.1 <IMG src="Java AWT Imaging.files/space.gif">The Renderable 
  Layer</H3></A>The renderable layer is primarily defined by the 
  <CODE>RenderableImage</CODE> interface. Any class implementing this interface 
  is a renderable image source, and is expected to adapt to 
  <CODE>RenderContext</CODE>s. <CODE>RenderableImage</CODE>s are referenced 
  through a user-defined coordinate system. One of the primary functions of the 
  <CODE>RenderContext</CODE> is to define the mapping between this user space 
  and the specific device space for the desired rendering. 
  <P>A chain in this layer is a chain of <CODE>RenderableImage</CODE>s. 
  Specifically, it is a chain of <CODE>RenderableImageOp</CODE>s (a class that 
  implements <CODE>RenderableImage</CODE>), ultimately sourced by a 
  <CODE>RenderableImage</CODE>. 
  <P>There is only one <CODE>RenderableImageOp</CODE> class. It is a 
  lightweight, general purpose class that takes on the functionality of a 
  specific operation through a parameter provided at instantiation time. That 
  parameter is the name of a class that implements a 
  <CODE>ContextualRenderedImageFactory</CODE> (known as a CRIF, for short). Each 
  instantiation of <CODE>RenderableImageOp</CODE> derives its specific 
  functionality from the named class. In this way, the Renderable layer is 
  heavily dependent on the Rendered layer. 
  <P>
  <P>
  <TABLE cellPadding=3 border=3>
    <CAPTION><FONT size=-1><B><A name=53782><I>Table 2-4 </I><IMG 
    src="Java AWT Imaging.files/sm-blank.gif" border=0> The Renderable Layer 
    Interfaces and Classes </A></B></FONT></CAPTION>
    <TBODY>
    <TR vAlign=top>
      <TH><A name=53788>Type </A>
      <TH><A name=53790>Name </A>
      <TH><A name=53792>Description </A>
    <TR vAlign=top>
      <TD rowSpan=2><A name=53794>Interface</A><BR>
      <TD><A name=53797>RenderableImage</A><BR>
      <TD><A name=53799>A common interface for rendering-independent images (a 
        notion that subsumes resolution independence).</A><BR>
    <TR vAlign=top>
      <TD><A name=53804>ContextualRenderedImage-Factory</A><BR>
      <TD><A name=53806>Extends: RenderedImageFactory</A><BR><A 
        name=53807>Provides an interface for the functionality that may differ 
        between instances of RenderableImageOp.</A><BR>
    <TR vAlign=top>
      <TD rowSpan=4><A name=53809>Class</A><BR>
      <TD><A name=53811>ParameterBlock</A><BR>
      <TD><A name=53813>Extends: Object</A><BR><A name=53814>Implements: 
        Cloneable, Serializable</A><BR><A name=53815>Encapsulates all the 
        information about sources and parameters (expressed as base types or 
        Objects) required by a RenderableImageOp and other future classes that 
        manipulate chains of imaging operators. </A><BR>
    <TR vAlign=top>
      <TD><A name=53819>RenderableImageOp</A><BR>
      <TD><A name=53821>Extends: Object</A><BR><A name=53822>Implements: 
        RenderableImage</A><BR><A name=53823>Handles the renderable aspects of 
        an operation with help from its associated instance of a 
        ContextualRenderedImageFactory.</A><BR>
    <TR vAlign=top>
      <TD><A name=53827>RenderableImageProducer</A><BR>
      <TD><A name=53829>Extends: Object</A><BR><A name=53830>Implements: 
        ImageProducer, Runnable</A><BR><A name=53831>An adapter class that 
        implements ImageProducer to allow the asynchronous production of a 
        RenderableImage.</A><BR>
    <TR vAlign=top>
      <TD><A name=53835>RenderContext</A><BR>
      <TD><A name=53837>Extends: Object</A><BR><A name=53838>Implements: 
        Cloneable</A><BR><A name=53839>Encapsulates the information needed to 
        produce a specific rendering from a 
  RenderableImage.</A><BR></TR></TBODY></TABLE>
  <P>The other block involved in the construction of 
  <CODE>RenderableImageOp</CODE> is a <CODE>ParameterBlock</CODE>. The 
  <CODE>ParameterBlock</CODE> houses the source(s) for the operation, plus 
  parameters or other objects that the operator may require. The parameters are 
  rendering-independent versions of the parameters that control the (Rendered) 
  operator. 
  <P>A Renderable chain is constructed by instantiating each successive 
  <CODE>RenderableImageOp</CODE>, passing in the last 
  <CODE>RenderableImage</CODE> as the source in the <CODE>ParameterBlock</CODE>. 
  This chain can then be requested to provide a number of renderings to specific 
  device spaces through the <CODE>getImage</CODE> method. 
  <P>This chain, once constructed, remains editable. Both the parameters for the 
  specific operations in the chain and the very structure of the chain can be 
  changed. This is accomplished by the <CODE>setParameterBlock</CODE> method, 
  setting new controlling parameters and/or new sources. These edits only affect 
  future <CODE>RenderedImage</CODE>s derived from points in the chain below the 
  edits. <CODE>RenderedImage</CODE>s that were previously obtained from the 
  Renderable chain are immutable and completely independent from the chain from 
  which they were derived. 
  <P><A name=51895>
  <H3>2.3.2 <IMG src="Java AWT Imaging.files/space.gif">The Rendered 
  Layer</H3></A>The Rendered layer is designed to work in concert with the 
  Renderable layer. The Rendered layer is comprised of sources and operations 
  for device-specific representations of images or renderings. The Rendered 
  layer is primarily defined by the <CODE>RenderedImage</CODE> interface. 
  Sources such as <CODE>BufferedImage</CODE> implement this interface. 
  <P>Operators in this layer are simply <CODE>RenderedImage</CODE>s that take 
  other <CODE>RenderedImage</CODE>s as sources. Chains, therefore, can be 
  constructed in much the same manner as those of the Renderable layer. A 
  sequence of <CODE>RenderedImage</CODE>s is instantiated, each taking the last 
  <CODE>RenderedImage</CODE> as a source. 
  <P>In <A 
  href="http://java.sun.com/products/java-media/jai/forDevelopers/jai1_0_1guide-unc/J2D-concepts.doc.html#51937">Figure 
  2-2</A>, when the user calls <CODE>Graphics2D.drawImage()</CODE>, a render 
  context is constructed and used to call the <CODE>getImage()</CODE> method of 
  the renderable operator. A rendered operator to actually do the pixel 
  processing is constructed and attached to the source and sink of the 
  renderable operator and is passed a clone of the renderable operator's 
  parameter block. Pixels actually flow through the rendered operator to the 
  Graphics2D. The renderable operator chain remains available to produce more 
  renderings whenever its <CODE>getImage()</CODE> method is called. 
  <P><A name=51936>
  <HR>

  <CENTER><IMG src="Java AWT Imaging.files/J2D-concepts.doc.anc1.gif"></CENTER>
  <HR>
  </A><A name=51937>
  <CENTER><FONT size=-1><B><I>Figure 2-2 </I><IMG 
  src="Java AWT Imaging.files/sm-blank.gif" border=0> Deriving a Rendering from 
  a Renderable Chain
  <P>
  <TABLE cellPadding=3 border=3>
    <CAPTION><FONT size=-1><B><A name=52034><I>Table 2-5 </I><IMG 
    src="Java AWT Imaging.files/sm-blank.gif" border=0> The Rendered Layer 
    Interfaces and Classes </A></B></FONT></CAPTION>
    <TBODY>
    <TR vAlign=top>
      <TH><A name=52082>Type </A>
      <TH><A name=52084>Name </A>
      <TH><A name=52086>Description </A>
    <TR vAlign=top>
      <TD><A name=52046>Interface</A><BR>
      <TD><A name=52048>RenderedImage</A><BR>
      <TD><A name=52050>A common interface for objects that contain or can 
        produce image data in the form of Rasters.</A><BR>
    <TR vAlign=top>
      <TD rowSpan=2><A name=52052>Class</A><BR>
      <TD><A name=52054>BufferedImage</A><BR>
      <TD><A name=52056>Extends: <CODE>Image</CODE></A><BR><A 
        name=52114>Implements: WritableRenderedImage</A><BR><A name=52115>A 
        subclass that describes an Image with an accessible buffer of image 
        data.</A><BR>
    <TR vAlign=top>
      <TD><A name=52060>WritableRenderedImage</A><BR>
      <TD><A name=52062>Extends: RenderedImage</A><BR><A name=52134>A common 
        interface for objects that contain or can produce image data that can be 
        modified and/or written 
  over.</A><BR></TR></TBODY></TABLE></B></FONT></CENTER></A>
  <P>A rendered image represents a virtual image with a coordinate system that 
  maps directly to pixels. A Rendered image does not have to have image data 
  associated with it, only that it be able to produce image data when requested. 
  The <CODE>BufferedImage</CODE> class, which is the Java 2D API's 
  implementation of <CODE>RenderedImage</CODE>, however, maintains a full page 
  buffer that can be accessed and written to. Data can be accessed in a variety 
  of ways, each with different properties. 
  <P><A name=52031>
  <H2>2.4 <IMG src="Java AWT Imaging.files/space.gif">Java Image Data 
  Representation</H2></A>In the Java AWT API, a sample is the most basic unit of 
  image data. Each pixel is composed of a set of samples. For an RGB pixel, 
  there are three samples; one each for red, green, and blue. All samples of the 
  same kind across all pixels in an image constitute a <EM>band</EM>. For 
  example, in an RGB image, all the red samples together make up a band. 
  Therefore, an RGB image contains three bands. 
  <P>A three-color subtractive image contains three bands; one each for cyan, 
  magenta, and yellow (CMY). A four-color subtractive image contains four bands; 
  one each for cyan, magenta, yellow, and black (CMYK).
  <P>
  <TABLE cellPadding=3 border=3>
    <CAPTION><FONT size=-1><B><A name=52193><I>Table 2-6 </I><IMG 
    src="Java AWT Imaging.files/sm-blank.gif" border=0> Java 2D Image Data 
    Classes </A></B></FONT></CAPTION>
    <TBODY>
    <TR vAlign=top>
      <TH><A name=52241>Type </A>