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.
Empirically, based on a series of photos of flowers at a particular resolution, jpeg size grows proportional to
q**-.75whereqis the jpeg quality number (smaller is higher quality), andw*h*(q**.75)/2is 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/5which 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.