[File] [PATCH] Magdir/images for X Window Dump image; undetected MARBLES.XWD ...
Jörg Jenderek
joerg.jen.der.ek at gmx.net
Fri May 6 22:11:58 UTC 2022
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
some days ago i used a print copy utility on Windows. That can be
found on web site hardcopy.de. Per hot key the screen or parts of
it can be directed to printer or saved as file. On offered file
formats one is called "X Window Dump" with version "v10" or "v11".
When running file command version 5.41 on such examples and related
files i get an output like:
MARBLES.XWD: data
betyboop.dmp: XWD X Window Dump image data,
"betyboop",
576x720x1
cccgirl1.dmp: XWD X Window Dump image data,
"girl1",
576x454x1
fig41.xwd: XWD X Window Dump image data,
"xwdump",
1014x704x8
fmt-401-signature-id-618.xwd: XWD X Window Dump image data,
-1414812757x-1414812757x16
hardcopy-x-window-v10.xwd: data
hardcopy-x-window-v11.xwd: data
input.xwd: XWD X Window Dump image data,
"input.xwd",
70x46x24
lenna.dmp: XWD X Window Dump image data,
"getX",
518x486x1
mandrill.dmp: XWD X Window Dump image data,
"getX",
518x486x1
my1xwd.xwd: XWD X Window Dump image data,
"mypi at pi1: /tmp/test/xwd-pi",
816x618x24
pal1-v10.xwd: data
pal4-v10.xwd: data
pal4rle-v11.xwd: data
pal8-v10.xwd: data
x-fmt-300-signature-id-619.xdm: data
With option --extension only 3 byte sequence ??? is shown.
For comparison reason i run the file format identification utility
TrID ( See https://mark0.net/soft-trid-e.html). All are described
as "X-Windows Screen Dump". The version 10 examples are described
with additional "(X10)" by definition xdm-x10.trid.xml and the
others are described with additional "(X11)" by xdm-x11.trid.xml
(See appended trid-v-xwd.txt.gz).
For comparison reason i also run the file format identification
utility DROID ( See https://sourceforge.net/projects/droid/). This
identifies all examples as "X-Windows Screen Dump". The X10 examples
are described with version "X10" by PUID x-fmt/300 and the others
with "X11" by PUID fmt/401 (See appended droid-xwd.csv.gz).
Luckily with information given by the other tools i also found a
page about XWD on file formats archive team web site. There now also
links for samples and C-header text are listed. That informations are
expressed by comment lines inside Magdir/images like:
# URL: http://fileformats.archiveteam.org/wiki/XWD
# Reference: https://wiki.multimedia.cx/index.php?title=XWD
# http://mark0.net/download/triddefs_xml.7z
# defs/x/xdm-x11.trid.xml
On that site download links for examples and graphic tools are
mentioned. I verified information by ImageMagick identify
(See appended identify-verbose-xwd.txt.gz, XnView command line tool
nconvert (See appended nconvert-xwd.txt.gz), xwud software ( see
xwud.txt.gz) and hardcopy tool by command lines like:
identify -verbose *
nconvert -in xwd -info *
xwud -in fig41.wxd -dumpheader
gimp fig41.wxd
The first work with version 6.9.11 on raspian 11, but not with
version 7.1.0 on Windows 64-bit. None of the mentioned tools work
100%. Some refuse to open or freeze on some examples, the displayed
image is distorted or the colours are wrong. What an annoyance with a
file format known since decades.
Some examples are not recognized. So according to header source i
check values of header fields for correctness.
The upper left coordinates of Window are stored inside header. Often
these values are zero, but sometimes not. So show these unusual
values by additional lines like:
>>>>>88 belong !0 \b, x=%d
>>>>>92 belong !0 \b, y=%d
So for example lenna.dmp i get x=568 and for example fig41.xwd i get
y=107.
The last part of shared header is the window border width. In most
examples this value is zero. But in example fig41.xwd i get value 1.
And some examples have just a few pixel border. So for maze.dmp i get
value 2 and for examples lenna.dmp and mandrill.dmp i get value 3. So
show non zero value by additional line like:
>>>>>96 ubelong >0 \b, %u border
Some fields are not so interesting or are redundant. So i do not show
this information, but just add it as comment line. The windows width
would be shown by line like:
#>>>>>80 ubelong x \b, %u width
This is apparently is redundant because
pixmap_width=WindowWidth+2*WindowBorderWidth
The number of entries in colour map are now shown by line like:
>>>>>76 ubelong x %u entries
So here i get values like like 256, 16, 2 or 0, where the last means
no colour map. Before the number of colours in image is stored.
This is shown by line like:
>>>>>72 ubelong x \b, %u colors
Some times i get unexpected information. I do not know how to
interpret it and maybe some programs also do not know it. So for
example MARBLES.XWD with depth 24 i get "0 colors 0 entries" and for
pal4rle-v11.xwd with depth 4 i get "0 colors 16 entries".
The example fmt-401-signature-id-618.xwd is not a real image. This is
the signature of DROID for XWD images. So an additional test to skip
this file must be added.
The pixmap width and height were shown by lines like:
>>>>16 belong x \b, %dx
>>>>20 belong x \b%dx
For DROID example i get here unrealistic value -1414812757. That is
abABabAB in hexadecimal. So i could additional check for dimension
limits. But at first glance in documentation i found no words about
upper limit of height and width. For me it is also unclear if this
values are signed or unsigned integers. So i do not use dimension
values as test. Instead i check for the existence of the border field
by additional line like:
>>>>96 ubelong x X-Window screen dump image data, version X11
If by "bad" circumstances like a file system crash you maybe get just
the first dozen starting bytes of a XWD image, when just a sample or
the DROID example is not misidentified as XWD image any more.
Furthermore i changed message text "XWD X Window Dump image data"
with aspect of comparing with text by other tools. I removed the word
XWD at the beginning because that aspect i now shown by --extension
option. As a newbie you probably get association "Microsoft Windows"
when you read the word windows in describing text. To avoid such
misinterpretation i changed "X Window" to "X-Window". The word "Dump"
could also be read like "memory dump". So i replace it by "screen
dump".
After describing text the mime type and file name extension are shown
by lines like:
!:mime image/x-xwindowdump
!:ext xwd/dmp
For mime type all tools and documentations mention the same one, but
for suffix things become complicated. Because such images are first
created by X11 utility xwd, this 3 byte suffix is used as file name
suffix.
In sample files section on file formats site we found also screen
dump images with 3 byte suffix dmp like betyboop.dmp or on
stuff.mit.edu site in compressed form hundreds of images like
mandrill.dmp.Z. But nowhere else this suffix is used or mentioned.
On some sites and also used by Xnview is the extension x11, but i
myself do not found such examples. TrID and DROID on the other hand
mention also extension XDM, but i found no such examples. TrID also
list extension XDW, but i believe this is a probably a misspelled
XWD. So i show only extensions i myself found, but maybe there
exist others.
After the identification a string is shown by line like:
>>>>100 string >\0 \b, "%s"
This string is called by ImageMagick under Properties as comment. The
xwud utility show this string as "window name". It also shows some
additional information. The size of the share header part is always
reported as "sizeof(XWDheader)" with value 100. This size plus the
string size with apparently terminating nil-byte is reported as
sizeof(XWDheader). That info hint is also reported inside DROID card.
That info is stored at offset 0 a 4 byte integer in big endian form.
So for example fig41.xwd with string "xwdump" we get here value 107.
Most examples contain such a comment string, but a few like
MARBLES.XWD and hardcopy-x-window-v11.xwd not. So here at offset 100
something like colour map is stored. And by lucky circumstances this
looks like printable ASCII and this would be printed as comment by
current magic. So this now becomes like:
>>>>>0 belong >100
>>>>>>100 string >\0 \b, "%s"
So for sizeof(XWDheader) i get values like:
100 104 105 106 107 109 110 113 114 115 118 172
As first test this value was checked by line like:
0 belong >100
That means samples without a comment (value=100) like MARBLES.XWD are
not matched and so not identified. So this line now becomes like:
0 belong >99
For X10 variant exist no magic lines. In principle it is similar to
other variant. So check first for valid header size, which is here
always 40. Then check for version which is here six. Then skip
DROID x-fmt-300-signature-id-619.xdm by check for border field. So
this looks like:
0 belong =0x000000028
>4 belong =6
>>36 ubeshort x X-Window screen dump image data, version X10
!:mime image/x-xwindowdump
!:ext xwd
Again file name extension is also not clear. TrID and DROID also
mention XDM suffix, but i do not found such examples.
After applying the above mentioned modifications by patch
file-5.41-images-xwd.diff then all my inspected X Window screen dump
examples are now described with more details, also version 10
variant is now recognized and some misidentification vanish. This
now looks like:
MARBLES.XWD: X-Window screen dump image data,
version X11,
1419x1001x24,
order 1, 0 colors 0 entries
betyboop.dmp: X-Window screen dump image data,
version X11, "betyboop",
576x720x1,
2 colors 2 entries
cccgirl1.dmp: X-Window screen dump image data,
version X11, "girl1",
576x454x1,
2 colors 2 entries
fig41.xwd: X-Window screen dump image data,
version X11, "xwdump",
1014x704x8,
order 1, 256 colors 256 entries
, x=24, y=107, 1 border
fmt-401-signature-id-618.xwd: data
hardcopy-x-window-v10.xwd: X-Window screen dump image data,
version X10,
1280x1024x8
hardcopy-x-window-v11.xwd: X-Window screen dump image data,
version X11,
1280x1024x32,
0 colors 0 entries
input.xwd: X-Window screen dump image data,
version X11, "input.xwd",
70x46x24,
order 1, 256 colors 0 entries
lenna.dmp: X-Window screen dump image data,
version X11, "getX",
518x486x1,
2 colors 2 entries
, x=568, y=8, 3 border
mandrill.dmp: X-Window screen dump image data,
version X11, "getX",
518x486x1,
2 colors 2 entries
, x=466, y=18, 3 border
my1xwd.xwd: X-Window screen dump image data,
version X11,
"mypi at pi1: /tmp/test/xwd-pi",
816x618x24,
256 colors 256 entries, x=80, y=128
pal1-v10.xwd: X-Window screen dump image data,
version X10,
127x64x1
pal4-v10.xwd: X-Window screen dump image data,
version X10,
127x64x4
pal4rle-v11.xwd: X-Window screen dump image data,
version X11,
127x64x4,
0 colors 16 entries
pal8-v10.xwd: X-Window screen dump image data,
version X10,
127x64x8
x-fmt-300-signature-id-619.xdm: data
I hope my diff file can be applied in future version of file
utility.
With best wishes,
Jörg Jenderek
- --
Jörg Jenderek
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYnWdLQAKCRCv8rHJQhrU
1rG9AJ9ZgsyLXzDUYguEV6pM0V1rz0t/3QCgjnOaweElSC0gVJqzc/5IzAduGdw=
=oufi
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trid-v-xwd.txt.gz
Type: application/x-gzip
Size: 577 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220507/cb0c4ab6/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nconvert-xwd.txt.gz
Type: application/x-gzip
Size: 776 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220507/cb0c4ab6/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: identify-verbose-xwd.txt.gz
Type: application/x-gzip
Size: 5665 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220507/cb0c4ab6/attachment-0007.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xwud.txt.gz
Type: application/x-gzip
Size: 691 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220507/cb0c4ab6/attachment-0008.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: droid-xwd.csv.gz
Type: application/x-gzip
Size: 745 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220507/cb0c4ab6/attachment-0009.bin>
-------------- next part --------------
--- file-5.41/magic/Magdir/images.old 2021-10-18 16:20:03.000000000 +0200
+++ file-5.41/magic/Magdir/images 2022-05-06 23:59:27.355781700 +0200
@@ -1193,21 +1193,136 @@
# XWD - X Window Dump file.
+# URL: http://fileformats.archiveteam.org/wiki/XWD
+# Reference: https://wiki.multimedia.cx/index.php?title=XWD
+# http://mark0.net/download/triddefs_xml.7z/defs/x/xdm-x11.trid.xml
+# Note: called "X-Windows Screen Dump (X11)" by TrID and
+# "X-Windows Screen Dump" version X11 by DROID via PUID fmt/483
+# verfied by XnView `nconvert -in xwd -info *`
+# and ImageMagick 6.9.11 `identify -verbose *` as XWD X Windows system window dump
+# and `xwud -in fig41.wxd -dumpheader`
# As described in /usr/X11R6/include/X11/XWDFile.h
# used by the xwd program.
# Bradford Castalia, idaeim, 1/01
-# updated by Adam Buchbinder, 2/09
+# updated by Adam Buchbinder, 2/09 and Joerg Jenderek, May 2022
# The following assumes version 7 of the format; the first long is the length
# of the header, which is at least 25 4-byte longs, and the one at offset 8
# is a constant which is always either 1 or 2. Offset 12 is the pixmap depth,
# which is a maximum of 32.
-0 belong >100
+# Size of the entire file header (bytes) like: 100 104 105 106 107 109 110 113 114 115 118 172
+0 belong >99
+# pixmap_format; Pixmap format; 0~1-bit (XYBitmap) format 1~single-plane (XYPixmap) 2~bitmap with two or more planes (ZPixmap)
>8 belong <3
+# pixmap_depth; Pixmap depth; value 1 - 32
>>12 belong <33
->>>4 belong 7 XWD X Window Dump image data
+# file_version; XWD_FILE_VERSION=7
+>>>4 belong 7
+# skip DROID fmt-401-signature-id-618.xwd by test for existing border field
+>>>>96 ubelong x X-Window screen dump image data, version X11
+# ./images (version 1.205) labeled the above entry as "XWD X Window Dump image data"
+# https://reposcope.com/mimetype/image/x-xwindowdump
!:mime image/x-xwindowdump
->>>>100 string >\0 \b, "%s"
->>>>16 belong x \b, %dx
->>>>20 belong x \b%dx
->>>>12 belong x \b%d
+#!:ext xwd
+!:ext xwd/dmp
+# https://www.xnview.com/en/image_formats/ NO example with x11 suffix FOUND!
+#!:ext xwd/dmp/x11
+# https://www.nationalarchives.gov.uk/PRONOM/fmt/401 NO example with xdm suffix FOUND!
+#!:ext xwd/dmp/x11/xmd
+# file comment if header > 100; so not in MARBLES.XWD and hardcopy-x-window-v11.xwd
+>>>>>0 belong >100
+# comment or windows name
+>>>>>>100 string >\0 \b, "%s"
+# pixmap_width; pixmap width like: 576 800 1014 1280 1419 NOT -1414812757=abABabABh
+>>>>>16 belong x \b, %dx
+# pixmap_height; pixmap height like: 449 454 600 704 720 1001 1024 NOT -1414812757=abABabABh
+>>>>>20 belong x \b%dx
+# pixmap_depth; pixmap depth
+>>>>>12 belong x \b%d
+# XOffset; Bitmap X offset; pixel numbers to ignore at the beginning of each scan-line
+#>>>>>24 ubelong x \b, %u ignore
+# ByteOrder; byte order of image data: 0~least significant byte first 1~most significant byte first
+>>>>>28 ubelong >0 \b, order %u
+# BitmapUnit; bitmap base data size unit in each scan line like: 8 16 32
+#>>>>>32 ubelong x \b, unit %u
+# BitmapBitOrder; bit-order of image data; apparently same as ByteOrder
+#>>>>>36 ubelong x \b, bit order %u
+# BitmapPad; number of padding bits added to each scan line like: 8 16 32
+#>>>>>40 ubelong x \b, pad %u
+# BitsPerPixel; Bits per pixel: 1~StaticGray and GrayScale 2-15~StaticColor and PseudoColor 16,24,32~TrueColor and DirectColor
+#>>>>>44 ubelong x \b, %u bits/pixel
+# BytesPerLine; size of each scan line in bytes
+#>>>>>48 ubelong x \b, %u bytes/line
+# VisualClass; class of the image: 0~StaticGray 1~GrayScale 2~StaticColor 3~PseudoColor 4~TrueColor 5~DirectColor
+#>>>>>52 ubelong x \b, %u Class
+# RedMask; red RGB mask values used by ZPixmaps like: 0 0xff0000
+#>>>>>56 ubelong !0 \b, %#x red
+# GreenMask; green mask like: 0
+#>>>>>60 ubelong !0 \b, %#x green
+# BlueMask; blue mask like: 0 0xff
+#>>>>>64 ubelong !0 \b, %#x blue
+# BitsPerRgb; Size of each color mask in bits like: 0 1 8 24
+#>>>>>68 ubelong x \b, %u bits/RGB
+# NumberOfColors; number of colors in image like: 256 4 2 0 (WHAT DOES THIS MEAN?)
+>>>>>72 ubelong x \b, %u colors
+# ColorMapEntries; number of entries in color map like: 256 16 2 0~no color map
+>>>>>76 ubelong x %u entries
+# WindowWidth; window width
+#>>>>>80 ubelong x \b, %u width
+# WindowHeight; window height
+#>>>>>84 ubelong x \b, %u height
+# WindowX; Window upper left X coordinate like: 0 24 32 80 237 290 422 466 568 (lenna.dmp)
+>>>>>88 belong !0 \b, x=%d
+# WindowY; Window upper left Y coordinate like: 0 8 18 26 60 73 107 (fig41.xwd) 128
+>>>>>92 belong !0 \b, y=%d
+# WindowBorderWidth; Window border width; apparently pixmap_width=WindowWidth+2*WindowBorderWidth
+# like: 1 (fig41.xwd) 2 (maze.dmp) 3 (lenna.dmp mandrill.dmp)
+>>>>>96 ubelong >0 \b, %u border
+# From: Joerg Jenderek
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/x/xdm-x10.trid.xml
+# Note: called "X-Windows Screen Dump (X10)" by TrID and
+# "X-Windows Screen Dump" version X10 by DROID via PUID x-fmt/300
+# verfied by XnView `nconvert -in xwd -info *`
+# HeaderSize is the size of the header in bytes; always 40 for X10 variant
+0 belong =0x000000028
+# FileVersion; always 6 for X10 variant
+>4 belong =6
+# skip DROID x-fmt-300-signature-id-619.xdm by test existing border field
+>>36 ubeshort x X-Window screen dump image data, version X10
+!:mime image/x-xwindowdump
+!:ext xwd
+# http://www.nationalarchives.gov.uk/pronom/fmt/401 NO example with xdm suffix FOUND!
+#!:ext xwd/xdm
+# PixmapWidth; pixmap width like: 127 1280
+>>>20 ubelong x \b, %d
+# PixmapHeight; pixmap height like: 64 1024
+>>>24 ubelong x \bx%d
+# DisplayPlanes; number of display planes like: 1 4 8
+>>>12 ubelong x \bx%u
+# DisplayType; display type like: 1 3
+#>>>8 ubelong x \b, type %u
+# PixmapFormat; pixmap format like: 1~bitmap with two or more planes (ZPixmap) 0~single-plane bitmap (XYBitmap)
+#>>>16 ubelong x \b, %u format
+# WindowWidth; window width; probably PixmapWidth=WindowWidth+2*WindowBorderWidth
+#>>>28 ubeshort x \b, width %u
+# WindowHeight; window height; probably PixmapWidth=PixmapHeight+2*WindowBorderWidth
+#>>>30 ubeshort x \b, height %u
+# WindowX; window upper left X coordinate like: 0
+>>>32 beshort !0 \b, x=%d
+# WindowY; window upper left Y coordinate like: 0
+>>>34 beshort !0 \b, y=%d
+# WindowBorderWidth; window border width like: 0
+>>>36 ubeshort !0 \b, %u border
+# WindowNumColors; Number of color entries in window like: 2 16 256
+#>>>38 ubeshort x \b, %u colors
+# if the image is a PseudoColor image, a color map immediately follows the header. X10COLORMAP[WindowNumColors];
+# EntryNumber; number of the color-map entry like: 0
+#>>>40 ubeshort x \b, colors #%u
+# Red; red-channel value
+#>>>42 ubeshort !0 \b, red %#x
+# Green; green-channel value
+#>>>44 ubeshort !0 \b, green %#x
+# Blue; blue-channel value
+#>>>46 ubeshort !0 \b, blue %#x
+# 2ND Entry like: 2
+#>>>48 ubeshort x \b, colors #%u
# PDS - Planetary Data System
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.41-images-xwd.diff.sig
Type: application/octet-stream
Size: 2935 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220507/cb0c4ab6/attachment-0001.obj>
More information about the File
mailing list