Legacy ImageMagick Discussions Archive

Trying to convert an image to stdout fails with Here's the image.
Here's the command line: Using Windows 7x64 Ultimate with ImageMagick-6.6.2-3-Q16-windows-x64-dll.

Thanks for this program, just discovered it and am overwhelmed with possibilities

I don't have pngout, but this works for me, Windows7 64, IM 6.6.0-8:
(It's a good idea to reduce the report to the minimum that creates the problem.)

I'm not sure why it's failing for me, but I just split the commands so I no longer use std, and I'm going to work with that. Thanks for testing though.

I'm getting the error, too when using pngout this way (and also 'broken pipe' errors). But I don't think that ImageMagick has any fault here.
If you're interested in why the command was failing, we could ask in the forums for pngout. I have started a bug report.

Edit:
@aletaziar: The command from your first post works now - with the latest pngout. But - as Ken Silverman said - it's really not recommended to use pngout with stdin/stdout.

By the way: If I'm not mistaken, "-quality 100" doesn't make much sense with PNG as output. (It seems that ImageMagick is using quality 90 then.) See PNG compression.

For me, this error was really frustrating me, and in the end after writing an entire program to work around it... this post helped me realize that windows and "FORFILES" was interpreting the hex character sequence that I had accidentally put as my image folder name.

In other words:
convert.exe D:\images3000x3000 ... D:\images3000x3000png

was taking the "0x30" part of that path and mangling it making the path "images300000" (eating the 0x30 part)
I accidentally created a bad folder name!!!
thanks for the nudge in the right direction!

If you put your file names inside double quotes, does that avoid the problem?

convert.exe "D:\images3000x3000" ... "D:\images3000x3000png"

Interestingly enough, no... which is why it was so hard to track down...
here's the original command that was working with other paths, but this path wouldn't work
I could have tried to use the hex value to try and encode the command, but changing the filepath to not include a 0x character group was an acceptable fix for me