Scope of Image in 2.2?
james.graham at oracle.com
Fri Apr 20 19:49:57 PDT 2012
The one area I was hoping to avoid for now was indexed color models.
They're a pain to deal with in a world where RAM is cheap and 32-bit
images are so common. How important is that capability for you and what
are the possible alternatives that would work for you?
On 4/20/12 3:31 AM, Martin Desruisseaux wrote:
> 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 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
> * ColorModel class, especially the IndexColorModel subclass, and the
> capability to define our own ColorModel implementation (even if
> much slower than native implementations).
> * 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
> * 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.
> 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)...
More information about the openjfx-dev