Automated testing discovered that `image::read_png` sometimes can not be initialized on Windows

🐛 Describe the bug

See https://github.com/pytorch/pytorch.github.io/runs/4042987825?check_suite_focus=true Several Windows configuration tests of torchvision failed with No such operator image::decode_png

Versions

0.11.1

cc @peterjc123 @nbcsm @guyang3532 @maxluk @gunandrose4u @mszhanyi

[peterjc123]

I think the cause of this problem is quite clear. First, In PyTorch, we use LoadLibraryEx and then LoadLibrary to load in the dependencies, but in torchvision, it relies on torch.ops.load_library, which uses ctypes.CDLL. (It uses LoadLibrary as the underlying API.) The behavior is inconsistent. Second, in PyTorch, we use AddDllDirectory and PATH for dependency resolving, but we do nothing when torch.ops.load_library is called. Actually, we should do the same, that is to add the directory containing the DLLs for dependency search.

Links:

1. pytorch init dependencies: https://github.com/pytorch/pytorch/blob/master/torch/__init__.py#L95-L136
2. pytorch torch.ops.load_library: https://github.com/pytorch/pytorch/blob/master/torch/_ops.py#L84-L111
3. torchvision init dependencies: https://github.com/pytorch/vision/blob/main/torchvision/extension.py#L13-L19

[andfoy]

and why do we bundle those libraries as dynamic dependencies instead of compiling them in?

It was easier when packaging the wheels, but statically compiling it into the image extension should fix these kind of issues indeed. However, OpenCV and other libraries also opt to dynamically link to libpng and other libraries.