SOLVED RPI Camera IMX327 different brightness values between startups
-
Hi,
I use the IMX327 camera with python and RPI to in controlled lighting settings where LEDs are used to for different colored lighting.
I am trying to find the reason, why the brightness between different images stays constant, within the same boot cycle (once I have switched on, the images are same) but not, when I switch the RPI on and off again and on again.
This is the code I use:
from time import sleep import time import datetime import RPi.GPIO as GPIO ### Camera Init import D_mipicamera as Dcam camera = Dcam.mipi_camera() camera.init_camera() status = os.system('sh ./veye_mipi_i2c.sh -w -f cameramode -p1 0x0 -b 10') #print status status = os.system('sh ./veye_mipi_i2c.sh -w -f daynightmode -p1 0xFF -p1 0x00 -b 10') #print status ##turn off automatic exposure status = os.system('sh ./veye_mipi_i2c.sh -w -f agc -p1 0 -b 10') #print status status = os.system('sh ./veye_mipi_i2c.sh -w -f wbmode -p1 0x1b -b 10') # print status status = os.system('sh ./veye_mipi_i2c.sh -w -f mwbgain -p1 0x74 -p2 0x74 -b 10') status = os.system('sh ./veye_mipi_i2c.sh -w -f lowlight -p1 0x01 -b 10') #print status status = os.system('sh ./veye_mipi_i2c.sh -w -f mshutter -p1 0x41 -b 10') #print status time.sleep(0.25) date = datetime.datetime.now().strftime("%m_%d_%Y_%H_%M_%S") frame = camera.capture(encoding = 'jpeg') camera.release_buffer(frame) del frame time.sleep(0.25) frame = camera.capture(encoding = 'jpeg') frame.as_array.tofile(dest+"control"+ date + ".jpg") camera.release_buffer(frame)
-
@what I forgot to say: Sometimes, the images are also the same between the boot cycles. For example the last test: 1. boot image is "normal", all are the same,
2. boot cylcle: images are brighter than in 1. cycle but all the same within the 2. boot cycle,
3. boot cycle: all are same as first boot cycle and all are same -
@seka
My understanding of your question:
You use manual exposure time and manual gain. You expect pictures with different brightness under different LED lights, but now the brightness of the image is the same. Isn't that right?
Is it just that the brightness of the picture is different, or is it possible to get a duplicate picture?
Can I use veye_raspistill to shoot?
In addition, can you upload the pictures you took? -
@veye_xumm Hello Xu,
I expect exact same images, but I get different ones. Images stay same within same boot cycle but change after booting. I will send you images later.
Can you please provide example code for raspistill where image settings are not automatic, all manual, everything controlled --> no changes between images?
-
@seka regarding example code: I still run the i2c commands and just raspistill, and that is all i guess... how much sleep between i2c commands do you recommend between commands and before taking image?
-
@seka
I see your question.
There is no need to test with raspistill, the result should be the same as your python test.
I have some test suggestions that you can try.- Do not enable low_light mode.
- Increase the speed of ae adjustment at the beginning of your scripts.
. / veye_mipi_i2c.sh-w-f aespeed-p1 0x64-p2 0x64
It's just for the purpose of pure testing.
-
@veye_xumm I just checked and another problem I have: I get no return value from the whitebalance mode and I cannot read its state also....
-
@seka Sorry, realised I had this error before: Problem: not current veye_mipi_i2c.sh ... solved now
-
@seka with regarding to your suggestion " do not enable low_light mode": When I disable it, images are very dark.... and I already have longest shutter settings....
-
@seka another problem that now occurs (and which has occured seldomly before): images are corrupted:
-
@seka ok, I understand now what the problem is: os.system does not reliably execute shell commands. When executing directly in the terminal ---> problem is gone. Thank you
-
@seka
Hi,
All problems sloved? -
@veye_xumm No, but I am currently assessing wether it is a light source problem or camera problem. Will get back soon..
-
@seka Seems to be fixed right now
-
@seka OK~