Normalize filter does not work anymore

[jhuckaby]

The ImageMagick 'Normalize' filter works perfectly in ImageMagick 6.3. Here are some shining examples of how well it corrects bad brightness and contrast in images:

Source Image #1 (too bright): https://dl.dropbox.com/u/4585115/imagem ... source.jpg
Source Image #2 (too dark): https://dl.dropbox.com/u/4585115/imagem ... source.jpg
Source Image #3 (low contrast): https://dl.dropbox.com/u/4585115/imagem ... source.gif

Now, simply running the '-normalize' filter on ImageMagick 6.3 fixes all three of these images nicely:

Code: Select all

convert car-bright-source.jpg -normalize car-bright-normalize-im63.jpg
convert car-dark-source.jpg -normalize car-dark-normalize-im63.jpg
convert car-lowcontrast-source.gif -normalize car-lowcontrast-normalize-im63.gif

Fixed Image #1 (IM 6.3): https://dl.dropbox.com/u/4585115/imagem ... e-im63.jpg
Fixed Image #2 (IM 6.3): https://dl.dropbox.com/u/4585115/imagem ... e-im63.jpg
Fixed Image #3 (IM 6.3): https://dl.dropbox.com/u/4585115/imagem ... e-im63.gif

However, when I try the very same commands on the same source images but with ImageMagick 6.8, the output images look awful:

Code: Select all

convert car-bright-source.jpg -normalize car-bright-normalize-im68.jpg
convert car-dark-source.jpg -normalize car-dark-normalize-im68.jpg
convert car-lowcontrast-source.gif -normalize car-lowcontrast-normalize-im68.gif

Output Image #1 (IM 6.8 ): https://dl.dropbox.com/u/4585115/imagem ... e-im68.jpg
Output Image #2 (IM 6.8 ): https://dl.dropbox.com/u/4585115/imagem ... e-im68.jpg
Output Image #3 (IM 6.8 ): https://dl.dropbox.com/u/4585115/imagem ... e-im68.gif

The #1 ("too bright") image is slightly darker but not normalized, the #2 ("too dark") image has been completely blown out to solid white, and the #3 ("low contrast") image has become too bright. Has the normalize filter changed since IM 6.3? Am I using it incorrectly?

I am running:

Version: ImageMagick 6.8.4-6 2013-04-04 Q8 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2013 ImageMagick Studio LLC
Features: DPC
Delegates: bzlib freetype jng jpeg lcms png tiff xml zlib
OS: Linux 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux (64-bit CentOS 6.2)

- Joe

[fmw42]

I can confirm.

I tested your first image (the car) with IM 6.4.7.10, 6.8.3.9, 6,8.4.6 and 6.8.4.7beta.

The results from 6.7.4.10 were the best and matched your 6.3 results. Results from 6.8.3.9, were a little brighter. But 6.8.4.6 and 6.8.4.7beta were much brighter.

It is possible, though not likely, that the default values for -normalize may have been changed at some point. However, that does not explain the inconsistencies between 6.8.3.9 and the 6.8.4.6 and 6.8.4.7beta versions.

All the following seem the same: sRGB, truecolor, gamma=0.4545. However 6.7.4.10 was before the colorspace change and so reports RGB which was actually sRGB. But it does not report the gamma

67410
Image: car-bright-normalize-im67410.jpg
Class: DirectClass
Colorspace: RGB
Type: TrueColor
Depth: 8-bit
Alpha: False
Channels: rgb
Rendering intent: Undefined


6839
Image: car-bright-normalize-im6839.jpg
Class: DirectClass
Colorspace: sRGB
Type: TrueColor
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Perceptual
Gamma: 0.454545

6846
Image: car-bright-normalize-im6846.jpg
Class: DirectClass
Colorspace: sRGB
Type: TrueColor
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Perceptual
Gamma: 0.454545

6847beta
Image: car-bright-normalize-im6847b.jpg
Class: DirectClass
Colorspace: sRGB
Type: TrueColor
Depth: 8-bit
Alpha: False
Channels: srgb
Rendering intent: Perceptual
Gamma: 0.454545


P.S. I tested with PNG output and the results are the same for 6.8.4.6. So it is not format dependent.

P.S. 2 I tested with -contrast-stretch 2x1% and got the same results as with -normalize.

[fmw42]

Adding -set colorspace RGB for newer versions, seems to fix the issue

convert car-bright-source.jpg -set colorspace RGB -normalize car-bright-normalize-im6846_rgb.jpg

This seems to match your 6.3 results.

I think this is now need because the image gets convert to a (linear) intensity grayscale image to get the statistics to process the image. So by adding -set colorspace RGB, we tell IM not to do the gamma conversion, so that the intensity is non-linear as it used to be before the colorspace and grayscale changes.

However, using IM 6.8.3.9 is still a bit too bright even with adding -set colorspace RGB to the command.

I would assume that since adding -set colorspace RGB to the more current 6846 version matches your old 6.3 and my 6.7.4.10, that it is now correct. I am not sure why 6.8.3.9 is too bright, but we are now past that version.

[snibgo]

Yup, "-normalize" needs "-set colorspace RGB" to work in the way we might expect.

So does "-threshold", "-equalize" and even "-contrast-stretch 0" though not "-auto-level".

[jhuckaby]

Thanks guys. Adding "-colorspace RGB" seems to be the universal solution to all my recent issues, haha.

[fmw42]

see

http://www.imagemagick.org/script/forma ... colorspace
and
viewtopic.php?f=4&t=21269

[anthony]

Question is is why is -normalize colorspace dependant?
And if so what are the rules? Image much be linear?
Or is it only a problem with Greyscale images?

Of course -auto-level is pure mathematical, and should be colorspace indepandant.

[fmw42]

It is colorspace dependent because it gets converted to grayscale to get the statistics. The grayscale image will be different if linear (gamma=1) or non-linear (gamma=0.4545). So the statistics will be different. One can control the conversion to use different colorspaces or formulae using -intensity before -normalize. See http://www.imagemagick.org/script/comma ... #intensity. According to Magick, the same is true of the following:

-adaptive-blur
-adaptive-sharpen
-selective-blur
-shade
-contrast-stretch
-tint
-distort {ErodeIntensity, DilateIntensity}
-colors for gray colorspace
-black-threshold
-white-threshold
-normalize
-threshold
-random-threshold

I think +level-colors also falls into this category, since it must be converted to grayscale before the colors are applied.

[anthony]

missing from that list
I have not checked if it does 'lookup' using intensity setting...

-compose {LightenIntensity, DarkenIntensity, CopyOpacity, CopyBlack}

-clut (when mapping greyscale CLUT image to alpha channel if set by -channels)


Note this is only a lookup for calculations, the image is not actually 'converted' whcih implies extra memory use for a full image, rather just just statistical information gathering.

I do hope 'intensity' is not applied for -colorspace grey if a 'special intensity' is wanted -greyscale {method} should be used. This is a image conversion rather than a statistical lookup.

[fmw42]

if a 'special intensity' is wanted -greyscale {method} should be used.

I was unaware that this was available. But I see it now at http://www.imagemagick.org/script/comma ... #grayscale

Note the docs list it as -grayscale and not -greyscale. Trying -greyscale gives an error.

But the docs at http://www.imagemagick.org/script/comma ... #intensity seem to show basically the same example of converting an image to grayscale as output rather than using -intensity before one of the above operators.

A better example is probably needed for -intensity. Also both need to explain that luminance (no apostrophe) is linear and lum (apostrophe) is non-linear.

Anthony, perhaps you can explain the difference and why we need both. That is, why can't (shouldn't?) -intensity be used just like -grayscale to simply convert and save an image to grayscale?

Also it might be nice to know when exactly both were made available and properly functional. The changelog shows -intensity at 6.8.3.10 and changed at 6.8.4.1. Do I assume both are properly working at 6.8.4.1 or 6.8.3.10?

I would also note that the method rec601luminance is like -colorspace gray and rec601luma is like -set colorspace RGB -colorspace gray.

[anthony]

if a 'special intensity' is wanted -greyscale {method} should be used.

I was unaware that this was available. But I see it now at http://www.imagemagick.org/script/comma ... #grayscale

Note the docs list it as -grayscale and not -greyscale. Trying -greyscale gives an error.

But the docs at http://www.imagemagick.org/script/comma ... #intensity seem to show basically the same example of converting an image to grayscale as output rather than using -intensity before one of the above operators.

That is because I have no good example as yet!!! normal use of the -intensity is rather 'hidden'. A good example
would probably be the same as used in -compose LightenIntensity but it is not using it yet!
http://www.imagemagick.org/Usage/compos ... _intensity


Anthony, perhaps you can explain the difference and why we need both. That is, why can't (shouldn't?) -intensity be used just like -grayscale to simply convert and save an image to grayscale?

Because as explained, it is used by various operators for behind the scenes work. For example the what greyscale value should CopyOpacity use when the image has no alpha to copy? At the moment it: 1/ assumes it is a RGB image and 2/ gets the intensity of that image. If the image is greyscale, well no problem.

Also it might be nice to know when exactly both were made available and properly functional. The changelog shows -intensity at 6.8.3.10 and changed at 6.8.4.1. Do I assume both are properly working at 6.8.4.1 or 6.8.3.10?

I would say as '-list Intensity' is not yet working they are both still in beta.

Code: Select all

I would also note that the method rec601luminance is like -colorspace gray and rec601luma is like -set colorspace RGB -colorspace gray.

I thought I said that! But then I often can't seem to say things that simply.


Revise it as you must. Fix the greyscale fault...


PS: As mentioned in the previous email... -grayscale with a 'colorspace' method is not getting the right value.
Read that mail!