(info) Choosing the jpeg_quality setting

[jameszah]

Here is a bit of info about choosing the jpeg_quality settings.

You have to choose twice. The first choice is before you run the esp_camera_init call. That call will look at jpeg_quality and allocate buffers for your photos.

And then before you take the picture, you can specify a different jpeg_quality with the call

sensor_t * ss = esp_camera_sensor_get();
ss->set_quality(ss, quality);

The ranges are jpeg_quality for the buffer allocation are as follows

1. jpeg_quality 0 ..5 -- 960,000 bytes uxga, 240,000 bytes svga
2. jpeg_quality 6..10 -- 384,000 bytes uxga, 96,000 bytes svga
3. jpeg_quality 11+ -- 240,000 bytes uxga, 60,000 bytes svga

esp32-camera/driver/camera.c

Line 1178 in b02992a

int compression_ratio_bound = 1;

This is the maximum size a picture can be, and sometimes the jpeg algorithm cannot squeeze your picture into the available space, so you get a partial picture, which might just show as a flicker on a live stream, but caused problems when saving an avi movie. I discussed it here: #162

The problem I was having was that I would do the esp_camera_init in that middle range, but when recording a jpeg_quality 10 or 12, I would always get some jpegs that were larger than the 384,000 limit. On an bright outdoor scene, at quality 10, with lots of complicated colors and shapes, the jpegs would average 393,000 and peak at 419,000, and my solution was to locate and discard that frame and get another one, but I was discarding most of the frames. (I think I mentioned elsewhere here that pictures of the sky were a problem, but it is actually the sky is easy as the jpeg can just draw some big blue squares and fit in all in, but bright complicated images are the problem.)

So the new solution is to do the esp_camera_init in the first range of 0..5, so it shoots up to 960,000 bytes and I have never got close to that with the standard ov2640 camera.

But this creates a new problem that you have to lower the fb_count number because the frames are so much larger. I think the standard examples start at 8, but with the massize 960,000 frames, you can only have fb_count at 3. (or maybe 4 if you do not use the ps-ram for anything else).

That means you can only have 3 pictures taken, or in progress of being taken, at a time. I used this 7-8 queue of jpegs at times in my original avi recorder, but have switched to a better system with one picture coming off the camera, and one picture moving to the SD card. The third buffer is sometimes used for streaming pictures to the internet, without interfering with the previous two buffers.

So that is my current knowledge, if anyone can make use of it. Correct me if I am wrong. 😄

[jameszah]

One more thing: here is a picture of jpeg sizes when using different quality settings. This graph mixes jpeg size, with different SD cards, so it is not a perfect representation, but the point is the jpeg sizes are very large, and declining rapidly as you increase from 5->12, but then flatten out quite a bit. So you pay the price in data to get that last bit of sharpness by lowering to 8 and 7 and 6.

The differing frame sizes for the V10 and V30 chips just shows that the V10 chip cannot keep up with all the data being written, so the recorder drops below the camera speed of 6.25 uxga frames per second. And this is indoors with much smaller jpeg sizes at 250,000 than the bright outdoor pictures at 400,000.