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