#Hey folks. I'm trying to run a Camera
hidden cairn
that seems reasonable, the pico has ~150kB of available RAM for the whole of your python script. I don't know the product or the library, but I assume you would want to lower the resolution or quality or go greyscale, something to make the math work (or use a pico 2)
cobalt bone
I can do that. But I'm just wondering why it is not working as stated in the docs. I'd have expected using all the same setup, hardware. etc. should work.
hidden cairn
the example from the guide says "allocated 102400 bytes" so it uses different parameters, or maybe some defaults changed in the library since ?
cobalt bone
I wonder if perhaps there is less available memory in the newer circuit python release?
The difference is so large though.
And I'm copying libs from the example github, so it's not like a package manager is grabbing incompatible libs/packages or something.
hidden cairn
it sets
cam.colorspace = adafruit_ov5640.OV5640_COLOR_JPEG
cam.quality = 3
and the library code states:
def capture_buffer_size(self) -> int:
"""Return the size of capture buffer to use with current resolution & colorspace settings"""
if self.colorspace == OV5640_COLOR_JPEG:
# This is somewhat arbirary but seems to work for a wide range of JPEG images
# the user can chose to further scale the buffer in the user code if necessary
return 2 * (self.width * self.height // self.quality)
and 640 × 480 × 2 / 3 == 204800
so yeah there's a factor 2 that slid in there 🤔
cobalt bone
I do happen to have a Pico 2, so I can try that. it's just a bummer it doesn't work following the example directions.
hidden cairn
can you leave feedback on the guide with the feedback link, maybe with your full error stacktrace and a link to that PR ?
cobalt bone
Yep, will do. Thanks for that.
hidden cairn
thanks, somebody will have to adapt the example
cobalt bone
I can submit a PR.
Perhaps there is a way to get some incremental improvement rather than just cutting resolution in two.
hidden cairn
well you can't PR the guide
you could try setting the buffer to the 102400 size and hope it fits ?
it seems that the size used by jpeg varies so 🤷
again i don't know the library or product
cobalt bone
I can note the guide and PR the repo: https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/main/PiCowbell_Camera_Demos/JPEG_Capture/code.py
Right. JPEG size varies greatly based on image complexity.
hidden cairn
I don't know what the PR would be, halve the resolution maybe ?
library PR says: setting the buffer to width*height//5 also seems to work and that's weird because it's even smaller ? 🤷
cobalt bone
Looks like a higher quality number will make a smaller buffer size.
I see that setting to quality 7 worked.
hidden cairn
yeah quality is more like compression
the register name is _COMPRESSION_CTRL07 even, and the admissible values are 2 - 55
cobalt bone
I see that the buffer calculation takes quality into account though. Since it's the divisor, setting to a larger number will reduce the buffer size allocated. 5 seems the minimum, although I did get one quastionable photo.
We could also auto-scale the quality down until the allocation succeeds. Then it will work all platforms independent of available memory.
hidden cairn
yeah, but capture_buffer_size is basically an estimate for jpeg, so you can manually set what you want without following it
cobalt bone
Right, if I modify the adafruit_ov5640 library. For now, I think modifying the example is probably a good start.
hidden cairn
I don't think you need to modify the library, the buffer is just set outside of it line 80
you can put any number:
b = bytearray(102400)
It would be good if the camera picowbell demo worked out of the box.
Oh, I think that would be a bad idea. The cam interface tells us the size of the buffer it needs. If I just reduce the buffer size, it may have a buffer overrun. I think the better solution is to have the adafruit_ov5640.OV5640 api work as usual, but have the calling code adjust the calls as required for the specific platform.
hidden cairn
the complicated thing is that we can't dynamically change the size of a buffer, and assigning a new one is complicated since that would require making sure that the old one is deinited and collected first. At least not on pico with those sizes.
cobalt bone
I'll experiment and make a couple PRs. One with a basic fix so that it works on Pico and then another with trying the dynamic stuff.
