Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: plasmoid!iang@dartvax.dartmouth.edu (Ian Gregory)
Newsgroups: comp.sys.sun
Subject: Re: Rasterfile Format questions
Message-ID: <11588@dartvax.Dartmouth.EDU>
Date: 7 Jan 89 01:59:01 GMT
References: <8812211244.AA20882@trantor.harris-atd.com>
Sender: usenet@rice.edu
Organization: U of Maryland, Dept. of Computer Science,gs
Lines: 24
Approved: Sun-Spots@rice.edu
Original-Date: 31 Dec 88 00:56:00 GMT
X-Sun-Spots-Digest: Volume 7, Issue 91, message 4 of 13

chuck@trantor.harris-atd.com (Chuck Musciano) writes:

>I assume that suffixes of "im1" and "im8" mean "1 bit image" and "8 bit
>image", respectively.  RT_BYTE_ENCODED files are read transparently by
>screenload, so a read failure probably indicates that the file is trashed.
>By the way, the "elle.im8" image from surya.waterloo.edu was truncated,
>and is not readable under any circumstances....

I have a couple of RT_BYTE_ENCODED rasterfiles I created with pr_dump,
which cause screenload to give "Error reading rasterfile input data".  If
I read one of these into a pixrect with pr_load then pr_dump it with
ras_type=RT_STANDARD I get a file which works. It seems there is a bug in
screenload which causes it to fail when reading certain encoded
rasterfiles (we are running 3.4).

Incidently, the file elle.im8 was truncated to approximately one third of
it's original length, so pr_load has a fit when it tries to read past the
end of the file. If you use adb to change the ras_height field in the
header from 0x1e0 to 0xa3 you will get a well behaved rasterfile. The
header and colormap were intact, there was just some (admittedly
important!) image data missing from the end.

            Ian Gregory
            iang@plasmoid.dartmouth.edu