Legacy ImageMagick Discussions Archive

Internally IM uses its compile time quaility setting. 8 bit images are stored at that quality and then saves at the current image 'depth' whcih is usualy the image input depth. Also HDRI versions of IM store values a floating poitn numbers in memory but use Q16 as a base for those numbers.

EG typically when reading and writing and image in Q16 IM
8bit image file --> 16bit memory --> 8bit image file

metric PAE is Peak Absolute Error -- Which is the largest 'error' distance between individual values, and not the diagonal colorspace distance.
In other words it is a Chebyshev Distance also known as a King's or Queen's distance in the distance a king or queen would move on a chess board.

As such for a black pixel vs a white pixel this is the 0 to 2^Q where Q is typically 16 or 65535. in Q8 that would be 255

Code: Select all

[b]compare xc:black xc:white -metric PAE null:[/b]
65535 (1)

NOTE I used IM itself to specify the image color to avoid the 'input' confusion.

-compare FUZZ will be using the colorspace distance (diagonal) also known as Euclidean distance (or a as the crow flies, distance)
As such the distance should be sqrt(3)*2^Q or roughly 113511 (for the -fuzz threshold).

However "compare" seems to do things a little differently to the -fuzz calculation. Basically it calculated in floating point, and then multiplies this 'normalised' value by Q^16 so it can be stored into the resulting image, in memory, to ensure it does not overflow the image bounds.

Best idea when using compare is to ignore the actual number and only use the floating point value (in parenthesis). So white to black is a floating (normalized) value of 1, same as for PAE.

Code: Select all

compare xc:white xc:black -metric FUZZ null:
65535 (1)

But you can see the difference between the two metrics clearly if you compare colors like Black to Cyan (cyan is #00FFFF or 0,255,255)
PAE will still get a maximum value distance (255 at Q8 or 65535 at Q16, or 1.0), but FUZZ will have a normalized value sqrt(2) / sqrt(3) or .816

Code: Select all

[b]compare xc:black xc:cyan -metric PAE null:[/b]
65535 (1)
[b]compare xc:black xc:cyan -metric FUZZ null:[/b]
53509.1 (0.816497)

Note that this is all "in memory", when saving to a image that value will be converted to the appropriate "depth" for that image be it depth 8 (GIF,JPEG), 16 (PNG), or floating point (PFM - PbmPlus floating point image).

Compare does not provide a Manhatten Distance (Taxicab) Metric (simple addition of the difference of all color channels), but
you can generate such a difference images very easily...
http://www.imagemagick.org/Usage/compare/#difference

snibgo wrote: ↑2017-11-13T12:56:30-07:00 You can set the output depth with -depth or +depth, but:

JPEG is always 8 bits/channel. GIF is up to 256 colours, each of which is 8 bits/channel. PNG is either 8 or 16. TIFF is anything.

Within those limits, the output depth is often set to the input depth. For PNG files, IM may reduce the bit depth if that doesn't change the image.

Thank You for your response. As anthony says:

anthony wrote: ↑2017-11-13T21:38:34-07:00 nternally IM uses its compile time quaility setting. 8 bit images are stored at that quality and then saves at the current image 'depth' whcih is usualy the image input depth. Also HDRI versions of IM store values a floating poitn numbers in memory but use Q16 as a base for those numbers.

EG typically when reading and writing and image in Q16 IM
8bit image file --> 16bit memory --> 8bit image file

Even when i forced Q8 IM still show me Q16 numbers.
I fixed this by installing Q8 IM, now all is fine. Well not all, but numbers are correct.

anthony wrote: ↑2017-11-13T21:38:34-07:00 -compare FUZZ will be using the colorspace distance (diagonal) also known as Euclidean distance (or a as the crow flies, distance)
As such the distance should be sqrt(3)*2^Q or roughly 113511 (for the -fuzz threshold).

I've put Euclidean formula to my excel file next to 'correct' formula for IM. They are basically same formula but in IM formula we've got also an Alpha Channel.

While i'm using PAE and AE i think IM is just searching highest and lowest value for RGB channels. Then as an output we have distance in RGB separate for all channels and All value is the highest distance from them.
Because of that when i'm trying to compare Euclidean's calculation result with IM result they are not the same.

In my case, when i'm trying to reproduce image i have to use -metric AE for wrong pixels count and PAE for RGB values distance.

Thank You for your help and knowledge share.

If You have any advices i'll be glad to read them.

The -metric AE is completely different to PAE. AE only returns a boolean (error or not-error) result, returning total count of the number of different pixels.
So normally is ANY pixel is different it is different!

Code: Select all

[b]compare xc:black xc:cyan -metric AE null:[/b]
1

However AE is one of the few metrics effected by a -fuzz threshold (not the FUZZ metric) to class pixels that is less than the 'fuzz factor' as being similar.

as such if I use an extrememly high fuzz factor of 82% (larger that the .81 value we had before), then black and cyan SHOULD be the same!

Code: Select all

[b]compare xc:black xc:cyan -metric AE -fuzz 82% null:[/b]
1

As you can see I have the WRONG result! Something is not correct, and I will be report this though it may be my IM version is OLD (standard Fedora Release at this time)

anthony wrote: ↑2017-11-16T17:52:16-07:00 The -metric AE is completely different to PAE. AE only returns a boolean (error or not-error) result, and a find count of the number of pixels.
So normally is ANY pixel is different it is different!
Code: Select all
[b]compare xc:black xc:cyan -metric AE null:[/b]
1
However AE is one of the few metrics effected by a -fuzz threshold (not the FUZZ metric) to class pixels that is less than the 'fuzz factor' as being similar.

as such if I use an extrememly high fuzz factor of 82% (larger that the .81 value we had before), then black and cyan SHOULD be the same!
Code: Select all
[b]compare xc:black xc:cyan -metric AE -fuzz 82% null:[/b]
1
As you can see however I have the WRONG result! Something is not correct, and I will be report this though it may be my IM version is OLD (standard Fedora Release at this time)

Unfortunetly, everything is fine.
You are using FUZZ and PAE that count that differently.
FUZZ - mean color distance.
PAE - peak absolute (normalized peak absolute).

In this case PAE will always show highest value from RGB channel as output.
To clear this You can use -verbose.

with -metric FUZZ

Code: Select all

compare xc:black xc:cyan -verbose -metric FUZZ null:
Image: black
	Channel distortion: Fuzz
		red: 0 (0)
		green: 65535 (1)
		blue: 65535 (1)
		all: 53509.1 (0.816497)
xc:black=> XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.012

and with -metric PAE

Code: Select all

compare xc:black xc:cyan -verbose -metric FUZZ null:
Image: black
	Channel distortion: Fuzz
		red: 0 (0)
		green: 65535 (1)
		blue: 65535 (1)
		all: 65535 (1)
xc:black=> XC 1x1 1x1+0+0 16-bit sRGB 0.031u 0:00.018

To clear with -fuzz threshold we have to use value 65535 or 100%.

anthony wrote: ↑2017-11-16T17:52:16-07:00 If I use an extrememly high fuzz factor of 82% (larger that the .81 value we had before), then black and cyan SHOULD be the same!
Code: Select all
[b]compare xc:black xc:cyan -metric AE -fuzz 82% null:[/b]
1
As you can see I have the WRONG result! Something is not correct, and I will be report this though it may be my IM version is OLD (standard Fedora Release at this time)

The problem with a -fuzz factor and -metric AE has been found and is being fixed in the main source.

Note -fuzz factor only works with a few metrics (like AE - error pixel counts), it has no effect on FUZZ or PAE or other metrics like that. Which is Why I removed it in those example tests in my previous posts.

Hmmm one side effect of -metric PAE. if you compare any image to another that is the same size but all black PAE will get you the largest color value in the image. On the other hand MAE will get you the average of all the color values in the image. Note this is over ALL color channels.

A -metric FUZZ is actually a much more useful value, especially in a perceptual color space like LAB or LUV, as it should match what differences we see.

Legacy ImageMagick Discussions Archive

Compare -FUZZ <- how it is calculated

Re: Compare -FUZZ <- how it is calculated

Re: Compare -FUZZ <- how it is calculated

Re: Compare -FUZZ <- how it is calculated

Re: Compare -FUZZ <- how it is calculated

Re: Compare -FUZZ <- how it is calculated

Re: Compare -FUZZ <- how it is calculated