Hi @Bodevan,

This is a common scenario when installing the standard opencv-python package on Databricks (or any headless server environment). The root cause is that opencv-python ships with GUI dependencies (Qt and X11 libraries) that are not available on Databricks cluster nodes, since they are headless Linux servers with no display. When Python tries to load the cv2 module, it attempts to link against those missing shared libraries, which causes the process to abort with SIGABRT (exit code 134) -- exactly the crash you are seeing.

You mentioned this was working a few weeks ago. This is likely because the opencv-python 4.13.0.92 release (which your logs show being downloaded) may have changed how it links to GUI dependencies compared to earlier versions. Either way, the solution below will resolve it reliably going forward.

THE FIX

Use opencv-python-headless instead of opencv-python. This package provides the exact same OpenCV functionality (all the same cv2 functions for image reading, processing, transformations, model inference, etc.) but without the GUI components that cause the crash. You do not need cv2.imshow() or other GUI display functions on a Databricks cluster anyway, since there is no display server.

In your notebook, run the following:

%pip install opencv-python-headless

Then in the next cell:

import cv2
print(cv2.__version__)

That should work without any crash.

IMPORTANT: UNINSTALL THE CONFLICTING PACKAGE FIRST

If you already ran %pip install opencv-python in your current session, the conflicting package may still be cached. To be safe, uninstall it first:

%pip uninstall opencv-python -y
%pip install opencv-python-headless

Then restart the Python environment to clear any cached module state:

dbutils.library.restartPython()

After that, import cv2 should work cleanly.

IF YOU NEED OPENCV CONTRIB MODULES

If your workload requires extra OpenCV contrib modules (such as SIFT, SURF, or other extended algorithms), use the headless contrib variant instead:

%pip install opencv-contrib-python-headless

This gives you the full contrib module set without the GUI dependencies.

MAKING IT PERSISTENT

If you want opencv available on every cluster start without re-running %pip each time, you have a few options:

1. Cluster library: Go to your cluster configuration, click Libraries, and install opencv-python-headless as a PyPI package. This installs it for all notebooks on that cluster.

2. Init script: Create a cluster-scoped init script that runs pip install opencv-python-headless at node startup. This is useful if you need it on all nodes for distributed UDF workloads.

3. Requirements file: If you use a requirements.txt for your project, add opencv-python-headless there and install via %pip install -r requirements.txt.

WHY THIS HAPPENS

The four OpenCV PyPI packages are:
- opencv-python (main modules + GUI) -- crashes on headless servers
- opencv-python-headless (main modules, no GUI) -- works on Databricks
- opencv-contrib-python (main + contrib + GUI) -- crashes on headless servers
- opencv-contrib-python-headless (main + contrib, no GUI) -- works on Databricks

These packages all provide the same "cv2" module name and conflict with each other, so only one should be installed at a time. The headless variants are designed specifically for server and cloud environments like Databricks.

REFERENCES

- Databricks documentation on notebook-scoped Python libraries: https://docs.databricks.com/en/libraries/notebooks-python-libraries.html
- Databricks documentation on cluster libraries: https://docs.databricks.com/en/libraries/cluster-libraries.html
- OpenCV Python package documentation explaining headless variants: https://pypi.org/project/opencv-python-headless/
- Databricks Runtime 17.3 LTS ML release notes (your runtime): https://docs.databricks.com/en/release-notes/runtime/17.3lts-ml.html

Hope this gets you unblocked. Let us know if you run into anything else.

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.