Scope of Image in 2.2?

Mario Torre neugens.limasoftware at
Fri Apr 20 03:30:18 PDT 2012

Hi Jim,

We started to do some swing/javafxintegration some time ago to allow
Swing component to be reused in JavaFX, although the export was not
done, I think our work could greatly benefit for something like this.

Please, see also for example:

and a nice video here:

Although I'm not working on JavaFX at the moment (until it will be
fully open sourced I doubt I'll jump back on it) I still have some
personal interest in seeing this work merged.


2012/4/20 Jim Graham <james.graham at>:
> 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 .
>> 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

pgp key: PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Proud GNU Classpath developer:
Read About us at:

Please, support open standards:

More information about the openjfx-dev mailing list