- RGB565 capture, stream via BMP (lossless)
- Foto Quality
- Full Resolution
- Low Framerate
To do HTTP-streaming or capture we have 3 choices:
- capture YUV422, convert it to JPG by software, then stream it to the browser. (low network payload)
- capture RGB565, convert it to JPG by software, then stream it to the browser. (low network payload)
- capture RGB565, put a BMP-header in front, then stream it to the browser (high network payload, but no conversion)
Framerate is between 1 and 10, depending on size.
There are 2 new controls.
- streamMode (JPG/BMP) = JPG streams as jpg and does software conversion. BMP streams direct as BMP (only if RGB565 is selected)
- PixFormat (rgb565/yuv) = This selects the cameras pixelformat that it delivers. RGB565 or YUV422. (YUV422 seems better contrast in jpg)
RGB565 = R(5/32), G(6/64), B(5/32) Bits/Values per Color. Colordepth is 16Bit = 326432=65536 different colors This low resolution per color results in lines/areas shown on high color-diff borders. Dithering should be applied to smoothen the image. Because Green has 6-Bits, a greenish tint might be visible.
By encoding an image to JPEG dithering is somehow implied in the jpeg algorithm, so jpeg looks nicer. For text-images jpeg is bad and RGB565 is the prefered.
YCrCb as YUV422 = YUYV422, is a downsample strategy. 4 Pixels share 2 Cr and 2 Cb values. (Cb,Cr are colordifference values) 422 is historical, actually its 211, as 2 Pixels share 1Cb and 1Cr value. Pixeldata is stored as YUYV: Y0Cr0Y1Cb0 , so we have reduced the croma info by 2, resulting in 2Bytes per Pixel. (as in RGB565) So 2 different 8Bit luminanzvalues(Y0,Y1) share the same color? No, because Y also carrys a "gammacorrection" part in it.
JPEG uses YCrCb.
IDF-V3.3.1 c code. git clone -b v3.3.1 --recursive https://github.com/espressif/esp-idf.git
adapted from: https://github.com/xenpac/ESP32-CAM-Linux-Motion
Have fun ;) xenpac