Corrupted output image imx219

edul · October 7, 2021, 1:58pm

Where did you get the camera module(s)?
Other - www.botland.com.pl
Model number of the product(s)?
Buy Raspberry Pi NoIR Camera HD v2 8MPx - Botland - Robotic Shop
USB3.0 shield plus (B0317) UC-593 Rev C
What hardware/platform were you working on?
Linux x86
Instructions you have followed. (link/manual/etc.)
https://github.com/ArduCAM/ArduCAM_USB_Camera_Shield
Problems you were having?

When using camera in following way:

Initialize camera
Start capture (run threads)
Capture few frames
Stop capture (stop threads and execute ArduCam_flush)
Wait for until data is needed again, then go to step 2.

Sometimes first image after restarting capture(marked on picture as (2)) has corrupted data. See picture attached below

Corrupted image contains part of previous frame(marked as (1)). Using ArduCam_flush doesn’t really help to prevent that. Do you think images buffers are handled correctly after ArduCam_endCaptureImage?

Sometimes before that happen, ArduCam_captureImage returns USB_CAMERA_DATA_LEN_ERROR followed by multiple USB_CAMERA_FRAME_INDEX_ERROR.
Can you help me to understand reason those errors appear?
a) USB_CAMERA_DATA_LEN_ERROR (is that transfer error? what does it mean?)
b) USB_CAMERA_FRAME_INDEX_ERROR (it appears at leas once at each start, sometimes after USB_CAMERA_DATA_LEN_ERROR multiple times)

The dmesg log from your hardware?
None
Troubleshooting attempts you’ve made?
Power cycle, check camera buffers flushing methods and try to clean pending images manually.
What help do you need?
Solve a bug (imho in SDK or board FW) or find reasonable workaround

wong · October 9, 2021, 12:21am

Hi @edul,

There are indeed some design vulnerabilities in the SDK,
My suggestion is not to stop the capture thread. The capture thread is actually the thread that obtains data from the USB. If it does not process the USB data in time, it will cause problems with the data on the device.

edul · October 11, 2021, 5:46am

Hi @wong,

Thanks for answer, are you planning to address design vulnerabilities in the SDK in near future?

Going back to my 2nd question. Can you help me to understand reason those errors appear?
a) USB_CAMERA_DATA_LEN_ERROR (is that transfer error? what does it mean?)
b) USB_CAMERA_FRAME_INDEX_ERROR (it appears at leas once at each start, sometimes after USB_CAMERA_DATA_LEN_ERROR multiple times)

wong · October 11, 2021, 5:56am

Unfortunately, there is no clear plan, in fact it needs to be refactored as a whole.

Yes, this is a transmission error.
The data may be lost due to the failure to process the data output by the device in time.

This error means that the image frames are not continuous, and each image frame has a frame number. If it is not continuous, it will prompt this error, but you can ignore it.

wong · October 11, 2021, 6:01am

The current design exposes too many things to users, and it is not easy to handle these combinations correctly. You can refer to this simple wrap:

C++ Version:

github.com

glddiv/Arducam_Opencv_Demo/blob/linux/src/Arducam.cpp

#include "Arducam.hpp"

bool ArducamCamera::openCamera(std::string fname, int index) {
	return camera_initFromFile(fname, this->handle, this->cameraCfg, index);
}

void ArducamCamera::closeCamera() {
	if (this->_running)
		this->stop();
	if (this->handle != nullptr)
		ArduCam_close(this->handle);
	this->handle = nullptr;
}

void ArducamCamera::start() {
	if (this->_running)
		return;

	ArduCam_setMode(this->handle, CONTINUOUS_MODE);
	this->_running = true;

This file has been truncated. show original

Python Version:

github.com

glddiv/Arducam_Opencv_Demo/blob/linux/python/Arducam.py

import threading

import ArducamSDK
from utils import *


class ArducamCamera(object):
    def __init__(self):
        self.isOpened = False
        self.running_ = False
        self.signal_ = threading.Condition()
        pass

    def openCamera(self, fname, index=0):
        self.isOpened, self.handle, self.cameraCfg, self.color_mode = camera_initFromFile(
            fname, index)

        return self.isOpened

    def start(self):

This file has been truncated. show original

edul · October 11, 2021, 6:07am

Thanks for quick answer.

The current design exposes too many things to users, and it is not easy to handle these combinations correctly.

From my point of view more extensive documentation combined with some examples are usually enough to handle such SDK. On the other hand I understand it could be more user friendly.