possible bug computing std IM 7.0.7.14 Q16

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
User avatar
fmw42
Posts: 24128
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

possible bug computing std IM 7.0.7.14 Q16

Post by fmw42 » 2017-12-07T16:56:50-07:00

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

snibgo
Posts: 10954
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: possible bug computing std IM 7.0.7.14 Q16

Post by snibgo » 2017-12-07T18:11:11-07:00

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.
snibgo's IM pages: im.snibgo.com

User avatar
fmw42
Posts: 24128
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: possible bug computing std IM 7.0.7.14 Q16

Post by fmw42 » 2017-12-07T19:32:06-07:00

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).

User avatar
magick
Site Admin
Posts: 10865
Joined: 2003-05-31T11:32:55-07:00

Re: possible bug computing std IM 7.0.7.14 Q16

Post by magick » 2017-12-08T05:41:55-07:00

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.)?

User avatar
fmw42
Posts: 24128
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: possible bug computing std IM 7.0.7.14 Q16

Post by fmw42 » 2017-12-08T11:02:45-07:00

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.

snibgo
Posts: 10954
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: possible bug computing std IM 7.0.7.14 Q16

Post by snibgo » 2017-12-08T12:20:09-07:00

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).
snibgo's IM pages: im.snibgo.com

User avatar
fmw42
Posts: 24128
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: possible bug computing std IM 7.0.7.14 Q16

Post by fmw42 » 2017-12-08T12:39:26-07:00

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.

User avatar
fmw42
Posts: 24128
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: possible bug computing std IM 7.0.7.14 Q16

Post by fmw42 » 2017-12-08T12:43:39-07:00

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.

snibgo
Posts: 10954
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: possible bug computing std IM 7.0.7.14 Q16

Post by snibgo » 2017-12-08T14:13:12-07:00

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.)
snibgo's IM pages: im.snibgo.com

User avatar
magick
Site Admin
Posts: 10865
Joined: 2003-05-31T11:32:55-07:00

Re: possible bug computing std IM 7.0.7.14 Q16

Post by magick » 2017-12-08T16:52:09-07:00

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.

User avatar
fmw42
Posts: 24128
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: possible bug computing std IM 7.0.7.14 Q16

Post by fmw42 » 2017-12-11T15:59:21-07:00

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

snibgo
Posts: 10954
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: possible bug computing std IM 7.0.7.14 Q16

Post by snibgo » 2017-12-20T14:28:06-07:00

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.)
snibgo's IM pages: im.snibgo.com

User avatar
magick
Site Admin
Posts: 10865
Joined: 2003-05-31T11:32:55-07:00

Re: possible bug computing std IM 7.0.7.14 Q16

Post by magick » 2017-12-20T14:34:43-07:00

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

Post Reply