Scope of Image in 2.2?
james.graham at oracle.com
Thu Apr 19 15:29:51 PDT 2012
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
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...
More information about the openjfx-dev