Scope of Image in 2.2?
neugens.limasoftware at gmail.com
Fri Apr 20 03:30:18 PDT 2012
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 oracle.com>:
> 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)...
> 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...
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
Please, support open standards:
More information about the openjfx-dev