Ensure that a GIF without any Global or Local color tables is still
decoded by libgd.
GIF89a spec indicates conforming image files need not have
Global or Local color tables at all.
Spec recommends creating custom color map in that situation, and
that at least Black+White as first two entries, to ensure B&W images
are decoded.
Some commonly used single-pixel GIFs found around the web are
undecoded by libgd otherwise. Test case has been included.
References:
https://www.w3.org/Graphics/GIF/spec-gif89a.txthttp://probablyprogramming.com/2009/03/15/the-tiniest-gif-ever
After calculating the top crop amount, we bail out if the whole image
was going to be cropped away. The condition to check this
is off-by-one, though, since `y` would be equal to `height` in this
case. However, `y` would be equal to `height` also in case only the
last row of the image would have to be retained. We instead check for
`match` which indicates whether all pixels have the same color.
After calculating the bottom crop amount, we must never calculate the
`crop.height` based on the image height, since its irrelevant.
When calculating the left and right crop amount, we must not ignore the
last row of the image.
The partially identical implementation of `gdImageCropThreshold()` has
exactly the same issues, so we fix it as well.
Future scope for *improvements*:
- Replace the `match` flag with respective `goto`s (basically, `break
2`) is supposed to yield clearer code.
- Don't check the rows which will be top-cropped anyway, when
calculating the left and right crop amount, for efficiency.
- Join the implementations of calculating the crop rectangle of
`gdImageCropAuto()` and `gdImageCropThreshold()`.
When using `gdImageCopy()` for image cropping, we have to make sure
that it doesn't use alpha blending (the current default), but rather
`gdEffectReplace`. We reset the `alphaBlendingFlag` after finishing
the copy operation.
Mike Frysinger
az6667
wilson chen
Christoph M. Becker
Pierre Joye