convert not always ovewriting output

[cbonallo]

We are using ImageMagic 6.5.6-10-Q8 in combination with WatchDir. The Command Line bat file contains this code:

"C:\Program Files\ImageMagick-6.5.6-Q8\convert.exe" "%WD_FILE%" -resample 72 / -filter lagrange -set option:filter:support 2.5 -resize 175X175 "\\harvard\webimages\%WD_FILE_B%.jpg"

Sometimes the desination file wil already exist. In most cases when this fires off because the original has changed (WatchDir job) the output file is overwritten with the new thumbnail.

However, just recently we had to redo all our thumbnails because we had some network outage that lead to the file server "Harvard" not being accessable while the ImageMagick bat file ran so the thumbnail was not created. It was just reported to me that some thumbnails do not match the original. I checked the time stamp on the file and it shows being modified at the right time by ImageMagick, but the underlying image did not get replaced with the new one?!

Is there a fix for this or has anyone else reported this?

Cory Bonallo
Retail Services Developer

[anthony]

It sounds more like a file system problem where the file system updated the date, but not the data.

All that can be suggested is you somehow re-run the script for any thumbnail with a time stamp within the effected time period.

[cbonallo]

We resized 80,000 images in 17 hour period. I have no idea which ones of those did not get updated... So this has never occured before? Are there any commands that can check the output image integrity?

Cory Bonallo

[anthony]

basically have your script read the image back again!
But with file system caching, even that is no guarantee that the file is saved properly!

[cbonallo]

What good would reading the image back do? If I checked the modify date it would be correct and I don't know the size because I resize it so what else can I compare that would be unique to a properly saved image verses one that is not?

[anthony]

reading it bask will verify that the DATA is readable and not corrupt. that is the issue is it not!

[cbonallo]

No. Let's see if I can make this clear. All the images are good images. However in some cases the new resized image is replacing an old image under the same name. On some of these particular images, the modified date is changed but it is still the old image, not the new one. It would read back ok.

[anthony]

I see.

Hmm... Well IM itself does do anything special in writing the resulting image
It opens the filename, write to it and closes it.

If the filesystem fails to open the filename (for example file or directory is not writable), nothing gets written though an error should be produced. The date also should not be changed in such a case, unless a separate script command does something else separate to IM.

I myself have had cases where IM errored and did not generate a thumbnail, but the script then 'fixed' the date of the old thumbnail, makign it wrong. But it was not IM's fault.

I have no idea how you can fix your erroneous thumbnails, other than by re-doing them all.

As for preventing future problems, that I suppose depends on what actually caused the problem in the first place.

[fmw42]

I don't know if this will help or not, but have you tried adding -regard-warnings to your command line to make IM provide a proper exit status so that you can see if IM is at fault. see http://www.imagemagick.org/Usage/basics/#controls

[cbonallo]

Well none of the images are write protected. IM is not throwing any errors. So my guess is that Im is opening the filename, which changes the dates and is not getting a chance to write to the file. Would IM not produce an error if it was able to open the file and not able to close it?

[cbonallo]

Thanks for the tip on -regards-warnings. I'll give that a shot and see if I can get more info. Do you know where the warnings are stored?

[fmw42]

Thanks for the tip on -regards-warnings. I'll give that a shot and see if I can get more info. Do you know where the warnings are stored?

Standard error I believe. But in command line any errors show at the terminal. Anthony can give you more details.

[anthony]

Hmmm if the data in the file is unchanged then the 'date' tag in the thumbnail (if it exists) will also be unchanged. However that tag would not be 'close' to the date of the file!

So (for generated thumbnails only) if the thumbnail format has a internal date you can compare that to the file date to see how 'off' it is, or if the thumbnail data itself is 'too old'.

Of course this only works if the image file format used for thumbnails contains a modified 'date'.
(PNG files I know do! Not certain about GIF)

[cbonallo]

These are JPG's. Any clue as to the proper commands to check the JPG header and file modify date? Sadly I am more developer than photographer so I don't know much about image files...

[fmw42]

perhaps exiftool

http://www.sno.phy.queensu.ca/~phil/exiftool/