yolo:latest image opencv waiting "xcb" code error? about yolov5 HOT 15 OPEN

Hello 👋,

It seems like there's an issue with OpenCV trying to open a display window in an environment where it can't find a display (common in Docker containers or headless servers). A quick solution is to use OpenCV in a headless mode which doesn't require a GUI for display. For displaying images, you can write them to a file instead of trying to display them in a window.

Replace your display code:

cv2.imshow('title', exampleImg)

With a file write operation:

cv2.imwrite('output.jpg', exampleImg)

This change will save the image as output.jpg instead of trying to display it. For docker or headless setups, this is a common workaround.

If your application strictly requires displaying images in a window and you're working in a GUI-capable environment, ensure that your OpenCV installation includes GUI support (often missing in minimal or server OpenCV builds) and that your environment has access to a display. In some cases, setting the DISPLAY environment variable correctly or installing missing dependencies (xorg, libxext etc.) might resolve the issue.

If you're still encountering difficulties, consider checking your environment's compatibility with graphical applications or explore alternatives for visual output.

Hope this helps, and thank you for contributing to the YOLOv5 community! 🚀

from yolov5.

hello @glenn-jocher

xorg from docker, how. Do you use it?

apt-get -y install xorg xrdp xserver-xorg mesa-utils xauth gdm3

root@331adcd46e1a:/Download#xhost +local:root
xhost: unable to open display ":0"
root@331adcd46e1a:/Download# xhost +local:docker
xhost: unable to open display ":0"

how. can`t i call you and use it?

from yolov5.

Hello! 👋

Configuring Xorg for Docker can be a bit tricky, especially for GUI applications. Typically, you would need to set the DISPLAY environment variable and perhaps mount the X11 socket file into the container. However, from your description, it seems like there might be an issue with accessing the display from within the Docker container.

Here's a more straightforward approach you might want to try, focused on sharing the host's display with a Docker container:

1. Ensure your Docker container has access to the host's X11 socket. This is done by mounting the X11 socket as a volume:

   docker run -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY [YOUR_IMAGE]

2. On your host machine, allow local connections to X11:

   xhost +local:root

Please make sure you understand the security implications of xhost +local:root as it allows root access from local connections to X11.

If you're still facing issues, running graphical applications in Docker might require a more detailed setup based on your specific environment. The steps above should work for most Linux host environments, but the exact setup can vary.

Let me know if this helps or if you have any more questions! 🚀

from yolov5.

hello @glenn-jocher

DISPLAY does not appear. What could be the reason?

We proceeded as follows. The screen doesn't come up.

"run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY" Even with this command, the screen is not displayed.

Is there anything else I need to do after installing xorg?
apt-get -y install xorg xrdp xserver-xorg mesa-utils xauth gdm3

#> podman run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY docker.io/rurusungoa/php-apache:yolotest

#> podman ps -a
a21824545289 docker.io/rurusungoa/php-apache:yolotest /bin/bash 2 minutes ago Up 2 minutes ago suspicious_haibt

podman exec -it suspicious_haibt /bin/bash
root@a21824545289:/usr/src/app# xhost +local:root
xhost: unable to open display "unix"

root@a21824545289:/usr/src/app# echo $DISPLAY
unix

from yolov5.

@rurusungoa hello! 👋

It seems like the issue might stem from the way $DISPLAY is being set or accessed in your Docker (or in this case, Podman) environment. While you've taken the correct steps to install xorg and set up your display environment, there's a common pitfall that could cause the DISPLAY variable not to behave as expected.

Try setting the DISPLAY variable directly to your host's display, which is typically :0 or :1. Assuming a common scenario where your display is :0, you can adjust your command like so:

podman run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=:0 docker.io/rurusungoa/php-apache:yolotest

If that does not work, ensure that your X server on the host is configured to allow connections from Docker (or Podman) containers. Running xhost + (be aware of the security implications) temporarily allows all connections. If this resolves the issue, you'll know the problem lies with allowing access to the X server.

Lastly, remember that environment variables and certain configurations might not persist across sudo or user changes, or might be interpreted differently by Podman compared to Docker. If you're switching between users or using sudo, ensure the DISPLAY variable is correctly set and exported for that environment.

Let us know if this helps or if you encounter any more issues! 🚀

from yolov5.

@glenn-jocher hello

Even if you try reinstalling with docker instead of podman, it's the same. I don't know what to do.

hmm. (T.T) It’s hard and my head hurts.
If you are loading a Conda image with a graphics card installed, you must also load the nvidia graphics card instead of -e DISPLAY.

[root@nfs ~]# echo $DISPLAY
localhost:12.0

[root@nfs ~]# docker run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=12.0 docker.io/rurusungoa/php-apache:yolotest

root@38029bf63564:/usr/src/app# echo $DISPLAY
12.0

root@38029bf63564:/usr/src/app# xhost +
xhost: unable to open display "12.0"

root@38029bf63564:/usr/src/app# xhost +local:docker
xhost: unable to open display "12.0"

root@d1319f36baf7:/etc/ssh# python
Python 3.10.9 (main, Mar 8 2023, 10:47:38) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import cv2
img = cv2.imread('/Download/123.jpg')
cv2.imshow('title',img)

qt.qpa.xcb: could not connect to display localhost:12.0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/opt/conda/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.

Aborted (core dumped)

from yolov5.

@rurusungoa hello 👋,

It seems the issue arises because your Docker container cannot correctly communicate with the X server due to the DISPLAY environment variable setting. When using a non-default display number (like localhost:12.0), ensure both the host and the container can understand and access it.

Your host's DISPLAY is set as localhost:12.0. However, when passing this value to Docker, you should format it as DISPLAY=localhost:12.0 instead of DISPLAY=12.0. Here's how you can adjust your Docker run command:

docker run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=localhost:12.0 docker.io/rurusungoa/php-apache:yolotest

Also, regarding the use of NVIDIA GPUs with Docker, ensure you have NVIDIA Docker toolkit installed and use the --gpus all flag to allow Docker containers to utilize the GPU:

docker run --gpus all -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=localhost:12.0 docker.io/rurusungoa/php-apache:yolotest

Make sure your X server allows connections from your Docker container. You might need to run xhost +local: on the host to permit local connections temporarily.

Lastly, if graphics rendering or GPU acceleration is involved, the Qt platform issue hints at a deeper integration problem with the graphical environment—in this case, considering running GUI applications in Docker might require ensuring that all dependencies (including graphical drivers and libraries) are correctly set up in your container.

Hope this direction helps alleviate the headache a bit! Let us know if there's more we can do. 🚀

from yolov5.

hello @glenn-jocher

I tried using localhost:10.0, but it didn't work.
The same “can` not open display” error occurs.

Isn't it possible to use display in x11 docker image?
Now I doubt whether it is correct to display it.

Is there anything else I need to check?
XHOST works well on RHEL8.4 base before using the conda image.

You should not try to load it from a conda image.

I wonder if the reason why I can't load the conda image is because I'm using Putty when connecting to SSH.
What program do you use when connecting via ssh?

echo $DISPLAY
localhost:10.0

#docker run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=localhost:10.0 docker.io/rurusungoa/php-apache:yolotest
root@2ec511776ff1:/usr/src/app# xhost
xhost: unable to open display "localhost:10.0"

root@2ec511776ff1:/usr/src/app# echo $DISPLAY
localhost:10.0

root@2ec511776ff1:/usr/src/app# xhost +
xhost: unable to open display "localhost:10.0"

root@2ec511776ff1:/usr/src/app# xhost +local:
xhost: unable to open display "localhost:10.0"

from yolov5.

Hey there! 😊 It looks like you're encountering a classic display issue when trying to use X11 forwarding with Docker, running GUI apps in containers, especially through an SSH connection (like with Putty), can be tricky due to how X11 forwarding is handled.

A couple of things to try/check:

• Ensure your SSH Client has X11 Forwarding enabled. In Putty, this is under Connection -> SSH -> X11 -> Enable X11 forwarding. You'll need an X server on your local machine, such as Xming or VcXsrv, running to handle the display.

• Instead of directly specifying localhost:10.0 for the DISPLAY environment variable, you could try using the IP of your host machine within your local network (not localhost or 127.0.0.1), as the container needs to communicate with the X Server outside its own network namespace.

• On the host machine (where you're running Docker), make sure to allow connections to your X server from the Docker container. Running xhost +local: before starting your container should allow connections from local users. However, remember this lowers security and revert it (xhost -local:) once done.

• When using SSH and X11 forwarding, sometimes the DISPLAY variable might not be set as expected within your Docker container. You could echo $DISPLAY on the host (after establishing the SSH connection with X11 forwarding enabled) and then manually set it using the same value within the Docker run command if it's different.

In terms of SSH clients, if Putty isn't working as expected with X11 forwarding, you might try another client that supports X11 forwarding more seamlessly in your setup or check the configuration again to ensure everything is correctly set.

Let's keep the exploration going, and don't hesitate to share any updates on your progress!

from yolov5.

hello @glenn-jocher

The same phenomenon occurs even if you set "Enable X11 forwarding" in Putty and open it as instructed.
/usr/bin/xauth: .Xauthority does not exist
=> vi /etc/ssh/sshd_config
If X11Forwarding is set to no, change it to yes

systemctl restart sshd
xhost +local:
non-network local connections being added to access control list

As displayed, the symptoms are the same.

[root@localhost ~]# xhost
access control disabled, clients can connect from any host
INET:_gateway
INET:192.168.0.31
LOCAL:

I also added the xhost + inet:192.168.0.1 command gate and the server IP accessing Windows, but it is the same.

My head hurts so much. Was xhost the reason why my head hurt so much?

from yolov5.

Hey there! 😊 It seems like you've been through quite the ordeal with X11 forwarding. Configuring X11 through SSH, especially with Putty, can indeed be a bit of a headache.

Given everything you've tried, here's a quick suggestion: Ensure that the DISPLAY variable is correctly set in your SSH session. After enabling X11 forwarding in Putty, once you're connected to the server, check the value of DISPLAY by typing:

echo $DISPLAY

This should return something like localhost:10.0. Then, when you run your Docker container, make sure to pass this exact value with the -e DISPLAY= parameter:

docker run -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=$DISPLAY your_image_name

If DISPLAY isn't set or doesn't reflect an expected value (localhost:N.0), there might be a misconfiguration in your SSH or X11 setup.

Also, /usr/bin/xauth: .Xauthority does not exist might indicate an issue with permissions or the setup of X11 forwarding. Ensure xauth is correctly installed, and you have permissions to create/access the .Xauthority file in your home directory.

If you're still stuck, perhaps revisiting the configuration of your X server (like Xming or VcXsrv on Windows) and ensuring it's set to allow connections from the network might help.

X11 and SSH can be a bit tricky 🤯, but you're on the right track. Take a deep breath, and let's tackle this one step at a time!

from yolov5.

hello @glenn-jocher

thanks. The first solution that made my headache go away was echo $DISPLAY.

When running Putty, I tried to use "localhost:10.0" and the screen did not appear properly.
Just in case, when I integrated it in the server monitor, echo$DISPLAY was displayed as ":1" and the problem was solved. Thank you for the hints and advice.

But this time, the error in jupyter notebook. Can you give me an answer?

import cv2
img = cv2.imread('/Download/123.jpg')
cv2.imshow('title',img)

When entering "cv2.imshow", a kernel error occurs as shown below.

Kernel Restarting
The Kernel for Untitled.ipynb appears to have died. it will restart automatically.

It is the same even if you change "NotebookApp.max_buffer_size" in jupyter-notebook.

#> cd /root/.jupyter
#> jupyter notebook --generate-config
Writing default config to: /root/.jupyter/jupyter_notebook_config.py

#> vim jupyter_notebook_config.py

c.NotebookApp.max_buffer_size = 536870912
=> c.NotebookApp.max_buffer_size = 100000000000000000000

I was wondering if it was a memory problem, so I ran "free -mh" and there was 10GB free, so it didn't seem to be a problem. Could you tell me which part I need to check more?

from yolov5.

Hey there! 😊 Great to hear that figuring out the $DISPLAY issue helped clear up some of the confusion.

Regarding the problem you're encountering with cv2.imshow within Jupyter Notebook, it's important to note that cv2.imshow relies on a GUI (graphical user interface) to display images, which Jupyter Notebook, especially when run over a remote connection or within a browser, might not support directly.

A common workaround is to use Jupyter Notebook's capabilities to display images directly in the notebook interface. Here's how you can do it:

from IPython.display import display, Image
import cv2

# Read the image using OpenCV
img = cv2.imread('/Download/123.jpg')

# Convert the image to RGB (OpenCV uses BGR by default)
img_rgb = cv2.cvtColor(img, cv2.COLOR_BGR2RGB)

# Save the image to a buffer
cv2.imwrite('temp_img.jpg', img_rgb)

# Display the image
display(Image(filename='temp_img.jpg'))

This approach avoids the need for cv2.imshow, which might be causing the kernel to crash, and instead uses IPython's built-in display mechanisms.

Hope this helps, and keeps the headaches at bay! Let me know if there's anything else.

from yolov5.

hello @glenn-jocher

thanks. Thank you for always replying. Thank you for your help.

As I said, there is a way to the buffer and look at it, but it was possible to check it in another way.
The information I sent was confirmed, and I confirmed that there was a new method as well.
Thanks for solving it.

• How to use Save the image to a buffer
  cv2.imwrite('temp_img.jpg', img_rgb)

• Share newly confirmed information. I hope we can refer to it together.

import cv2
import matplotlib.pyplot as plt
bgr_img = cv2.imread('/Download/123.jpg')
rgb_img = cv2.cvtColor(bgr_img, cv2.COLOR_BGR2RGB)
plt.imshow(rgb_img)

Let me know the kick points and share what I learned. This is how I first used it with success. I'm trying to get rid of the headache.

thanks.

from yolov5.

Hello @rurusungoa,

I'm thrilled to hear that you've found a solution that works for you and appreciate you sharing your findings with the community! 🎉 Your method using Matplotlib is indeed another great way to display images within Jupyter Notebooks or similar environments without relying on cv2.imshow, which requires a GUI.

The switch from BGR to RGB before displaying the image is crucial when working with OpenCV in conjunction with Matplotlib, as OpenCV uses BGR by default, while Matplotlib expects RGB. Your concise example perfectly illustrates this important step.

Here's a compact way to integrate your approach into a single function for future use:

import cv2
import matplotlib.pyplot as plt

def display_image(path):
    bgr_img = cv2.imread(path)
    rgb_img = cv2.cvtColor(bgr_img, cv2.COLOR_BGR2RGB)
    plt.imshow(rgb_img)
    plt.show()

display_image('/Download/123.jpg')

This handy function display_image simplifies the process, making it reusable for multiple images.

Thanks for sharing your learnings! It's always great to see community members helping each other out. 🙌 If there's anything more you're curious about or need assistance with, feel free to ask!

from yolov5.