[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Scope of Image in 2.2?
From:       james.graham () oracle ! com (Jim Graham)
Date:       2012-04-28 0:05:13
Message-ID: 4F9B3439.4050207 () oracle ! com
[Download RAW message or body]

Hi Martin,

Unfortunately all of this is outside the scope of what we want to 
achieve in 2.2.  We aren't trying to replace JAI (yet?).  In this short 
term, we're trying to give developers the ability to customize pixels in 
an Image when they need to...

		...jim

On 4/25/2012 2:15 AM, Martin Desruisseaux wrote:
> 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
>

[prev in list] [next in list] [prev in thread] [next in thread]