Proposal: A new common Image API

[Philip Race]

First, note than John Neffenger replied to this but only on openjfx-dev
and the first thing I saw was the reply and couldn't see the original.
After some consternation I tracked down this cross-post.

Here's a link to the reply 
https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html

A fundamental problem is that all the users need to be able to produce 
and consume the data.
So there either needs to be a module dependency (not viable) or an 
agreed format (are we
really going to define an image format which encapsulates everything, 
including the multi-frame
GIF support) and then everyone needs a reader and don't forget writers 
and they need to be able to do .. so much ..

I just don't see a viable path here.
And several (8 ?) years ago, I pondered some way to separate image 
handling from the
desktop module to see if a server app could use it without pulling in 
AWT but the intra-package
dependencies made it impossible without changes I didn't even figure out 
if they were possible.

-phil.

On 4/16/25 3:04 AM, Glavo wrote:
> Currently, there are multiple different image APIs in the Java 
> ecosystem: AWT, JavaFX, Android, etc.
> What's worse, the Android platform does not provide support for AWT, 
> making the Java ecosystem even more fragmented.
>
> There are some obvious problems with the current situation:
>
> * Third-party libraries that need an image API are difficult to be 
> universal.
>   A practical example: Apache Commons Imaging has been in the alpha 
> stage and cannot release version 1.0.
>   The main reason is that it depends on `java.awt.image`, so it 
> doesn't work on Android.
>   We hope to solve this problem before the official release.
> * Different image APIs have to repeatedly implement support for 
> reading the same image format (such as JPEG).
>   In fact, AWT, JavaFX, and Android now each implement reading JPEG 
> images.
>   This is a waste.
>
> I thought we might be able to create a new module independent of 
> java.desktop that provides a common abstraction for images.
> It should:
>
> * Provides common Image and ImageProvider interfaces that can be 
> implemented by different providers.
> * Provides a unified abstraction for colors, color spaces, pixel 
> formats, etc.
> * Provides general and extensible image I/O support.
>   Read/write support should only need to be implemented once per image 
> format.
>   It should be bidirectionally compatible with `javax.imageio`:
>   The implementation of either API can be accessed through the other API.
>
> I want to know if this is an idea worth putting into practice?
> I'm not an expert in this field, so I'm worried about creating designs 
> with many flaws.
> Therefore, I haven't attempted to implement it yet.
> If anyone is willing to implement it, I'd like to help.
>
> I had sent an email a few days ago but no one responded, so I 
> re-edited it and sent this one.
>
> Glavo
>