Scope of Image in 2.2?

[Dr. Michael Paus]

Again ++1
We are not using JAI because we use some in-house tooling instead (which 
we would have to
rewrite in a JFX environment) but the mentioned functionality is exactly 
what we need too.

When designing a new canvas node it might also be useful to see what 
others have done just
to get some ideas.
http://developer.android.com/reference/android/graphics/Canvas.html

Am 25.04.2012 11:15, schrieb Martin Desruisseaux:
> 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
>


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