Bug introduced in 8 or earlier and persisting through 13.1.0

Reported to the support as [CASE:3968587]. Published on Wolfram Community.

In the presence of alpha channel ImageCrop doesn't remove borders at all despite the fact that the latter are exactly uniform (both in the color channels and in the alpha channel). Here is an example of inconsistent behavior of ImageCrop (checked with versions 8.0.4, 9.0.1, 11.2.0 and 11.3.0):

img = Rasterize[
   Graphics[{Circle[{0, 0}, 1], 
     Text[Style[l, FontFamily -> "Times"], {1.2, 0}]}, Frame -> False,
     PlotRange -> {{.9, 1.3}, All}], "Image", Background -> None];

Show[#, Frame -> True, FrameTicks -> False, 
   PlotRangePadding -> None] & /@
 {img, ImageCrop[img], ImagePad[img, -BorderDimensions[img, 0]]}


The built-in ImageCrop function "effectively removes borders from image whose pixel value distribution is almost uniform" (emphasis mine). I need an efficient cropping function which removes borders whose pixel values are identical. What is the best way to do this in Mathematica? I don't need support for 3D images, but images with an alpha channel should be supported.

  • 1
    $\begingroup$ This is apparently the default in Version 7: "ImageCrop[image] effectively starts at the borders of image, then removes as many layers of pixels as possible where all their color values exactly match the colors of the borders." (emphasis mine) $\endgroup$
    – Mr.Wizard
    Mar 2, 2013 at 9:11
  • 2
    $\begingroup$ @Mr.Wizard Such hidden changes is a source of troubles for the users. On the Documentation page of v.8 we read the same as in v.9. But on the bottom of the page in v.8 nothing is said about changes since v.7 (one can see only "New in 7"). I think that the difference in the behavior as compared to v.7 is significant. I wasted half an hour before realised that ImageCrop is "smarter" than I need! $\endgroup$ Mar 2, 2013 at 11:55
  • 2
    $\begingroup$ @Mr.Wizard Usually when working with new version of Mathematica I check only the bottom of the page for the function I use and if nothing is said about changes I think that there are no significant changes. But this case is critical for me! I am forced to revrite some functions I thought reliable from version to version... $\endgroup$ Mar 2, 2013 at 12:05
  • 1
    $\begingroup$ I agree. That's a nasty change to not announce. It would have been better to introduce a new Option for tolerance; this way old code would not break but users who wanted to could e.g. SetOptions[ImageCrop, Tolerance -> 0.03] and get the "new" behavior. $\endgroup$
    – Mr.Wizard
    Mar 2, 2013 at 12:26
  • 1
    $\begingroup$ @AlexeyPopkov +1 I think three small images (original, fuzzy and strict cropping) may improve the question comprehension time $\endgroup$ Mar 2, 2013 at 17:17

2 Answers 2


I just realized that BorderDimensions accepts second argument as tolerance. So, what I need is

ImagePad[img, -BorderDimensions[img, 0]]

A workaround allowing ImageCrop to crop images having alpha channel is to temporarily set ColorSpace -> Automatic:

Image[ImageCrop[Image[img, ColorSpace -> Automatic]], ColorSpace -> "RGB"]

Also published here: http://community.wolfram.com/groups/-/m/t/1215584

Strongly related:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.