Legacy ImageMagick Discussions Archive

The command line below will add 'Missing Signature' with a box to the first page of a multi page tif or a single page tif. The text and box are red on a single page tif, but black and white on multi page tifs. Any idea what I have wrong?

magick MultiPageTiff.tif ( -clone 0 ( -background white -fill red -font times-new-roman -pointsize 110 label:"Signature Missing" -bordercolor red -border 10 ) -compose over -geometry +900+250 -composite ) -swap 0,-1 +delete MultiPageTiff2.tif

Thanks,
Scott

What version of IM, on what platform? Perhaps an old version of IM, on some version of Windows. It works fine for me, IM v7.0.7-28 on Windows 8.1.

If that doesn't help, please link to an input tiff file that shows the problem..

I'm running IM v7.0.6-10 on Windows 10 Pro. I will download the latest version of IM and see if that resolves my problem. Thanks.

Upgraded to IM v7.0.8-11. See version info below.

Still not working, but it's not due to the number of pages. Because I am working with medical documents I created my multi-page tif using our copy/scanner machine and saved to disk (this if file that is not working). When I needed a single page tif to share I scanned only one page. It would not show color. My original test documents were originally PDF's that I converted to tif using IM. After single tif created from copy/scanner did not work I converted a multi page PDF to a multi page tif and the annotations were in color. Any ideas why it will not work on a scanned document?

E:\Source\WorkSpaces\TestWorkSpace\Test ImageMagick\ImageMagick\Test Images>magick -version
Version: ImageMagick 7.0.8-11 Q16 x64 2018-08-29 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2018 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Visual C++: 180040629
Features: Cipher DPC Modules OpenMP
Delegates (built-in): bzlib cairo flif freetype gslib heic jng jp2 jpeg lcms lqr lzma openexr pangocairo png ps raw rsvg tiff webp xml zlib

Command:
magick SinglePage.tif ( -clone 0 ( -background white -fill red -font times-new-roman -pointsize 110 label:"Signature Missing" -bordercolor red -border 10 ) -compose over -geometry +900+250 -composite ) -swap 0,-1 +delete SinglePage2.tif

Multi Page Input File:
https://gtpdd.sharefile.com/d-s3fe6ce7cabb4204b

Multi Page Output File:
https://gtpdd.sharefile.com/d-s774658b272241199

Single Page Input File:
https://gtpdd.sharefile.com/d-sd4efca1cb484257b

Single Page Output File:
https://gtpdd.sharefile.com/d-s373712bcda5406b9

Thanks,
Scott

Your input image is binary (bilevel), so Imagemagick is trying to save the output as binary. This is a bug in Imagemagick as it should see that the other image is color and make the output color.

I even tried forcing the input tiff to truecolor. But that did not work unless I save the output as miff and pipe to the rest of your command.

I have simplified your command as follows and run in Unix syntax. I tried both IM 6.9.10.11 and IM 7.0.8.11 Q16 Mac OSX

Input:
https://gtpdd.sharefile.com/d-sd4efca1cb484257b

This produces b/w output: This produces b/w output and -type truecolor does not change the image from bilevel (when I save a temp file after -type truecolor) This works to make your label and border red: I will report this as a bug

The problem is the input compression. The fix is to insert "-compress Zip" before the output filename. (Or "-compress LZW" or -compress None".)

snibgo wrote: ↑2018-09-10T15:53:39-07:00 The problem is the input compression. The fix is to insert "-compress Zip" before the output filename. (Or "-compress LZW" or -compress None".)

Thanks for digging deeper. But is that still not a bug?

The input has Group4 compression. This is lossy: just one bit, and no colour. By default, IM compresses output with the same compression as the first input.

Personally, I think IM should ignore input compression if it is lossy. So a Group4 input would create an output with no compression, unless the user asks for it with "-compress Group4" or whatever.

But then users might complain that a Group4 input that is merely trimmed creates a massively larger output file.

So, is it a bug? I don't think so. Would I like a behaviour change so IM never uses a lossy compression unless I tell it to? Yes I would, but I don't personally use lossy compressions, so I don't really care.

EDIT: For completeness, I'll add that IM could have more intelligence. It could "know" which operations can add information to an image which will be removed by lossy compression or small bit depths. It might then automatically upgrade the compression method or bit depth, or at least warn the user that data will be lost. But I don't think this is a realistic enhancement.

A more feasible enhancement: IM could have an option that, when requested, alters the behaviour of saving an image. After saving the image and before removing it from memory, IM reads the image from the file. If it is different to the in-memory image, it informs the user. There would be a performance penalty, but useful when developing or debugging a system.

Thanks guys.... Your suggestions got me past my problem.