Legacy ImageMagick Discussions Archive

I think the title says it all ...

I do not know if it is already previewed or possible to incorporate the redist or similar "smart" histogramm function as an internal function of IM ...

Some moths ago I tried to put it to work in a windows "form" ...but with no sucess ...
I even tried to used Cygwin to call be able to call awk but still no sucess...

So I am asking if would be possible to add it as an internal function in IM ...

Any comments?

It is OK with me. I would be happy to work with the IM developers to get this folded in, if/when they have the time.

Fred

We'll take a look at integrating it this weekend. Should the option name be -redist?

magick wrote:We'll take a look at integrating it this weekend. Should the option name be -redist?

That is OK with me. Something like:

-redist shape brightness,low-contrast[,high-contrast]

or

-redist shape mean,low-sigma[,high-sigma]

( or -redistribute is OK, too). You can decide or see if Anthony has any input.

There are two current options for shape of distribution: Gaussian and Uniform. When uniform is used, there are no other arguments. The 3 other arguments are only for the Gaussian option.

If only one contrast/sigma value is supplied then use that for both. In my redist all values are in percent range 0-100 (or higher for contrast/sigma). I am not sure how you want to deal with the 3 values (i.e. if you want to use percents and/or raw graylevels or the usual sigma type values.) I will leave that to you. The sigma values are the percent graylevels that correspond to one-sigma on the gaussian distribution -- so they control the rate of roll-off or width in percent graylevel for the gaussian. The mean/brightness controls the percent graylevel corresponding to the center or peak of the gaussian distribution.

Uniform is the same as IM -equalize, except that in my redist it uses the global histogram. But it would be nice to have the new function be channel sensitive. That way it can use the global histogram or work channel by channel. I also have an option to use the Lightness/Brightness channel from HSL or HSB (or intensity channels from other colorspaces), but if that is too much, leave it off. The main thing is that it should do it globally or each channel separately (for RGB). If you decide only to do the Gaussian, then it would be nice to have -equalize be channel sensitive and allow one to work on the global histogram as well as the current channel-by-channel situation.

It would be nice to have the distribution/shape be modular, so that other distributions could be added later if desired. But if not, and you decide to only do the Gaussian, then it could be: -gaussian-redist or -gaussian-redistribute as below:

-gaussian-redistribute brightness,low-contrast[,high-contrast]

or

-gaussian-redistribute mean,low-sigma[,high-sigma]

( The 3 values are something like midtones,shadows,highlights)


In any case, if you want to use my nominal values (or some nominal values for the defaults --- I used 60,60,60), then all the arguments would be optional

Here is a synopsis of how it works.

It works by first converting the image to some color space, nominally HSL or
RGB. Then it computes a histogram for the image.
If the image is converted to other than RGB, then the grayscale will come
from an intensity-like channel. Otherwise, if the color space is RGB, the
RGB image is converted to a simple global grayscale image. The script then
generates the integral of the specified distribution scaled to the last
value in the image's cumulative histogram. For each value in the image's cumulative
histogram, it finds the closest value in the integral and then looks to see
what is its graylevel. It uses those graylevel values as the y-value in a
mapping transformation whose x-values range from 0-255. This mapping
transformation is expressed as a 1-D image and used with the IM function
-fx or -clut to transform the input image's values in each of its channels.
For the uniform distribution, it turns out that the cumulative histogram is
lookup transformation for -clut itself. So no integration is necessary.


See my page at http://www.fmwconcepts.com/imagemagick/redist.php and the script for more details. Feel free to contact me for further discussions.

Fred

P.S.

Another nice modification would allow the merging of my histmatch and redist scripts. Histmatch converts one image so that its histogram matches that of another image. This has been useful to me in a number of situations. Thus if there is an option for a second input image, its cumulative histogram could be used in place of the gaussian integral. If you decide to go that far, then I would definitely use the name as -redist or -redistribute (leaving off potentially the -gaussian part).

Fred

magick wrote:We'll take a look at integrating it this weekend. Should the option name be -redist?

I was preparing a -histogram type set of options This probably should be something like -histogram Gaussian
With -equalize rolled in to form -histogram Uniform

This was what I wanting the "histogram.c" module for, but it seems to have been taken over with other functions.
It is also why the sub-function of -auto-level is in "histogram.c" as it was to be part of that suit of operators.
I just never got back to it ;-(

This probably should be something like -histogram Gaussian
With -equalize rolled in to form -histogram Uniform

That naming convention would work but appears to me to be a bit misleading as one is not generating a gaussian histogram graph, but actually changing the histogram of the image. The process is one of redistribution of graylevels although it is done by a a lookup table generated from the integral of the gaussian and the cumulative histogram of the image.

However, I think Anthony's point is that he would like to see a more modular set of histogram utilities that could be used elsewhere. This might include generating a simple histogram and generating a cumulative one (both of which should be channel sensitive). Anthony, correct me if I am wrong about this latter issue.

That is what I am thinking. More moduluar use of options, collecting and depreciating a lot of the mess of options that currently exist

The -histogram option in this case was for any histogram modifying or extraction functions.

I do not envisage these generating any form of graph. At least not directly. However extracting the histogram data, or cumulative data as a linear LUT image would be a posiblity. That is a image of given length, where pixel 0,0 has a count of all black values (red,green,blue etc), pixel 0,1 a count of all values in the next bin etc.

This can be either saved, printed (TXT:), used as a LUT, or converted to a graph by a future 'profile graphing' operator.
I want that as a separate operation (with various options) as a graphing output would be a useful addition in and of itself.
(Graphing -function output, LUT's or sections through images, in either X or Y directions.

This can all eventually replace the old, hard to use "Histogram:" Coder.


In any case that is what I see happening.

Sorry for being a bit blunt but
what is the Status of the initial post ?

I believe that it may have been delayed for IM 7, which is under development right now. I don't know the ETA for the alpha thought.