Scope of Image in 2.2?

[Martin Desruisseaux]

Hello Jim

Thanks for information, the plan sound good. On the import/export things, 
exports to BufferedImage is fine. But it would be nice if the imports could 
accept the RenderedImage interface, maybe with internal optimization for the 
BufferedImage special case. The main differences are:

  * RenderedImage may have an arbitrary number of tiles, while BufferedImage is
    restricted to a single tile
  * Pixel values in RenderedImage may be computed only when first needed
    (deferred execution)
  * Coordinate of upper left pixel in RenderedImage can be any integer, while
    BufferedImage is restricted to (0,0)


RenderedImage is heavily used in the /Java Advanced Imaging/ (JAI) library, 
which was designed by Sun Microsystems in collaboration with Nasa. JAI doesn't 
seem to be maintained anymore, but still in active use judging by the mailing list.

On the JavaFX side, it would be nice if the API is designed with tiled images, 
arbitrary pixel value types and deferred execution in mind, even if early JavaFX 
implementation is restricted to untiled images stored in byte buffers. Taking 
inspiration from the java.awt.image package, from my point of view the following 
classes and methods proved to work well in practice, so maybe an equivalent 
design in JavaFX would be nice:

  * RenderedImage interface (could be an abstract class)
      o getMinX, getMinY, getWidth, getHeight (could be a Rectangle)
      o getMinTileX, getMinTileY, getNumXTiles, getNumYTiles (could be a Rectangle)
      o getTile(int tileX, int tileY) : returns a single tile as a Raster
  * Raster class:
      o getSample(int x, int y, int b)
      o getSampleFloat(int x, int y, int b)
      o getSampleDouble(int x, int y, int b)
  * DataBuffer, could be replaced by java.nio.Buffer (not always ByteBuffer)
  * ColorModel class, especially the IndexColorModel subclass, and the
    capability to define our own ColorModel implementation (even if much slower
    than native implementations).


Notes:

  * getMinX, getMin are often (0,0), but not always.
  * Deferred execution happen at RenderedImage.getRaster(int tileX, int tileY)
    invocation time, on a tile-by-tile basis.
  * java.awt.image provides a special DataBuffer for unsigned shorts, which is
    often needed with IndexColorModel having more then 256 colors.
  * SampleModel and ColorSpace are a nice ideas, but in practice so closely tied
    to the ColorModel that I'm not sure it is worth to keep this separation of
    concern. There may be room for simplification here.


     Martin



Le 20/04/12 00:29, Jim Graham a écrit :
> At some point we will have BufferedImage import and export and I think that we 
> may want to start out with a more generalized set of Image APIs for FX that 
> cater to the needs of general GUI application programmers with basic ARGB 
> formats.  The BufferedImage import/export will hopefully happen soon enough 
> that applications with richer imaging needs can just stick with that API and 
> go through the import/export to use their data in FX applications.
>
> As FX evolves and caters to a wider application base and we get to 
> modularization so we want to be enable all of those applications to use just 
> FX without a lot of other Java APIs, then we can look at providing more 
> flexible formats in the core FX APIs without having to go through an import 
> step, but that won't be for this next release as I see it.  I don't think the 
> import step will be difficult, though.  The only drawbacks will be needing to 
> pull in the footprint of the core Java APIs for such an app and a slight 
> performance hit (optimistically I'll emphasize the word slight, but we don't 
> have the final import APIs yet to test)...
>
>             ...jim