fix(JXL): Correctly set Quality for JPEG XL #4933
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Jonathan Brown <[email protected]>
Signed-off-by: Jonathan Brown <[email protected]>
Signed-off-by: Jonathan Brown <[email protected]>
Collaborator
|
Looks reasonable to me, but I'm not a JXL expert. @1div0 any thoughts? |
Contributor
|
I will check++ Had free(time_t t) where t equals to 0 |
Collaborator
|
@1div0 Any chance to look at this? It's short, and it's certainly safe, I just seek a second opinion on whether it seems like a wise improvement to behavior. |
Collaborator
|
@1div0 thoughts? |
Contributor
Author
|
You can test the behaviour by encoding with OIIO without this PR and cjxl at the same quality setting. |
Contributor
|
OK |
Collaborator
|
@1div0 Does that mean "ok, I will take a look", or "I looked and I think this is ok?" |
Contributor
|
@lgritz the second one. The usage of distance = JxlEncoderDistanceFromQuality(compqual.second); is right. |
Collaborator
|
Thanks, I appreciate the check from you. |
lgritz
approved these changes
Oct 31, 2025
Distance in JPEG XL isn't linear, causing previous quality settings to scale between lossless and visually lossless, instead of lossless and the lowest quality.
Thankfully libjxl has a built in function to convert Quality to Distance, so I've swapped it in.
Unable to test it myself, but it's a simple fix that I ran by another libjxl dev too.