Skip to content

Conversation

@dvida
Copy link
Contributor

@dvida dvida commented May 29, 2025

Description of the fix supplied by Ed Harman:

Ever since we started building RMS using the opencv-python package I
have been aware of a conflict due to the fact that -

Traditionally when we build opencv from source we compile with Gstreamer
support so modules like ShowLiveStream use that to render their output

If we omit that lengthy opencv build process and use instead the
pre-compiled version that pip supports we get -

opencv with Qt5 as it's rendering module and no Gstreamer support.

The impact of this is varied depending upon which distro and version you
use and how you install it, however what it is masking is this -

opencv-python installs a QT5 python-plugin version under cv2 called
libqxcb.so

SkyFit2 utilises QT5 as its rendering framework, which is installed by
pip - PyQt5 and it loads its own version of libqxcb.so under the QT5
plugin path.

The issue is that SkyFit2 imports opencv implicitly via other RMS
modules and so when it comes to load QT it finds it has already got the
plugin it requires (but which is incompatible) and promptly crashes -

(vRMS) eharman@rms-ubuntu-lts:~/source/RMS$ python -m Utils.SkyFit2
~/RMS_data/UK001B/ArchivedFiles/UK001B_20240224_180023_923809
running build_ext
skipping 'RMS.Astrometry.CyFunctions' extension (up-to-date)
running build_ext
skipping 'RMS.Routines.MorphCy' extension (up-to-date)
QObject::moveToThread: Current thread (0x5642ad6b9b70) is not the
object's thread (0x5642ae405bf0).
Cannot move to target thread (0x5642ad6b9b70)

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in
"/home/eharman/vRMS/lib/python3.10/site-packages/cv2/qt/plugins" even
though it was found.
This application failed to start because no Qt platform plugin could be
initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb, eglfs, linuxfb, minimal,
minimalegl, offscreen, vnc, wayland-egl, wayland,
wayland-xcomposite-egl, wayland-xcomposite-glx, webgl.

Aborted (core dumped)
(vRMS) eharman@rms-ubuntu-lts:~/source/RMS$

The web is littered with much noise and misinformation about this and
the QT folk are particularly unhelpful and merely state 'you are only
supposed to have one version of a plugin library installed..'

There is however a rather simple workaround -
If in SkyFit2 we initially pre-load opencv and then reset the QT plugin
path then it all works ok, and the beauty is that say for RPi3 users
using stock RMS images, they are unaffected by this change because they
are likely using a custom compiled version of opencv and so don't have
multiple QT libraries installed, i.e. it's transparent to them.

I've tested this on my RPi4 with Bookworm, Ubuntu 20.04/22.04 and stock
Buster RMS image 64bit only and it works fine, grateful if others can
test that this is backward compatible on all supported distros - I don't
have a RPi3 to play with.

I appreciate that some folk only use SkyFit2 from their Windows systems

  • I cannot test this since last time I attempted to install Anaconda it
    could not resolve some dependencies however am confident it should work.
    Also in my experience even on an RPi4 SkyFit2 is perfectly useable,
    pretty fast etc even when running headless over the network...

@Cybis320
Copy link
Contributor

On Linux / Pi, the current installation approach now uses system packages for both OpenCV and Qt5. Since both packages share the same system Qt5 installation, there should no longer be a conflict between competing bundled Qt5 libraries.
However, on Windows there are no system packages, so I'm unsure if it's currently still an issue.

@dvida
Copy link
Contributor Author

dvida commented Jan 13, 2026

Is there any issue if we applied this patch regardless?

@Cybis320
Copy link
Contributor

Is there any issue if we applied this patch regardless?

I'm not sure. I'm not able to reproduce the issue on any Mac, Pi, or Ubuntu machine running the current RMS code, whether OpenCV was built or not. It could be that the modern install method RMS now uses somehow solves this issue?

Can we check whether it is still a problem on Windows first? If it still is, to be on the safe side, we could make it conditional:

# Fix Qt platform plugin "xcb" error when pip-installed opencv bundles its own Qt
# that conflicts with PyQt5's Qt. Only apply workaround if bundled Qt is detected.
import cv2
cv2_path = os.path.dirname(cv2.__file__)
if os.path.exists(os.path.join(cv2_path, 'qt', 'plugins')):
    from PyQt5.QtCore import QLibraryInfo
    os.environ["QT_QPA_PLATFORM_PLUGIN_PATH"] = QLibraryInfo.location(QLibraryInfo.PluginsPath)

To find out if it fires:

# Fix Qt platform plugin "xcb" error when pip-installed opencv bundles its own Qt
# that conflicts with PyQt5's Qt. Only apply workaround if bundled Qt is detected.
import cv2
cv2_path = os.path.dirname(cv2.__file__)
if os.path.exists(os.path.join(cv2_path, 'qt', 'plugins')):
    from PyQt5.QtCore import QLibraryInfo
    os.environ["QT_QPA_PLATFORM_PLUGIN_PATH"] = QLibraryInfo.location(QLibraryInfo.PluginsPath)
    print("Set QT_QPA_PLATFORM_PLUGIN_PATH to", os.environ["QT_QPA_PLATFORM_PLUGIN_PATH"])

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants