Headless version???

[candalfigomoro]

Would it be possible to have a "headless" version of opencv in conda-forge?

[hmaarrfk]

I think that is a reasonable request.

I do not want to call it "headless" like the pypi version does.

But I think it should be dooable.

I had a sketch of a PR a while back:
#206

I think we would want to "weigh down" the noqt version and give people by default the qt version.

[hmaarrfk]

Are there dependencies other than qt that would need to be removed for the headless version you have in mind?

[candalfigomoro]

Are there dependencies other than qt that would need to be removed for the headless version you have in mind?

At the moment only qt come to mind

[candalfigomoro]

@hmaarrfk However, if there could be other dependencies in addition to qt, maybe "noqt" is not a very future-proof name, as it looks related only to qt

[hmaarrfk]

(I thought I sent this message earlier so sorry if I double sent this)

I am with supportive of wanting to make this second version. However I'm not sure on how best to maintain it.

To my knowledge, I don't think we can simply delete the dependency, or opencv would fail to import in python.

This might mean that we would have to build the package twice (which I'm kinda OK with).

However, what I don't know how to answer is how do we name the package so that it stays consistent with the rest of the ecosystem.

I would try to find a similar issue in: https://github.com/conda-forge/conda-forge.github.io

and cross reference here. There must be others that want slightly fewer features than the "feature full" packages that we provide by default.

Typically this involves creating a base package like libopencv-base but I'm not sure if that can be done with opencv.

Demonstration PRs would be welcome by me if you have an idea on how to do it.

[mshabunin]

OpenCV have ability to decouple some of dependencies using plugin mechanism. Currently GTK (highgui), OpenMP (core), TBB (core), MSMF (videoio), FFmpeg (videoio), GStreamer (videoio) and MediaSDK (videoio) are supported. Corresponding options can be found in the reference guide, e.g. https://docs.opencv.org/4.5.4/db/d05/tutorial_config_reference.html#tutorial_config_reference_highgui These plugins can be built in the main build process or in separate builds.

Howether I don't know how to tie this with Conda packaging, because I'm not fluent with it. Is there any package flavor mechanism or should it be implemented as _additional packages or meta-packages? And how would existing users transition to this new scheme? What should we do with Qt dependency?

[candalfigomoro]

As a side note, there's a "opencv-python-headless" package within:

• "intel" channel: https://anaconda.org/intel/opencv-python-headless (basically it just wraps the opencv-python-headless pypi wheel)
• "fastai" channel: https://anaconda.org/fastai/opencv-python-headless

[hmaarrfk]

@mshabunin can we remove the so files and keep OpenCv working? if so, that should be readily doable with Conda. i can help with that if you can help me identify the so file that is dependent on Qt

[mshabunin]

@hmaarrfk , you mean libraries? I'm afraid not. But we can split these libraries into smaller plugins which depend on other libraries. For example:

• Python library cv2.so depend on all OpenCV libraries (libopencv_*.so)
• libopencv_highgui.so can depend on GTK (this is not the case for conda-forge, just for example)
• if GTK is not found this library can not be loaded and cv2.so can not be loaded -> import cv2 fails
• we can create separate plugin library libopencv_highgui_gtk.so with this dependency and libopencv_highgui.so will try to load it at runtime and fail silently if it does not work, then import cv2 will work even if there is no GTK, but cv2.imshow() will throw Not implemented error if called

Main problem here is that OpenCV does not support extracting Qt dependency to a plugin yet, it should be implemented first.

Second problem is making packages and keeping compatibility with existing package names. Currently there are 3 packages opencv, py-opencv, libopencv:

For example we could make additional libopencv-qt and opencv-headless packages. Then users will be able to install only required set of packages using "opencv-headless + libopencv-xxx" combination.

Or maybe libopencv-headless and py-opencv-headless should be added too to allow C++-only installations - "libopencv-headless + libopencv-xxx"

[hmaarrfk]

Thank you for the explanation and the graphs. Very helpful.

Here are my thoughts:

1. It seems that from a packaging standpoint, we would want to work with OpenCV and get their help in making the Qt portion a "plugin" instead of a hard dependency.
2. I think I would want more input from conda-forge/core (I didn't tag them here yet) before making many packages with different names. The challenge I see, is that the GUI dependencies are only one of many dependencies we might want to start stripping away. What about "Video conversion" and other "features"?

Personally, I think we would want to create a core package, that starts to strip down more and more of these dependencies get removed gradually? However, that "breaks" things for somebody everytime we remove one dependency.

[hmaarrfk]

(@mshabunin as I understand you are involved with OpenCV upstream but my point is that it seems that it is a project htat is more than just a "conda-forge quick fix")

[hmaarrfk]

@candalfigomoro seeing as opencv was flagged as posing "systemic" risk, I am apprehensive at doing big changes here:
https://github.com/conda-forge/cfep/blob/main/cfep-08.md

I would suggest maintaining your own fork and simply building what you need. It should be pretty maintainable in the short term.... You can use a higher build number to prioritize it on your channel.

[candalfigomoro]

At the moment, I think I can try to just copy fastai's or intel's recipe for opencv-python-headless

[hmaarrfk]

That will work, if you don't use any package on conda-forge that depends on opencv

[adrosa]

has their been any updates on this? from what i can see opencv was flagged as posing "systemic" risk and the correct way to do that relies on getting OpenCV to make the Qt portion a plugin, which seems to have had no progress.
This is a constant pain point for using opencv with conda in ai clusters.

[hmaarrfk]

Increasing the number of configurations would (in my mind) make this package more difficult to maintain.

I understand that you may have constraints to try to reduce the size of your package. That is somewhat reasonable. You can fork conda-forge recipes and remove the Qt dependency. I do this for my own projects where I require special configurations.

Other solutions include working with upstream to make the package optionally depend on qt instead of having qt as a hard dependency.

unless an other long term maintainer of conda-forge steps in, I don't want to take on the additional burden of the different configurations.

[hmaarrfk]

For people that want a headless version, I might suggest that we start by building out a few packages;

• noqt
• noqt5
• noqt6

to help mamba find solutions that avoid the qt dependency.

I'm taking inspiration from @ocefpaf's recipe where nomkl is created
https://github.com/conda-forge/nomkl-feedstock/blob/main/recipe/meta.yaml

While this does "blow up" the build matrix, I feel like it might be ok.

[hmaarrfk]

it might be ok since it gives people an easy way to say: "my environment is devoid of a graphical interface, please do not install qt at all in my environment".

This would help pick out the correct version of opencv, but also of other packages.

[traversaro]

A kind of related but orthogonal issue (that probably can be spin-off in a separate discussion, feel free to do so if yo think it is the case) is "when should pip list list also opencv-python-headless as installed?

To make a concrete example stemming from a discussion with @roaldarbol . Let's say you installing the following environment:

mamba create -n idtrackeraipip python pip numpy rich h5py scipy opencv pyqt5 qtpy superqt toml-python matplotlib
mamba activate idtrackeraipip 
pip install idtrackerai

The last command will install the idtrackerai pypi package, and also the opencv-python-headless, as pip list only indicates as installed opencv-python, not opencv-python-headless . How to solve this? While I am aware the root of the problem is the confusing packaging on opencv on PyPI with separate opencv-python and opencv-python-headless packages, I think that on the conda-forge side we could also install the PyPI metadata also for opencv-python-headless beside of the opencv-python metadata that we already install since #300 .

Clearly, this is the tradeoff between two "evils", i.e. :

• E1: The fact that if you pip list after installing opencv with conda you see both opencv-python and opencv-python-headless
• E2: The fact that opencv-python-headless gets installed if you pip install a library that depends on it, even if opencv conda package is already installed.

Currently we have E2, but I personally think that E1 is the lesser evil.

[hmaarrfk]

we got opencv-python to showup (i htink you did that actually), we should just say that we also provide opencv-python-headless as well. No matter which version gets installed.

Pip packagers have just used it for their projects to avoid big downloads.

[traversaro]

we got opencv-python to showup (i htink you did that actually), we should just say that we also provide opencv-python-headless as well. No matter which version gets installed.

Pip packagers have just used it for their projects to avoid big downloads.

Great, I can add opencv-python-headless!

[hmaarrfk]

I feel like there might be something else that we also want to do. I remember seeing a list somewhere at conda-forge for the "translation" between certain pypi packages and those of conda-forge.

we should add that opencv-headless is just opencv

[traversaro]

I feel like there might be something else that we also want to do. I remember seeing a list somewhere at conda-forge for the "translation" between certain pypi packages and those of conda-forge.

we should add that opencv-headless is just opencv

I already opened conda/grayskull#530, I can also add it in https://github.com/regro/cf-scripts/blob/master/conda_forge_tick/pypi_name_mapping_static.yaml even if I am not sure where this file is used.

[hmaarrfk]

Thank you. https://github.com/regro/cf-scripts/blob/master/conda_forge_tick/pypi_name_mapping_static.yaml is what I was looking for.

[hmaarrfk]

Ok with the exception f the noqt package, I think we have the building blocks for the strategy outlined in: #396

Feedback and review appreciated.

[hmaarrfk]

While we have expanded our build matrix, I think that this is the reasonable course of action given the existing resources.

I've pinned #401 to guide users through. @traversaro also has a PR to staged recipes to help with opengl requirements.

Thank you @mshabunin for the insightful discussion. Hopefully you can keep this in mind upstream as new opencv build requirements are added!