Write time very variable

[peter01242]

I am adding a barcode to a TIFF file (read, composite, write) and the time taken by the write() call varies quite significantly depending upon where I place the bar code.
I am monitoring the ImageInfo progress as part of the process.

The source file is a single-strip LZW compressed TIFF file (18.6" x 12.2" @2540 dpi).

Code: Select all

Barcode    Overall   Time before write
Position   Time      write progress starts
tlc        31.7s     10.3s
trc        31.83s    10.4s
blc        69.02s    46.4s
brc        65.58s    42.8s

The final column is the approximate time between making the write() call and the progress monitor method being called for the first time.

Placing the barcode at the bottom of the image seems to cause the write() call to take approximately twice as long as placing it at the top.
Any suggestions as to what IM is doing for the additional 30 seconds, as the copyPixels command seems to take about the same time regardless of the position?

Peter Young

[snibgo]

You don't say what the output format is. I suspect the write time will depend on the nature of the image and the compression method. Perhaps if you turn compression off, the times will be the same.

[peter01242]

The source and target files are both TIFF files so I am not changing file format as such; I am not sure what IM does internally.

I tried several compression methods with the following save time results for placing the barcode at the TLC and BRC.
The times are the time between the write() command being called and the first progresss callback message.

Code: Select all

Compression Type     TLC     BRC
No compression       11.7s   41.1s	
RLE Compression      9.7s    41.6s
LZW compression      10.5s   41.2s
Group 4 compression  37.4s   75.8s

I can only assume that whatever the write() call is doing before it actually starts writing to disk, the G4 compression is really time-expensive compared to the other compression formats, although there is a consistent difference of about 30 seconds between the TLC and the BRC regardless of compression type used which would tend to imply that it is not applying the selected compression algorithm during this time.

[snibgo]

So each test has a large image, the same image each test except for a position of a small barcode, which is in the top-left corner or bottom-right corner?

When there is no compression, I don't see why the barcode position affects the times.

These are large images, about 1.5 G pixels. What version and Q-number IM? Grayscale or colour? IM v6 Q16 will need 12 GB of memory per copy of the image. Are you running out of memory?

[peter01242]

I am using IM 7.0.2-Q8.
The image is 18.6" x 12.2" @ 2540 dpi and is a 1-bit TIFF.