On Wed, 14 Oct 2026 21:17:01 GMT, Sergey Bylokhov <[email protected]> wrote:
> > Yes it does. I referenced the exact place in the JPEG spec that requires it. > > any use of 16 bit quantization with 8 bit samples is a bug in what ever > > provides it or whatever allows it. > > That is correct. But neither "8 bit samples" nor this clamp makes the plugin > baseline-only, before or after the patch. It is not, since progressive is > supported. So the reason of the fix should be updated: not "ImageIO's native > JPEG library is compiled to support baseline JPEG only", but "drop the > libjpeg extension (16 bit quantization tables for 8 bit samples) which the > plugin supported since 1.4". Baseline has nothing to do with it, and that is > a behavior change. 8 bit samples is what is important. Progressive 8 bit does not change anything. The plugin has never *supported* 16 bit quantization. It not "preventing" it is not the same thing as supported. > If the clamp on the read path is a guard against values outside 1..255, it > does not work: the table stored in the image is read by libjpeg itself and > reaches the decoder as is, the code change in this PR never sees it. To guard > that the library must be changed, which is impossible with the system > libjpeg. And the decoder does not need it, it only multiplies by the table, > the crash is in the encoder. So the 255-clamp might be applied on write only. What crash ? I'm not seeing any crash, nor fixing a crash. I'm just fixing the out of range values. The null de-ref crash was the Huffman tables problem, not related to this. The alternative would be to reject such an image which doesn't seem necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33217#discussion_r4276818642
