Scope of Image in 2.2?
martin.desruisseaux at geomatys.fr
Sat Apr 21 06:32:39 PDT 2012
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:
but we don't need the following to work:
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).
More information about the openjfx-dev