Tricky problem with signal loss (convert image)

C++
1

Hello everyone,

I’m fairly new to opencv but I have a problem that I have been trying to solve for many weeks and finally found a “solution”

The problem I had is that sometimes the screen loses signal and flashes. after a long test period of replacement of contacts, slip rings and more, control of signal and everything is perfect, this happens more frequent at “brighter” places, for example when you point the camera directly at a strong light source.

To keep it short, the problem fully disappears if you convert the image to COLOR_BGR2XYZ before pass it into imshow call.

What exactly does convert with (COLOR_BGR2XYZ) flag do to the image so that the problem disappears and screen do not lose signal?

Can it have something to do with image quality, resizing? depth? channels? do you have any idea?

I hope for help here with this incredibly wierd problem.

OpenCV version 3.4

Some quick info on hardware:

  • Jetson TX2 with HDMI output
  • NA1012B-ET | HDMI to 3G/HD-SDI Converter
  • Lilliput FA1014/S - 10.1" SDI Field monitor

addional links:

NA1012B-ET Converter:
http://aivion.de/en/na1012b-et-hdmi-to-3ghd-sdi-converter/

Lilliput FA1014/S:
https://lilliputdirect.com/3g-sdi-lilliput-monitors/10-inch-3g-sdi-lilliput-monitors/lilliput-fa1014s-10-inch-sdi-field-monitor

Best Regards
/rndbit

2

it’s unclear, why you want to convert to yuv at all, mind explaining ?

also, please show actual code.

3

Hello,

I do not want to convert the image, but if I do, the problem of signal loss disappears, which I wonder why.

I ment convert to COLOR_BGR2XYZ, my mistake.

So if I add cv::cvtColor(main_frame, main_frame, cv::COLOR_BGR2XYZ); before imshow this issue will be gone and I do not understand why.

Testing code is nothing special at all, captures an image from the camera and displays it.

int main(int argc, char *argv[])
{
	cvNamedWindow("window", CV_WINDOW_NORMAL);
	cvSetWindowProperty("window", CV_WND_PROP_FULLSCREEN, CV_WINDOW_FULLSCREEN);

	VideoSources sources;
	sources.startup();

	cv::Mat main_frame;

	double fps = 60.0;
	std::chrono::time_point<std::chrono::system_clock> startTime = std::chrono::system_clock::now();

	while(true)
	{
		if (!sources.capture(main_frame))
		{
			continue;
		}

		//cv::cvtColor(main_frame, main_frame, cv::COLOR_BGR2XYZ);
		//adding line abow will remove the issue

		cv::imshow("window", main_frame);
		cv::waitKey(1);

		if (fps > 0.0)
		{
			int32_t processingTime = (int32_t)std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::system_clock::now() - startTime).count();
			int32_t waitTime = (int32_t)(1000.0 / fps) - processingTime;
			if (waitTime > 0)
			{
				std::this_thread::sleep_for(std::chrono::milliseconds(waitTime));
			}
		}
		startTime = std::chrono::system_clock::now();
	}
	return 0;
}
4

cvtColor shouldn’t have any electrical effect on your display.

is that “window” a full screen window or something?

I would guess that the color conversion somehow results in reduced/different value ranges, which result in different signal amplitudes… somewhere deep in the display itself, because everything before that is digital.

the display probably drops out because it tries to emit a lot of photons and that strains the power supply, which drops the supply voltage in response, which kills the monitor.

or maybe some digital conversion is tweaked by whatever values flow into/out of it…

instead of the cvtcolor, try simply multiplying the picture by 0.5, which also reduces the value range.

you need to debug this some more. replace every part. the display and/or the signal converter may be defective.

colors = np.uint8([[[0,0,0], [0,0,255], [0,255,0], [255,0,0], [255,255,0], [255,0,255], [0,255,255], [255,255,255]]])
>>> cv.cvtColor(colors, cv.COLOR_BGR2YUV)
array([[[  0, 128, 128],
        [ 76,  91, 255],
        [150,  54,   0],
        [ 29, 239, 103],
        [179, 165,   0],
        [105, 202, 255],
        [226,  17, 153],
        [255, 128, 128]]], dtype=uint8)
>>> cv.cvtColor(colors, cv.COLOR_BGR2HLS)
array([[[  0,   0,   0],
        [  0, 128, 255],
        [ 60, 128, 255],
        [120, 128, 255],
        [ 90, 128, 255],
        [150, 128, 255],
        [ 30, 128, 255],
        [  0, 255,   0]]], dtype=uint8)
>>> cv.cvtColor(colors, cv.COLOR_BGR2XYZ)
array([[[  0,   0,   0],
        [105,  54,   5],
        [ 91, 182,  30],
        [ 46,  18, 242],
        [137, 201, 255],
        [151,  73, 247],
        [196, 237,  35],
        [242, 255, 255]]], dtype=uint8)
5

Hello,

Thank you for your response and thoughts.

Some answers to your questions / thoughts:

  • I agree that it has no electrical effect on display
  • Yes it is full screen display

cvNamedWindow(“window”, CV_WINDOW_NORMAL);
cvSetWindowProperty(“window”, CV_WND_PROP_FULLSCREEN, CV_WINDOW_FULLSCREEN);

  • I have driven with their powersupply that comes with the screen and tried to change the screen but the same result. So drop of voltage sounds unlikely, they should have a supply rated to their screen requirements.

Have tried debugging but without results, and have replaced all components twice.

I will try your suggestion by multiplying the picture by 0.5 and see results.

It is very strange, could it be that the conversion changes size, depth or image type that the screen handles better? I do not know, just throws out some ideas :confused:

6

update:

multiplying the picture by 0.5 seems to solve the issue same as the convert XYZ.

Still this issue does not make sense for me still.

7

you can probably use any program or method to display a picture with lots of perfect white, and that should have the same effect. a fullscreen browser showing a blank white tab maybe?

if that doesn’t cause it, that would be curious.

8

Hello,

Yes, if I load an image that is white, the same thing happens when you start the program, the screen starts to lose signal. I do not understand why a normal image causes the screen to lose signal. I have also tried a stronger power source instead of their original and the same result.

9

return to manufacturer

10

I already asked and they did not know anything regarding issue.

So I guess I will lower the pixels for now, was just interesting to know what causing this wierd issue.

11

maybe they just don’t want to deal with the problem. send them a video showing what you do.

12

They were helpful but they do not know at all what it could be :confused:

13

they need to escalate that to the electrical engineer who made the thing… someone who has an oscilloscope and knows how to use it :wink:

if they can’t do that, maybe they just resell this stuff, and it was constructed/designed elsewhere.