Legacy ImageMagick Discussions Archive

Hi, I use convert in my gpl'ed program http://www.forkosh.com/mathtex.html which runs latex on a user-supplied math expression to produce a .dvi file, and then has several options to produce browser-displayable images. One option first runs dvips to get .dvi-->.ps, and then runs convert to get either .ps-->.gif or .ps-->.png (user's choice, defaults to .gif). The convert command line that's used is

convert -density 120 -gamma 0.5 -trim -transparent "#FFFFFF" dvips.ps convert.gif
(or convert.png for that last argument, depending on which image format is desired)

The problem is that I'm getting exactly the same convert.gif (or .png), byte-for-byte (files diff with no differences), regardless of the -gamma value on the command line. Pngs are always a bit darker than gifs, but all pngs are the same and all gifs are the same regardless of -gamma. And I'd like to be able to specify the gamma correction. I can provide sample .ps/.gif/.png/.whatever-you'd-like output.

When I first released mathtex in early 2007, I'm sure -gamma did work. And I haven't changed convert's command line since then. So I'm (wildly) guessing that some new release of convert may have affected its -gamma behavior, at least with respect to postscript input images. Can't find anything that I seem to be doing wrong, but, of course, that would be the easiest thing to fix.

Thanks for any suggestions,
John Forkosh

try putting the input image before the operators

convert -density 120 dvips.ps -gamma 0.5 -trim -transparent "#FFFFFF" convert.gif

fmw42 wrote:try putting the input image before the operators

convert -density 120 dvips.ps -gamma 0.5 -trim -transparent "#FFFFFF" convert.gif

Thanks for the suggestion, but it doesn't seem to have any effect, neither exactly as you suggested, nor several other argument permutations I tried.

Here's a sample .ps input file at
http://www.forkosh.com/dvips.ps

and exactly the output from the above convert command at
http://www.forkosh.com/convert.gif

and substituting convert.png for the last argument we get
http://www.forkosh.com/convert.png

I'm saying that if you download that dvips.ps file, then any convert command you run against it, like the one above but changing only the -gamma value, will create an output .gif or .png that's byte-for-byte identical (will diff with no differences) to the ones on my site.

Of course, I'm hoping that I'm somehow wrong about that, but I haven't been able to figure out what I might be doing wrong or how it might be corrected.

Thanks again,
John Forkosh

Since the -gamma switch used to work, I figured the problem is either in some newer version of dvips or some newer version of convert. As it turns out, a current .ps file run against an ImageMagick version 6.2.9 convert does work with the -gamma switch. So there appears to be some problem with -gamma, running against .ps files, introduced between 6.2.9 and current.

Let me emphasize the "running against .ps files" part. I also tried first running a .ps file through ps2pdf to create a .pdf version of the same file. Then, running that .pdf through convert to create a .gif, the -gamma switch worked fine with the current version of convert.

So there seems to be some minor convert bug that somebody might want to look at. But meanwhile, my own problem could be solved by reverting to ImageMagick version 6.2.9. Unfortunately, only the netbsd binary version of 6.2.9 was available to me. I need it for an intel linux box, but couldn't google an existing copy of that source. Could someone point me to an archive that goes back that far? Thanks a lot,
John

I tried it with your "dvips.ps" file and checked output...

Code: Select all

convert -density 120 dvips.ps -gamma 0.5 -trim -transparent "#FFFFFF" gamma_0.5.gif
convert gamma_0.5.gif -unique-colors txt:

output was only two colors... Black and None. as gamma does not effect either color in any appreciable way, it is not suprizing you get no difference!

Remember you image is producing transparency, but GIF does not save semi-transparency!!! Lets avoid the transparency...

Code: Select all

convert -density 120 -background white dvips.ps -gamma 0.5 -trim gamma_0.5.png
convert gamma_0.5.png -unique-colors txt:

That has lots of colors, but is still mostly black and white!

Lets anti-alias the output a bit!

Code: Select all

convert -density 480 -background white dvips.ps -resample 120 -gamma 0.5 -trim gamma_0.5.png
convert -density 480 -background white dvips.ps -resample 120 -gamma 1.5 -trim gamma_1.5.png

Now that has a goo range of colors.

However your are right in that I do not find any color differences!!!!

I should now at least see some differences in the grey-level colors!!!!
Even switching to using -level to do the gamma (different implementation)
does not help. EG; -gamma 0.5 -> -level 0,100%,0.5

Sorry I have no idea why gray levels are not being modified.

I have sent a message to the primary developer for input on this problem.

There are no gray levels in the dvips.ps image. Instead it appears to have gray levels because of the range of alpha values associated with each black pixel. By default, the alpha channel is not considered by -gamma. Therefore, each pixel value is just black, and a gamma of black is always black. If you associate the alpha values with the color, you would then get levels of gray color and -gamma works as expected.

There are gray levels if -background white is used!
And that is what my final tests (that also failed) was using.

Where are these gray levels you speak of? We seem to have a bunch of black with various alpha values and bunch of white.

Code: Select all

convert -density 480 -background white dvips.ps dvips.png
identify -verbose dvips.png
  Histogram:
      3402: (    0,    0,    0,65535) #000000000000 black
       351: (    0,    0,    0,43690) #000000000000AAAA rgba(0,0,0,0.666667)
       111: (    0,    0,    0,21845) #0000000000005555 rgba(0,0,0,0.333333)
        77: (    0,    0,    0,34952) #0000000000008888 rgba(0,0,0,0.533333)
        72: (    0,    0,    0, 4369) #0000000000001111 rgba(0,0,0,0.0666667)
        69: (    0,    0,    0,52428) #000000000000CCCC rgba(0,0,0,0.8)
        57: (    0,    0,    0,48059) #000000000000BBBB rgba(0,0,0,0.733333)
        52: (    0,    0,    0,13107) #0000000000003333 rgba(0,0,0,0.2)
        50: (    0,    0,    0,26214) #0000000000006666 rgba(0,0,0,0.4)
        45: (    0,    0,    0,17476) #0000000000004444 rgba(0,0,0,0.266667)
        42: (    0,    0,    0,56797) #000000000000DDDD rgba(0,0,0,0.866667)
        41: (    0,    0,    0,61166) #000000000000EEEE rgba(0,0,0,0.933333)
        36: (    0,    0,    0,39321) #0000000000009999 rgba(0,0,0,0.6)
        35: (    0,    0,    0, 8738) #0000000000002222 rgba(0,0,0,0.133333)
        32: (    0,    0,    0,30583) #0000000000007777 rgba(0,0,0,0.466667)
     47428: (65535,65535,65535,    0) #FFFFFFFFFFFF0000 rgba(255,255,255,0)

Strange. I was getting greylevels before, now I'm not. Of course if there is no gray levels -gamma does not effect things.

However getting back to the original problem.....

You can effect the 'gamma' of the alpha channel by using
-channel A -level 0,100%,0.5 +channel

that is THIS does what I assume you want.. Make the image darker looking...

Code: Select all

convert -density 480 -background white dvips.ps -resample 120 \
           -channel A -level 0,100%,0.5 +channel -trim   equation_darker.png

WARNING: if you use -gamma with alpha the effect is reversed due to the internal arrangement of how transparency is stored in ImageMagick.

Thanks Anthony, Site Admin, and fmw42.

My understanding of gamma correction is explained at
http://www.forkosh.com/mathtex.html?gammadirective
Consider a grayscale from x=0 for black to x=1 for white. Then, the canonical formula to apply gamma correction is x-->x^{1/gamma}, whereby gamma<1 becomes blacker and gamma>1 becomes whiter. The convert program appears to follow this convention (whereas dvipng applies x-->x^gamma instead and behaves the other way around).

The little table at forkosh.com/mathtex.html?gammadirective which accompanies that discussion shows convert handling the -gamma option properly. That's because I built ImageMagick 6.2.6 on that machine, and am using that version of convert. The default version 6.3.7 doesn't work right, as discussed in my original post.

I understand that two-color black/white won't be affected by -gamma, as per the above discussion. And my typical images would indeed be two-color, except for antialiasing which typically adds lots of grayscale pixels to smooth out jaggies. So these antialiased images should be gamma-correctible.

Anthony's final equation_darker.png suggestion above gave me a hint about a possible explanation for the observed problem. That suggestion works as advertised (thanks Anthony), but recall my original post that said .png was never a problem, only .gif. However, when I re-run Anthony's same convert command, only changing it to equation_darker.gif, I see lots of jaggies. That suggests to me that antialiasing is somehow defeated during .ps-->.gif conversion but not defeated during .ps-->.png conversion. In that case .gif images would indeed be reduced to black/white, and therefore -gamma would have no effect on them. Maybe it's that kind of problem that somehow got introduced between 6.2.6 and current.

Anyway, reverting to 6.2.6 seems to solve my immediate problem, which is what I'm now suggesting to mathtex users at
http://www.forkosh.com/mathtex.html?convertadvisory
If the situation ends up resolving itself differently, I'll rewrite that "advisory" accordingly. Thanks again, guys, for all your help,
John Forkosh

That suggests to me that antialiasing is somehow defeated during .ps-->.gif conversion but not defeated during .ps-->.png conversion.

Possible reason: gif is 8-bit and png is 24 bit, so gif will show more aliasing artifacts as it has fewer colors to show the interpolated values.

The images are not black and white, but black and transparency.

As a sure when converted to GIF you get jaggies, simply because GIF only allos boolean transparency.

Try adding a -background white -flatten before your -gamma setting to replace the transparency with white, forcing the image to be grayscale. and not 'transparency-scale'

Thanks again, Anthony, but

Code: Select all

convert -density 120 -background white -flatten -gamma 1.5 -trim dvips.ps convert.gif

doesn't seem to address the problem. That gives exactly the same file (byte-for-byte identical) as -gamma 5.5 or any other gamma value. And the .gif it produces looks almost as jaggy as the original -transparent one produced by

Code: Select all

convert -density 120 -gamma 1.5 -trim -transparent "#FFFFFF" dvips.ps convert.gif

(Note: for these tests I'm using convert -version 6.4.3 that just installs standard with slackware linux 12.2)

Also, I'm not sure your remark about gifs is completely right. My other math rendering program http://www.forkosh.com/mimetex.html has gif rendering built-in, explicitly programmed in C, and adapted from gifsave.c at http://shh.thathost.com/pub-dos/ But that original gifsave.c had no transparent background option, which I had to write into the version you'll find in http://www.forkosh.com/mimetex.zip (see the
WriteTransparentColorIndex() function). This just requires writing a graphic extension block into the gif file that sets the transparent colormap index. But there's no additional limitation about the number of colors (maximum colormap index) that can be used. I'm not quite sure what you mean by "boolean transparency."

And mimetex works fine, producing antialiased gifs with plenty of grayscale values, and with a gamma option that works without affecting the number of different grays displayed. Moreover, older versions of convert also work just fine (as far as I can tell). So I still think that maybe something else is going on with recent versions of convert.

Thanks again,
John Forkosh

forkosh wrote:Thanks again, Anthony, but
Code: Select all
convert -density 120 -background white -flatten -gamma 1.5 -trim dvips.ps convert.gif
doesn't seem to address the problem. That gives exactly the same file (byte-for-byte identical) as -gamma 5.5 or any other gamma value.

The order of operations is important. Up until the first image is read IM sets settings, and collects operations for use AFTER the first image is read. This is a legacy system and one that should not be relied on. See
http://www.imagemagick.org/Usage/basics/#legacy

In the future your previous code probably should generate a error on the -flatten operation as no image has been read in before that operation is applied.

What probably happens is that the gamma gets performed before the flatten due to the way in which operations were ordered by the legacy system. In fact I know this is really what is happening due to my recent study of some of the IM code!!!

Only density is important for the reading, as such it is the only thing that should be set before the read of the postscript file. After reading the image, operations will
be performed in the order given, just as it is supposed to.

Code: Select all

convert -density 120 dvips.ps -background white -flatten -gamma 1.5 -trim convert.gif

This does work for me. -gamma 0.5 is darker. -gamma 5.5 very light edges.

anthony wrote:The order of operations is important. Only density...should be set before the read of the postscript file. After reading the image, operations will be performed in the order given.
Code: Select all
convert -density 120 dvips.ps -background white -flatten -gamma 1.5 -trim convert.gif
This does work for me. -gamma 0.5 is darker. -gamma 5.5 very light edges.

Thanks, Anthony. That works for me, too. And thanks for the order-of-arguments info, which I'd only been dimly aware of, and hadn't paid any real attention to. I'll certainly change mathtex to construct convert commands correctly now.

I'd also just change -transparent "#FFFFFF" to -background white -flatten, except that a transparent background is better. My own web pages typically have white backgrounds anyway, so if mathtex were just for me then it wouldn't matter. But to accommodate an unknown user community whose web page designs I can't predict, a transparent background is better. I'd guess that's why the -transparent option is there in the first place.

And -transparent used to work the way I naively expected it to work with earlier/legacy versions of convert. Moreover, transparent backgrounds continue to work with any gamma correction for gif images produced by dvipng (despite its name dvipng has a gif option) and by mimetex (as discussed above). So I don't think there's any "mathematical reason" why it can't work with current versions of convert, though I haven't looked at the theory or the code carefully enough to be sure of anything.

Do you think convert will ever re-support -transparent together with -gamma for .ps-->.gif conversions? That would be optimal. What I can also easily do is add a \background{color} directive (along with a -DBACKGROUND=\"color\" compile switch default) to mathtex, to control the kind of convert command line it constructs. That will let users decide what they want/need to do, but it will also mean that users have to think about it -- never a good requirement:).

Thanks very much,
John Forkosh

Legacy ImageMagick Discussions Archive

convert -gamma has no effect for .ps-->.gif or .ps-->.png

convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png

Re: convert -gamma has no effect for .ps-->.gif or .ps-->.png