Skip to content
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

Package libjpeg and libpng within torchvision #2291

Closed
fmassa opened this issue Jun 5, 2020 · 7 comments · Fixed by #2301
Closed

Package libjpeg and libpng within torchvision #2291

fmassa opened this issue Jun 5, 2020 · 7 comments · Fixed by #2301

Comments

@fmassa
Copy link
Member

fmassa commented Jun 5, 2020

With the addition of image-reading functions enabled by default in torchvision #1632 #1881 #1909, we will need to properly package libjpeg and libpng (and other libraries will be used soon as well, like ffmpeg) so that users of {Windows, Linux, OSX} x {pip, conda, source} can use those new functionalities in torchvision without issues.

I believe the current recommended way that PyTorch deals with 3rd-party libraries is the following:

  • for conda, we use conda's package manager to handle the dependencies. Both libjpeg and libpng are available in standard channels, although I'm not sure if using the conda-forge channel would bring problems due to conflicts with other libraries we use.
  • for pip, I believe the preferred way is to include the libraries together with the torchvision wheel
  • for source, we would need to handle the common installation locations, or at least provide clear instructions on how to provide the path to the libraries, either via CMake or performing the handling via python like Pillow does (although the logic seems quite intricate).

We will also need to make sure our CI (which is fairly tied to binary builds) is updated.

cc @seemethere @rgommers

@rgommers
Copy link

rgommers commented Jun 5, 2020

although I'm not sure if using the conda-forge channel would bring problems due to conflicts with other libraries we use.

It may right now I think, we really need to improve that situation. It would also force the users to mix channels. libpng is available in defaults. libjpeg-turbo is in defaults as well, but it looks outdated. Needs a more detailed look at what the best option is here.

@rgommers
Copy link

rgommers commented Jun 5, 2020

for pip, I believe the preferred way is to include the libraries together with the torchvision wheel

@fmassa said that size of the wheels isn't critical, and just bundling in libpng and libjpeg should be fine for now. So using auditwheel (Linux) and delocate (macOS) seems like the way to go. There's no such tool for Windows, so there the right libs need to be copied in by hand.

@andfoy
Copy link
Contributor

andfoy commented Jun 5, 2020

@fmassa, is it possible to have assignment permissions on this repository?

@fmassa
Copy link
Member Author

fmassa commented Jun 6, 2020

@andfoy I gave you and @rgommers triage permissions to torchvision

@andfoy
Copy link
Contributor

andfoy commented Jun 8, 2020

@jjhelmus is it possible to update libjpeg-turbo to the latest version on the default channel in Anaconda? It seems that the current version (1.2.1) is older than the one found on conda-forge.

@jjhelmus
Copy link

libjpeg-turbo is provided as a CDT in defaults not a standard package. CDT are packages which stand in for system installed libraries and therefore cannot be updated.

@rajveerb
Copy link

Is there a way to force the system to use a system libraries for instance libjpeg instead of the one with Pillow (default)?

I am asking this because the libjpeg library available in Pillow does not have debug symbols available which makes it hard to profile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants