Should be self-explaining:

$ xwd -root | file -
/dev/stdin: XWD X Window Dump image data, "xwdump", 1280x1024x24
$ xwd -root | convert - /tmp/foo.png
convert-im6.q16: no decode delegate for this image format `' @ error/constitute.c/ReadImage/504.
convert-im6.q16: no images defined `/tmp/foo.png' @ error/convert.c/ConvertImageCommand/3257.
$ xwd -root > /tmp/foo.xwd ; convert /tmp/foo.xwd /tmp/foo.png
$ echo $?
0
$ file /tmp/foo.png
/tmp/foo.png: PNG image data, 1280 x 1024, 8-bit/color RGB, non-interlaced

control: forwarded -1 https://github.com/ImageMagick/ImageMagick/issues/333

Hi,

It is really hard from a pipe to guess the type of file.

XWD magic is only 3 bytes and better error handling need seek that are not
available on pipe (stdin).

Using file more information could be given using file extension.

Thus close

Control: reopen 848849

Huh?

It has been possible and has been working fine (from user POV) for
years. Even the oldest version I can access right now (Ubuntu 14)
works this way.

And if this is a deliberately introduced regression then I expect you to
announce such things via the NEWS file.

This is not really an explanation. Are you trying to say that previously
they did the detection in later stages when more data was available and
now this happens in the beginning, within the first read package or
something? In which case... why not increase the size of the first read
package to get enough data?

Huh?

There is no suffix, it's a stream. You probably mean "-format xwd"?
But even that workaround is broken:

$ xwd -root | convert -format xwd - deleteme.png
convert-im6.q16: no decode delegate for this image format `' @ error/constitute.c/ReadImage/504.
convert-im6.q16: no images defined `deleteme.png' @ error/convert.c/ConvertImageCommand/3258.

And this also was ok with older version.

Regards,
Eduard.

No i mean

  xwd -root | convert xwd:-