Page **1** of **1**

### possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-07T16:56:50-07:00**

by **fmw42**

The standard deviation of a single pixel should be 0.

IM 6.9.9-26

Code: Select all

`convert logo: -scale 1x1! -format "%[fx:standard_deviation]\n" info:`

**0 <--- Correct**
IM 7.0.7-14

Code: Select all

`magick logo: -scale 1x1! -format "%[fx:standard_deviation]\n" info:`

**0.00675767 <--- Incorrect**
Likewise:

Code: Select all

`convert xc:"rgb(25,128,50)" -format "%[fx:standard_deviation]\n" info:`

**0**
Code: Select all

`magick xc:"rgb(25,128,50)" -format "%[fx:standard_deviation]\n" info:`

**0.210684**

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-07T18:11:11-07:00**

by **snibgo**

The (rather old) v7.0.3-5 gives:

Code: Select all

```
magick xc:"rgb(25,128,50)" -format "%[fx:standard_deviation]\n" info:
0
```

This is the correct result.

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-07T19:32:06-07:00**

by **fmw42**

The oldest version I could easily test was 7.0.5.4 and it fails. So the change occurred between 7.0.3.5 and 7.0.5.4.

I note from the changelog:

2016-11-18 7.0.3-8 Cristy <quetzlzacatenango@image...>

Off by 1 error when computing the standard deviation (reference

https://www.imagemagick.org/discourse-s ... =2&t=30866).

2017-03-06 7.0.5-2 Cristy <quetzlzacatenango@image...>

Return proper minima / maxima (reference

https://www.imagemagick.org/discourse-s ... =3&t=31377).

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-08T05:41:55-07:00**

by **magick**

The standard deviation of a single pixel component is 0. However, fx:standard_deviation is the standard deviation of all pixel components of a pixel. So our population is 3: red, green, and blue. As such, IM6 is wrong and is corrected in the latest beta. We could return 0 for STD if we change the definition of the overall pixel STD such that each pixel is treated as one channel, gray, rather than individual channels, RGB. But that's problematic because we then lose info about all 3 channels and it begs the question what is gray? Do we use linear or luma or average the pixel channels? Do we allow the user to specify the gray colorspace? Or do we treat each pixel for the overall standard deviation as a population of the number of pixel components (i.e. 3 for RGB, 4 for RGBA, 4 for CMYK, etc.)?

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-08T11:02:45-07:00**

by **fmw42**

Yes, I had a feeling that was going to be it. But there is a single color.

Another approach would be to do the std of all channels appended as if grayscale.

What do you do for overall statistics in identify -verbose for mean, std, kurtosis and skew?

Perhaps others have an opinion.

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-08T12:20:09-07:00**

by **snibgo**

Fred, can you repeat your test with a size, using a recent IM version, eg:

Code: Select all

```
magick -size 1x1 xc:"rgb(25,128,50)" -format "%[fx:standard_deviation]\n" info:
magick -size 2x1 xc:"rgb(25,128,50)" -format "%[fx:standard_deviation]\n" info:
magick -size 3x1 xc:"rgb(25,128,50)" -format "%[fx:standard_deviation]\n" info:
```

Perhaps these now give three different numbers. Or perhaps only two. Huh? Do they have the same mean?

Please also try different colours, eg black and white. Is the SD of a white pixel different to the SD of a black pixel? I can't see why it should be different.

As far as I can see, the SD of each result should be zero. Because the SD is the sqrt of the variance from the mean. And none of them have any variance from the mean, so the SD is zero.

The number of channels isn't relevant, because the calculation will use the "colour distance" between pixels, ie sqrt(dr^2+dg^2+db^2).

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-08T12:39:26-07:00**

by **fmw42**

snibgo wrote:The number of channels isn't relevant, because the calculation will use the "colour distance" between pixels, ie sqrt(dr^2+dg^2+db^2)

For mean, min and max, I do not think there is any confusion.

But for higher order stats such as std, perhaps one of these 3 choices:

1) append the channels and take the std of the appended image

or

2) simply the average (std_r+std_g+std_b)/3

or if you feel strongly about using rms values

3) sqrt((std_r^2+std_g^2+std_b^2)/3)

All three of these options produces a zero std for a constant color image.

Personally I like option 1).

I think we just need to settle on an approach and make it clear what is being computed.

**So if anyone has any strong feelings, let us know soon.**

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-08T12:43:39-07:00**

by **fmw42**

magick wrote:However, fx:standard_deviation is the standard deviation of all pixel components of a pixel. So our population is 3: red, green, and blue

This does not make sense to me. If you have a constant color, then the std of each channel will be 0 and averaging the channel std values is still 0.

So what exactly do you mean.

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-08T14:13:12-07:00**

by **snibgo**

magick wrote:So our population is 3: red, green, and blue.

But a single pixel has exactly one colour. The population is 1, however many channels it has.

If there are two pixels, the SD should be zero (if they have the same colour) or some larger number if they are different.

I accept there is room for different interpretations when we have transparency. IM calculates SD as if there was no transparency, but I calculate as if fully-transparent pixels are ignored (which causes an "unknown SD" problem if the image is entirely transparent). Both approaches can be justified.

But for opaque pixels, I can't see the problem. If an image has a constant opaque colour, its SD is zero, however many pixels and channels it has.

(Sidenote: we are finding the SD of the entire population, of all the pixels. If we were sampling a few pixels and estimating the SD of the entire population, that would be a different situation.)

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-08T16:52:09-07:00**

by **magick**

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @

https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @

https://www.imagemagick.org/download/beta/ by sometime tomorrow.

We average the pixel components to derive the pixel standard deviation.

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-11T15:59:21-07:00**

by **fmw42**

This seems to be fixed now in IM 7.0.7.15 beta

Code: Select all

`magick xc:"rgb(25,128,50)" -format "%[fx:standard_deviation]\n" info:`

0

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-20T14:28:06-07:00**

by **snibgo**

magick wrote:We average the pixel components to derive the pixel standard deviation.

Does this mean that an image with two colours such as red (#f00) and blue (#00f) has zero standard deviation? I hope not.

If an image has one colour, it should have zero SD.

If an image has more than one colour, it should have non-zero SD:

Code: Select all

```
convert xc:red xc:blue +append -format "%[fx:standard_deviation]\n" info:
0.408249
```

This is how IM v6.9.5-3 works, and I can't see a good reason to change that. (Of course, SD could be calculated in many different ways, to measure different things. If those are desirable, they can be added as new functions.)

### Re: possible bug computing std IM 7.0.7.14 Q16

Posted: **2017-12-20T14:34:43-07:00**

by **magick**

Both IMv6 and IMv7 currently return 0.471405 for your two color use case. For one color, both return 0.