<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Kevin,<div><br></div><div><div>Going from two implementations to three is really frustrating. But what’s even more frustrating is </div><div>that the Java ecosystem now doesn’t have just two implementations—it has five, six, or even more. </div><div>In addition to AWT and JavaFX, there are Android, SWT, Qt Jambi, and Skija, along with countless other image libraries.</div><div><br></div><div>The problem isn’t that there are multiple implementations, but that none of them are common enough, </div><div>so developers keep reinventing the wheel. Here’s a recent example: jxlatte[1]. It’s a pure Java JPEG XL decoder. </div><div>To avoid depending on java.desktop, its developers once again created new abstractions for colors and images.</div><div><br></div><div>The current situation is chaotic for the entire ecosystem and also sets a high barrier for creating new libraries. </div><div>Developing a small library for image processing should be simple, </div><div>but now developers have to think carefully before starting—and might even end up reinventing the wheel themselves. </div><div>This also creates a poor experience for users.</div><div><br></div><div>I’m not suggesting we deprecate all existing implementations, but I do think a new common library is important. </div><div>This library should provide a unified facade for existing implementations (SLF4J is a good example) </div><div>and prevent developers from having to reinvent the wheel repeatedly.</div></div><div><br></div><div>Glavo</div><div><br></div><div>[1]: <a href="https://github.com/Traneptora/jxlatte">https://github.com/Traneptora/jxlatte</a></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Apr 20, 2025 at 12:11 AM Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com">kevin.rushforth@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
I agree with Phil on this. I don't see enough value in creating yet
another image library in the JDK to justify the effort and the
weight of the API and implementation. We would need to design,
specify, implement, and support a new imaging API all while
maintaining the existing JavaFX and Java2D imaging libraries. We
wouldn't deprecate the existing imaging libraries in favor of the
new one, at least not any time in the next several years (if ever),
so we would either end up with three implementations (instead of
two) or additional effort to redo the implementation BufferedImage,
Raster, Image, etc, on top of the new library. Similarly for
JavaFX's (smaller) implementation. And then there's Image IO, which
would also need to be redone.<br>
<br>
So I am not at all optimistic about this, and I doubt this is
something we should pursue.<br>
<br>
--Kevin<br>
<br>
<br>
<div>On 4/18/2025 8:37 PM, Glavo wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi Jeremy,
<div><br>
</div>
<div>The purpose of my email is to:</div>
<div><br>
</div>
<div>
<ol>
<li>Find out if people feel the
work is worth the effort.</li>
<li>Find out if there is anyone
willing to take the lead.</li>
<li>Discuss how this work will
begin.</li>
</ol>
<div>I did have a draft design,
but I was not an expert in the
field, so I knew it had a lot of
flaws.</div>
</div>
<div>I guess if that's what people
really want, then people should
have their own ideas about it.</div>
<div>So instead of presenting this
flawed idea, I wanted to discuss
other things first.</div>
<div><br>
</div>
<div>Once I've determined that the
work is worth the effort, but no
expert has the free time to take
the lead, </div>
<div>I'll try to implement it myself
and then seek guidance.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What
is the difference between what
you’re describing and the Apache
Commons Imaging project itself?</blockquote>
<div><br>
</div>
<div>Apache Commons Imaging
currently depends on AWT
BufferedImage. It does not include
the things mentioned in the email.</div>
<div><br>
</div>
<div>Glavo</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Apr 18, 2025 at
4:37 AM Jeremy Wood <<a href="mailto:mickleness@gmail.com" target="_blank">mickleness@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<div><span>What is the scope / ideal feature set of this
project? </span><span>(Can you start outlining some of
the main interfaces you</span>’<span>re envisioning?
maybe in a google doc?)</span></div>
<div><span><br>
</span></div>
<div><span>What exactly are you looking for in this email
thread? Are you looking for resources (mostly people?)
who can work on this project? Or are you looking to
see if OpenJDK is willing/able to maintain this API?
(or something else?)</span></div>
<div><br>
</div>
<div>What is the difference between what you’re describing
and the Apache Commons Imaging project itself?</div>
<div><br>
</div>
<div>I assume this project is strictly related to reading
& writing images. So it will NOT support anything
analogous to:</div>
<div>1. Graphics2D</div>
<div>2. AffineTransform</div>
<div>3. PerspectiveTransform</div>
<div>4. Fonts</div>
<div>5. MultiResolutionImage</div>
<div>
<div id="m_5287744070152225820m_-1893235187118475663x64c725ac8a3d46a7b1f28aae80eb29d4">
<div><br>
</div>
</div>
</div>
<div> - Jeremy</div>
<div><br>
</div>
<div>obligatory xkcd reference:</div>
<div>
<div id="m_5287744070152225820m_-1893235187118475663x0474a3baca5744f7a5788dcdb0775e6b">
<div><br>
</div>
<div>
<div id="m_5287744070152225820m_-1893235187118475663x64c725ac8a3d46a7b1f28aae80eb29d4">
<div><a href="https://www.explainxkcd.com/wiki/index.php/927:_Standards" target="_blank">https://www.explainxkcd.com/wiki/index.php/927:_Standards</a></div>
<div><br>
</div>
</div>
</div>
</div>
</div>
<div>
<div>------ Original Message ------</div>
<div>From "Scott Palmer" <<a href="mailto:swpalmer@gmail.com" target="_blank">swpalmer@gmail.com</a>></div>
<div>To "Philip Race" <<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a>></div>
<div>Cc "Glavo" <<a href="mailto:zjx001202@gmail.com" target="_blank">zjx001202@gmail.com</a>>;
"openjfx-dev" <<a href="mailto:openjfx-dev@openjdk.org" target="_blank">openjfx-dev@openjdk.org</a>>;
<a href="mailto:client-libs-dev@openjdk.org" target="_blank">client-libs-dev@openjdk.org</a></div>
<div>Date 4/17/2025 12:57:17 PM</div>
<div>Subject Re: Proposal: A new common Image API</div>
</div>
<div><br>
</div>
<div id="m_5287744070152225820m_-1893235187118475663x074590b04d0741c">
<blockquote cite="http://CAL3e5iEX-guStx59X0C=K4VuG+yRt+1NAbQ5zR7AR_pDu7=FAw@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif">I think a
common image I/O library that is not tied to a UI
framework makes sense and is long overdue.</div>
<div class="gmail_default" style="font-family:arial,sans-serif">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.</div>
<div class="gmail_default" style="font-family:arial,sans-serif">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.</div>
<div class="gmail_default" style="font-family:arial,sans-serif">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.</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">I'm sure it
is all much harder than I suspect, but I don't
think it should be. :-)</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif">Scott</div>
<div class="gmail_default" style="font-family:arial,sans-serif"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 17,
2025 at 12:10 AM Philip Race <<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">First,
note than John Neffenger replied to this but only
on openjfx-dev<br>
and the first thing I saw was the reply and
couldn't see the original.<br>
After some consternation I tracked down this
cross-post.<br>
<br>
Here's a link to the reply <br>
<a href="https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html" target="_blank">https://mail.openjdk.org/pipermail/openjfx-dev/2025-April/053616.html</a><br>
<br>
A fundamental problem is that all the users need
to be able to produce <br>
and consume the data.<br>
So there either needs to be a module dependency
(not viable) or an <br>
agreed format (are we<br>
really going to define an image format which
encapsulates everything, <br>
including the multi-frame<br>
GIF support) and then everyone needs a reader and
don't forget writers <br>
and they need to be able to do .. so much ..<br>
<br>
I just don't see a viable path here.<br>
And several (8 ?) years ago, I pondered some way
to separate image <br>
handling from the<br>
desktop module to see if a server app could use it
without pulling in <br>
AWT but the intra-package<br>
dependencies made it impossible without changes I
didn't even figure out <br>
if they were possible.<br>
<br>
-phil.<br>
<br>
On 4/16/25 3:04 AM, Glavo wrote:<br>
> Currently, there are multiple different image
APIs in the Java <br>
> ecosystem: AWT, JavaFX, Android, etc.<br>
> What's worse, the Android platform does not
provide support for AWT, <br>
> making the Java ecosystem even more
fragmented.<br>
><br>
> There are some obvious problems with the
current situation:<br>
><br>
> * Third-party libraries that need an image
API are difficult to be <br>
> universal.<br>
> A practical example: Apache Commons Imaging
has been in the alpha <br>
> stage and cannot release version 1.0.<br>
> The main reason is that it depends on
`java.awt.image`, so it <br>
> doesn't work on Android.<br>
> We hope to solve this problem before the
official release.<br>
> * Different image APIs have to repeatedly
implement support for <br>
> reading the same image format (such as JPEG).<br>
> In fact, AWT, JavaFX, and Android now each
implement reading JPEG <br>
> images.<br>
> This is a waste.<br>
><br>
> I thought we might be able to create a new
module independent of <br>
> java.desktop that provides a common
abstraction for images.<br>
> It should:<br>
><br>
> * Provides common Image and ImageProvider
interfaces that can be <br>
> implemented by different providers.<br>
> * Provides a unified abstraction for colors,
color spaces, pixel <br>
> formats, etc.<br>
> * Provides general and extensible image I/O
support.<br>
> Read/write support should only need to be
implemented once per image <br>
> format.<br>
> It should be bidirectionally compatible
with `javax.imageio`:<br>
> The implementation of either API can be
accessed through the other API.<br>
><br>
> I want to know if this is an idea worth
putting into practice?<br>
> I'm not an expert in this field, so I'm
worried about creating designs <br>
> with many flaws.<br>
> Therefore, I haven't attempted to implement
it yet.<br>
> If anyone is willing to implement it, I'd
like to help.<br>
><br>
> I had sent an email a few days ago but no one
responded, so I <br>
> re-edited it and sent this one.<br>
><br>
> Glavo<br>
><br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>