Scope of Image in 2.2?

[Jim Graham]

Hi Martin,

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?

			...jim

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
>     * 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
>