Scope of Image in 2.2?
Dr. Michael Paus
mp at jugs.org
Sat Apr 21 06:48:29 PDT 2012
Martin describes exactly the use-case that I have in my daily work too.
I might add that the indexed
image data we work with can easily exceed 1 GB. We read the raw bytes of
the currently relevant portion
of it and render it directly via a BufferedImage with an appropriate
IndexColorModel. This is very efficient
and any alternative would be much slower and would consume a lot more
We also don't need the reverse option.
it into an
Am 21.04.2012 15:32, schrieb 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:
> 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).
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.
More information about the openjfx-dev