Different result using the same command

[Alberti]

Hello

I use the following command to write an text on an TIF image and to convert the image.

convert -font c:\windows\fonts\ariali.ttf -pointsize 90 -gravity west -draw "translate 0,0 rotate -90 text 80,150 %title%" "%image_old%" %image_new%
convert -rotate "-90>" -geometry 3307x3307 +compress "%image_new%" "%image_new%"

To fasten up the command i try to use the following statement
convert -font c:\windows\fonts\ariali.ttf -pointsize 90 -gravity west -draw "translate 0,0 rotate -90 text 80,150 %title%" "%image_old%" image.mpc
convert -rotate "-90>" -geometry 3307x3307 +compress image.mpc "%image_new%"

But the result of both actions is different. The new TIF has 256 colors instead of 2. Why?

I get the same "wrong" result if I combine the commands like
convert -font c:\windows\fonts\ariali.ttf -pointsize 90 -gravity west -draw "translate 0,0 rotate -90 text 80,150 %title%" -rotate "-90>" -geometry 3307x3307 +compress "%image_old%" %image_new%

My original TIF has the following data:
Compression: Group 4 Fax Encoding
Resolution: 300x300
Size: 3507 x 2480 Pixels (8.70 MPixels) (1.41)
Colors: 2 (1 BitsPerPixel)

The converted TIF has the following data:#
Compression: NONE
Resolution: 300x300
Size: 2339 x 3307 Pixels (7.74 MPixels) (1.41)
Colors: 256 (8 BitsPerPixel)

Thanks
Albert

[fmw42]

I am not an expert on TIFFs. But there are several things.

1) This probably won't matter, but your syntax is outdated. IM 6 uses syntax

convert input options output

see http://www.imagemagick.org/Usage/basics/#why

2) try adding -depth 2 -type bilevel before your output

see http://www.imagemagick.org/script/comma ... loou7#type

or try

-monochrome

(but this will dither) see http://www.imagemagick.org/Usage/quantize/#monochrome

or -quantize gray +dither -colors 2 -type bilevel

see http://www.imagemagick.org/Usage/quantize/#quantize

You might post a link to your input image so others can test things with it.

[Drarakel]

I'm not even sure if your output file really had 256 colors - as we don't know what software you used to display that:

Colors: 256 (8 BitsPerPixel)

But anyway.. It can happen, as you're drawing text and - with antialiasing turned on - this adds colors. Disable antialiasing if you want to have only 2 colors:
convert %image_old% +antialias <your operations> %image_new%
(If you don't disable antialiasing, then the colors are always added first. If ImageMagick stores that image as 1bpp/2bpp file after that, it gets again color-reduced. But that's sort of unnecessary.)

I suspect that you're using IrfanView for your.. statistics. Is that correct?

[Alberti]

Hello,

thanks for your answers. I will check this.

Here you can find the original image: http://www.doetsch-maenner.de/107953.tif
The converted image (compressed) is http://www.doetsch-maenner.de/100110_3.tif

Yes you are rights I am using IrfanView.

Thanks
Albert

[fmw42]

When I do:

convert 107953.tif -compress none 107953b.tif

I still get a bilevel image from Imagemagick when using

identify -verbose imagefile

Original:

Image: 107953.tif
Format: TIFF (Tagged Image File Format)
Class: DirectClass
Geometry: 3507x2480+0+0
Resolution: 300x300
Print size: 11.69x8.26667
Units: PixelsPerInch
Type: Bilevel
Base type: Bilevel
Endianess: MSB
Colorspace: RGB
Depth: 1-bit
Channel depth:
gray: 1-bit
Channel statistics:
Gray:
min: 0 (0)
max: 1 (1)
mean: 0.96079 (0.96079)
standard deviation: 0.194095 (0.194095)
kurtosis: 20.5444
skewness: -4.74809
Histogram:
341025: ( 0, 0, 0) #000000 black
8356335: (255,255,255) #FFFFFF white
Rendering intent: Undefined
Interlace: None
Background color: white
Border color: rgb(223,223,223)
Matte color: grey74
Transparent color: black
Compose: Over
Page geometry: 3507x2480+0+0
Dispose: Undefined
Iterations: 0
Compression: Group4


Converted:

Image: 107953b.tif
Format: TIFF (Tagged Image File Format)
Class: DirectClass
Geometry: 3507x2480+0+0
Resolution: 300x300
Print size: 11.69x8.26667
Units: PixelsPerInch
Type: Bilevel
Base type: Bilevel
Endianess: MSB
Colorspace: RGB
Depth: 1-bit
Channel depth:
gray: 1-bit
Channel statistics:
Gray:
min: 0 (0)
max: 1 (1)
mean: 0.96079 (0.96079)
standard deviation: 0.194095 (0.194095)
kurtosis: 20.5444
skewness: -4.74809
Histogram:
341025: ( 0, 0, 0) #000000 black
8356335: (255,255,255) #FFFFFF white
Rendering intent: Undefined
Interlace: None
Background color: white
Border color: rgb(223,223,223)
Matte color: grey74
Transparent color: black
Compose: Over
Page geometry: 3507x2480+0+0
Dispose: Undefined
Iterations: 0
Compression: None


I am on IM 6.6.3.0 Q16 Mac OSX Tiger.

Perhaps it is your IrfanView reporting.

[Drarakel]

Your file '100110_3.tif' is not available. But it doesn't matter.

One problem is IrfanView. You mustn't look at "Current colors", but at "Original colors". The "Original colors" field in Irfanview probably reports you "4 (2 BitsPerPixel)". The first number you can ignore (it's only the maximum number of colors that could be stored). But the '2 BitsPerPixel' is correct.
And the actual colors in the image are reported in the field "Number of unique colors". (But you can't trust the latter figure in every case - sometimes IrfanView has problems with that number.)

The other part of the problem (well, it's not a big problem, but it could be confusing) is indeed ImageMagick. It seems that some of the draw operations create an alpha channel (fully opaque) if IM uses an image with only grayscale values.
A better command in your case would be:

Code: Select all

convert "%image_old%" +antialias -font c:\windows\fonts\ariali.ttf -pointsize 90 -gravity west -type Grayscale -draw "translate 0,0 rotate -90 text 80,150 %title%" -rotate "-90>" -resize 3307x3307 +compress %image_new%

"-type Grayscale" ("-type BiLevel" works, too with this image) before "-draw" avoids the creation of an alpha channel (thus, the output image can be stored with 1 bit per pixel again). Don't know why ImageMagick tries to do this in the first place...

[Alberti]

Create it works
And it is so fast by comparison with my command.

Thanks for your help.

I see IM is very complex to handle and to understand .
I am from Germany and so I have some problems to understand the english documentation in all details.

Albert

[Drarakel]

I am from Germany

Me, too. If you have further problems with the english documentation, then you can write me a PM (in german).

[anthony]

I see IM is very complex to handle and to understand .

It isn't that it is complex and many things are easy. the problem is that there is a LOT it can do because image processing is a very large field with so many options (and still getting larger)!