From e795306bbc866c51323e0172d3079c2abf5a7d24 Mon Sep 17 00:00:00 2001 From: Fabian Giesen Date: Fri, 2 Jul 2021 22:52:15 -0700 Subject: [PATCH] stb_image: Document image size limits Both the buffer size limits and the image dimension limits. Fixes issue #672. --- stb_image.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/stb_image.h b/stb_image.h index 87ae770..3057481 100644 --- a/stb_image.h +++ b/stb_image.h @@ -187,6 +187,24 @@ RECENT REVISION HISTORY: // // returns ok=1 and sets x, y, n if image is a supported format, // // 0 otherwise. // +// Note that stb_image pervasively uses ints in its public API for sizes, +// including sizes of memory buffers. This is now part of the API and thus +// hard to change without causing breakage. As a result, the various image +// loaders all have certain limits on image size; these differ somewhat +// by format but generally boil down to either just under 2GB or just under +// 1GB. When the decoded image would be larger than this, stb_image decoding +// will fail. +// +// Additionally, stb_image will reject image files that have any of their +// dimensions set to a larger value than the configurable STBI_MAX_DIMENSIONS, +// which defaults to 2**24 = 16777216 pixels. Due to the above memory limit, +// the only way to have an image with such dimensions load correctly +// is for it to have a rather extreme aspect ratio. Either way, the +// assumption here is that such larger images are likely to be malformed +// or malicious. If you do need to load an image with individual dimensions +// larger than that, and it still fits in the overall size limit, you can +// #define STBI_MAX_DIMENSIONS on your own to be something larger. +// // =========================================================================== // // UNICODE: