-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HQ Camera does not start at full resolution. #46
Comments
Hi, thanks for reporting this. Could you please post:
Thanks. |
Occurs with an HDMI display and separate mouse and keyboard over a USB hub, as well as over SSH without the HDMI and USB connected. It is being powered from a 5V 3.4A Max power source over USB power.
Full Raspberry Pi OS 32Bit installed using Raspberry Pi Imager on March 18th 2022.
I don't believe so. This was a completely fresh install of the OS for the sole purpose of running Picamera2. Following the install instructions, enabling glamor, increasing the swap space to 2048 and gpu memory to 128. The same errors still occur if I revert back to 64. |
This was with preview_configuration at full res (which I believe has 3 or 4 buffers). If I run the original script over SSH with display and keyboard unplugged and with GPU set to 64 the script runs normally. |
The most obvious thing that I see in your /proc/meminfo is that you have very little free CMA. Here are some things to try:
Then have a look at your /proc/meminfo and let's see if the CMA is in better shape. |
I tried a new clean install of Raspberry Pi OS Lite 32Bit. It needs the following things to also be installed:
However I am getting the same
Here is the output of
|
After rebooting and running the script from the Lite OS command line using a mouse and keyboard, the script works. After rebooting and logging in through SSH and running the script, I get this error:
Logging out of SSH (without rebooting) and running the script using mouse and keyboard input works. Then logging in to SSH (still without rebooting) works. Rebooting, logging in through SSH, and then running the script using mouse and keyboard fails. Then logging out of SSH and trying the script again with mouse and keyboard works. Does it make sense for SSH to take up enough memory on the pi to make this big of a difference? Or could it be a permissions/access issue separate from the previous ones? |
Hi, so this is all sounding very strange. I don't see how an ssh process can affect the amount of CMA that you have. Does running Another couple of things to check:
|
It gets even stranger. After booting up the device seems to have about 160000 of cma free, then after running the camera script (or really running anything from command line) another 60000-80000 of cma becomes free. I don't think SSH is to blame, since I was able to run successfully after running grep -i cma /proc/meminfo right after a failed run. These were a few test runs I did. Success failure is pretty random, but then success is consistent once enough cma is free.
This is what I go at the end of
|
I've been trying some of this as well, and I do see slightly strange behaviour in that the free CMA seems somewhat variable, and indeed can occasionally go up. We'll investigate some more. In the meantime, there's probably some more advice I can give. The default image formats that Picamera2 (currently) chooses are not always the best ones. By default it selects RGBA type images because those are the only ones that work with all the different kinds of preview windows as well as the hardware video encoder, in OpenCV and the usual Python still image encoders. But they are also much the most memory hungry ones. So you would almost certainly have more luck if you set the format like this:
In fact this format works OK with the DRM/KMS preview window (which is what you would get if you aren't running X Windows), and also in those various image encoders, so there's probably no reason not to use it. But there's no way round the fact that on a Pi Zero 2 you're going to have to be a bit careful - a single 12MP RGBA buffer occupies 48MB (an RGB only buffer is better, but still 36MB each), and the camera system needs several to keep the frames flowing through. Do you have a particular application in mind? As you can see, there are definite pros and cons to some of the image format and resolution choices, and they can vary depending on the platform. |
Thank for the the additional advice. Anecdotally specifying the format seems more reliable, but I do still occasionally get the error after bootup. But after a minute or two the error just seems to go away without any intervention. Could it be that there is some background process from boot up that is still freeing up memory after logging in? Or perhaps even the camera itself needs more time after the pi has been turned on? The project I am working on is synchronized still photography of multiple Pi HQ Cameras. I am planning to use the external sync signal feature (https://forums.raspberrypi.com/viewtopic.php?t=281913) but haven't gotten to that point yet. For my particular use case I'm not planning on doing any realtime previews on the pi itself, and I really only need the first received frame from the camera (exposure, gain and whitebalance would all be manually fixed and set in the start command). I am curious if there is a way to just use 1 buffer for this use case, but it seems like the library and API are built around a sequential camera feed. |
Yes, we're going to look into the mysterious CMA issues, it feels somewhat like a fragmentation issue though it's not clear to me how it's happening. You should be able to get by with a single set of buffers (pass |
Just to update you with our progress on this. We have found that the Linux kernel is a bit over-zealous in trying to use CMA memory for itself, and this particularly afflicts platforms where the CMA area is at least half the the total system memory. This clearly includes the Pi Zero 2 as the CMA area defaults to 256MB and the total memory is 512MB. So we'll put in a patch to improve the situation there, and I've verified that the original script starts reliably now. That will appear through |
The latest images (released yesterday) should have this kernel fix in, in fact when I installed a fresh OS Lite onto a Pi Zero today, updated and rebooted it, it reports 240MB free CMA (out of 256MB) right away. Armed with a bit more information about formats (for example prefer "RGB888" if you aren't using the X-Windows OpenGL accelerated preview) and the number of buffers you need, I'm going to mark this one as resolved. But please get back to us if you're still experiencing problems or would like more advice in this area. Thanks! |
I installed a brand new install of the latest official OS Lite 32. After startup the original example code I posted at the beginning of this issue failed for the first 10-15 seconds. But as expected this modified version works even immediately after startup. So far I have tested it 10 reboots in a row without issue.
Thank you again for all of your help! |
Hmm, maybe I'm wrong about that fix being in the latest image. If you could bear to perform one more experiment.... Would you be able to run |
Your config = picam2.still_configuration(main={"format": "RGB888", "buffer_count": 1}) should be config = picam2.still_configuration(main={"format": "RGB888"}, buffer_count=1) At least that's what worked by me |
With a Raspberry Pi Zero 2 W running Buster 32bit and an HQ Camera this is the code I am using:
and this is the output:
Increasing the buffer size at full resolution to 3 or greater:
config = picam2.still_configuration(buffer_count=3)
Causes a different error:
Lowering the resolution by half works:
config = picam2.still_configuration(main={"size": (2028, 1520)})
Preview configuration also works at half resolution:
config = picam2.preview_configuration(main={"size": (2028, 1520)})
But a preview configuration at full resolution results in the same
Not enough buffers provided by V4L2VideoDevice
error:config = picam2.preview_configuration(main={"size": (4056, 3040)})
The text was updated successfully, but these errors were encountered: