Legacy ImageMagick Discussions Archive

Hello.

I try to write perl script that is analogue to:

convert rose: -channel RB -fx 0 channel_red.gif

When I try to use $img->Fx() there is no effect,
and when I use img->Mogrify( 'fx', ... ) I get
Exception 410: unrecognized PerlMagick method `fx' @ Magick.xs/XS_Image__Magick_Mogrify/6497

Please, advise.

And one more question.

Here is original picture


And here is what I get when doing in perl
$img->Modulate( brightness => '85');



And the same result I get when executing analogue for convert:
convert -modulate 85 bride.jpg bride2.jpg

This problem concerns only white color.

Any comments?

Thank you in advance.

p.s
I use ImageMagick 6.4.5

use $image->Fx() rather than $image->Modify('Fx',...).

Code: Select all

convert rose: -channel RB -fx 0 channel_red.gif

note that that outputs a 'green channel' not the red channel!

Alternatives include the FASTER miss use of -gamma (0= set to 0; 1 = leave alone; -1 = set to 1 ) Colorize specific channels to black
convert rose: -fill black -colorize 100%,0,100% channel_green.gif

use of separate and combine! Using threshold to set to zero Multiplying by an approprite color will do it too!
convert rose: \( +clone +level-colors lime \) \
-compose multiply -composite channel_green.gif[/code]

And probably many many many other methods too!


See http://www.imagemagick.org/Usage/channels/#zeroing

Thank you for such detailed response!

I use this perl code
my $res = $img->Threshold( channel => 'Red', threshold => '101%');
my $res = $img->Threshold( channel => 'Blue', threshold => '101%');

and it works fine.

Does anybody have suggestions about brightness?
This is very odd problem, but it really exists.

You should be able to threshold BOTH channels in the one operation.

It tried this
$img->Threshold( channel => 'GB', threshold => '101%');
and it also works!

Anthony, may be you have any thoughts about brightness?
It is very annoying problem. Did you every see anything similar?

What I recommend is to convert the image into HSB or HSL before doing the task. One will do as before, the other shouldn't.

Otherwise try using -level instead for brightness adjustments.

What ever you find let us know what worked for you.

The problem with the near-white colours is an artifact of the HSL colourspace. While reading up on HSL I found a comment here which says that changing the brightness/lightness of near-white colours in the HSL colourspace causes problems.
To see why, you can use one of the online HSL <-> RGB converters (for example, this one).
Pure white is RGB(255,255,255). This is HSL(0,0,100). Reducing the brightness by 50% (for example) gives HSL(0,0,50). Converting back to RGB we get RGB(128,128,128) which is essentially what you'd expect after cutting the brightness in half.
But now lets use RGB(254,255,255) which is very close to white. It is HSL(180,100,100) which, when the lightness is reduced, becomes HSL(180,100,50).
Converting that back gives RGB(0,255,255) which is not even close to RGB(128,128,128) as we would expect it to be. This is why the near-whites of the limousine and the image's border are so badly affected by the modulate.

To show the difference in using HSL and HSB colourspaces I wrote a program which uses the original image from this thread and reduces the brightness/lightness by 50% in both the HSL and HSB colourspaces and writes the results to two separate files. (The program will be added to my MagickWand examples)
This is the HSL result and this is the HSB result.

Obviously, the HSB result is what we would expect, and prefer, when reducing the brightness of an image but I don't know how you would do this from the command line.

Pete

I don't know how you would do this from the command line

Inspiration struck me after reading Anthony's examples of colour space http://www.imagemagick.org/Usage/channels/#channels Pete

I have made notes about this 'off-white' color problem in IM Examples on -modulate
http://www.imagemagick.org/Usage/color/#modulate


I am just wondering if -modulate should be changed to do its work in HSB colorspace rather than HSL. This should be an easy change.

Does anyone see a downside to this?

In my own experiments, I found that the modulate problem does not seem to be as big if JPEG was not involved.

That is if you reduced your original JPEG image to the working size but did NOT save it to JPEG format (PNG or MIFF instead).

Further if you kept the working image in memory, or only use MIFF file format for intermediate work (16 bit quality, rather than 8bit) while continuing to work on it you get a better color resolution for modulate to work with, and the exaggeration of colorspace is not so great. They is not enlarging a 1 or 2 unit value differences.

The moral of this is... Always start with the original, and do all your processing in one command. If you must save, save to MIFF intermediate images which preserves the high intermediate quality level of the image being processed.

anthony wrote:I have made notes about this 'off-white' color problem in IM Examples on -modulate
http://www.imagemagick.org/Usage/color/#modulate


I am just wondering if -modulate should be changed to do its work in HSB colorspace rather than HSL. This should be an easy change.

Does anyone see a downside to this?

Only issue is backward compatibility for any one's scripts. But HSB might work better for -modulate. One would need to test if other issue arise. Generally one will not get the exact same results using HSB compared to HSL in a -modulate function. But the issue near white is avoided by using HSB.

The issue that is being discussed has to do with the difference between the HSB (hexcone model) and HSL (double hexcone model).

In HSB, we have a single cone model. Imagine the peak of the cone at the bottom (black) and the top (widest end) of the cone at the top (white). Height along the axis represent intensity (brightness). Angle around the cone represents hue and distance from the axis to the some place within the cone represent saturation. At the top, one has max brightness and max range of saturation and easily distinguishable hue. But at the bottom, near black, one has little saturation and hue becomes nearly indeterminant.

In HSL, we have two cones placed widest end together. Thus in the double cone, the widest part is at the middle or mid-gray, where saturation has the widest range and hue values is easily separated. But at the bottom (black) and now at the top (white), saturation becomes near zero and hues become nearly indeterminant.

Thus for colors near white, separability is better when using HSB rather than HSL. Both will have the same problem at near black.

For general use, HSL is a better model to represent colors. It is closest to the color cube turned so that its major diagonal is vertical, i.e. vertex to diagonal vertex is oriented vertically. Then the shape of the color cube is similar to the double hexcone. However, the limitation color separation for the double hexcone near white is its main issue.

anthony wrote:I have made notes about this 'off-white' color problem in IM Examples on -modulate
http://www.imagemagick.org/Usage/color/#modulate


I am just wondering if -modulate should be changed to do its work in HSB colorspace rather than HSL. This should be an easy change.

Does anyone see a downside to this?

Why not just make two functions? -modulate2 H,S,B

or change the argument processing somewhat like -distort so that you can specify

-modulate HSL h,s,l or -modulate HSB h,s,b

or

-modulate lightness h,s,l or -modulate brightness h,s,b

If that is possible. Or just create a new name, say, -modulation h,s,b