Normalize Problem

[likwidoxigen]

This is the original image


I then do the following two steps.

Code: Select all

convert -normalize testOrig.jpg testOld.jpg
mogrify -level 5%,87%,1.2 testOld.jpg

This first one was done with the Ubuntu standard ImageMagick version which appears to be Version:6.2.4-5


This version was done with version 6.3.3-4 which I just compiled.


This is clearly not the results I was looking for. Is there a way to bring back the functionality to the same as the older version? I also tried
the same normalize but this time with a

Code: Select all

-channel all

but that yielded this image which is still not what I wanted.




So it feels to me like this is a bug.. am I right?

[anthony]

-normalize is probably not the function you thought it was. In fact it had a bug fix that should be the reason for the change.

See IM Example, Normalize
http://www.imagemagick.org/Usage/color/#normalize

If you want the old behaviour (not good for all images) use

Code: Select all

   -separate -normalize -combine

or

Code: Select all

   -channel ALL -normalize

What you are probably looking for is a some sort of auto-level function which is something IM is sorely lacking.

[likwidoxigen]

No. If you look at the last image I posted in my original message I included that the output of what happens when you use -channel all. And the result is definately very different.

I've test processed about 4000 different images with solely image magick incorporated into bash scripts and the results of the former normalize produced output far better than any auto-levels from any program photoshop,gimp,Paint.net etc. The results were actually good enough that I could shoot in jpg's for my professional gig's and only spend time editing the images i really liked and have my images over-all look good.

[anthony]

Can try the test images

Code: Select all

    convert -size 150x100 gradient:grey70-grey30 grey_range.png

and

Code: Select all

    convert -size 100x100 gradient:grey70-grey30 \
            -size  50x100 gradient:blue-navy  +append  color_range.png

and let us see the results of your previous tests (outputting png) so we can have a look at what the operator is doing.

Also try -contrast-stretch 0

We have also been looking at a proposed -histogram-stretch type of normalize that discards the number of pixels given (or percentage) from a histogram curve to find the color points to normalize. This should stop a single pixel throwing of the normalization.
Unfortunatally it has not been implemented (for the command line in any case).
See... http://redux.imagemagick.org/discourse- ... hp?p=24216

There has also been a discussion about a auto-gamma type of adjustment...

Fit a gaussian peak to a histogram. This will give you a peak position, and a width for the peak (two half-widths, actually). Then choose a gamma value that will realign
the distribution to be more centered and appropriately wide.

See the updates to http://www.imagemagick.org/Usage/bugs/future/#contrast in a few hours, where I tryied to sumerize the current normalized/de-normalize situation. however this is probably getting off your specific problem.

[likwidoxigen]

Wow. That was a really really weird experiment. I must say I can see why -normalize was "broken" but man... it makes color images look fantastic, it's literally the "perfect" amount of "fix" to them. They're just a hair of tweaking away and you don't lose any image information. Honestly i'm gong to keep the old version around just for that. Maybe you guys could look into including it as a filter? I mean "-enhance-photo" would be a great name for it to. It's seriously better than anything I've ever used and I've used alot (i'll list if you want).

Ok on to the images

This is the original grey_range that you said to create.

This is it run through the new version of image magick

This is the one run through the old version.

Pretty much the same

This is where things get cool.
Here's the color range that you wanted

Here's what the New Image magick did.

Here's what the old image magick did.


I'll admit I'm flummoxed, I have no idea why it makes photos look so dang good, it does a bit of leveling and white balance all in one. It's a great tool for sure.

So I'm clearly wrong, this was not a bug on the part of the new version. But man can we get that old version as a filter in the coming versions? Please?

[anthony]

The point is the old version should have been achieved by using a "-compose all -normalize" or the "-separate -normalize -combine" as described in IM examples.

The only other difference I can see is the 'lossy' aspect. The old one appears to be using a slightly smaller value than the new ones equivelent of "-color-stretch 1%"

Can you check the Q-level (convert -version) of both your old and new IM's. It may be related to that.

Hmmm I was able achieve the equivelent of the old Ubuntu standard IM 6.2.4-5 using

Code: Select all

convert testOrig.jpg -separate -contrast-stretch 0.2% -combine  x:

As such it may be that the current -normalize level of '1%' may be a little too high.

Again it is probably Q-level dependant as 1 unit quantum limit for a Q8 Im is about 0.4%
or '256' in a IM Q16

[likwidoxigen]

Wow I must say you guys amaze me with the kind of things that you can do.

Ok the Q version is both Q16. I did some testing on the high res images and Alot of one image then the other swapping and i found .05 or .07 to make it just about identical. The .2 looked perfect on the small image but on the high res it was a tad brighter. Great eye though.

Is there a quick explanation of the Q level around any place? If would you be ok with doing a quick overview of what it means? Like what does one unit quantum limit translate to?

Thanks!

Bryce

[likwidoxigen]

Damn it. I was a moron and compared the wrong sets of images. The ones done with the -separate -contrast-stretch 0.05% -combine come out with the right brightness but the files are coming out way too red. Do you have any idea as to what would be causing that or how to fix it? I'd really like it to be a setting to the -contrast-stretch and not something like a desat of the red it appears to be a varying amount of red that needs to be changed from image to image. I can't think of what would need to be tested as the test color range images come out damn near identical with out the bumped reds. It appears to be dependant upon the amount of red in the image...

Any suggestions?

[anthony]

That was why -normalize (and later -contrast-stretch) by default links the channels together except if channels are done separatally, or the special 'all' option is used. This was simular to a old bug we had for alpha channel with blur (blur did not like alpha channel with color so produced black halos about objects with transparency).

I suggest you check carefully what works and what does not then get back to us with your final result.

PS; don't feel bad, I have made an idiot out of bugs which I thought existsed but was just me doing something very stupid.