Scope of Image in 2.2?

[Jim Graham]

At some point we will have BufferedImage import and export and I think 
that we may want to start out with a more generalized set of Image APIs 
for FX that cater to the needs of general GUI application programmers 
with basic ARGB formats.  The BufferedImage import/export will hopefully 
happen soon enough that applications with richer imaging needs can just 
stick with that API and go through the import/export to use their data 
in FX applications.

As FX evolves and caters to a wider application base and we get to 
modularization so we want to be enable all of those applications to use 
just FX without a lot of other Java APIs, then we can look at providing 
more flexible formats in the core FX APIs without having to go through 
an import step, but that won't be for this next release as I see it.  I 
don't think the import step will be difficult, though.  The only 
drawbacks will be needing to pull in the footprint of the core Java APIs 
for such an app and a slight performance hit (optimistically I'll 
emphasize the word slight, but we don't have the final import APIs yet 
to test)...

			...jim

On 4/19/12 7:24 AM, Martin Desruisseaux wrote:
> Hello all
>
> Le 19/04/12 15:14, Kevin Rushforth a écrit :
>> One thing we should have mentioned up front is that the ImgaeData (and
>> ImgFormat) classes are very preliminary, which is why they have
>> started out life as "@deprecated". The final form they will take
>> depends on http://javafx-jira.kenai.com/browse/RT-17409 .
>
> Is it in the scope of the new Image API to support non-byte data? I'm
> thinking about oceanographer, meteorologist, astronomer, medical imagery
> and much more, where pixels may be floating point values, for example
> "/Sea Surface Temperature/" as real-world values in °C units, rendered
> to screen using a color palette.
>
> To be more specific, something equivalent to
> java.awt.image.IndexColorModel would be critical for the rendering of
> "/Sea Surface Temperature/" maps for instance. Something equivalent to
> the ability to specify our own java.awt.image.ColorModel in Java2D would
> be nice for the rendering of floating point data, but less important
> than IndexColorModel (because custom ColorModel are slow in Java2D
> anyway, so we often transform the data into something more suitable to
> IndexColorModel. Nevertheless it was nice to have a ColorModel that can
> work directly on floating point data, even if slow).
>
> It is okay if scientific imagery is considered out-of-scope for JavaFX
> (i.e. if JavaFX targets only vizualisation), since we can continue to
> use Java2D for that purpose - which work reasonably well - and convert
> to JavaFX only at rendering time. But some indications about the
> expected scope would be very useful...
>
> Regards,
>
> Martin
>