-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a warning message (or even error message) if cjpeg binary is from libjpeg-turbo instead of mozjpeg #1532
Comments
hi, thanks for the clear report. is the rest of cjpeg between the two libraries compatible (for what imagine is using)? i wonder if we break things for people if we throw an exception and people who did not use features that use the what if we catch the error of binary excecution and do the check if things failed, to be able to do a better error message? the other thing this brought to my mind is that we should have some "check setup" command that checks if all the binaries are configured correctly (and that could check the version and warn about the wrong cjpeg binary) |
For what I tested, the rest of the features between binaries seems identical, but we can expect more divergence in the future. Unless the user set I agree to add a I can open a PR for that in coming weeks. |
fantastic for the check-setup command 🚀 if the -quant-table is enabled and calling cjpeg fails, i would continue to throw an exception, but instead of the generic exception it could be a more specific one that points the user into the right direction. |
The further I go, the more I wonder if the solution wouldn't be to add libjpeg-turbo support to the bundle? As it is said in MozJPEG Readme:
I understand that their What about adding another post-processor for libjpeg-turbo? |
so the mozjpeg patch also adds functionality? does the quant-table option exist in turbo too, but with a different name? are there other features we rely on that are not provided by turbo library? if there are not too many missing things, i would agree that a processor for turbo is a good idea. it will mean the user will need to configure which variant they have - but having to choose also prompts people to figure out what they have. |
Is your feature request related to a problem? Please describe.
Emit a warning or throw an error if the
cjpeg
binary is fromlibjpeg-turbo
instead ofmozjpeg
.Describe the solution you'd like
A possible solution could be to run
cjpeg -version
(which is available on both binaries) and check on the output. If it containslibjpeg-turbo
, a warning message can be logged, or an error can throw to alert the developer that the current binary is not supported by the bundle.The main difference in the bundle usage context is the
-quant-table
argument, which is not available oncjpeg
fromlibjpeg-turbo
. Using this binary leads to a 500 error on my application. If needed I can make a reproducer easily.Describe alternatives you've considered
I've considered to version a standalone binary of
mozjpeg
, but I have applications that runs on debian, exherbo, arch, macOS … It's not ok to have a specific version ofmozjpeg
for all OS.The text was updated successfully, but these errors were encountered: