I think a common image I/O library that is not tied to a UI framework makes sense and is long overdue. Raster images do have a common format that encapsulates everything. We essentially have this abstracted in the two UI frameworks already. At some level it comes down to PixelFormats and data buffers. There are not so many of them that it is impossible to make a common abstraction for the purposes of I/O that can be mapped to what is needed by the UI framework. Just as JavaFX already has the SwingFxUtils for converting between AWT and JavaFX formats, there can be a utility to convert between the I/O library format and each UI framework's format. I would expect in most cases that the raw pixel data could be shared without extra copying. ImageIO is a good starting point. Remove the actual UI classes from it like BufferedImage and keep plain raster representations of the data that can be wrapped by the UI classes. Under the hood the arrays or buffers of raster data don't have to change,they are the important parts that the I/O library needs to deal with. Mapping the metadata (width, height, colour space, pixel format, etc.) will usually be very cheap. Some cases may need to run a conversion, like the example of 1-bpp black/white needing to be remapped to RGB, but that that can happen in the utility layer that moves the image from the Image I/O domain to the UI framework domain on a case-by-case basis. Worst case is that the UI framework throws an UnsupportImageFormat exception when it doesn't have code to deal with raster data in a particular format.
I'm sure it is all much harder than I suspect, but I don't think it should be. :-) Scott On Thu, Apr 17, 2025 at 12:10 AM Philip Race <philip.r...@oracle.com> wrote: > 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 > > > >
