On Fri, 9 Oct 2026 22:00:41 GMT, Phil Race <[email protected]> wrote: >> src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 734: >> >>> 732: if (quant_ptr->quantval[j] > 255) { // ImageIO supports >>> baseline only >>> 733: quant_ptr->quantval[j] = 255; >>> 734: } >> >> There is a place where the clamp to 8-bit is used only if baseline is set, >> otherwise the 16-bit is used: [int max = (forceBaseline) ? 255 : >> 32767;](https://github.com/openjdk/jdk/blob/f2fd22f7a23505bef47227a97a51bc9e1837111e/src/java.desktop/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java#L179). >> I think it should be possible to trigger the usage of such JPEGQTable by >> the test and confirm that the 16 is actually used when the image is >> saved/read? > > I don't fully understand the suggestion. > But I've created a test for this that validates that the data is corrected > during write.
JPEGQTable.getScaledInstance(scale, false) mentioned above is specified to return a table "clamped to the range 1..32767" ([JPEGQTable.java#L179](https://github.com/openjdk/jdk/blob/f2fd22f7a23505bef47227a97a51bc9e1837111e/src/java.desktop/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java#L179)), and such a table can be passed to the writer (metadata `dqtable` node, `JPEGImageWriteParam.setEncodeTables`) and to the reader (`JPEGImageReadParam.setDecodeTables`). Before this patch the libjpeg seems writes a 16bit data, and the result decodes. After the patch every entry above 255 is silently clamped to 255, on the write and decode since the code path is shared. So I do not think this is accurate: >ImageIO's native JPEG library is compiled to support baseline JPEG only. This >means 8 bit quantization values in the range 1 -> 255. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33217#discussion_r4253026743
