gabriel rosenkoetter on Thu, 22 Aug 2002 18:30:10 +0200


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] reading old jpeg format?


On Thu, Aug 22, 2002 at 05:01:12PM +0200, Jeff Abrahamson wrote:
> No problem: <http://www.purple.com/image.bin>.

Ummm... that file extension screams MacBinary compression.
Decompress it. This should match it:

122 beshort&0xFCFF  0x8081    Macintosh MacBinary data

... but I just downloaded it and it doesn't.

Perhaps you've managed to flip the endianness of it somewhere along
the line?

Ah, this might explain it:

# MacBinary format (Eric Fischer, enf@pobox.com)
#
# Unfortunately MacBinary doesn't really have a magic number prior
# to the MacBinary III format.  The checksum is really the way to
# do it, but the magic file format isn't up to the challenge.
#
[Specifics of the file format, clipped for brevity]
#
# This attempts to use the version numbers as a magic number, requiring
# that the first one be 0x80, 0x81, 0x82, or 0x83, and that the second
# be 0x81.  This works for the files I have, but maybe not for everyone's.

122 beshort&0xFCFF  0x8081    Macintosh MacBinary data

# MacBinary I doesn't have the version number field at all, but MacBinary II
# has been in use since 1987 so I hope there aren't many really old files
# floating around that this will miss.  The original spec calls for using
# the nulls in 0, 74, and 82 as the magic number.
#
# Another possibility, that would also work for MacBinary I, is to use
# the assumption that 65-72 will all be ASCII (0x20-0x7F), that 73 will
# have bits 1 (changed), 2 (busy), 3 (bozo), and 6 (invisible) unset,
# and that 74 will be 0.  So something like
# 
# 71  belong&0x80804EFF 0x00000000  Macintosh MacBinary data
# 
# >73 byte&0x01 0x01    \b, inited
# >73 byte&0x02 0x02    \b, changed
# >73 byte&0x04 0x04    \b, busy
# >73 byte&0x08 0x08    \b, bozo
# >73 byte&0x10 0x10    \b, system
# >73 byte&0x10 0x20    \b, bundle
# >73 byte&0x10 0x40    \b, invisible
# >73 byte&0x10 0x80    \b, locked

Using that second matching method gets me:
humbug:~% file -m tmp/magic image.bin
file: Using regular magic file `tmp/magic'
image.bin: Macintosh MacBinary data, type "    ", creator "    "

Hah!

Got anything handy that speaks Mac compression formats?

Maybe macutil from ftp://ftp.cwi.nl/pub/dik/ would help?

> Package xv has no installation candidate, says apt-get. So apt-get
> install xview-clients, but that's not it. Oh, well. It probably
> wouldn't have worked, anyway. ;-)

Huh. It's its own package under NetBSD's pkgsrc. ::shrug::

> Well, it was ftp'd from my old Mac two years ago to my linux box. I
> wouldn't expect much damage, though it's certainly possible.

Did you transfer it using binary or ascii mode? (The latter will
break that file, if it's really a MacBinary I file. That's what
BinHex and UUEncode are for.)

> It still doesn't look like anything real to me. I look forward to your
> opinion(s).

Here 'tis.

> Mind you, this has become a matter of pride more than necessity, since
> my brother says he can open it and convert it to a different format. I
> like to think I can do most everything besides quicktime on my linux
> box.

He's opening it because jpegViewer is doing on-the-fly decompression
of the MacBinary I format. I'd forgotten it could do that, but the
more I think about it I think I even remember a preference setting
for that.

-- 
gabriel rosenkoetter
gr@eclipsed.net

Attachment: pgpT4GSZro4C1.pgp
Description: PGP signature