Skip to content
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

better jpeg maximum size estimate #2

Open
jepler opened this issue Oct 7, 2021 · 0 comments
Open

better jpeg maximum size estimate #2

jepler opened this issue Oct 7, 2021 · 0 comments

Comments

@jepler
Copy link
Member

jepler commented Oct 7, 2021

Empirically, based on a series of photos of flowers at a particular resolution, jpeg size grows proportional to q**-.75 where q is the jpeg quality number (smaller is higher quality), and w*h*(q**.75)/2 is about 10% larger than the flower files at a range of qualities. Different resolutions might have different characteristics, and there's no guarantee that "the most visually complicated scene" won't require a lot more bits than my particular vase of flowers.

We need to know a safe maximum size because if the encoded jpeg data exceeds its buffer, the image can't be captured. But we don't want it to be far too big, or else we use up too much RAM. (target device is esp32-s2 with 2MB PSRAM; if it can't capture the highest pixel size at the best quality, it's okay)

esp32-cam uses w*h/5 which seems fine (an over estimate) for images at the default quality of q=12. The lowest usable quality number at 2560x1920 seems to be q=5, with failed captures (even with large buffer sizes) becoming more frequent for lower q= numbers, though some q=4 images were captured. Even some of the q=5 images that were "successfully captured" are corrupted, though it's not clear yet whether it's the camera→mcu step or the mcu→sd step where this occurs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant