I have a strange problem with ZMQ dequeuing. An image processing run is processing the images correctly and then sending them to the display image run. The test I am running has over 2000 images from four different cameras, with the images displayed on four different screens. The images are all processed without any problems for all four cameras, but the display of the images from the second camera are never displayed, and in fact are never dequeued by the display image run. Switching screens for the second camera does not help. These displays are done in order of camera sending, and the images for the first, third and fourth cameras are being displayed on the first, third and fourth screens without any problems. That tells me that there is not a resource issue to cause the failure to dequeue for the second camera, since these images are all about the same amount of memory. The code that sends the processed images to the display image run, which was declared with a ZMQ_PUB declaration, is:
unsigned long sent = zmq_send(xmitter, ki, image_size, ZMQ_DONTWAIT); if (sent < 0) { log_error(THREAD_NAME " image write error (%d:%s)", errno, strerror(errno)); } else { if (sent != image_size) log_error(THREAD_NAME " sent image of wrong size to display image run"); log_debug(THREAD_NAME " published image %d, size of %ld", frame_number, sent); }The code receiving the image in display image run, which was declared with a ZMQ_SUB declaration, is:
// Forever do while (!exiting) {KEYED_IMAGE *keyed = malloc(sizeof(KEYED_IMAGE));// Verify image buffer was allocatedif (keyed == NULL) log_fatal("Unable to allocate image buffer");float *display_buffer = malloc(MAX_COMPONENTS * sizeof(float));// Verify display buffer was allocatedif (display_buffer == NULL) log_fatal("Unable to allocate display buffer");// Wait for OpenGL events// display_check_for_events();// Read next image from the queueif (zmq_recv(zmq_receiver, keyed, sizeof(KEYED_IMAGE), 0) < 0) { log_error("Receive socket read error (%d:%s)", errno, strerror(errno));}else{ // Calculate image size int width = fmd_get_fs_x(keyed->image.meta);The log file from the image processing send, showing the last sends for camera 1 and the first sends for camera 2, is:
^[[96;49m2023-216-17:28:21.433 [52] VISI-D:process-image thread pipeline sending image 14379^[[0m^[[96;49m2023-216-17:28:21.436 [52] VISI-D:process-image thread pipeline sent processed image 14379, size of 15925392^[[0m ^[[96;49m2023-216-17:28:21.441 [50] VISI-D:display-image thread received image 14379^[[0m ^[[96;49m2023-216-17:28:21.441 [50] VISI-D:Image key = 0005^[[0m ^[[96;49m2023-216-17:28:21.441 [50] VISI-D:>Gate test 14379^[[0m ^[[96;49m2023-216-17:28:21.441 [50] VISI-D:Gate passing frame 14379^[[0m ^[[96;49m2023-216-17:28:21.444 [50] VISI-D:display-image thread published image 14379, size of 15925396^[[0m ^[[96;49m2023-216-17:28:21.444 [50] VISI-D:display-image thread waiting for something to display...^[[0m ^[[96;49m2023-216-17:28:21.789 [52] VISI-D:process-image thread pipeline sending image 9802^[[0m ^[[96;49m2023-216-17:28:21.792 [52] VISI-D:process-image thread pipeline sent processed image 9802, size of 15925392^[[0m ^[[96;49m2023-216-17:28:21.798 [50] VISI-D:display-image thread received image 9802^[[0m ^[[96;49m2023-216-17:28:21.798 [50] VISI-D:Image key = 0008^[[0m ^[[96;49m2023-216-17:28:21.798 [50] VISI-D:>Gate test 9802^[[0m ^[[96;49m2023-216-17:28:21.798 [50] VISI-D:Gate passing frame 9802^[[0m^[[96;49m2023-216-17:28:21.801 [50] VISI-D:display-image thread published image 9802, size of 15925396^[[0m^[[96;49m2023-216-17:28:21.801 [50] VISI-D:display-image thread waiting for something to display...^[[0mImage 14379 is the last image for camera 1, and 9802 is the first image for camera 2. Note that image order is checked within a camera's image, the order can be different for a different camera.
The log for the receiving display image run, showing image 14379 and what happens next, is:^[[39;49m2023-216-17:28:16.641 [15] DPYI-I:Received image #14378 with ERT 1970-001-00:00:00.000^[[0m^[[96;49m2023-216-17:28:16.650 [15] DPYI-D:Scaling image, 1296x1024 -> 1366x1080^[[0m^[[39;49m2023-216-17:28:16.748 [15] DPYI-I:Displayed image #14378 from PTU-1 on Screen 0^[[0m^[[39;49m2023-216-17:28:21.454 [15] DPYI-I:Received image #14379 with ERT 1970-001-00:00:00.000^[[0m^[[96;49m2023-216-17:28:21.463 [15] DPYI-D:Scaling image, 1296x1024 -> 1366x1080^[[0m^[[39;49m2023-216-17:28:21.563 [15] DPYI-I:Displayed image #14379 from PTU-1 on Screen 0^[[0m^[[39;49m2023-216-17:30:25.519 [15] DPYI-I:Received image #13150 with ERT 1970-001-00:00:00.000^[[0m^[[96;49m2023-216-17:30:25.528 [15] DPYI-D:Scaling image, 1296x1024 -> 1366x1080^[[0m^[[39;49m2023-216-17:30:25.626 [15] DPYI-I:Displayed image #13150 from FSA-4 on Screen 2^[[0m^[[39;49m2023-216-17:30:25.950 [15] DPYI-I:Received image #13151 with ERT 1970-001-00:00:00.000^[[0m^[[96;49m2023-216-17:30:25.959 [15] DPYI-D:Scaling image, 1296x1024 -> 1366x1080^[[0m^[[39;49m2023-216-17:30:26.059 [15] DPYI-I:Displayed image #13151 from FSA-4 on Screen 2^[[0m
Image 13150 is from camera 3, and none of the camera 2 images were ever dequeued. You can see that the display image run sat idle for almost 4 minutes, even though the image processing run was sending camera images all of that time. Once again, since cameras 1,3, and 4 were being displayed without problems, I cannot believe that there was a resource issue to cause mute mode for camera 2 images.
I expected the images for all four cameras to be dequeued and displayed by the display image run. Since the images for three of the four cameras worked fine, I don't think there is a resource issue for camera 2. I changed the screens the images were displayed on to verify the screens are not the problem, and it is always camera 2 that does not display, no matter which screen is being used.