[File] [PATCH] Magdir/images for X Window Dump image; undetected MARBLES.XWD ...
Christos Zoulas
christos at zoulas.com
Mon May 9 18:35:49 UTC 2022
On 2022-05-06 18:11, Jörg Jenderek wrote:
Committed!
Thanks,
christos
> -----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-----
--
christos
More information about the File
mailing list