Fix qtables and quality scaling

[Kyliroco]

When both a custom quantization table and a quality value are provided,
the quantization table should be scaled using the JPEG quality scaling factor.
If quality is not explicitly set, the default base quality of 50 is used to preserve the original table.
This ensures consistent behavior when saving JPEGs with custom qtables.

Before this correction, a quality set with a quantization table worked in reverse: the closer the quality was to 0, the less aggressive the quantization table was (made up of 1) and the closer it was to 100, the more it resembled the original table, whereas a standard jpeg table corresponds to a quality of 50. now the inserted table is modified by the quality parameter like a standard jpeg quantization table.

[radarhere]

Just to note - this code was originally added in #77

Would you be able to add a test that passes with your change, but fails without it?

a standard jpeg table corresponds to a quality of 50

Could you link to documentation or similar describing this?

[Kyliroco]

This behavior is defined directly in the libjpeg-turbo source code. In jcparam.c, it is explicitly stated:

/* The basic table is used as-is (scaling 100) for a quality of 50.
 * Qualities 50..100 are converted to scaling percentage 200 - 2*Q;
 * note that at Q=100 the scaling is 0, which will cause jpeg_add_quant_table
 * to make all the table entries 1 (hence, minimum quantization loss).
 * Qualities 1..50 are converted to scaling percentage 5000/Q.
 */

This means that a quality value of 50 corresponds to using the default quantization table as-is, without any scaling. Hence, when reusing or preserving a quantization table, it's consistent to assume that it's equivalent to a quality of 50.

[radarhere]

The test you added was to

verify that specifying standard qtables and a quality is equivalent to specifying only a quality

You tested it with a value of 75. Testing this further, I find that the results don't match for 0-23, do match for 24-100, but don't match if I don't specify quality at all. Any thoughts?

Also, in case you haven't seen it, and think it needs updating, here is our current documentation of the 'quality' parameter.
https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#jpeg-saving

[Kyliroco]

I found the problem, it came from the fact that force_baseline was set to true when the qtable was not given and to false when the qtable was given so I set it to true when the qtable and the quality were given and to false when only the qtable was given

[Kyliroco]

And for the documentation, the quality parameters seem good to me, it's more qtables that need to be modified, adding the fact that they are modified by the quality parameters if they are present. Or add it to the 2?

[Kyliroco]

@radarhere is it ok with you or are there still things you want me to correct?

[radarhere]

but don't match if I don't specify quality at all

Sorry, still wondering about this. If I save with qtables and no quality, and compare that against no qtables and no quality, it doesn’t match. From the user’s perspective, why should that be a special case?

https://pillow--8879.org.readthedocs.build/en/8879/handbook/image-file-formats.html#jpeg-saving

The image quality, on a scale from 0 (worst) to 95 (best), or the string keep. The default is 75.

Isn't the default value different when saving with qtables?

[Kyliroco]

Hello yes save with qtables and no quality use the qtable without changing it and giving no qtable and no quality will take the standard qtables from jpeg standard at 50 and apply a factor calculated from the default quality in pillow so 75

For the default quality value when saving only with qtables, there is none because the qtable is not modified if there is no quality and so can be considered to have already been applied to the qtable sent. This makes it possible to recompress an image with a precise quantization table.