For paletted images, header-scanning mode (used by stbi_info) kept
going after the image header to see if a tRNS (transparency) chunk
shows up to correctly determine the channel count, but we would
immediately return after IHDR for non-paletted images.
This is incorrect. We also change our reported channel count on
RGB images with a tRNS chunk, therefore non-paletted images also
have to resume scanning further chunks.
Update the logic to keep scanning regardless and report the
correct channel count from stbi_info for RGB images with tRNS
(constant alpha channel).
Fixes issue #1419.
Limit to 1k, which is the maximum size of a 256-entry palette that
would ordinarily go there. It feels sensible to relax this a bit but
we don't want to go overboard.
Fixes issue #1325.
Specifically, this rejects length codes 286 and 287, and distance codes 30 and 31.
This avoids a scenario in which a file could contain a table in which
0 corresponded to length code 287, which would result in writing 0 bits.
Signed-off-by: Neil Bickford <nbickford@nvidia.com>
The component resamplers are not written to support this and I've
never seen it happen in a real (non-crafted) JPEG file so I'm
fine rejecting this as outright corrupt.
Fixes issue #1178.
As per MS's own docs, should ignore the r/g/b bitmasks in the
header unless BI_BITFIELDS compression is selected. Factor out
setting the default masks since that now exists in two branches.
Add some more checking for unsupported compression formats and
illegal bpp/compression combinations while I'm at it.
Fixes issue #783.
Put the formats that start with a clear magic number first,
the dodgy ones that don't have much of a distinctive header
should be tested for later after we've ruled out the clearer
ones.
Fixes issue #787, hopefully. (Never got a clean repro.)
It's implementation-specified behavior. Writing this code and then
relying on compiler strength reduction to turn it back into shifts
feels extremely silly but it is what it is.
Fixes issue #1097.
Define lrot in a way that doesn't involve UB when n==0.
Also, the previous patch ensures that n <= 15 for all callers
of stbi__extend_receive, so can remove the (less restrictive)
bounds check for 0 <= n < 17 (the bounds of stbi__bmask)
entirely.
Fixes issue #1065.
extend_receive implicitly requires n <= 15 (code length);
the maximum that actually makes sense for 8-bit baseline JPEG is
11, but 15 is the natural limit for us because the AC coding path
stores the number of magnitude bits in a nibble.
Check that DC delta bits are in range before attempting to call
extend_receive.
Fixes issue #1108.
Put the formats that start with a clear magic number first,
the dodgy ones that don't have much of a distinctive header
should be tested for later after we've ruled out the clearer
ones.
Fixes issue #787, hopefully. (Never got a clean repro.)
