Problem with -format "%b" INFO:test.txt

[Detlev Dalitz]

Hi all, this is my first visit and posting here in the ImageMagick forum, and what I have to report is hopefully not discussed too often by other users of this fine software.

Long time ago I've stumbled over a quirk with the -format option. Now I have time to write about.

Executing the following commandline string ...

Code: Select all

convert frame.jpg -format "Image: %f\n Format: %m\n  W x H: %wx%h\n  X x Y: %[xresolution]x%[yresolution]\nQuality: %Q\n   Size: %b\n" INFO:

... will give such result:

Code: Select all

Image: frame.jpg
 Format: JPEG
  W x H: 176x108
  X x Y: 72x72
Quality: 85
   Size: 6067

... which seems to be fine.

Now using following commandline to write the formatted output into text file ...

Code: Select all

convert frame.jpg -format "Image: %f\n Format: %m\n  W x H: %wx%h\n  X x Y: %[xresolution]x%[yresolution]\nQuality: %Q\n   Size: %b\n" INFO:test.txt

... will give such result in file "test.txt":

Code: Select all

Image: frame.jpg
 Format: JPEG
  W x H: 176x108
  X x Y: 72x72
Quality: 85
   Size: 0

Look at the zero size value.

Using ...

Code: Select all

convert frame.jpg -format "Image: %f\n Format: %m\n  W x H: %wx%h\n  X x Y: %[xresolution]x%[yresolution]\nQuality: %Q\n   Size: %b\n" INFO: >test.txt

... will give such result in file "test.txt":

Code: Select all

Image: frame.jpg
 Format: JPEG
  W x H: 176x108
  X x Y: 72x72
Quality: 85
   Size: 6067

So what is going on with the "%b" value when using "INFO:test.txt"?
Thanks in advance for a good answer!
In the meantime I can help me with the redirection symbol.

Detlev Dalitz
DD.20100203.2220.CET

[magick]

ImageMagick is behaving properly. The %b returns the size in bytes associated with the image file handle. Since you are writing to text.txt, the image file handle is now associated with text.txt rather than frame.jpg. The size in bytes is 0 since text.txt was just created. It returns the input image size (frame.jpg) when writing to stdout because you can't get the size of stdout (see fstat()) so on exception it returns the size of the original file (frame.jpg) instead. In your case you are taking advantage of a side-effect.

[Detlev Dalitz]

Thank you for your quick reply.

You've spoken of a "side effect", well, this explains how, when handling multiple files via "@input.txt" list, the related "%b" values are displayed shifted by one file to another (sorry, cannot better explain ... it is difficult to me to describe this effect).

So as I understand ... IM behaves different when writing formatted text info redirected to text file rather than writing directly to console output. Seems to be quirky.

Can you provide a workaround to get a formatted message containing "%b" into textfile output?

DD.20100204.0955.CET

[fmw42]

Can you provide a workaround to get a formatted message containing "%b" into textfile output?

convert rose: -format "%b" info:- > rose.txt

shows 9673 in rose.txt file.

[Detlev Dalitz]

Can you provide a workaround to get a formatted message containing "%b" into textfile output?

convert rose: -format "%b" info:- > rose.txtshows 9673 in rose.txt file.

Yes, this seems to be obvious.
Because I use convert exe in a scripting environment with RunShell(...) and I have to catch the redirected output there is an additional problem.
Command Before: "convert.exe rose: -format "%b" info:info.txt"
Command Now: "cmd.exe /c convert.exe rose: -format "%b" info:- >info.txt"
So the return value of convert.exe ist lost.

Further on ...
Having a text file "list.txt" containing four filenames.
Executing on the commandline: "convert @list.txt -format "%f %[EXIF:DateTime] %b" info:"
will give the result ...
20091202.001.jpg 2009:12:02 08:25:31 1212182
20091202.002.jpg 2009:12:02 08:25:41 1212182
20091208.001.jpg 2009:12:08 19:34:53 1212182
20091208.002.jpg 2009:12:08 19:35:17 1212182

Is there any good reason how the filesize of the first file is "multiplied" onto the other files?

DD.20100205.0051.CET

[magick]

We have a patch for the problem you reported in ImageMagick 6.5.9-2, available sometime tomorrow. Unfortunately the patch did not make it to the Windows binary distributions. We'll need to reissue them within a week or two.

[Detlev Dalitz]

Ok, I will wait for the Windows binaries.
Thank you for looking into the problem and fixing it.

DD.20100205.0320.CET