Scope of Image in 2.2?

Martin Desruisseaux martin.desruisseaux at geomatys.fr
Wed Apr 25 02:15:12 PDT 2012


Le 21/04/12 15:48, Dr. Michael Paus a écrit :
> +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.

Right. Terabytes of images are becoming more and more commons too. While 
processing power and storage capabilities increase fast, the amount of images 
from satellites is increasing as fast. I think that Earth observation will 
continue to stretch computers to their limit for the foreseeable future.

Continuing on my previous email listing things from existing API that may be 
nice to preserve, there is some other proposals from Java Advanced Imaging 
(http://download.java.net/media/jai/javadoc/1.1.3/jai-apidocs/index.html):

javax.media.jai.TileCache
---------------------
Stores the result of an image operation. The cache content may be flushed at any 
time, so only data that can be re-computed on demand are cached there. The 
default implementation caches in memory, but developers can override e.g. for 
flushing tiles to temporary files on disk.

javax.media.jai.iterator
-------------------
Iterates over the pixel in an image. Such iterations are not so easy when an 
image has more than one tile. The iterators insulate the users from this 
complexity. Note: the JAI iterator interfaces could probably be simpler.

javax.media.jai.Warp
-----------------
A more generic way than AffineTransform for performing images resampling. Warp 
is the base class, and WarpAffine is one subclass among others (admittedly the 
most important one). Another useful subclass is WarpGrid, which will be needed 
for the map component if it is planed to support map projections. Note that JAI 
has a lot of redundancies like "Translate", "Scale" and "Affine" operations 
duplicating the work of WarpAffine. Such duplication could be avoided, assuming 
that the JavaFX implementation would detect by itself when a WarpAffine is just 
a translation, or just a scale (for optimization purposes).

javax.media.jai.Interpolation
------------------------
Actually any mechanism allowing the developer to provide his own interpolation 
algorithm would fit. "Nearest neighbourhood", "Bilinear" and "Bicubic" are 
probably sufficient for a standard library, but more specialized interpolation 
methods exist. All JAI operations that may interpolate pixel values, especially 
the above-cited Warp operation, accept an arbitrary Interpolation object.

     Martin



More information about the openjfx-dev mailing list