Legacy ImageMagick Discussions Archive

Hi Anthony and fmw42,
I just checked your advices.
1. result: rgb converting needs about 3/4 of the time of cmyk - this makes sense, because I have three instead of four channels. Good!
2. result: with an 508MB rgb .mpc file the extent option takes 1Minute and 3 seconds, the draw method needs 56 seconds. Well, ok, it is faster...
3. result: trying mogrify instead of using convert reduces the time to 29 seconds, but does not work. The image is unchanged.

This shows that most of the time is not used by the conversion but simply by reading and writing the image from/to disk.

How can I use the knowledge that draw does not need to copy the image if mogrify does not work.

Here is my code:
echo $right: rectangle 17853,0 17953,13465
echo $left: rectangle 0,0 100,13465 works great
needs about half the time but leaves the image unchanged.

By the way, you say IM uses Q16 for color conversion. Does this mean identify bild.mpc should say 16bit?
Because it doesn't:
bild.mpc MPC 17953x13465 17953x13465+0+0 8-bit DirectClass 508MB 0.780u 0:02.829
Or does it mean the conversion is done with 16bit but the image is still 8bit?

Greetings
Roland

stupid me!

It should be This works !
Thank you for not posting (yet) that I am an idiot!

But here is the drawback:
this also needs 56 seconds, so obviosly the whole image is read and written again.

???

Greetings
Roland

mogrify is usually use to process a whole folder of images, not just one image. If you have just one image to process, then you want to use convert. Also your -draw command is not proper. you need to tell -draw what kind of primitive to use -- text, rectangle point, etc. I assume you want to draw text. But you also have to specify the coordinates where you want to draw the text.

IM will always read the image and then write it out. You cannot modify an image without processing it and saving as a new image, even if you write over the input.

The difference between mogrify and convert is that mogrify will process each image in the directory and write an output for each. Convert reads all the input images at once (memory hog) and then processes them and then outputs them to the same output name file. If more than one input is to be saved, then the output name will have appended, -0,-1 ... to create multiple images (but with the same base name) or it will create one output with multiple frame. This depends upon the output format. Gif will save to frame, png and jpg will save to individual numbered images.

typical syntax for mogrify is

mogrify -format png -path /pathtonewdirectory <commands> *

This will tell mogrify you want to create a png image (-format) for every (*) image in the current directory that you are currently at (via cd). The path tells mogrify that you want to put the results into a different (previously created) directory.

see
http://www.imagemagick.org/Usage/basics/#mogrify
http://www.imagemagick.org/Usage/text/#draw

Hi fmw42,
ok I see, mogrify is no option. Thanks!
So there is no way of writing directly to the image file instead of writing the whole file again?
I thought the mpc format would allow this...
Well ok, if not, I need a way of reading and writing the file faster.
I will try using a ramdisk next.
If I can increase the speed, I am allowed to order more ram...

Also your -draw command is not proper.

Did you realise that I set right='rectangle 17853,0 17953,13465' and left='rectangle 0,0 100,13465' before?
I still want to border the image.

There is only the question about the 16bit conversion left.
If I get this answered, I am happy

Greetings
Roland

Your command said nothing about what the variables were. Sorry I missed the $ sign for the variable.

When you convert an image to mpc format, it is memory mapped. So that you don't have to read it again. Thus you can do several command lines on the same data without reading it again.

But using it as an output format (for convert or mogrify) does not help, unless you are going to do more processing later on to the same file.

I think the mpc format is the best choice for me, because I have to do lost of tasks with the image.
0) the original image is a cmyk-tiff with 6Gb, so I convert to RGB with 4GB
1) crop the 4gb image into 8 rows ( I cannot use split, because I need some overlapping , the last 2inch of the first row have to be repeated in the first 2inch of the second row and so on.
2) these 8 rows have to get a 3000 pixel (hight) "header", a footer-line and the two borders beside.
3) every second row has to be rotated 180 degrees
4) the rows have to be converted to cmyk-tiff-lzw compressed images

Writing this I just wonder if I could use a kind of pipe to do all this commands in one task instead of storing the picture in between.
Well I won't do it now.
Unfortunatly you, Anthony and I are placed around the world (California, Brisbaine, Düsseldorf(Germany)) and so
I have to go to bed now, facing a tiring day tomorrow...

I hope to read from both of you tomorrow night.
Thanks anyway, the internet is great!

Greetings
Roland

Normally you could use clones and parenthesis processing. But your breaking things into rows may mean that you have to process each row separately, but you may be able to do much if not all the row processing using -clones and parenthesis ( or .mpr format rather than clones if you keep it all in one command line). However, your cropping may cause problems even with this.

I don't know that IM can do overlapped cropping in a simple manner. That would be a good question for Anthony. If it cannot, then it would make a nice addition in IM 6 or even just IM 7 later.

robuntu wrote:stupid me!

It should be

Code: Select all

time mogrify -fill blue -stroke black -draw "$left" -draw "$right" bild.mpc

This works !
Thank you for not posting (yet) that I am an idiot!

But here is the drawback:
this also needs 56 seconds, so obviously the whole image is read and written again.

mpc is a fast 'memory maps from disk' read (no format parsing needed)
But write still needs time though again it is just a direct memory dump, so is fast.

Assuming $left and $right contain draw primitives, you can do it in one draw command, though it will not generate a large speed improvement (some minor memory copy reduction only) "mogrify" has trouble with composition, as it is very hard to specify the second image as being part of image processing, rather than as 'an image to process'. This is likely why you had no result with your previous mogrify attempt.