Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!axion!galadriel!marks
From: marks@galadriel.bt.co.uk (Mark Shackleton)
Newsgroups: comp.graphics
Subject: Re: What format used in this file?
Message-ID: <1990Oct5.152753.1829@galadriel.bt.co.uk>
Date: 5 Oct 90 15:27:53 GMT
References: <8812@helios.TAMU.EDU>
Organization: RT611 BTRL, Martlesham Heath, Ipswich, UK
Lines: 42

From article <8812@helios.TAMU.EDU>, by guansy@cs.tamu.edu (Sheng-Yih Guan):
> I used GBA-Scanin software to scan in a color picture and store it in
> Sun output format.  Then I shifted it to our Sun workstation.  Using
> ALV package, I found that the configuration of the file is:
> 	xsize = 300
> 	ysize = 230
> 	depth = 8
> But, the size of the file is 207800.  If we multiply 300 by 230, we
> get 69,000.  So, I thought it must be stored as 3 bytes per pixel.

- The header says the image array SHOULD BE 69000 bytes, one byte per pel,
colour lookup tables supplied before the image data.

> 0000000  59a6 6a95 0000 012c 0000 00e6 0000 0008
> 0000020  0001 0d88 0000 0001 0000 0001 0000 0300
> ...

If you look up the Sun manual page RASTERFILE(5) it gives you the header
format for sun rasterfiles. Also the include file 'rasterfile.h' gives
meanings to some of the types used (it is found in /usr/include).

According to the header data above most of the details you give are
confirmed:

Xres=300, Yres=230, Bits per pel = 8, bytes of image data = 69000,
raster type = 1 (standard, see rasterfile.h), map type = 1 (3x256 colourmap
lookup entries, first red, then green, then blue).

> After I ran the r24r8 (developed by ncsa), I found the following
> error: more bytes in file ../images/rat1.sun than dimensions indicate.
> 

I think the error you get is probably accurate: the file is larger than the
header says it should be. Note however that the image pel values are lookup
entries and the RGB data is not stored explicitly. The colour lookup tables
contained at the start of the file are used to produce the true RGB values.
You could try using the sun SCREENLOAD(1) command to display the file to see
if the file simply has garbage tacked on the end or gets corrupted sooner.

Hope this is helpful,

Mark.