17

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]]}

screenshot

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.

Alexey Popkov
  • 61,809
  • 7
  • 149
  • 368
  • 1
    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) – Mr.Wizard Mar 02 '13 at 09:11
  • 2
    @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! – Alexey Popkov Mar 02 '13 at 11:55
  • 2
    @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... – Alexey Popkov Mar 02 '13 at 12:05
  • 1
    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. – Mr.Wizard Mar 02 '13 at 12:26
  • 1
    @AlexeyPopkov +1 I think three small images (original, fuzzy and strict cropping) may improve the question comprehension time – Dr. belisarius Mar 02 '13 at 17:17
  • @belisarius I have added an example (this case is opposite to what I got stuck on but it demonstrates inverse side of the problem). Obviously, new ImageCrop is a crap. – Alexey Popkov Mar 02 '13 at 20:53
  • Nice, thanks a lot – Dr. belisarius Mar 03 '13 at 05:51
  • I was experiencing this, in which images with alpha channel aren't actually cropped, but RGB images are though (both cases being "exactly uniform"). Not sure if something has changed in the new versions. – abcd Aug 02 '20 at 03:42

2 Answers2

19

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

ImagePad[img, -BorderDimensions[img, 0]]
Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
Alexey Popkov
  • 61,809
  • 7
  • 149
  • 368
2

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:

Alexey Popkov
  • 61,809
  • 7
  • 149
  • 368