Lighten or Darken pixel selection by Color Intensity

[magick]

We will fork ImageMagick 7.0 within the next two weeks. We recommend adding the selection of grayscale methods to 7.0 as part of the design instead of adding it to ImageMagick 6 series where it won't integrate as smoothly.

[NicolasRobidoux]

Maybe doing various things based on the "luminosity" is more common than I thought.

According to http://www.xs4all.nl/~bvdwolf/main/foto ... ample1.htm, using USM only on the "luminosity" channel is sometimes recommended (and can be done easily with PS). Another example: http://www.controlledvocabulary.com/ima ... pling.html.

Apparently, this is also done with GIMP: http://gimpguru.org/Tutorials/SmartSharpening2/

(Apologies if I'm suggesting features already in IM.)

[NicolasRobidoux]

... and of course http://imagemagick.org/discourse-server ... =1&t=10266.

[fmw42]

I could build a script to do smart sharpening. It is not too much different from some of my other edge sharpening scripts. However, I would imaging that almost any histogram operation, or other contrast/brightness type operations or blurring or sharpening operations could be done simply on one of the intensity like channels of some other colorspace, then combine the processed intensity channel with the other channels from that colorspace to get the result. This of course can be done now with a short script or longer command line. But it might be nice to be able to do such in a more compact method.

But I think we need to let the developers get the basics done before we bombard them with new features and enhancement requests.

[NicolasRobidoux]

But I think we need to let the developers get the basics done before we bombard them with new features and enhancement requests.

Agreed. Above, I was just mollifying my statement that applying operations to just the "luminosity" is "unusual." It's not.

[fmw42]

But I think we need to let the developers get the basics done before we bombard them with new features and enhancement requests.

Agreed. Above, I was just mollifying my statement that applying operations to just the "luminosity" is "unusual." It's not.

I would agree that there are lots of applications for working only on an "intensity-like" channel of some colorspace rather than all 3 RGB independently that will produce interesting and possibly better results.

[anthony]

However just applying the Lighten to just the intensity channel does not always work.
That is what 'Lighten' can do.

At the moment the 'LightenIntensity' only works with RGB images. For a HSL image it will need some smarts to figure out that it should only use the Lightness (Blue) channel of the image for the determination of where the whole pixel should be copied from. You can restrict the channels it copies using -channel, but at the moment you can not specify how it should calculate 'intensity'.

[NicolasRobidoux]

So, this should be done by "manually" separating the colors etc (like in Fred's scripts) and no special command/option should be given?

I'm OK with that.

[fmw42]

For a HSL image it will need some smarts to figure out that it should only use the Lightness (Blue) channel of the image for the determination of where the whole pixel should be copied from. You can restrict the channels it copies using -channel, but at the moment you can not specify how it should calculate 'intensity'.

In principle, a table of what intensity-like channel could be set up to for each relevant colorspace so that that channel could be processed. Just a thought. It would be a neat addition to IM 7, but probably low priority.

[anthony]

For a HSL image it will need some smarts to figure out that it should only use the Lightness (Blue) channel of the image for the determination of where the whole pixel should be copied from. You can restrict the channels it copies using -channel, but at the moment you can not specify how it should calculate 'intensity'.

In principle, a table of what intensity-like channel could be set up to for each relevant colorspace so that that channel could be processed. Just a thought. It would be a neat addition to IM 7, but probably low priority.

Actually this is the case with almost all usage of intensity, in all the functions I have previously mentioned. EG: -combine, -compose CopyOpacity (no alpha channel set), -clut (channel set to copy alpha, but no alpha in one of the images) and so on.

Using a lookup table is not straight forward. For example the 'L' channel in HSL for example is NOT intensity (though seems like it) it is average of RGB max and min. HSB is just minimum of RGB. and so on. Ideally if 'intensity' is wanted, intensity will be calculated as appropriate from the color.

ASIDE: when I said setting intensity to 'red' what I really mean was to the 'normaly red channel', not calculated red color

IM v7 may need a little more color smarts (with user control) about this.

[fmw42]

Using a lookup table is not straight forward. For example the 'L' channel in HSL for example is NOT intensity (though seems like it) it is average of RGB max and min. HSB is just minimum of RGB. and so on. Ideally if 'intensity' is wanted, intensity will be calculated as appropriate from the color.

But HSL and HSB (L and B) are "intensity-like" in their respective colorspaces (though computed from a subset of R,G,B). I found them useful for processing in many of my scripts to avoid color shifts from processing each channel separately or to give slightly different results from the global histogram. In other scripts I allow the histogram to be computed from any intensity-like channel including L or B. So the usefulness of using any intensity-like channel has been proven. Making IM 7 more intelligent about such channel processing would be nice, but as it can be done currently by separating channels and then recombining, it is not urgent in my situations. Just a thought following on Nicolas and your conversations about such things.

Actually a lookup table is not even necessary as long as there is some way (-set or -define or argument) to tell a function what channel of what colorspace to use (and the function is made sensitive to that kind of option).

However, there are much more important other improvements that I am sure you guys are working on that have no current way to do them.