Skip to content

Replace JAI

Jump to bottom Edit New page
Jody Garnett edited this page Dec 22, 2023 · 25 revisions

Replace Java Advanced Imaging

GeoTools has long been hosted on top of closed source software - up until OpenJDK Java was only available under a dual Sun Binary License / Sun Research License. The image processing library we use, Java Advanced Imaging (JAI), was originally released as a Java extension using these two licenses.

There are two problems with JAI:

  • The Binary License / Research License is not open source
  • The project has been abandoned by Oracle

In 2015 we took the first step on this road - replacing the Vecmath library used for matrix calculations. This allows GeoTools to be used, on a pure open source platform, for vector processing tasks.

The next step is Replacing JAI allowing GeoTools to provide a similar freedom to those working with raster data.

The JAI-Ext project (from GeoSolutions) appears to be a front-runner to replace JAI for LocationTech use as it has already rewritten functionality for geospatial raster use. We have discussed the initial scope Simone Giannecchini (JAI-Ext project lead) on what it would take to make this a standalone project being extra careful about avoiding potential encumbrances.

Game Plan

The larger picture (beyond just a proposal for a new project) is a four step joint initiative:

  1. Raster Processing Engine API (LocationTech): definition of raster-processing-api

  2. Raster Processing Engine (LocationTech) : reference pure-java implementation

    • core implementation
    • migrate jai-ext implementation (operations etc...) to new api

  3. Raster Processing Wrapper (OSGeo) : benchmark jai-wrapper implementation

  4. GeoTools Replace JAI (OSGeo): migrate to raster processing engine api and coordinate transition affected projects (GeoServer, GeoNode, uDig, GeoScript, etc...)

The advantage of this game plan is the ability to benchmark raster processing engine against java advanced imaging and confirm performance targets are met. By supporting the raster-processing-engine api each project can transition at their own pace.

Initial 2016 Scope

Create a Raster Processing Engine:

  • New modern Java API
  • Pure Java implementation
  • Ability to stage tiles in memory and process tiles in parallel
  • Clear image processing operations, allowing installations to use native libs to accelerate processing if available

Backwards compatibility is not a requirement - it is explicitly to be avoided. This is a new project providing a functional replacement free of any Oracle encumbrance.

Impact:

  • imageworker: simple api ontop of JAI, builder pattern, wraps rendered image, etc...
  • raster process: base class for WPS raster process (tend not to this approach)
  • grid coverage wrapper: geotools operators classes that handle raster + bounds

Approach

We would like to carefully create a replacement, with a minimal disruption, keeping in mind that applications (and organizations) world wide are dependent on this functionality.

GeoTools operations currently wrap JAI operations. We are not in position to reuse JAI Interfaces (due to license restrictions). Our approach is to create a new API, and update the GeoTools wrappers, carefully shielding downstream projects from the change of image proccessing library.

Clarification

JAI provides both tile staging (loading data into an in-memory tile cache) and image processing (working on the individual tiles once in memory). This is a key point of difference allowing GeoTools to work with images larger than memory. Indeed image processing libraries can be used to implement "native" JAI Operations at this stage.

To keep this goal in mind we will focus on "Tile Processing" when discussing scope.

Updated 2018 Scope

As work on LocationTech Raster Processing Engine began at LocationTech we made one last-ditch effort to contact Oracle.

Thanks to Andrea Ross and some careful negotiation we arranged the donation of the JAI codebase to the Eclipse Foundation.

  1. Raster Processing Engine was renamed as ImageN:

  2. The source code has been integrated and compiles in a modern maven environment

  3. Documentation was converted to Markdown

  4. Pending: Test cases were not donated to the project and will need to be written.

    • short term: While we can trust integration testing at the JAI-EXT and GeoTools level; a minimum of test cases should be be included.
    • medium term: Add Unit tests as issues are encountered and fixed
    • long term: Use the perceptual difference testing code from GeoTools and build up a suite of test examples. This approach has been used successfully by the JTS Topology Suite and promote library stability.

  5. Pending: Port JAI-EXT operations and functionality to a JAI-EXT 2.x, or ImageN-Ext 1.x, or integrate with ImageN project directly.

Thanks to Boundless for starting this process, and Jody Garnett for working on this activity thus far.

ImageIO and ImageIO-EXT

We should double check the relationship with ImageIO and ImageIO-Ext.

The ImageIO project was also abandoned by Oracle. It has been picked up in the form of https://java.net/projects/jai-imageio-core:

  • jai-imageio-core version 1.1 is available under a BSD style license

By excluding the dependencies (and CODECLib library) ImageIO can be used as a BSD project. Some glue code may be required to connect this subset up to the tile processing engine.

Planning

Interested Parties

  • Boundless
  • GeoSolutions
  • H2Gis
  • Eclipse Foundation (LocationTech and Science working groups)
  • OSGeo (GeoTools, GeoServer, ...)

Projects:

  • GeoTools, GeoServer, H2Gis, JAI-EXT, ImageIO-EXT, JAI-Tools, uDig, GeoScript
  • Image-IO - need to sort out approach here

Background discussion:

Add a custom footer
Add a custom sidebar
Clone this wiki locally