mephdbo%prism@gatech.edu (d. majumder) (12/21/88)
A couple of questions about Sun Rasterfile formats. 1) There are some pub domain rasterfiles with their filename extension being ---.im1 or ---.im8. The file command indicates that these are in RT_BYTE_ENCODED format. now the screenload command fails to read them most of the time. Is there some routine to convert the BYTE_ENCODED rasters to STANDARD form or am I doing something wrong. 2) Does anyone know if there exists any utility to convert the CompuServe GIF format to SUN rasterfile format (color/mono). Thanks Deeptendu mephdbo@prism.gatech.edu meibmdm@gitvm2.bitnet
chuck@trantor.harris-atd.com (Chuck Musciano) (12/31/88)
> Is there some routine to convert the BYTE_ENCODED rasters to > STANDARD form or am I doing something wrong. 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. Anyone at surya care to fix that one up? And, it would be nice if a README was placed in the directory, so we don't have to suck down all the images only to find that most are not very interesting, or of particularly low quality. Chuck Musciano Advanced Technology Department Harris Corporation (407) 727-6131 ARPA: chuck@trantor.harris-atd.com
gandalf@csli.stanford.edu (Juergen Wagner) (01/04/89)
ad 1: There are a some conversion utilities called convert.0 and convert.2.
They come with the Sun distribution and are somewhere like
/usr/local/rasters or /usr/lib/rasfilters... I forgot. However, if
screenload fails, this might also happen with those converters.
[[ Hey wow. Sure enough, they're in /usr/lib/rasfilters. In our release
there's even source for convert.2. The standard distribution doesn't have
a /usr/local (or if it does, it's empty). --wnl ]]
ad 2: GIF can be converted to Sun rasterfiles with the GIF2RAS program by
Patrick Naughton at Sun (I hope I remember the name right). A simple
version of the program is in Jef Poskanzer's PBM package. You could also
use `bmx', a bitmap conversion package I have written, and which allows
you to convert any of the 18 input formats to Sun rasterfiles (and
others).
Juergen Wagner gandalf@csli.stanford.edu
wagner@arisia.xerox.comtale@pawl.rpi.edu (01/04/89)
In Digest 7.69, mephdbo%prism@gatech.edu (d. majumder) wrote: >1) There are some pub domain rasterfiles with their filename extension >being ---.im1 or ---.im8. The file command indicates that these are in >RT_BYTE_ENCODED format. now the screenload command fails to read them most >of the time. Is there some routine to convert the BYTE_ENCODED rasters to >STANDARD form or am I doing something wrong. RT_BYTE_ENCODED (run-time byte encoded) is a format used when someone wants to save space and still have the rasterfile readyily available. This effectively rules out compression utilities, as various programmes like suntools-e, touch-up, screenload et al can't do the decompression themselves. Suntools, suntools-e, screenload and screenloadc are all able to handle RT_BYTE_ENCODING; images will appear as advertised. I don't know if touch-up can cope with it; I haven't checked and can't until I'm near a sun. I suspect it might not be able to since an option to save it RT_BYTE_ENCODED does not exist in that programme. >2) Does anyone know if there exists any utility to convert the CompuServe >GIF format to SUN rasterfile format (color/mono). There is one in development here and I suspect that when it is completed it will be announced in Sun-Spots and made available via anonymous ftp. If one already exists out there, our developers would be happy to hear about it. Dave -- tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edu
ajy@uunet.uu.net (andrew yeomans) (01/05/89)
mephdbo%prism@gatech.edu (d. majumder): >1) There are some pub domain rasterfiles with their filename extension >being ---.im1 or ---.im8. The file command indicates that these are in >RT_BYTE_ENCODED format. now the screenload command fails to read them most >of the time. Is there some routine to convert the BYTE_ENCODED rasters to >STANDARD form or am I doing something wrong. I've not looked at .im1 or .im8 rasterfiles, so I'm not sure if this is the same problem. But here goes anyway:- The sun routine pr_dump does not always encode RT_BYTE_ENCODED rasterfiles correctly, if copy_flag = 0 (compress in place). It seems to occur when the encoded image (up to a given point) is longer than the unencoded image, hence the original image gets corrupted. This seems to happen more frequently on small images (eg 40*40), when data values of 0x80 are in the original image. If the image is corrupted, then pr_load (used by screenload) cannot read the file correctly. Often the image is recoverable, though a part of a line may be lost, causing the image to 'slip' partway through. The following code is my own implementation of the sun pr_load routine, which might be useful for hacking about. Remove the lines: if (ch == EOF) /* Check end reached */ return (NULL); to always return a pixrect even if the file was corrupt (or ignore the errors returned). Andrew Yeomans PSTN: 0442 230000 ext 3371 Crosfield Electronics Ltd INTL: +44 442 230000 Three Cherry Trees Lane Fax: 0442 232301 Hemel Hempstead UUCP: ajy@cel.co.uk Hertfordshire mcvax!ukc!uk.co.cel!ajy HP2 7RH England ----- cut here ----- /* pr_load Load a pixrect from Sun raster file */ /* Returns pixrect, or NULL if error */ /* The byte-encoded data format is as follows (not documented by Sun): */ /* 0x80 is used as a flag to introduce run-length encoded data */ /* <0x80> <rept> <value> represents rept+1 occurrences of <value> */ /* <0x80> <0> represents a single occurrence of <0x80> */ /* All other values represent unencoded data */ /* It is only worth encoding repetitions of 3 or more, except if the */ /* value is <0x80> which must always be encoded. */ #include <stdio.h> #include <malloc.h> #include <sys/types.h> #include <pixrect/pixrect.h> #include <pixrect/memvar.h> #include <pixrect/pr_io.h> #include <rasterfile.h> struct pixrect * pr_load(input, colormap) register FILE * input; /* Input file */ colormap_t * colormap; /* Optional colourmap */ { struct pixrect * output_pr; /* Output pixrect */ struct rasterfile fileheader; /* Rasterfile header */ register char * p_image; /* Pointer to image data */ register int length; /* Length of image */ register int ch; /* Input data character */ register int ch2; /* Input data character */ /* Read and check file header */ if (fread(&fileheader, sizeof(fileheader), 1, input) != 1) return (NULL); if (fileheader.ras_magic != RAS_MAGIC) return (NULL); /* Load (or skip) colormap */ if (colormap == NULL) { fseek(input, fileheader.ras_maplength, 1); /* skip map */ } else { colormap->type = fileheader.ras_maptype; if (fileheader.ras_maptype == RMT_EQUAL_RGB) { colormap->length = fileheader.ras_maplength / 3; fread(colormap->map[0], colormap->length, 1, input); fread(colormap->map[1], colormap->length, 1, input); fread(colormap->map[2], colormap->length, 1, input); } else { fseek(input, fileheader.ras_maplength, 1); /* skip map */ } } /* Create pixrect and load data */ if ((output_pr = mem_create(fileheader.ras_width, fileheader.ras_height, fileheader.ras_depth)) == NULL) return (NULL); p_image = (char *) mpr_d(output_pr)->md_image; length = mpr_d(output_pr)->md_linebytes * output_pr->pr_height; if (fileheader.ras_type == RT_STANDARD) { if (fread(p_image, fileheader.ras_length, 1, input) != 1) return (NULL); } else if (fileheader.ras_type == RT_BYTE_ENCODED) { while (length--) { if ((ch = getc(input)) == 0x80) /* Flag value? */ { if ((ch2 = getc(input)) != 0) /* Count 0 means a 0x80 */ { ch = getc(input); /* Else count + 1 of ch */ while (ch2-- && length--) *p_image++ = ch; } } *p_image++ = ch; } if (ch == EOF) /* Check end reached */ return (NULL); } return (output_pr); } ----- cut here -----
iang@dartvax.dartmouth.edu (Ian Gregory) (01/07/89)
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
david@sun.com (D. David David) (01/13/89)
mcvax!cel!ajy@uunet.uu.net (andrew yeomans) writes: >The sun routine pr_dump does not always encode RT_BYTE_ENCODED rasterfiles >correctly, if copy_flag = 0 (compress in place). It seems to occur when >the encoded image (up to a given point) is longer than the unencoded >image, hence the original image gets corrupted. Fixed in SunOS 3.4. >/* The byte-encoded data format is as follows (not documented by Sun): */ Documented in the SunOS 4.0 pixrect manual. -- David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com
tim@uunet.uu.net (Tim Pointing) (01/13/89)
In issue v7n85, tale@pawl.rpi.edu writes: >In Digest 7.69, mephdbo%prism@gatech.edu (d. majumder) wrote: >>The screenload command fails to read [RT_BYTE_ENCODED format files] most >>of the time. Is there some routine to convert the BYTE_ENCODED rasters to >>STANDARD form or am I doing something wrong. I have found that screenload will fail to load RT_BYTE_ENCODED format files from time to time (although this *should* not be the case.) I have been able to get around the problem by using "/usr/lib/rasfilters/convert.2" to convert it to RT_STANDARD format which screenload never seems to have trouble with. >I don't know if touch-up can cope with [RT_BYTE_ENCODING]; I haven't checked >and can't until I'm ear a sun. I suspect it might not be able to since an >option to save it RT_BYTE_ENCODED does not exist in that programme. My copy of touchup (version 2.3) does indeed have an option for saving in either "standard format" or "byte encoded". >>2) Does anyone know if there exists any utility to convert the CompuServe >>GIF format to SUN rasterfile format (color/mono). >There is one in development here and I suspect that when it is completed >it will be announced in Sun-Spots and made available via anonymous ftp. >If one already exists out there, our developers would be happy to hear >about it. As somebody already mentioned, there is one (gif2ras) available. It was converted from a Turbo Pascal program in comp.graphics by Patrick J. Naughton <naughton@wind.sun.com>. There might be a bug or 2 left in it as it dumped core on a few of the images I have and created rasterfiles which didn't screenload properly (looked like the horzontal hold was off!). These may, however, be due to faulty GIF files and buggy screenload respectively. Alas, I can't remember where I picked gif2ras up from. It may have been in comp.sources.unix or it may be in the sun-sources archives at titan.rice.edu. Tim Pointing, DCIEM tim@{zorac,dretor.ben}.dciem.dnd.ca -- Tim Pointing, DCIEM {decvax|ihnp4|watmath}!utzoo!dciem!ben!tim uunet!mnetor!dciem!ben!tim or nrcaer!dciem!ben!tim tim%ben@zorac.dciem.dnd.ca or tim@ben.dciem.dnd.ca (or tim@zorac.arpa)
ajy@uunet.uu.net (andrew yeomans) (01/16/89)
Further to my message on raster files being corrupted by pr_dump when using RT_BYTE_ENCODED: I believe the bugs are fixed in the latest Sun releases. I had problems with a program built with an early version of pr_dump, which sometimes refuses to save or load small pixrects, especially when the data would contain values of 0x80. 'what' reports that the buggy version of the module containing pr_dump is 'pr_io.c 1.1 85/12/19'. On SunOS 3.5, (yes, I'm still looking forward to the joys of 4.x!) the version is 'pr_io.c 1.5 87/08/14', which does not have the problem. Conclusion: Software built with an early version of the pixrect library may fail to save certain pixrects properly. Solution: rebuild it! Andrew Yeomans __________ Patrick J. McEvoy (Sun Entry Systems ISV Liason) <swagman@sun.com> adds the following: > The sun routine pr_dump does not always encode RT_BYTE_ENCODED > rasterfiles correctly, if copy_flag = 0 (compress in place). Not quite. copy_flag = 0 means don't bother making a copy of the *source* pixrect before doing all the work. Nothing is done in place. (One might want to make a quick copy of the source pixrect if the data is subject to modification by another process, e.g. the framebuffer.) > My copy of "Pixrect Reference Manual" (admittedly old, dated 17 Feb 1986) > states that: > "There are two situations where the copy_flag value should be non_zero: > > - If the output type is RT_BYTE_ENCODED - This is because the encoding > algorithm does the encoding in place and will destroy the image data > of input_pr if it fails while working on input_pr directly. > - if input_pr is a pixrect in a frame buffer ...." The 4.0 source code currently really does write directly to a FILE *, when you specify RT_BYTE_ENCODED. Nothing gets kept around in memory. More likely, you can run into trouble when pr_dump'ing a CG2, CG3, or CG5 if the screen gets updated during the dump (likely if you are running a clocktool). The CG? has hardware registers that put it into one of several address modes: 8-bit pixels, 8 1-bit pixel planes, rasterop mode. Normally the window system cordinates those registers, but pixrects alone (e.g. pr_dump) does not. So if those registers get hit during your dump the rest of your image is foobar -- even if you specify RT_STANDARD. Try setting the copy_flag. Feel free to post anything I said to sunspots. Andrew Yeomans PSTN: 0442 230000 ext 3371 Crosfield Electronics Ltd INTL: +44 442 230000 Three Cherry Trees Lane Fax: 0442 232301 Hemel Hempstead UUCP: ajy@cel.uucp Hertfordshire mcvax!cel!ajy@uunet.uu.net HP2 7RH England >From a program you can call wmgr_refreshwindow (Sunview System Programmer's Guide Chapter 13 on Window Management). Example: main(){ int rootfd; rootfd = open("/dev/win0",0); /* or getenv("WINDOW_PARENT") */ if(rootfd>=0)wmgr_refreshwindow(rootfd); exit(rootfd<0); }