I find that when I focus the camera on a target with a lot of detail such as a screen displaying a lens test chart, the live view in the IDE will return a black white pattern of squares.
I think this only happens when the sensor is in JPEG mode at a high quality setting (>80) with sensor.set_quality, and I am wondering whether it is related to the fact that images with high JPEG quality are often incompletely saved such as in this example (the image was even in black-and-white, even though the pixformat was set to JPEG, using 4.1.1 firmware):
or this example with an image saved while the board was not connected to the IDE (with a previous firmware, maybe 3.9 or 4.0, notice the gray bar at the bottom):
So: given that the advice in the documentation for people using the high resolution modes is to use the JPEG pixel format, and given that a high JPEG quality is desirable, how do we get to see and save a stable image feed from the sensor at these high-res, high-quality JPEG settings?
Hi, can you not use the JPEG format on the camera? But, just use RGB565? Using the JPEG format on the camera uses the OV5640’s JPEG compressor. We don’t have much documentation on that. When you set it to RGB565 we use the JPEG compressor on the H7. This of course takes more CPU but will likely work.
The JPEG compressor on the OV5640 can crash if the readout clock speed and fifo depths configured via register settings on the chip aren’t quite right. I.e. if you have the camera running as fast as possible and the image is complex causing the JPEG compressor to slow down then the camera will generate corrupt frames. It’s possible to fix this by increasing the horizontal and vertical timing registers on the OV5640 via direct register writes. If you need to use sensor.JPEG mode I can provide information on how to write to these registers. But, I’d avoid that mode if you don’t have to.
Thanks @kwagyeman , problem solved.
I did not try RGB565 because I was trying to see whether JPEG quality setting influences the stability.
Still, it would be useful to mention this important caveat in the sensor.pixformat documentation.
Also useful to mention: does sensor.set_quality only apply when the pixformat is in JPEG mode? Does it influence the IDE image preview quality? Or do you recommend setting the quality only when saving the image?
Yes, sensor.set_quality() only affects JPEG mode. In general the timing settings should not be so tight as to cause the jpeg compressor to crash. That’s a bug… can you make a github issue ticket with pictures of what type of scene cause this to happen?
The IDE preview quality is dynamic. But, you can force it to a certain level by calling .compress(quality=90) and pre-compressing an image. It either transfers a JPEG image or compresses the non-jpeg image at a variable quality.
Thanks! I’ll try to modify the readout speed settings to make sure this doesn’t happen. I’m kinda shooting in the dark though on what to do as there is no detail on how this works.
It looks like on firmware 4.3.1, saving JPEGs from quality 90 to 100 is safe now. I tried all values in increments of 2 and all JPEGs were entirely saved. I just haven’t saved the unstable image transfer to the IDE. Anyway, thanks openMV!
