dlib Python module references save_jpeg() even if built with DLIB_JPEG_SUPPORT=0

[aldanor]

When building dlib with -DDLIB_JPEG_SUPPORT=0, Python bindings shouldn't unconditionally refer to save_jpeg() (in face_recognition module), otherwise dlib becomes unimportable like so:

ImportError: dlib.cpython-36m-x86_64-linux-gnu.so: undefined symbol: 
_ZN4dlib9save_jpegERKNS_7array2dINS_9rgb_pixelENS_33memory_manager_stateless_kernel_1IcEEEERKSsi

[aldanor]

(Perhaps the whole face_recognition module could be dropped if jpeg support is off since most methods there deal with jpegs?)

[davisking]

Why would you compile the python bindings without jpeg support in the first place?

[aldanor]

In my particular case? Since I only use dlib for its global opt module, nothing to do with image-related stuff - and because of this build issue all Python environments that use dlib have to carry a ljbjpeg around.

[davisking]

Are there any problems this causes? What bad things happen because of this? I'm not excited about adding more switches because users find them confusing. I don't want to get questions from people like, "I compiled with DLIB_JPEG_SUPPORT=0 and then got an error that I couldn't load a jpeg file. I am confused." I get lots of such questions already. :(

[aldanor]

My point of view, as a user, may be different from yours, of course :) Ditto re: not being excited about adding more switches, but here goes:

• Most 'normal' users of the Python side of dlib would just do a pip install or conda install a pre-built tarball, not having to mess with cmake compile flags and the like. This gives them the 'whole thing' if possible so, thus no questions.
• Those who disable things on purpose (e.g. jpeg support) probably do so because they know what they're doing and why they're doing it - in which case it should be no surprise to them that this or that feature ends up being disabled; I would be very surprised if someone purposefully disabled jpeg support and then opened a ticket to complain about, as you've noted above.
• There's parts of dlib (e.g. global optimization) that don't deal with any image related stuff; making libjpeg.so a hard dependency of the Python package is pretty brutal, since now you either have to ensure the boxes you deploy your Python package to have libjpeg installed, or haul it around in every conda environment your package gets installed to, depending on how you're structuring/packaging your Python code. If it wasn't for libjpeg, the only dependency is numpy - which makes total sense.
• When building Python package, you could probably wrap module bindings that depend on libjpeg in an ifdef and possibly output a big red cmake warning when building pybind11 bindings (e.g. "face_detection module is disabled due to jpeg_support=0").

[davisking]

- I would be very surprised if someone purposefully disabled jpeg support and then opened a ticket to complain about, as you've noted above.

Yes, it's very surprising. But I nevertheless get a huge number of questions along these lines.

- There's parts of dlib (e.g. global optimization) that don't deal with any image related stuff; making libjpeg.so a hard dependency of the Python package is pretty brutal, since now you either have to ensure the boxes you deploy your Python package to have libjpeg installed, or haul it around in every conda environment your package gets installed to, depending on how you're structuring/packaging your Python code. If it wasn't for libjpeg, the only dependency is numpy - which makes total sense. - When building Python package, you could probably wrap module bindings that depend on libjpeg in an ifdef and possibly output a big red cmake warning when building pybind11 bindings (e.g. "face_detection module is disabled due to jpeg_support=0").

OK, I'm convinced. Can you submit a PR with the necessary #ifdefs or whatever in the code so the build doesn't fail?

[aldanor]

Thanks! I'll try and do so in the next few days.

[dlib-issue-bot]

Warning: this issue has been inactive for 146 days and will be automatically closed on 2018-09-07 if there is no further activity.

If you are waiting for a response but haven't received one it's likely your question is somehow inappropriate. E.g. you didn't follow the issue submission instructions, or your question is easily answerable by reading the FAQ, dlib's documentation, or a Google search.

[dlib-issue-bot]

Notice: this issue has been closed because it has been inactive for 149 days. You may reopen this issue if it has been closed in error.