search

TheImagingSource / Linux-tiscamera-Programming-Samples

Programming samples in Python and C++ for the tiscamera GStreamer modules.
71 stars 35 forks source link

Null value on sample_getbuffer in TIS.py #38

Open Preburk opened 8 months ago

Preburk commented 8 months ago

Hello,

We are sporadically getting null values in the following code from TIS.py: ` sample = self.appsink.emit("try-pull-sample", timeout * Gst.SECOND) buf = sample.get_buffer() data = buf.extract_dup(0, buf.get_size()) if convert_to_mat and sample is not None: try: self.img_mat = self.__convert_to_numpy(data, sample.get_caps()) except RuntimeError:

unsuported format to convert to mat

            # ignored to keep compatibility to old sample code
            pass`

Error message: "TIS.py", line 170, in snap_image buf = sample.get_buffer() AttributeError: 'NoneType' object has no attribute 'get_buffer'

I´am guessing the timeout runs out and sample becomes null.

The issue seem to happen after we have used the script and then closed it down. A reboot of the computer seem to be the only way to solve the problem. We did not encounter this problem on ubuntu 16.04 but now with 20.04 it happens very often and stops our clients from using the cameras in their systems.

It usually happens after a few images have been taken. Any pointers of what could be wrong? Is there any granular logs produced that could point us in the right direction?

Cameras are DFK 33UX183 and DFK 33UX250.

Regards

TIS-Stefan commented 8 months ago

Hello You are right, the sample is null. But it seems, you use an older version of the TIS.py, because the line number 170 has different content in the code at https://github.com/TheImagingSource/Linux-tiscamera-Programming-Samples/blob/master/python/python-common/TIS.py. If I am right, could you please use the version from the link above?

Stefan

Preburk commented 8 months ago

Hello, yes we have removed some redundant code from the class, it is still the same version of the code. You can see the line at 183 in the one you referenced.

Preburk commented 8 months ago

This is what we get from dmesg when starting the pipeline if this can help with the troubleshooting:

`

`

TIS-Stefan commented 8 months ago

Hello If the same scripts runs on the old, but not on the new OS, then the error could be in the OS. However, I never had such issues in Ubuntu 18.04, 20.04 and 22.04 with tiscamera 1.0 / 1.1. Lets start from bottom. Can you please run and install "qv4l2"? If this works, can you please run gst-launch-1.0 v4l2src ! videoconvert ! ximagesink If this works, can you please run tcam-capture?

Please let me know your results.

Stefan

Preburk commented 5 months ago

Hi, The issue was that the software trigger signal wasnt picked up by the driver or camera. Now we try to send a new signal if we encounter this error and it usually works the second time.

TIS-Stefan commented 5 months ago

Hi

I am not sure, whether I understand correctly: The software trigger signal is not picked up at all, or sometimes only?

Trigger signals are ignored, if the camera is busy. Which means, you may send them to fast.

Preburk commented 5 months ago

They are sometimes ignored, which led to the first issue. So i guess the camera is busy sometimes.

Now it usually works the second time we retry after 1s if we encounter the error, it is fine for our current purpose but might not be if time of capture is critical.

Only issue we encounter now is that we have to disconnect/connect the USB after a restart of the program since it fails to snap images, it is like the driver or gstreamer gets stuck in a bad state.

TIS-Stefan commented 5 months ago

Hi The camera is busy, while it exposes and deliver the images. Thus, if you have 1/100s exposure time and 30 fps, then you have 1/100 + 1/30 = 0.04 seconds, in which the camera is busy. That means, you can send a software trigger in 1/25 seconds interval.

For the Gstreamer state, maybe you can create a very small reproducible project, which contains the camera code only. From this you may see, what causes the issues.

Preburk commented 5 months ago

Hi The camera is busy, while it exposes and deliver the images. Thus, if you have 1/100s exposure time and 30 fps, then you have 1/100 + 1/30 = 0.04 seconds, in which the camera is busy. That means, you can send a software trigger in 1/25 seconds interval.

For the Gstreamer state, maybe you can create a very small reproducible project, which contains the camera code only. From this you may see, what causes the issues.

We are getting the following error: "gi.repository.GLib.Error: tcam-error-quark: Error: Device not opened (20)" Any idea why this would happen?

TIS-Stefan commented 5 months ago

Hello

This happens, because

in dmesg output you can see, whether a device disconnected, thus you may check this after the message is shown.

Stefan