|
|
|
@ -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:
|
|
|
|
|