Legacy ImageMagick Discussions Archive

Hi everybody,

I would like to change the color of several images to grayscale. However, simple grayscale conversion is not suitable in my case because i want to convert scientific images with scalar bar from blue to red. So the red and blue all become black.

I managed to do it with photoshop by changing HSV values for RGB and CMY.
I tried several thing with the option recolor:
convert test.png -recolor ".1 .2 .7 0.9 0.1 0 0 0 1" res.png

but can not figure out what should be the good combination of parameters.
I also tried to separate channel to play on the alpha without success.
To you have any tip ?
Here is a source image
and what i should have
Here is a source image

Thanks in advance.
Lo

try this

convert test.png -fill "rgb(255,0,255)" -opaque white -colorspace HSB -channel r -separate +channel -auto-level test_gray.png

Hi fmw42,

Thanks for the hint, it is perfect.

One remark, with image magick 6.4.0 (cygwin), -auto-tone is not recognized and the white becomes gray
However, with a new version, it is perfect.

This is without auto-tone.



Laurent

I guess that you mean "-auto-level" instead of "-auto-tone" (?). Fred's code works perfectly on my Windows computer in a simple cmd box. You don't have to use Cygwin for such simple commands (see link below). Just make sure that Convert is not mistaken for the homonymous Windows command.

@Anthony: You should include this example in the Usage section (if you haven't done so already), because this is a common problem in scientific publictaions. I have seen more than one false colour image becoming totally illegible by the standard conversion to grayscale.

Perhaps -- but where should I put it?


The reverse of this 'coloring scientific image data' perhaps just as an array of values, can be just a tricky. It was something that I dealt with for some one else. In his case weather maps of 'frost levels',
where the grid needed to be expanded and controur colors added for very strict value ranges.

The solution is to use covert the grid data into an image, and resize to produce a greyscale gradient map. The grayscale values was then used to lookup a color table (CLUT) to find the appropriate color for those values. You do not want interpolation (mixing of two colors in small CLUT images) so you would turn off -interpolation setting using 'integer' or 'nearest' (latest IM shorthand for 'nearest_neighbor' interpolation.

See CLUT coloring grayscale...
http://www.imagemagick.org/Usage/color_mods/#clut

For scientific images it is important to keep a track of how values are converted and looked up. especially in the 'limits'. So some testing is a good idea.

For this case however it is not critical as you have limited number of grey values to map.

Another similar example was using a CLUT to lookup the new pixel value using the results of a 'neighbour counting' transformation. The specific example was a implementation of a 'conways life' Cellular Automation.
http://www.imagemagick.org/Usage/convolve/#life

One remark, with image magick 6.4.0 (cygwin), -auto-tone is not recognized and the white becomes gray
However, with a new version, it is perfect.

-auto-level was only introduced at IM 6.5.5-1

However it can be duplicated by getting the min and max statistics for the image from the verbose info (or using string formats http://www.imagemagick.org/script/escape.php) and then using those values in -level.

anthony wrote:Perhaps -- but where should I put it?

I would expect it under http://www.imagemagick.org/Usage/color_mods/#grayscale, under a subheading like "False color images". The point is that the information is often coded in the hue. This is the case for numeric simulations of pressure distributions (like we seem to deal with over here), but also for infrared images. Thus we would basically like to convert the hue into grayscale information -- how can this be done? Moreover, some special color, typically white, often represents some other information, like the contour over here, so what to do about that? Fred's command line gives a good example.

One should mention that often only a partial range of the possible hue values is used, stretching from red to blue, corresponding to ... -- well, to what exactly? And that "-auto-level" provides an easy way to stretch the greyscale gradient from 0 -- 255.

Fred wrote:-auto-level was only introduced at IM 6.5.5-1

I didn't understand the original remark, because it didn't mention what "version" it referred to -- could as well have been Cygwin, and mentioning "-auto-tone" instead of "-auto-level" didn't quite help understanding ...

Hi yes i made a mistake it is not -auto-tone but -auto-level that is not working with cygwin because of the imagemagick version.
lo

Hi all,

It is strange, but it seems to not work in all cases.

Look at these pictures (coming also from VTK):



and:



It is also the same for images coming from Matlab, the white background is not preserved




Basically, what i do is:

eps -> pdf
pdf -> png
png (color) -> png grayscale.

When the eps is a 3D eps, i generally use a non vectorial image embedded inside an eps unless i have problems at printing the image because it is so large (like in this conrod example)

Do you have any hint to solve the problem in this case. It is strange because i works very with the first example given in this thread forum

The issue with converting hue to grayscale is that red becomes black, but so does any gray in the image. That is that gray (from black to white) is indeterminant in the usual HSL and HSB transformation when looking just a hue. Usually gray is then coded as black same as red. So one needs to convert gray to some other shade before doing the auto-level. In the first example, I found that magenta worked for reasonable color before converting to HSB, so that after auto-level it would stretch appropriately to match the given colors. So I am not surprised that it is image specific. Gray masking is needed to preserve the white background and the black lettering.

Here is a modified algorithm. It uses the H,S and B channels to do the masking. But the S and B channels need to be properly thresholded to avoid white artifacts and get the graph ticks and step wedge to show and that is still image dependent. You need to look at the HSB channels to see how to threshold them.

This is the basic algorithm


infile="3D_conrod_iso.png"
hueshift=XX # shift the hue towards red, if red is bluish-red and not yellowish-red; otherwise red turns to white and not black
satthresh=XX # S threshold
brithresh=XX # B threshold
inname=`convert $infile -format "%t" info:`
hueval=$((100+hueshift))
# first line -- modulate to shift hue if needed and convert and separate HSB channels
# second line -- threshold the S channel and negate for masking to preserve the white background
# third line -- composite the H channel with the thresholded and negated S channel
# fourth line --threshold the B channel
# fifth line -- delete the tmp files and composite the previous composite with the thresholded B channel
convert $infile -modulate 100,100,$hueval -colorspace HSB -separate +channel \
\( -clone 1 -threshold $satthresh% -negate \) \
\( -clone 0 -clone 3 -clone 3 -compose over -composite \) \
\( -clone 2 -threshold $brithresh% \) \
-delete 0-3 -compose multiply -composite \
${inname}_gray.png



Here are the 3 test image results:


infile="test.png"
hueshift=0
satthresh=80
brithresh=93
inname=`convert $infile -format "%t" info:`
hueval=$((100+hueshift))
convert $infile -modulate 100,100,$hueval -colorspace HSB -separate +channel \
\( -clone 1 -threshold $satthresh% -negate \) \
\( -clone 0 -clone 3 -clone 3 -compose over -composite \) \
\( -clone 2 -threshold $brithresh% \) \
-delete 0-3 -compose multiply -composite \
${inname}_gray.png





infile="cone_ls2.png"
hueshift=0
satthresh=15
brithresh=85
inname=`convert $infile -format "%t" info:`
hueval=$((100+hueshift))
convert $infile -modulate 100,100,$hueval -colorspace HSB -separate +channel \
\( -clone 1 -threshold $satthresh% -negate \) \
\( -clone 0 -clone 3 -clone 3 -compose over -composite \) \
\( -clone 2 -threshold $brithresh% \) \
-delete 0-3 -compose multiply -composite \
${inname}_gray.png





infile="3D_conrod_iso.png"
hueshift=3
satthresh=10
brithresh=50
inname=`convert $infile -format "%t" info:`
hueval=$((100+hueshift))
convert $infile -modulate 100,100,$hueval -colorspace HSB -separate +channel \
\( -clone 1 -threshold $satthresh% -negate \) \
\( -clone 0 -clone 3 -clone 3 -compose over -composite \) \
\( -clone 2 -threshold $brithresh% \) \
-delete 0-3 -compose multiply -composite \
${inname}_gray.png

That last did not seem to work quite right. Some black areas on the are blue hues. not red hues.

The cause is really that red in Hue spaces can be either black or white. A Hue shift (modulate, or modulas add in hues can shift that discontinuity to some other hue such as purples which is obviously a more 'natural' division point in these false color images.

Purple for example does not actually match to a single wave light of light but is always a mix of at least two wavelengths that our eyes interpret as 'purple'.

Hi,

How do you explain that it works very well for the first image (fillet - sigma_x) and not for the last whereas they both comes from VTK with the same scalar bar color range ?

However, the first comes from VTK->eps->pdf (vectorial) -> png
Whereas, the second comes from VTK->png

Laurent

The issue with converting hue to grayscale is that red becomes black, but so does any gray in the image. That is that gray (from black to white) is indeterminant in the usual HSL and HSB transformation when looking just a hue. Usually gray is then coded as black same as red. So one needs to convert gray to some other shade before doing the auto-level. In the first example, I found that magenta worked for reasonable color before converting to HSB, so that after auto-level it would stretch appropriately to match the given colors. So I am not surprised that it is image specific. Gray masking is needed to preserve the white background and the black lettering.

So see my modified version above. It is still image dependent with regard to the masking.

All your graphs do not use the same coloring scheme. In the first example, red was on the yellow side. In your last example red was more on the blue side. In the first case, that shade of red becomes black in HSB, but in the last example that shade of red becomes white in HSB. Hue is cyclical and the transition is at pure red. See my colorwheel at http://www.fmwconcepts.com/imagemagick/huemap/index.php

That last did not seem to work quite right. Some black areas on the are blue hues. not red hues.

That is because the blue shades are almost gray and so end up black. Also the B channel thresholding is not perfect. I have to include some of that black in order to get the numbers at the bottom to show. It is a thresholding issue.