Lighten or Darken pixel selection by Color Intensity

[anthony]

The Intensity variants of Lighten and Darken as now been added to the SVN, and will be published in IM v6.6.9-5

Examples of its use are in IM Usage (which takes longer to update than the actual coding).
http://www.imagemagick.org/Usage/compos ... _intensity

It has two modes of operation, a default 'alpha-weighted intensity' whole pixel selection mode,
or a 'no-weighting' mode but allowing you to just transfer specific (or 'ALL') channels.

That second mode makes it relatively easy to generate a 'shaped mask' using alpha channel coping, if a mask is all you want.

You could even use it as a funny type of "Select this alpha on this, otherwise select that alpha" type of selection.

I am still looking for a more formal definition of "Lighten by Intensity", as it is not covered by the normal SVG or Photoshop definitions I use for composition methods.

[NicolasRobidoux]

Would you be satisfied with

Define intensity as the pixel value in greyscale. Lightening consists in selecting the (full colour) pixel value of the second image if its intensity is strictly larger than the intensity in the first image. Darkening consists in selecting the (full colour) pixel value of the second image if it is strictly smaller than the intensity of the first image.

?
As discussed in the Digital Image Processing Forum, this breaks the symmetry w.r.t. to the two input images, but it does not introduce any new colours.

The obvious alternative is

Define intensity as the pixel value in greyscale. Lightening consists in selecting the (full colour) pixel value of the first image if its intensity is strictly larger than the intensity in the second image, selecting the (full colour) pixel value of the first image if its intensity is strictly smaller than the intensity in the second image, and otherwise (if the intensity is the same for both images) averaging the pixel values. Darkening is defined by interchanging smaller and larger in the above.

This preserves the symmetry w.r.t. the two input images, but introduces new colours (pixel averages of the two images). IMHO the first definition is probably more useful.

[anthony]

Sorry to miss-lead you Nicholas, I did not mean a actual 'scientific definition' but a previously implemented 'algorithmic definition' of the function, specifically in how it should handle ALPHA values.

An example of such definitions is this one for Photohop
http://www.simplefilter.de/en/basics/mixmods.html
Or this on for Pegtop Lighting composition
http://www.pegtop.net/delphi/articles/b ... tlight.htm
though these are also incomplete as they do not detail alpha channel handling.

In this case I followed the SVG specification that details how to do the alpha blending needed for any by-value mathematical formula. The document essentially specifies that all non-duff-porter or Plus composition is to use 'Over' alpha blending. And that is what I have done.

However SVG defintions would not apply for Lighten by Intensity, and I have no guide on alpha handling in that case, so I made an educated guess.

Basically the question is how to compare something like 'half-transparent white' or 'half-transparent black' verses say 'Opaque Gray' and get appropriate handling of alpha with 'shaped images' in the composition results.

[anthony]

Subject: halo minimization by local min/max smooth clampingIf you don't want to add any new colour, you cannot have that the operation does not depend on the order of the input images, because resolving ties (same "greyscale" intensity in both images at some pixel) cannot be resolved symmetrically.

Solution 1: If there is a tie, you take the average of the two pixel values. This, of course, will introduce new colours.

Solution 2: If there is a tie, you always pick the pixel value from the first input image. This will not introduce new colours, but it will break the symmetry w.r.t. the two inputs.

I am using solution 2. Even though it means darken and lighten is not exact opposites over which pixel to select (masks are not pure negatives). Though any such tie is unlikely in the extreme.

Intensity is not a simple average of the three RGB color channels, but a weighted ratio.
The exact formula being used is...
0.299*red + 0.587*green + 0.114*blue
It would be very very rare to find any two different colors that have the same intensity!
As such the equality condition is practically non-existent.

Also as you are more likely to be using this with images containing very similar colors, I doubt this would be much of an issue.

[fmw42]

Intensity is not a simple average of the three RGB color channels, but a weighted ratio.
The exact formula being used is...
0.299*red + 0.587*green + 0.114*blue

I don't believe that I can find any exact formula for intensity. Mostly it is luminance -- i.e. the intensity-like channel of various colorspaces.

So the above is only one choice, namely from the following:

Rec609Luma, YCbCr, YIQ, YUV, YPbPr and Gray all use Y=0.299000*R+0.587000*G+0.114000*B

But...
Rec709Luma uses 0.21260*R+0.71520*G+0.07220*B

And...
OHTA uses 0.33333*R+0.33334*G+0.33333*B (simple average)

I am not sure if the above luma components are gamma-corrected (rgb values) in IM or not. But if the name is luma, then according to Wikepedia, they may very well be.

Luminance would not be gamma-corrected according to Wikipedia.

see http://en.wikipedia.org/wiki/Luma_(video)

see http://www.imagemagick.org/script/comma ... colorspace

[NicolasRobidoux]

0.299*red + 0.587*green + 0.114*blue seems to be the most common.

[fmw42]

0.299*red + 0.587*green + 0.114*blue seems to be the most common.

Right (as seen above). Just suggesting there are a few other variants and no unique definition of intensity. In fact, Lightness and Brightess are two other variants. However, I would agree that going with the most common is the best approach.

[NicolasRobidoux]

The "common" variant has one big "fan" in its corner: JPEG compression.

[NicolasRobidoux]

http://en.wikipedia.org/wiki/Luminous_intensity

[anthony]

Suggesting there are a few other variants and no unique definition of intensity.

It is possible that a special 'intensity-type' flag, could be introduced to select from a number of different formulas.
For example...

Code: Select all

  Intensity     -- see grayscale formual above -- also called Luminance
  Luminosity    -- the RGB average EG:  (r+g+b)/3
  Rec709Luma  -- see formula from Rec709Luma above
  Brightness     -- from HSB brightness, or negated CMYK black  EG: MAX(r,g,b)
  Lightness    -- from HSL, or (MAX(r,g,b)-MIN(r,g,b))/2

The above has been edited as more information comes to light

This is probably best to be a special pre-parsed image 'attribute' rather than a -define.
-intensity-formula or -set intensity-formula

This setting can also be used in a lot of other places, such as, CopyOpacity (when alpha in source is turned off), CopyBlack (when source image contains not black channel), -combine, -alpha Copy and -alpha shape, -morphology Intensity methods, greyscale LUT involving alpha values. and quite a few other places.

Should it effect a -colorspace Gray option? -- if defined?


Also for an odd ball use of this 'expert' setting, we could even just specify a specific channel as being the 'intensity'
value.
Red, Green, Blue, Alpha

NOTE that at the moment the Lighten_Intensity does not understand non-RGB images.

This lets you use one channel of a greyscale image for speed.

OR in Lighten_Intensity, you can then use just one channel to select values from another channels.
For example: compare alpha channels, to select color in final image!

I already have an example of using color channels to select alpha values!
See last example in...
http://www.imagemagick.org/Usage/compos ... _intensity

[fmw42]

Allowing IM to use different "Intensity/Gray/Luminosity" channels for various statistical things makes sense to me as a future enhancement. For example, consider my redist script, which lets the use select which intensity-like channel is used to generate the cumulative histogram, which of course allows one to also use the global histogram from all 3 RGB channels. The same could be said for -equalize or perhaps even -contrast-stretch or -linear-stretch or even -level and such things that work off the histogram. However, in my opinion, this is a bit less important than allowing those same functions to be channel sensitive for rgb (separate operation) vs the global rgb operation (equally on each channel). I believe with your (Anthony) existing modification many of these are already channel sensitive.

[NicolasRobidoux]

Anthony:

Your suggested enhancements make a lot of sense.

[anthony]

Implementation may be harder as current intensity is currently a simple inline function (specifically MagickPixelIntensity(pixel)) without any external references to allow access to what 'method' to use.

It would need a new addition to the image structure (or cache structure), and a function to do the conversion from pixel value to greyscale value, that looks up the 'method' and applies the right formula.

[NicolasRobidoux]

Implementation may be harder...

Sounds like a back burner to me (until somebody REALLY needs this).

[anthony]

I could add it immediately using a -define Intensity=??? method BUT will only be able to apply it to specific Composition methods (perhaps even it the Moprhology Intensity method). Without it being an Image/Cache attribute, I could not make it more general. (EG: -colorspace, Gray).

Let me think about it some more. I have also requested direction from Cristy.