Multi-threading: I previously used an uasyncio webcam server. This time around, I am testing a multi-thread webcam server. The result is promising. A multi-thread server seems to give a better throughput.
The program logic is simpler when compared to the server based on uasyncio. The server is a four threaded application, two for port 80, one for port 81, and port 82 runs on the main thread, which blocks the REPL. You can start a dedicated thread for port 82 if you do not want to block the REPL.
I found pix/7 gives the best performance. A spe/2 will reduce the image size but give you a grayscale image. Please see my previous blog if all these seem mysterious to you.
I have compiled a new firmware, MicroPython v1.11-571-g7e374d231. You can download the new firmware from my repository at GitHub. The soft reset is not functioning properly. You need to do a hard reset.
I also include four new functions in modcamera.c:
The pixformat changes the sensor format. The default format is JPEG, a compressed image. The other 2 are raw formats, which are not useful for webcam purposes.
The agcgain is gain control.
The aelevels and aecvalue are for auto-exposure control. They seem to produce lighter/darker images.
The multi-threading webcam server mth_webcam.py controls the valid value range for these functions:
Are these functions useful? Ido not know. You are free to experiment. For sure, the raw images need post-procesv1.11-571-g7e374d231sing to be useful.
While I am at it, I have also compiled MicroPython v1.11-571-g7e374d231 for esp32, esp8266, Unix and Windows. All firmware ports are of a slim version. That is to say, no webrepl, upip and help modules compiled into them.
You find all these and more in my respective GitHub repositories.
The program logic is simpler when compared to the server based on uasyncio. The server is a four threaded application, two for port 80, one for port 81, and port 82 runs on the main thread, which blocks the REPL. You can start a dedicated thread for port 82 if you do not want to block the REPL.
I found pix/7 gives the best performance. A spe/2 will reduce the image size but give you a grayscale image. Please see my previous blog if all these seem mysterious to you.
I have compiled a new firmware, MicroPython v1.11-571-g7e374d231. You can download the new firmware from my repository at GitHub. The soft reset is not functioning properly. You need to do a hard reset.
I also include four new functions in modcamera.c:
- pixformat
- agcgain
- aelevels
- aecvalue
The pixformat changes the sensor format. The default format is JPEG, a compressed image. The other 2 are raw formats, which are not useful for webcam purposes.
The agcgain is gain control.
The aelevels and aecvalue are for auto-exposure control. They seem to produce lighter/darker images.
The multi-threading webcam server mth_webcam.py controls the valid value range for these functions:
- fmt (0:JPEG, 1:YUV422, 2:RGB) - pixformat
- agc (0 to 30) - agcgain
- ael (-2 t0 +2) - aelavels
- aev (0 to 1200) - aecvalue
Are these functions useful? Ido not know. You are free to experiment. For sure, the raw images need post-procesv1.11-571-g7e374d231sing to be useful.
While I am at it, I have also compiled MicroPython v1.11-571-g7e374d231 for esp32, esp8266, Unix and Windows. All firmware ports are of a slim version. That is to say, no webrepl, upip and help modules compiled into them.
You find all these and more in my respective GitHub repositories.
Love your work! I'm using your firmware for a project here : https://github.com/KipCrossing/Micro-Camera
ReplyDeleteI'll add the new functions too.
Is there any reason that you've decided to leave out modules such as help?
Kip
I just want to save space. I will have a look at your project. Thanks for finding the logical mistakes in the range tests.
DeleteSharil
Ouch! I have made stupid logical mistakes in webcam.py and mth_webcam.py scripts Thanks to Kip for telling. I have made changes in GitHub. Thanks again Kip!
ReplyDeleteSharil