Legacy ImageMagick Discussions Archive

Hi all !
I have a script that converts EPS files to TIFF.
In one pass, it crops the EPS into 1000x1000 TIFF tiles, with a given density and a 8bit depth, compressed in LZW.

The command is as follow :
convert -density 500 -compress LZW -depth 8 -colorspace RGB -limit memory 2500 -crop 1000x1000 myeps.eps -background mytif-%d.tif

As you can see, I specified "%d" in the output file name to have them automatically numbered. That is important for the rest of the batch process.

This worked very well, but I upgraded to the latest version of Imagemagick (after a server crash, so I don't even know the old version number), and now all the TIFF are created with a transparency.
That is very bad, because the API that uses them in the end cannot read these TIFF. If I "identify -verbose" them, they are now "Type : TrueImageMatte", and before they where "Type : TrueImage".

I tried "mogrify -background white -flatten +matte mytif-0.tif" and I got the correct result. (Image is TrueColor and no transparency)

Now, my problem is that I don't find how to modify my previous command to integrate the "-background white -flatten +matte" into it.
I tried to add these options with the other options, but the file was not cropeed anymore. I tried to add them between the file names and it did not work either (sorry, I tried all kind of stupid things because I jsut don't get it...).

Could you tell me how to achieve this in just one line ?

Thanks a lot !

try adding -type TrueColor or whatever you need

see

convert -list type

fmw42 wrote:try adding -type TrueColor or whatever you need

see

convert -list type

Thanks for your answer.
I already tried that but it doesn't work, the effect is the same as +matte.

More precisely : since the EPS has a transparent background, the "antialiasing" of features that are drawn over the background is contained in the alpha channel. Adding +matte or +type TrueColor flattens the image but the features over the background are drawn without antialias.

I guess this might be a bug ?

Well, I for one am now very confused about what your problem really is? I thought you were complaining about the resulting image type. Now you seem to be saying the problem is antialiasing?

Can you try to rephrase the issue and supply some example images of the issue?

Also you may like to try and seperate input setting from the output settings so you know what is for what... and read the image before trying to crop it!
You also did not given -background a argument!


This ordering will more than likely be enforced in IM v7, so that IM can process options from a stream or file instead of the command line.

Well Anthony, you got it right !
I was totally at loss about where should I write which command.
So if I get it right, modifiers should precede the image ?

The correct command was :
convert -limit memory 2500 \
-density 400 -colorspace RGB -background white myeps.eps \
-flatten +matte -compress LZW -depth 8 -crop 1000x1000 mytif-%d.tif


Sorry for not making myself clear in the first post.
Thanks a lot to everyone for your help in this !

Read settings should proceed the image read (which is a type of image operator. Simularly for write settings.

Basically any settings for a specific operation should precede that operation.

convert settings... operation... settings.... operation...
save_image

naturally you should read the image (an operation itself) BEFORE turning to modify the image (like with -crop)

PS: after -crop you should add a +repage operator to clean up any virtual canvas offsets -crop may leave behind.

The -limit is a setting for the whole command, so should be done before any operation.

ALL this is detailed in IM examples, Basics.

anthony wrote:ALL this is detailed in IM examples, Basics.

I've read a lot of the "usage" pages, which are great, but the command line syntax remained quite obscure to me.
Thanks a lot for clarifying all this !
(and thanks for the +repage, I'll add it too)

Bingo wrote:I've read a lot of the "usage" pages, which are great, but the command line syntax remained quite obscure to me.

Yes the section of command line syntax was written when IM v6 first came about, and the key was making people understand that things should be done in operational order. What was not made clear is that READING IMAGES is an operation too.

What has made this more difficult is that doing things out of order continued to work due to 'legacy' mode. What should happen is that IM should throw a warning about this if an operation is applied BEFORE any image is read or created.

In IM v7 this will probably be worse as I want to change the command line API is such that IM could read its settings and operations from a stream (including files). That however means it will not be able to backtrack to provide any sort of 'legacy' mode.

anthony wrote:Yes the section of command line syntax was written when IM v6 first came about, and the key was making people understand that things should be done in operational order. What was not made clear is that READING IMAGES is an operation too.

Indeed, that's the point.
Furthermore, one needs a certain understanding of the way IM works to get things in order.
For instance, write "-density xxx" before reading a vector file is only obvious if IM draws a vector file on a canvas when reading it. If it did work internally with vectors, applying "-density xxx" after reading the vector image could be logical.
Also, if I understand this correctly, "-background white" could be written either before or after reading the EPS.

Also, it might be quite logical to apply -compress LZW at the very end, just before writing the TIF, right ?

What has made this more difficult is that doing things out of order continued to work due to 'legacy' mode. What should happen is that IM should throw a warning about this if an operation is applied BEFORE any image is read or created.

That was exactly my problem here. I wrote this script a long time ago, and I wrote it in a bad way (all options, then input image, then output image). Upgrading IM broke the script, but now I am quite happy to know that my command is written in the correct way and that it will continue to work with future versions.

Bingo wrote:Also, if I understand this correctly, "-background white" could be written either before or after reading the EPS.

Yes it can appear before or after reading an image, bt it should ONLY appear sometime BEFORE the operator that needs it.

When reading images some vector images needs to have a background color provided if you don't want a white background (defaults to white). If you give it AFTER an image read, it will NOT apply to the image read but to the operators that follow.

The KEY is all options should be applied IN ORDER GIVEN.
That is if an an operation needs a particular setting, then that
setting should be SET before giving the operation. That is set the setting, then apply the operation using that setting.

For -density. It must be given BEFORE reading a vector image for it to take effect. Setting -density after reading the image will not effect the read operation, though it may effect the final write operation.

Also, it might be quite logical to apply -compress LZW at the very end, just before writing the TIF, right ?

Yes. -compress is generally used as a write operation setting.

In IM Examples, References I list settings seperateally to operators. As part of that like I flagged what type of setting it it. weather it is typically used for input (reading) output (writing), normal image processing (Operation), or general program control (Control).

Note that -set is not a setting as it modifies image attributes, of images in memory. That is it is an operation, not a setting.