[File] [PATCH] Magdir/images, claris Macintosh QuickDraw PICT versus Claris clip art
Jörg Jenderek (GMX)
joerg.jen.der.ek at gmx.net
Sun May 19 22:56:48 UTC 2024
Hello,
some days ago i must an old CD-ROM. This contains graphical pictures
with file name extension pict, pic or pct. When running file command
version 5.45 on such graphics and related files i get an output like:
016.pict: data
062A_fnr.N.pict: data
20071025155910162.pct: data
8_PriceFixingCartoon.pct: data
Compact Pro.010.pict: data
FC80.PCT: data
FC9.PCT: data
LEAF_(2).PIC: Yanagisawa PIC image file, model: X68000,
256x256, colors: 256
MS.PCT: data
PICT_129.pict: Claris clip art
PICT_2012.pict: Claris clip art
PPIC0821.PICT: data
TL_FACES.PIC: Yanagisawa PIC image file, model: X68000,
288x256, colors: 16
abydos.raw.pict: data
circlemask.pct: data
fbobt2.pic: data
flag_b24.pct: data
fmt-341-signature-id-468.pct: data
fmt-341-signature-id_468.pct: data
les38.pic: data
test-claris1.bin: Claris clip art
x-fmt-80-signature-id-859.pct: data
x-fmt-80-signature-id-860.pct: data
With option --extension only ??? are shown and with -i
option only generic application/octet-stream is shown.
For comparison reason i run the file format identification utility
TrID ( See https://mark0.net/soft-trid-e.html). Most samples are
"recognized correctly" and described as "QuickDraw/PICT bitmap" but not
with highest priority. Here 3 file name suffix (.PCT/PICT/PIC) and mime
type image/pict are listed. Most of the recognized samples are described
with additional phrase (v2) for version number 2 by pict-v2.trid.xml.
A few samples (like "Compact Pro.010.pict", FC80.PCT, FC9.PCT) are
described with additional phrase (v1) for version number 1 by
pict-v1.trid.xml. A sample MS.PCT is described wrong as other file type
with description "PIC bitmap" by bitmap-pic.trid.xml like also for samples
LEAF_(2).PIC TL_FACES.PIC. Many samples are described with highest
priority wrong as "HomeLab/BraiLab Tape image" with file name suffix
(.HTP) by img-htp.trid.xml. The "artificial" DROID sample
x-fmt-80-signature-id-859.pct is not recognized. The "artificial" DROID
sample x-fmt-80-signature-id-860.pct is described as version 1 variant.
The "artificial" DROID fmt-341-signature-id-468.pct is described as
version 2 variant. A few version 2 variants (like 8_PriceFixingCartoon.pct)
are also described with higher priority as "Macintosh Quickdraw/PICT
Drawing" without version phrase by pict.trid.xml. Many samples are also
described wrong with low priority as "Adobe PhotoShop Brush" by
abr.trid.xml, "Sybase iAnywhere database files" by
sybase-ianywhere-dbf.trid.xml, "Warcraft game data archive" by
war-wc.trid.xml, "MacBinary 1" by macbinary-1.trid.xml , "Photoshop
Action" by atn.trid.xml, "PrintFox/Pagefox bitmap (640x800)" by
bitmap-printfox-p.trid.xml, "Memo File Apollo Database Engine" by
smt-apollo.trid.xml, "VXD Driver" by vxd.trid.xml, "Pro Pixel Demo
Image" by pp2d.trid.xml. These are triggered by unspecific patterns (
especially few nil bytes near the beginning (See appended
trid-v-pict.txt.gz).
For comparison reason i also run the file format identification
utility DROID ( See https://sourceforge.net/projects/droid/).
Here all Macintosh graphics are recognized and described as "Macintosh
PICT Image". All three file name suffix (pict pct pic) are considered as
valid. Here correct mime type image/x-pict is shown. The version two
variants are marked with additional 2.0 version field by PUID fmt/341.
This is represented by fmt-341-signature-id-468.pct. This is not a real
graphic but just contain the first bytes of such a graphic.
The version one variants are marked with additional 1.0 version field by
PUID x-fmt/80. This is represented by x-fmt-80-signature-id-859.pct and
x-fmt-80-signature-id-860.pct. These are not a real graphics but just
contain the first bytes of such a graphic. The first contains 6 byte
DRWGMD at the beginning whereas the second contains here only nil bytes.
The samples with other file format (like TL_FACES.PIC LEAF_(2).PIC) are
not recognized (See appended droid-pict.csv.gz)
On Linux according to shared MIME-info database such samples are called
"Macintosh Quickdraw/PICT drawing". Here also correct image/x-pict is
used as mime type. The version 2 samples are just recognized by looking
for byte sequence 0x001102FF0C00FFFE at offset 522 or 10. Here 4 file
name suffix (pict2 pict1 pict pct) are listed. That information can be
seen in source freedesktop.org.xml.in found for example on
gitlab.freedesktop.org.
Luckily with information given by the other tools i also found a
page about PICT on Wikipedia and file formats archive team web site.
There also links for samples, suited software and references are listed.
That information is expressed by comment lines inside Magdir/images like:
# URL: http://justsolve.archiveteam.org/wiki/PICT
# https://en.wikipedia.org/wiki/PICT
# Reference: https://www.fileformat.info/format/macpict/egff.htm
# http://web.archive.org/web/20010703041301/
# http://developer.apple.com/technotes/qd/qd_14.html
# http://mark0.net/download/triddefs_xml.7z
# defs/p/pict-v2.trid.xml
# defs/p/pict-v1.trid.xml
# defs/p/pict.trid.xml
There you find download links for samples like the above inspected ones.
There i also found links to software (like LibreOffice Deark XnView)
ImageMagick Netpbm). With the help of these tools i could handle many of
my inspected samples. I also could verify, convert samples partly
(See appended deark-pict.txt.gz nconvert-pict.txt.gz
identify-pict.txt.gz picttoppm-pict.txt) with command lines like:
deark -m pict -l -d2 flag_b24.pct
nconvert -in pict -fullinfo *.pict *.pct *.pic
identify PPIC0821.PICT
picttoppm venus.pct | file
The DROID samples are correctly neither recognized nor converted by any
of these tools. I also tried LibreOffice Draw. This display some samples
and some not.
For real examples the first point has usually coordinate (0,0) and for
the second i get positive values. For the DROID samples we got here all
The description now starts at the end inside Magdir/images by lines like:
522 ubelong 0x001102ff
!:strength +11
>526 ubeshort 0x0c00
>>520 ubeshort !0
>>>0 long !0xABABABAB Macintosh QuickDraw PICT, version 2
!:mime image/x-pict
!:apple ????PICT
!:ext pict/pic/pct
By first line test for version operator (0011h) and version number
(02FFh). Afterwards i rise magic strength from 70 to 81 by adding 11. So
few Macintosh QuickDraw with one corner at -1/-1 coordinates (like
PICT_129.pict PICT_2012.pict) now comes before "Claris clip art" handled
by Magdir/claris with strength 80. By second test line i look for
Version operator (0C00h). By third test line i skip DROID samples
fmt-341-signature-id-468.pct with invalid dimension x=0.
By forth test line i skip a DROID sample variant where 0xAB instead 0x0
is used to fill variables. Some tools like TrID use image/pict as mime
type, but such type is not officially registered at IANA. So i display
used defined type as it is done by DROID and Wikipedia. One file name
suffix is 4 byte pict. Apparently to overcomes 8+3 limits on FAT16 file
system two 3 byte suffix (pic pct) are also used. According to page
about supported formats by xnview also 5 bytes suffix pict2 is valid. I
assume that this is used to explicitly distinguish version 2 variant
from version 1 variant. Unfortunately i myself found no examples with
this suffix. So i do use it and mention this observation in a comment
line. If i understand documents right than such pictures can contain
bitmap and/or vector graphics. So i avoid phrase like image or drawing
in my description because i do not know how to distinguish these 2
graphic types. I do not know if this the reason why many software fail
on some examples.
A few samples (like 8_PriceFixingCartoon.pct) are described by TrID
with higher priority compared to version 2 as "Macintosh Quickdraw/PICT
Drawing" by pict.trid.xml. When comparing this definition with version 2
variant i got here additional lines inside global strings section like:
<String>DECOMPRESSOR'(</String>
<String>QUICKTIME</String>
<String>APPL</String>
When i open such samples in LibreOffice it shows only a text box with
sentence like "QuickTime™ and a None decompressor are needed to see this
picture". Instead the phrase "None" i also found "Cinepak" in
fbobt2.pic, "Compact Video" in les38.pic and "Photo - JPEG" in 016.pict.
When looking in deark output i see that that such a sentence is often
produced by 3 parts ( See as line break in LibreOffice) by LongText
opcode (0x0028). But this only the message for the user. The real
content is done by CompressedQuickTime opcode 0x8200. Unfortunately this
occurs on different offsets (like 574 584) and with different
compression types. Therefore i use the message fragments to do sub
classification. So i look for LongText QuickTime followed by trademark
character. Then look for LongText afterwords like "and a/None|
Cinepak|Photo - JPEG decompressor/are needed to see this picture".
The "Cinepak" and "Compact Video" decompressor seems to be cvid. So this
looks like:
>>>>554 search/691976/b QuickTime\252 \b, QuickTime
>>>>>&0 search/28/bs \040decompressor with decompressor
>>>>>>&-4 string None None
>>>>>>&-7 string Cinepak Cinepak
>>>>>>&-12 string Photo\040-\040JPEG JPEG
>>>>>>&-13 string Compact\040Video cvid
>>>>>>&-6 default x
>>>>>>>&0 string x "%0.6s"
The file size in bytes is stored at offset 512, but this seems to be not
reliable; because sometimes 0 or little smaller than real size is shown.
Maybe this depends also on other sub parameter i do not know. So i do
not show this and add it as a comment line like:
#>>>>512 ubeshort x \b, size %u
Afterwards comes 8 bytes picFrame (rectangle). In the mentioned
documentation at Encyclopedia of Graphics File Formats (egff) the x and
y dimension are swapped compared to XnView, ImageMagick, Netpbm and
Deark. In most examples one corner is located at coordinates 0/0. In few
samples like (like 062A_fnr.N.pict "Compact Pro.010.pict") the corner is
locate at low positive values. So to get dimension of whole picture that
value must be subtracted. But in some case (like PICT_129.pict
PICT_2012.pict) i get her negative value. So negative value must be
subtracted (shown by 2 byte --). At this point nearly all software
except deark fail for such cases. So dimensions are shown by lines like:
#>>>>518 ubeshort x Y=%#4.4x
>>>>520 ubeshort x \b, %u
>>>>>516 beshort !0 \b-%d
>>>>518 ubeshort x x %u
>>>>>514 beshort !0 \b-%d
Unfortunately i get duplicates messages for few samples with coordinates
-1/-1 and Y=0x01?? (like Y=x0118 in PICT_129.pict) or 0x00?? (like
Y=0x0047 in PICT_2012.pict). These are also interpreted as "Claris clip
art" (magic strength=80) by Magdir/claris with lines like:
514 string \377\377\377\377\000
>0 string \0\0\0\0\0\0\0\0\0\0\0\0\0 Claris clip art
514 string \377\377\377\377\001
>0 string \0\0\0\0\0\0\0\0\0\0\0\0\0 Claris clip art
Unfortunately i found no samples or file specification for Claris clip
art. So maybe such clip art are in reality Macintosh QuickDraw or a
complete other file format. I try to simulate this by artificial example
test-claris1.bin. But in the end by rasing magic string from 70 to 81
the Macintosh QuickDraw messages comes first. The samples with such
duplicated are found on:
https://sembiance.com/fileFormatSamples/image/pict/
According to DROID at the beginning (512 byte header) all bytes are
zeros or contain information about the particular software (like PICT).
So show for "non zero" samples that information by line like:
>>>>0 long !0 \b, at 0
>>>>>0 string x %.4s
The samples with 512 zero header bytes are described by TrID with
highest priority therefore as "HomeLab/BraiLab Tape image" by
img-htp.trid.xml. A few samples are not described in that way. The
sample 062A_fnr.N.pic start with nil bytes but contain some nil bytes in
header. So here "HomeLab/BraiLab Tape image" is missing. Even worse
sample like MS.PCT is not recognized by TrID because it starts with 4
byte PICT string, where TrID expects nil bytes at that position.
The version 2.0 files also have a 26-byte header following the version
information. In my examples found 3 values (like 0 FFFEh FFFFh). The
freedesktop shared mime database expects here the second value.
The Encyclopedia of Graphics File Formats (egff) also accepts here the
third values and other tools make no assumption about that value here.
So i do not know if this is a hint for a sub classification. So i show
this values by line like:
>>>>528 ubeshort x \b, at 528 %#4.4x
Then after that 26-byte header comes the second opcode. Here i get
different values (like 0x0000~NOP 0x0001~Clip 0x00a0~ShortComment
0x00a1~LongComment 0x001e~DefHilite 0x001f~OpColor). So show this
values, that maybe can be used as hint for sub classification or gives
more strength to recognizing patterns. So this done by line like:
>>>>552 ubeshort x \b, at 552 second opcode %#4.4x
According to documents the last opcode is opEndPic (00FFh). So show
unexpected values (like in artificial test-claris1.bin) by line like:
>>>>-2 ubeshort !0x00FF \b, at the end %4.4x opcode
Unfortunately i could not use this as additional test because afterwards
i can not access the bytes at offset 0. Maybe this is a bug in program?
Then in principal i do the same procedure for version 1 variant which
shares some structures with version 2 variant. The main difference is
that here opcode use only 1 byte whereas for version 2 variant 2 bytes
are used.
Unfortunately i get no 32 bit for recognition here. To overcome i put
displaying part in sub routine mac-pict1. The first test checks for 1
byte opcode for picversion (11h) and next byte version number (1). In my
inspected samples the next opcode was clipRgn (1h), which seems to the
standard. So by second test line i skip DROID
x-fmt-80-signature-id-859.pct x-fmt-80-signature-id-860.pct. This looks
like:
522 ubeshort 0x1101
>524 ubyte =0x01
>>0 use mac-pict1
0 name mac-pict1
>520 ubeshort x Macintosh QuickDraw PICT, version 1
So this was sufficient for me. If there exist samples with other second
opcode or collisions with other file formats, then more branches and
test lines must be added. But i am not a Macintosh expert. So i can not
do this with the rare and incomplete mentioned documentation.
After applying the above mentioned modifications by patches
file-images-pict.diff and file-claris-pict.diff and using
Magdir/x68000 then all my inspected Macintosh graphics are now
described. Also dimension informations are shown. The description as
"Claris clip art" which is probably wrong, now comes second and
"artificial" DROID samples are skipped. This with -k option then looks like:
016.pict: Macintosh QuickDraw PICT, version 2,
QuickTime with decompressor JPEG,
128 x 128,
at 528 0xfffe, at 552 2nd opcode 0x001e
062A_fnr.N.pict: Macintosh QuickDraw PICT, version 2,
1015 x 744-7,
at 528 0xffff, at 552 2nd opcode 0x00a0
20071025155910162.pct: Macintosh QuickDraw PICT, version 2,
387 x 409,
at 528 0xfffe, at 552 2nd opcode 0x00a1
8_PriceFixingCartoon.pct: Macintosh QuickDraw PICT, version 2,
QuickTime with decompressor None,
480 x 360,
at 528 0xfffe, at 552 2nd opcode 0x001e
Compact Pro.010.pict: Macintosh QuickDraw PICT, version 1,
616-200 x 751-750
FC80.PCT: Macintosh QuickDraw PICT, version 1,
1083 x 1389
FC9.PCT: Macintosh QuickDraw PICT, version 1,
2954 x 2682
LEAF_(2).PIC: Yanagisawa PIC image file, model: X68000,
256x256, colors: 256
MS.PCT: Macintosh QuickDraw PICT, version 2,
23 x 23,
at 0 PICT,
at 528 0xfffe, at 552 2nd opcode 0x0000
PICT_129.pict: Macintosh QuickDraw PICT, version 2,
357--1 x 280--1,
at 528 0xffff, at 552 2nd opcode 0x00a1
Claris clip art
PICT_2012.pict: Macintosh QuickDraw PICT, version 2,
349--1 x 71--1,
at 528 0xffff, at 552 2nd opcode 0x00a1
Claris clip art
PPIC0821.PICT: Macintosh QuickDraw PICT, version 2,
872 x 698,
at 528 0xfffe, at 552 2nd opcode 0x001e
TL_FACES.PIC: Yanagisawa PIC image file, model: X68000,
288x256, colors: 16
abydos.raw.pict: Macintosh QuickDraw PICT, version 2,
800 x 600,
at 528 0xfffe, at 552 2nd opcode 0x001e
circlemask.pct: Macintosh QuickDraw PICT, version 2,
640 x 480,
at 528 0xfffe, at 552 2nd opcode 0x00a1
fbobt2.pic: Macintosh QuickDraw PICT, version 2,
QuickTime with decompressor Cinepak,
240 x 180,
at 528 0xffff, at 552 2nd opcode 0x001f
flag_b24.pct: Macintosh QuickDraw PICT, version 2,
124 x 124,
at 528 0x0000, at 552 2nd opcode 0x0001
fmt-341-signature-id-468.pct: data
fmt-341-signature-id_468.pct: data
les38.pic: Macintosh QuickDraw PICT, version 2,
QuickTime with decompressor cvid,
240 x 180,
at 528 0xffff, at 552 2nd opcode 0x001f
test-claris1.bin: Macintosh QuickDraw PICT, version 2,
152--1 x 139--1,
at 528 0x0000, at 552 2nd opcode 0x0000
, at the end 0xaaff opcode
Claris clip art
x-fmt-80-signature-id-859.pct: data
x-fmt-80-signature-id-860.pct: data
I hope my diff files can be applied in future version of file
utility. In my inspected cases all have the 512 header. So maybe
existing samples without this header are missed. Furthermore the
collision with "Claris clip art" is not really solved. Furthermore the
file name suffix PIC is used by many other file graphic picture formats
like "Yanagisawa PIC image file".
With best wishes,
Jörg Jenderek
--
Jörg Jenderek
-------------- next part --------------
--
File mailing list
File at astron.com
https://mailman.astron.com/mailman/listinfo/file
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trid-v-pict.txt.gz
Type: application/x-gzip
Size: 1902 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240519/0c62b67a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: droid-pict.csv.gz
Type: application/x-gzip
Size: 982 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240519/0c62b67a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: identify-pict.txt.gz
Type: application/x-gzip
Size: 810 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240519/0c62b67a/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nconvert-pict.txt.gz
Type: application/x-gzip
Size: 936 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240519/0c62b67a/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: deark-pict.txt.gz
Type: application/x-gzip
Size: 113002 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240519/0c62b67a/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: picttoppm-pict.txt.gz
Type: application/x-gzip
Size: 643 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240519/0c62b67a/attachment-0005.bin>
-------------- next part --------------
--- file-master/magic/Magdir/claris.old 2022-05-27 18:06:00.000000000 +0200
+++ file-master/magic/Magdir/claris 2024-05-20 00:07:56.137416800 +0200
@@ -3,6 +3,8 @@
# $File: claris,v 1.8 2016/07/18 19:23:38 christos Exp $
# claris: file(1) magic for claris
# "H. Nanosecond" <aldomel at ix.netcom.com>
+# Update: Joerg Jenderek 2024 May
+# URL: https://en.wikipedia.org/wiki/AppleWorks
# Claris Works a word processor, etc.
# Version 3.0
@@ -12,8 +14,14 @@
#0001000 #010 250 377 377 377 377 000 213 000 230 000 021 002 377 014 000
#null to byte 1000 octal
514 string \377\377\377\377\000
+# https://sembiance.com/fileFormatSamples/image/pict/
+# Claris clip art (strength=80) after few Macintosh QuickDraw (strength=81=70+11 ./images) with corner coordinates -1/-1 and Y=0x00?? like PICT_2012.pict
+#!:strength +0
>0 string \0\0\0\0\0\0\0\0\0\0\0\0\0 Claris clip art
514 string \377\377\377\377\001
+# https://sembiance.com/fileFormatSamples/image/pict/
+# Claris clip art (strength=80) after few Macintosh QuickDraw (strength=81=70+11 ./images) with corner coordinates -1/-1 and Y=0x01?? like PICT_129.pict
+#!:strength +0
>0 string \0\0\0\0\0\0\0\0\0\0\0\0\0 Claris clip art
# Claris works files
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-claris-pict.diff.sig
Type: application/octet-stream
Size: 734 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240519/0c62b67a/attachment.obj>
-------------- next part --------------
--- file-master/magic/Magdir/images.old 2024-05-12 17:26:55.211533800 +0200
+++ file-master/magic/Magdir/images 2024-05-20 00:43:59.031282900 +0200
@@ -4420,3 +4420,101 @@
>>&1 string x \b, sizes: %s
>0 search encoding:
>>&1 string x \b, encoding: %s
+
+# From: Joerg Jenderek
+# URL: http://justsolve.archiveteam.org/wiki/PICT
+# https://en.wikipedia.org/wiki/PICT
+# Reference: https://www.fileformat.info/format/macpict/egff.htm
+# http://mark0.net/download/triddefs_xml.7z/defs/p/pict-v2.trid.xml
+# Note: called "Macintosh Quickdraw/PICT drawing" by shared MIME-info database from freedesktop.org,
+# "QuickDraw/PICT bitmap (v2)" by TrID and "Macintosh PICT Image" version 2.0 by DROID via PUID via fmt/341
+# verified by command like `deark -m pict -l -d2 flag_b24.pct` as PICT v2,
+# partly by NetPBM `picttoppm venus.pct | file` as "Macintosh PICT",
+# partly by ImageMagick `identify -verbose flag_b24.pct` as (Apple Macintosh QuickDraw/PICT) and
+# partly by XnView `nconvert -fullinfo *.pict *.pic *.pct` as "Macintosh PICT 2"
+# look for version operator (0011h) and version number (02FFh)
+522 ubelong 0x001102ff
+# few Macintosh QuickDraw with one corner at -1/-1 coordinates like PICT_129.pict PICT_2012.pict (strength=81=70+11) before Claris clip art (strength=80 ./claris)
+!:strength +11
+# look for Version operator (0C00h)
+>526 ubeshort 0x0c00
+# skip DROID fmt-341-signature-id-468.pct with invalid dimension x=0
+>>520 ubeshort !0
+# skip DROID variant fmt-341-signature-id-468.pct using 0xAB instead 0x0
+>>>0 long !0xABABABAB Macintosh QuickDraw PICT, version 2
+#!:mime application/octet-stream
+!:mime image/x-pict
+!:apple ????PICT
+!:ext pict/pic/pct
+# maybe also suffix pict2 https://www.xnview.com/de/image_formats/
+#!:ext pict2/pict/pic/pct
+# Reference: http://mark0.net/download/triddefs_xml.7z/defs/p/pict.trid.xml
+# Note: called "Macintosh Quickdraw/PICT Drawing" by TrID
+# "real" content stored by opcode 0x8200 (CompressedQuickTime *.qtif) with none, cvid or JPEG compression
+# look for LongText QuickTime followed by trademark character
+>>>>554 search/691976/b QuickTime\252 \b, QuickTime
+# look for LongText afterwards like "and a/None|Cinepak|Photo - JPEG decompressor/are needed to see this picture"
+>>>>>&0 search/28/bs \040decompressor with decompressor
+>>>>>>&-4 string None None
+# Cinepak and "Compact Video decompressor" seems to be cvid
+>>>>>>&-7 string Cinepak Cinepak
+>>>>>>&-12 string Photo\040-\040JPEG JPEG
+>>>>>>&-13 string Compact\040Video cvid
+# case where decompression is not like: Cinepak None "Photo - JPEG" "Compact Video decompressor"
+>>>>>>&-6 default x
+>>>>>>>&0 string x "%0.6s"
+# file size in bytes; not reliable sometimes 0 or little smaller than real size
+#>>>>512 ubeshort x \b, size %u
+# 8 bytes picFrame (rectangle); for most examples one corner is located at coordinates 0/0; except deark other tools fail when negative values
+# GRR: samples with coordinates -1/-1 and Y=0x01??|0x00?? are interpreted as "Claris clip art" (strength=80 ./claris)
+#>>>>518 ubeshort x Y=%#4.4x
+>>>>520 ubeshort x \b, %u
+>>>>>516 beshort !0 \b-%d
+>>>>518 ubeshort x x %u
+>>>>>514 beshort !0 \b-%d
+# Note: at the beginning all zeros or information about the particular software like: PICT
+>>>>0 long !0 \b, at 0
+>>>>>0 string x %.4s
+# version 2.0 files also have a 26-byte header following the version information
+# like: 0 FFFEh (freedesktop egff~Encyclopedia of Graphics File Formats) FFFFh (egff)
+>>>>528 ubeshort x \b, at 528 %#4.4x
+# 2nd opcode like: 0x0000~NOP 0x0001~Clip 0x00a0~ShortComment 0x00a1~LongComment 0x001e~DefHilite 0x001f~OpColor
+>>>>552 ubeshort x \b, at 552 second opcode %#4.4x
+# last opcode if not opEndPic (00FFh)
+>>>>-2 ubeshort !0x00FF \b, at the end %#4.4x opcode
+# Reference: http://web.archive.org/web/20010703041301/http://developer.apple.com/technotes/qd/qd_14.html
+# http://mark0.net/download/triddefs_xml.7z/defs/p/pict-v1.trid.xml
+# Note: called "QuickDraw/PICT bitmap (v1)" by TrID and "Macintosh PICT Image" version 1.0 by DROID via PUID via x-fmt/80
+# verified by command like `deark -m pict -l -d2 FC9.PCT` as PICT v1,
+# by ImageMagick `identify -verbose *.pict` as PICT (Apple Macintosh QuickDraw/PICT) and
+# by XnView `nconvert -fullinfo *.pict *.pct` as "Macintosh PICT"
+# 1 byte opcode for picversion (11h); next byte version number (1)
+522 ubeshort 0x1101
+# skip DROID x-fmt-80-signature-id-859.pct x-fmt-80-signature-id-860.pct without next opcode usually clipRgn (1h)
+>524 ubyte =0x01
+>>0 use mac-pict1
+# display Macintosh PICT drawing version 1 information
+0 name mac-pict1
+>520 ubeshort x Macintosh QuickDraw PICT, version 1
+#!:mime application/octet-stream
+!:mime image/x-pict
+!:apple ????PICT
+!:ext pict/pct
+# maybe also suffix pict1 and pic
+#!:ext pict1/pict/pic/pct
+# file size in bytes; not reliable sometimes 0 or smaller than real size
+#>512 ubeshort x \b, size %u
+# 8 bytes picFrame (rectangle)
+>520 ubeshort x \b, %u
+>516 ubeshort !0 \b-%u
+>518 ubeshort x x %u
+>514 ubeshort !0 \b-%u
+# Note: According to DROID at the beginning all zeros or information about the particular software like DRWG(MD|D2)
+>0 long !0 \b, at 0
+>>0 string x %.6s
+>>0 ubelong x %#8.8x
+>>4 ubeshort x \b%4.4x
+# 2nd opcode if not clipRgn (1h)
+>524 ubyte !0x01 \b, at 524 %#2.2x opcode
+# last opcode if not opEndPic (FFh)
+>-1 ubyte !0xFF \b, at the end %#2.2x opcode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-images-pict.diff.sig
Type: application/octet-stream
Size: 2431 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20240519/0c62b67a/attachment-0001.obj>
More information about the File
mailing list