mogrify using @ and -path ... bug?

[mastabog]

Hi,

I tried to use mogrify and the -path while reading the images from a list file using the @ option. This is because I want to avoid calling convert in a loop as it increases the processing time quite a lot when there are many images. The command line I tried was a variation of:

Code: Select all

mogrify @list.txt -resize 100x100 -path m:\pics\thumbs

What happens is that all thumbnails get created in the same directory as the source images, in this case m:\pics, and are based on the filename of *ONLY* the first file in the list (which is deleted) *PLUS* a counter appended to the filename, before the extension. I wanted them to go in the "thumbs" subdirectory and have the filename and extension preserved.

Example, if list.txt contains the following:

Code: Select all

m:\pis\pic1.jpg
m:\pis\pic2.jpg
m:\pis\pic3.jpg

then the the above command yields the following converted files:

Code: Select all

m:\pics\pic1-0.jpg
m:\pics\pic1-1.jpg
m:\pics\pic1-2.jpg

The original pic1.jpg is deleted, pic2.jpg and pic3.jpg are not. The files are created in m:\pics and not in m:\pics\thumbs and all converted files are of the form pic1-*.jpg (note the pic1). However, the content of all converted files does correspond to the original files. It seems list.txt is indeed read correctly as per what conversion goes but the output file naming is only based on the first file in list from list.txt.

However, this seems to work fine:

Code: Select all

mogrify -resize 100x100 -path m:\pics\thumbs m:\pics\*.jpg

but i can't use the above since my file list contains only a selection of files (the output of a script).

I could go around this by reading list.txt and create a one line string of file names which I then append to the mogrify command line but this would fail when the string goes beyond the command line length limit of the shell (32768 in my case) which happens easily when I have many hundreds of files as each line in list.txt is long'ish, containing the full path to the file.

Any ideas?

As a side note also (do prod me in case I'm missing something), IM is an incredibly advanced tool but it lacks one of the most basic features: processing of multiple files with filename format modifiers for the output files. Both convert and mogrify can read file names from a file with @ or from globbing a directory with e.g. *.jpg, so why not allow the user to specify the output directory and file based on the tokens from the input file, e.g. %b for basename, %f for file name, %e for extension, %p for path, etc ... outputting to a different directory would become much easier. Currently, I see IM insists on using counters and the output directory can only be specified for mogrify in that sense (i.e. when using @ or globbing and, for instance, when trying to just replicate the file names for the converted files in another directory).

Cheers and keep up the good work!

[anthony]

As you are using DOS, you could use a DOS script 'FOR' loop to go though the files one at a time

See http://www.imagemagick.org/Usage/api/#windows.

[mastabog]

I already said in the first line of my post above that "I want to avoid calling convert in a loop as it increases the processing time quite a lot when there are many images." ...

Regardless, the issue I raised seems rather like a bug which needs to be fixed rather than users having to work around it (which I already did for now). Working on multiple images without using a loop is a must for a tool like IM's convert and mogrify in order to only initialize it once.

To reply to your message though, on hundreds and thousands of images, calling convert/mogrify hundreds and thousands of times more than doubles the processing time as the image manipulations themselves are faster than initializing IM for each call. You can try yourself a mogrify *.jpg versus a mogrify loop to see the difference. YOu can also try mogrify *.jpg -filter bogus in a loop to force it to fail ... the overhead is awful

p.s. My workaround for now is building a string of filenames in a loop, checking for its length to be greater than 16000 chars, calling mogrify when that happens and erase the string, repeat this until the last filename ... this avoids calling mogrify for every file but also solves the problem of command line length being too long when there are thousands of files. btw, I'm using bash for win32 for almost all my windows scripts.

[magick]

We have a patch for the problem you reported. Look for it in ImageMagick 6.5.2-0 Beta within the next day or two.

[mastabog]

We have a patch for the problem you reported. Look for it in ImageMagick 6.5.2-0 Beta within the next day or two.

Cheers