Perhaps it's just me, but it seems like since the SkyWeather unit has a sunlight sensor that it could be read prior to taking a picture and the resulting value used as a guide to the camera adjustments for any given time of the day.
Not something that I have the time to try coding up at present, but just thought I would toss it out as a concept.
Post by mikemcdonald on Aug 30, 2019 3:23:18 GMT -8
Checking around for help with this issue, I found oter products with the same issue. In at least a few of them, the problem was ascribed to simply creating the camera and taking the picture (as happens in SkyCamera.py) without allowing time for the camera to "warm up". This means, supposedly, that time is not allowed for the camera to properly adjust auto-exposure and auto-white balance.
I noticed in the SkyCamera code that it looks a lot like sample code from the picamera.py docs, shown below:
camera = PiCamera()
camera.resolution = (1024, 768)
# Camera warm-up time
But SkyCamera.py lacks the delay
camera = picamera.PiCamera()
camera.exposure_mode = "auto"
camera.rotation = 180
#camera.rotation = 270
camera.resolution = (1920, 1080)
# Camera warm-up time
So I added the 2 second warm-up time back and will see how that works. Should have a useful result later this morning.
Post by mikemcdonald on Aug 30, 2019 3:30:43 GMT -8
This quote, found on a raspberrypi.org forum, should provide some insight:
System will first try and connect to the camera, which needs to respond. This requires the camera to be powered up which takes a while. Now that system knows camera is present it preps the ISP, then starts the camera streaming. Total about 200ms to this point IIRC. First frames need to be discarded, so assuming we get the second, at 30fps, that another 66ms. So we now have the first frame back from the camera. Now we can start doing the calculation for AWB and the like. This takes 2 frames at least, not sure what the max will be, lets assume it takes 6, so that's another 200ms.
So that's about 460ms total, assuming everything works perfectly. However, measurements show it actually takes just over a second to get up and running, due to all the communications and processing overhead
Post by mikemcdonald on Aug 30, 2019 3:56:10 GMT -8
Sorry for the rapid-fire posts, but this result was super fast. Adding the 2 second delay definitely fixed the over-exposure problem. Seems this is just how the camera works. The first several frames are used to calculate AWB and other auto-stuff, so they need to be discarded. Below is the code I am using and it's taking one properly exposed photo after another.
Added the delay line to the SkyCamera.py file on my unit as well, and while I'll probably wait for a bit before a final decision, the half dozen of so pix I have viewed so far appear to be properly exposed.
Post by jaybird116 on Feb 16, 2020 17:36:31 GMT -8
How does one use the existing I/R cut filer in this camera? I looked in the SkyCamera.py and looked through the link posted at the beginning of this thread but saw no option for it and am guessing its not that easy. I have one of my demo cameras with I/R that covers the same area as the weather station and figured I could get some night shots.