Replace JAI

Brad Hards edited this page Nov 7, 2017 · 23 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.

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.

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:

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.