Scope of Image in 2.2?

[Dr. Michael Paus]

+1
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 
memory.
We also don't need the reverse option.
Regards, Michael

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


-- 
--------------------------------------------------------------------------------------
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.