<div dir="ltr">I support this! HDR support would be nice, but if there are issues with color spaces, that to me is a higher priority.<div><br></div><div>What do you mean to fix in the macros and graphics pipelines?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 26, 2023 at 5:11 AM Laurent Bourgès <<a href="mailto:bourges.laurent@gmail.com">bourges.laurent@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 dir="auto">Hi,<div dir="auto"><br></div><div dir="auto">I would like enhancing Java Image classes (awt / java2D) to support natively new image types with their use cases:</div><div dir="auto">- BGRA (inverse RGBA) with both byte, integer & PREMUL variants (4x8bits), as supported by skia, metal, vulkan apis</div><div dir="auto">- 10 or 16 bits per RGBA component to support HDR or 64bits images like R10G10B10A2 or R16G16B16A16, as supported by skia, metal, vulkan apis but also by PNG & TIFF file formats</div><div dir="auto"><br></div><div dir="auto">It represents a lot of work:</div><div dir="auto">- CSR to define new BufferedImageType, Image API changes to deal with short / long values (rgba 48 or 64bits)</div><div dir="auto">- fix native software loops (macros)</div><div dir="auto">- fix DirectX, OpenGL, XRender, Metal pipelines for accelerated Surface</div><div dir="auto"><br></div><div dir="auto">Ideally such image handling requires to handle properly gamma correction & colorspaces (linear RGBA or perceptual sRGB, P3...) but it is maybe another topic !</div><div dir="auto"><br></div><div dir="auto">Comments are welcome & potential use cases too,</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Laurent</div></div>
</blockquote></div>