Scope of Image in 2.2?

[Martin Desruisseaux]

Hello Jim

Le 21/04/12 04:49, Jim Graham a écrit :
> 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?

Fortunately I think we need only the "easy" part of indexed color models. We 
need to be able to render an image having IndexColorModel to an ARGB image or 
Canvas, but we don't need the converse (drawing inside the indexed image 
itself). So the difficult problem of selecting an index value that approximate 
an arbitrary color can be avoided. In terms of Java2D API, we would need the 
following method to work with indexed images:

    Graphics2D.drawRenderedImage(RenderedImage, AffineTransform);

but we don't need the following to work:

    BufferedImage.createGraphics();


Actually in the way we are using it, we can see IndexColorModel as something 
equivalent to CSS styling applied to images. For us, images are data with some 
legend like "pixel value 0=forest, 1=land, 2=cold water, 3=hot water", /etc./, 
and we need to tell "/paint me the forests in green, the cold water in dark 
blue, etc./". We need to be able to change the "styling" efficiently, because 
GUI applications will often provide a slider allowing the users to emphases cold 
water or hot water or all the intermediate temperatures, etc. Such effect can 
also happen in animation.

With the Java2D API, the "styling" of an indexed image can be changed very 
efficiently by creating a new BufferedImage with the same DataBuffer but a 
different IndexColorModel. The key point is that the pixel data are not copied; 
both images share the same DataBuffer. So the operation is practically 
instantaneous and cheap even if the underlying image is huge. The indexed pixel 
values are converted to ARGB values on the fly by Graphics2D.drawRenderedImage.

In summary, we don't really need IndexColorModel. We need efficient "styling" of 
pixel values when those values have some "real world meaning" rather than being 
ARGB, with the "styling" applied on the fly at rendering time. The Java2D 
IndexColorModel is fantastic for this task. This kind of solution is actually 
widely used in major open source and commercial Geographic Information Systems. 
Any solution allowing us to perform similar "styling" as efficiently as Java2D 
currently does (in particular without copying or transforming pixel values) 
would be good. For beginning, we don't need any "styling" more sophisticated 
than what IndexColorModel allows since it covers 80% of the need (we manage the 
remaining 20% with our own ColorModel subclass - so some extension mechanism 
would still be needed).

     Regards,

         Martin