On Wed, 14 Oct 2026 07:19:27 GMT, Sergey Bylokhov <[email protected]> wrote:
>>> Our plugin is already non-baseline without 12 bit samples. >> >> No idea what that was meant to say, but no our plugin is baseline only. >> >> And if "--with-libjpeg=system" is used the capabilities are set by the >> system libjpeg. >> >> In the one in a million chance that really doesn't exist since there aren't >> a million distros, some one has compiled their JDK to use system libjpeg and >> does not control the system libjpeg and it is 12 bit (only) then they should >> not have done that. They'd have a jpeg library that cannot decode 99.999% of >> the JPEGs out there. > >>>Our plugin is already non-baseline without 12 bit samples. >>No idea what that was meant to say, but no our plugin is baseline only. > > It is not. Baseline is defined by the spec (8 bit samples, sequential, > Huffman, 2+2 tables). Our plugin can: > * Write and read progressive jpeg, which is not baseline, and the public API > JPEGImageWriteParam documents > "[Progressive](https://github.com/openjdk/jdk/blob/c368bac40e185398fbc40dc4d75a457f7a36f954/src/java.desktop/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java#L108) > encoding is supported". > * The test above shows it writes and reads 16 bit quantization tables > created by the public API > [JPEGQTable.getScaledInstance()](https://github.com/openjdk/jdk/blob/c368bac40e185398fbc40dc4d75a457f7a36f954/src/java.desktop/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java#L177) > which is also non-baseline feature. > > If the plugin were baseline only, the 255 clamp would be a noop, but it is > needed exactly because the plugin is not. > > And even with this change the plugin still decodes non-baseline images: the > clamp is applied only to the table passed by the application, the table > stored in the image itself is used as is, even when it is 16 bit. So the > reader is not made baseline only, it is made inconsistent. That is why I > asked: "Maybe we should clamp on write only and skip it on read?". I can prep > a test to prove that as well. > >>And if "--with-libjpeg=system" is used the capabilities are set by the system >>libjpeg. >>They'd have a jpeg library that cannot decode 99.999% of the JPEGs out there. > >>In the one in a million chance that really doesn't exist since there aren't a >>million distros, some one has compiled their JDK to use system libjpeg and >>does not control the system libjpeg and it is 12 bit (only) then they should >>not have done that. > > I did not say anything about system libjpeg with 12-bits(only). My point is > that to make a proper clamp on decoding you need to change the library itself > not only the glue code this patch touches, and that is impossible to force if > the system libjpeg is used. The plugin is baseline only. Any processing of 16 bit quantization tables can legitimately be disabled, but if it is not disabled that does not in any way make the plugin non-baseline. There is no need to edit the libjpeg. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33217#discussion_r4273119304
