Only clear to background color if index is non-zero.
Fixed a the disposal test gif I was using - now renders properly (gif has no transparent set, but all renderers still considered it transparent. Spec says 0 should be ignored if 0, but was confusing by saying it only in the context of the pal not existing.. but seems to be the case always.
- Fix an issue where the spec of the gif for restore to previous uses code 3, not 4.
- To get results that worked - made an assumption that "clear to background" meant "revert back to what was there before I drew", where mode 1 would revert back to the previous frame [slightly different]. If I clear to background color instead, I ended up with large opaque squares in gifs that changes their transparent colour each frame.
- Background color is supposed to be used only for pixels not rendered by the image, so took that to mean it only really affected the previous frame, or potentially any frame that used full disposal. Since background color is allowed to be unspecified this is what lead me to believe I shouldn't use it for disposal.
- Oh, also upped the codes table to 8192 as 4096 ended up being too small for a few of my test cases.
Full disclaimer - I only read through the GIF format for this contribution, so competly could be misinterpreting the spec - but this gave me reuslts that matched Chrome.
- Allow loading a gif as multiple frames into a single buffer. Each frame is a full image seperated by a (w * h * comp) stride.
- Optionally, can pass in a pointer to a int, which will be filled with an array layers long contain ms for each frame.
- Fix gif's not loading the initial transparent background
- I believe also fix disposal rules for subsequent frames (though being somewhat inefficient with memory to do so)
- Add a flip_vertical that takes into account slices as well.
Compiled using VS2017, but nothing else as I'm not really setup for it. Apologies.
This incorporates #462, but also factors everything into one
function that is shared between 8-bit integer, 16-bit integer, and
float pixels (vertical flip operates on rows of bytes and doesn't
really care), and finally always uses a 2k on-stack buffer without
dynamic memory allocation, doing multiple memcpys per row if
necessary. Not only does this remove an out-of-memory failure mode,
it is also preferable for large images, since it's more
L1-cache-firendly this way.
Fixes#462.
We used to require exact match between img_len and raw_len for
non-interlaced PNGs, but the PNG in issue #276 has extra bytes
(all zeros) at the end of the compressed DEFLATE stream.
The PNG spec doesn't have anything to say about it (that I
can tell), and if libpng accepts this, who are we to judge.
Fixes issue #276.
My guideline for the rules is the PNG loader (which I consider
"canonical"). In the _load functions, x and y are required but
comp is optional; in the _info functions, all three are optional.
Fixes issue #411 (and other related, unreported issues).
We tried but it was nothing but trouble. New rule: with
GCC/Clang, if you're compiling with -msse2, you get always-on
SSE2 code, otherwise you don't get any. Trying to ship
anything with proper runtime dispatch requires both working
around certain bugs and some fiddling with build settings,
which runs contrary to the intent of a one-file library,
so bail on it entirely.
Fixes issue #280.
Fixes issue #410.
stbi__process_frame_header had two bugs when dealing with progressive
JPEGs:
1. when malloc failed allocating raw_data, previous components'
raw_coeff didn't get freed
2. no out-of-memory check in raw_coeff allocation
Fix both and share a bit more cleanup code in general.
Adds some helpers that check whether a product of multiple
factors (that need to be non-negative: this is enforced)
summed with another non-negative value overflows when
performed as int. Since stb_image mostly works in ints,
this seems like the safest route. Limits size of images
to 2GB but several of the decoders already enforce this
limit (or even lower ones).
Also adds wrappers for malloc that combine a mul-add-with-
overflow-check with the actual malloc, and return NULL
on failure. Then use them when allocating something that
is the product of multiple factors.
For image formats, also add a top-level "is this too big?"
check that gives a more useful error message; otherwise,
the failed mallocs result in an "out of memory" error.
The idea is that the top-level checks should be the primary
way to catch these bugs (and produce a useful error message).
But a misleading error message is still vastly preferable to
a buffer overflow exploit.
Fixes issues #310, #313, #314, #318. (Verified with the
provided test images)
Along the way, this fixes a previously unnoticed bug in
ldr_to_hdr / hdr_to_ldr (missing NULL check); these functions
are called with the result of an image decoder, so NULLs can
definitely happen.
Another bug noticed along the way is that handling of
interlaced 16-bit PNGs was incorrect. Fixing this (along
with the previous modifications) fixes issue #311.
Yet another bug noticed during this change is that reduce_png
did not check the right pointer during its out of memory
check. Fix that too.
