imageio.plugins.freeimage.download() downloads wrong architecture on Apple Silicon

[irieger]

Hello,

I'm using python (3.9.2) on a Mac Mini M1 installed via conda as a native Apple Silicon/arm64 executable. When I install imageio and execute

>>> import imageio
>>> imageio.plugins.freeimage.download()
Imageio: 'libfreeimage-3.16.0-osx10.6.dylib' was not found on your computer; downloading it now.
Try 1. Download from https://github.com/imageio/imageio-binaries/raw/master/freeimage/libfreeimage-3.16.0-osx10.6.dylib (4.3 MB)
Downloading: 4461680/4461680 bytes (100.0%)
  Done
File saved as /Users/ingmar/Library/Application Support/imageio/freeimage/libfreeimage-3.16.0-osx10.6.dylib.

The downloaded libfreeimage...dylib is for x64:

ingmar@u2 % file '/Users/ingmar/Library/Application Support/imageio/freeimage/libfreeimage-3.16.0-osx10.6.dylib'
/Users/ingmar/Library/Application Support/imageio/freeimage/libfreeimage-3.16.0-osx10.6.dylib: Mach-O 64-bit dynamically linked shared library x86_64

When executing, I don't get an error regarding the wrong architecture, but I can't open files like EXR which should require freeimage.

[FirefoxMetzger]

Disclaimer: Not a Mac user, so my Mac experience is limited.

The helper script that downloads freeimage (imageio.plugins.freeimage.download()) comes from a time before Apple used M1 (ARM-based) processors, so it likely doesn't account for this and simply assumes all Macs are x64. Indeed, our auxiliary repo that contains the binaries for download (found here) only has an x64 binary.

I think the solution here would be to add an ARM binary for Mac to the repo and to also check the user's processor architecture when selecting the download target. However, it would be good if somebody with Mac experience could comment on this as well :)

[kmilos]

I find the whole binary download process error/security-prone and prefer to stick with system provided freeimage.

@irieger Just undo it and conda install freeimage (they provide one for arm64) and imageio should pick it up...

[almarklein]

I find the whole binary download process error/security-prone and prefer to stick with system provided freeimage.

Yeah, we've already improved this for ffmpeg by providing a separate repo+package for it, and we want to do the same for freeimage. Just a a lack of time.

[KelSolaar]

@irieger : I just came across this one, the Homebrew library worked just fine for me: brew install freeimage

[sfjohnston]

Would love to have freeimage in my virtualenv sandbox rather than condo or brew.
Could this be done as:
pip install imageio[freeimage]
Similar to the ffmpeg plugin?

[FirefoxMetzger]

@sfjohnston Yes I think that can be done, but it will require a larger refactor.

First off, for imageio[freeimage] to work the same way as imageio[ffmpeg] we would have to create a dedicated package for freeimage that can be installed, or we would have to hack setuptools to run a certain script that installs freeimage when freeimage is set in extra_requires. Regarding the former, it is already in the backlog; regarding the latter, I don't know if that is actually possible.

For freeimage to then run on M1, we would have to then create our own precompiled binaries and distribute them. This is - essentially - why others chose the brew/conda route because the packages there do that for you.

So yes, it can happen (and should) happen. I can't tell you when though, because we core devs are currently busy solving other issues. That said if you - or someone else - would like to volunteer in spearheading this effort it will likely happen sooner than later. I will - of course - support you during that process :).

[sfjohnston]

Thank you for responding. Had a few minutes this morning and got freeimage to compile for arm64, and a universal one. Started to do the work myself, but found a solution online that made things easier. - Downloaded FreeImage from sourceforge: http://downloads.sourceforge.net/freeimage/FreeImage3180.zip - Unzip and apply the attached patchfile. The origin of these changes is from the following link, though I did create a different solution in the Makefile.osx: https://www.ultraengine.com/community/topic/59665-freeimage-build-errors/ - make - copy the resulting dylib from Dist to ~/Library/Application Support/imageio - Note that imageio wants to download dylibs to a freeimage subdirectory, but on my machine that folder is not in the library search path, but the parent "imageio" directory is. The quickest fix for imageio may be to incorporate this revised patchfile in the build process for the binary file downloaded on osx by the internal downloader. I haven't fully tested it with all image combinations, but I was able to test on both intel and apple silicon to confirm it works on both. Note that the universal binary can be compiled on either Apple Silicon or Intel. [macos_universal_fixes.diff.gz](https://github.com/imageio/imageio/files/7833730/macos_universal_fixes.diff.gz)

[FirefoxMetzger]

Interesting find @sfjohnston. I had a look at the diff and it all looks like reasonable changes; I can't test them further at the moment because I'm currently on a Windows machine. That said, the build should ultimately be done by GH Action runners, so once that exists I think we will add it there :)

I'm actually not sure how we got the currently available macOS binaries. @almarklein, what has the process been so far? Depending on that, we might be able to build them the old way, add the binary to our suite, and close this issue for now.

[almarklein]

what has the process been so far?

Copying the binaries from the freeimage sourceforge page :/

Ideally, as mentioned earlier in this issue, there would be a new project (called e.g. imageio-freeimage) that would implement the wrapper and handle the distribution of the freeimage lib. If I'd do it now, I would indeed build the binaries from source on GH actions, using e.g. cibuildwheel to make this process easier. I'm not interested enough in freeimage to lead this effort, and I think @FirefoxMetzger also has his hands full, so it would be great if someone with a special interest in freeimage could have a crack at this. I'd be happy to help/advice on the GH actions stuff though.

[aknoerig]

Can someone shed light on the current status? I tried a few of the suggested workarounds, but not all are working:

1. brew install freeimage doesn't fix it for me, as somehow the library isn't picked up
2. There is a imageio-freeimage library now, but it doesn't address the arm64 issue
3. conda install -c conda-forge freeimage works (!), but it's not picked up not in all situations (e.g. inside a blender script)
4. Automatically use locally available version libfreeimage #706 is a bit unclear regarding the resolution - does it suggest to install imageio via conda, hoping that it would then find any separate freeimage install. It doesn't seem to make a difference for me.

In summary, there are currently only some conda-based ways to get it to work, but not reliably. Is that correct, or am I missing something?

Until there is a new approach, wouldn't it be easiest to simply amend the existing "download"-approach with a pre-compiled arm64 library?

[KelSolaar]

This is causing some drama on the latest macOs Github Actions runner currently. They have been updated to use macOS Sonoma sometimes last week and the freeimage library cannot be loaded properly now.

Would not it make sense to update the current freeimage download to use an ARM library? The first M1 was released in November 2020 so it is probably about time to switch to ARM fully and drop x64 support?

Cheers,

Thomas

[almarklein]

The best way forward, imo, is to improve imageio-freeimage so that it posts platform specific wheels to pypi that each contain the appropriate freeimage library. Then in imageio, rely on imageio_freeimage.

A short-term fix is also possible, by:

• Adding an macos-arm binary to https://github.com/imageio/imageio-binaries/tree/master/freeimage, from conda builds?
• Updating get_platform() to make macos-arm look different from x86.
• Adding an entry for it here.

I don't have any time to work on this, and I suspect @FirefoxMetzger has neither. But I can review pull requests. Is anyone interested in helping out with this?

[FirefoxMetzger]

I agree with @almarklein . Having a wheel that ships the binary alongside it would be the best solution. The problem is that there currently isn't motivation to build this and FreeImage was last updated in 2018. I tried building this a while back (PR here); however, I hit a wall for MacOS. As it turns out, you have to tweak the FreeImage source to make things compile and this means we'd have to maintain a custom fork. I don't think there is enough community interest here to support this.

Zooming out a bit, we have alternative readers for most formats that FreeImage supports today. Pillow covers the bulk of it and the rest will soon be covered by our new rawpy plugin (PR here). Since this will provide us with coverage of all supported formats, and considering the lack of development on the FreeImage side, the better thing to do would be to deprecate the FreeImage plugin. It will continue to exist in its standalone repo for those who want (or need) it, but removing it here would make it more difficult for unaware users to start depending on abandoned code - and it would not randomly break our (otherwise working) CI/CD pipeline.

---

@almarklein Conda is building FreeImage for M1? I didn't know, but will have a look. If it provides working binaries I can make the PR to add logic for M1 vs x86 Macs.

and I suspect @FirefoxMetzger has neither

It's true, I haven't had much time for dev work. I've been promoted last month (yay me 🎉) and have been busy transitioning between roles.

[FirefoxMetzger]

@almarklein I just checked the conda files. There is indeed an arm64 version, but when I unpack it the resulting library is only 500kB in size. For comparison, all existing FreeImage libraries in imageio-binaries are around 4-5MB. Do you know if the provided binary is a standalone?

[KelSolaar]

Homebrew also ships it and we use it with imageio as follows: https://github.com/colour-science/colour/blob/bbcd4c699192a95da037f36b447ce2ddb21b694d/.github/workflows/continuous-integration-quality-unit-tests.yml#L35

It is certainly working on the new Sonoma runners from Github Actions.

[almarklein]

I uploaded Brew's version: imageio/imageio-binaries@4491157

[almarklein]

I've been promoted last month (yay me 🎉)

Congratulations!

[FirefoxMetzger]

I uploaded Brew's version: imageio/imageio-binaries@4491157

Awesome! I will block some time towards the end of the week to modify the plugin to download a hardware-specific version on Apple.