We would definitely accept contributions which people are able to stand
behind.
We always recommend that people float ideas here before appearing with a PR.
This exchange is a start on that but should also be done for the
specific ideas.
Thanks,
-phil
On 10/17/25 8:23 AM, Liam Miller-Cushon wrote:
Also, I can't promise anything, but would there be any interest in
accepting contributions in this area? Or would they be unlikely to be
reviewed and accepted given current resourcing?
On Mon, Oct 13, 2025 at 2:19 PM Liam Miller-Cushon <[email protected]>
wrote:
Understood, thanks for the response.
On Fri, Oct 10, 2025 at 9:05 PM Phil Race <[email protected]>
wrote:
It is something we are aware of, but isn't something we are
resourced to do, not even to look into it.
-phil.
On 10/6/2025 4:57, Liam Miller-Cushon wrote:
Hi,
Are there any plans around HDR image support in the JDK?
My colleague Alec Mouri provides the following background:
Advancements in display and imaging technology have enabled
HDR (High Dynamic Range) content, which allows for displaying
content at a greater luminance than SDR (Standard Dynamic
Range) content. Google
<https://android-developers.googleblog.com/2025/08/what-is-hdr.html>and
Adobe
<https://blog.adobe.com/en/publish/2023/10/10/hdr-explained>have
informative blog posts explaining this new technology.
HDR images are part of intentional standards ISO 22028-5
<https://www.iso.org/standard/81863.html>and ISO 21496-1
<https://www.iso.org/standard/86775.html>. ISO 21496-1 in
particular is heavily used by the mobile ecosystem to
generate high-quality images. See the UltraHDR
<https://developer.android.com/media/platform/hdr-image-format>image
format as an example.
Every major operating system now has support for rendering
HDR GUIs. See: Android’s ExtendedRangeBrightness
<https://developer.android.com/reference/android/view/SurfaceControl.Transaction#setExtendedRangeBrightness(android.view.SurfaceControl,%20float,%20float)>and
COLOR_MODE_HDR
<https://developer.android.com/reference/android/content/pm/ActivityInfo#COLOR_MODE_HDR>,
Apple’s EDR
<https://developer.apple.com/documentation/metal/displaying-hdr-content-in-a-metal-layer>,
and Wayland’s HDR Protocol
<https://www.phoronix.com/news/Wayland-CM-HDR-Merged>, and
Window’s Advanced Color
<https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range>.
Platforms built on top of these OSs are accordingly adding
support for HDR. See: QT
<https://doc.qt.io/qt-6/qrhiswapchainhdrinfo.html>and CSS
<https://www.w3.org/TR/css-color-hdr-1/>.
Support in the JDK would involve decoding and display support.
Decoding support could be added to Image I/O. For ISO
22028-5, this means that ICC_ColorSpace
<https://docs.oracle.com/javase/8/docs/api/java/awt/color/ICC_ColorSpace.html>could
support CICPs as described in ITU-T H.273
<https://www.itu.int/rec/T-REC-H.273>to represent HLG and PQ
encodings. For ISO 21496-1, this means that BufferedImage
<https://docs.oracle.com/javase/8/docs/api/java/awt/image/BufferedImage.html>could
be decorated with a gainmap representation.
Display support could be added to Swing and JavaFX. This
would involve interacting with each major OS’s capabilities
to color manage and draw HDR images through ImageIcon or
JComponent. Note that SDR content should not be
colorimetrically affected when there is no HDR on screen.
I.e., the rest of the UI should not “flicker”.
