rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) (05/06/88)
Has anyone successfully implemented a run-length-encoding scheme for compressing pixel information sent to the image operator? Several attempts I have made actually *increased* the processing time of large images on the Apple LaserWriter. I'd love to here about a method for speeding up the throughput of images. If you're interested in what I've tried, read on... ******* PostScript is quite convenient for displaying pixel images, but if the printer hangs off a serial line, it's a real bitch waiting for something significant like a Sun screendump to be printed. Most of the time (about 6 minutes) is spent in downloading all those hex numbers to the image operator at 9600 baud (portrait mode, that is... landscape takes another 25 minutes for rotation). Initially, I tried to write a run-length-encoding protocol to speed up the transmission by sending eight pixels per character rather than the four pixels per character you can get via readhexstring. I quickly ran into the snag that things like ^S, ^T, etc have to be guarded, so I set aside one character to be an "escape" so that the few bit patterns which corresponded to ^S, ^T, etc could be passed in two bytes. Unfortunately, I had to specially process the input to translate the two-byte symbols back into the original characters. Whether I used read to grab a character at a time or readstring to grab a whole string to operate on, the times were ultimately worse than 6 minutes even though I was sending half the number of bytes down the pipe. MILD BUT WARMING FLAME: If the usual processor for PostScript engines (I suppose my LaserWriter's 68000 is the usual) can't handle all those manipulations, I think that Adobe should include a compressed-data read operator in a future release of PostScript. As far as I can tell, it can't be implemented in the interpreter with any efficiency to make it worth while. I can't believe a text/graphics page description language worth its salt could not afford to make a concession to the reality of the systems in which it is used. Well, that's one to think about Adobe... If anyone has any suggestions (short of getting faster printer or a parallel interface) I'd appreciate hearing about them. -- | Ray Lubinsky, UUCP: ...!uunet!virginia!uvacs!rwl | | Department of BITNET: rwl8y@virginia | | Computer Science, CSNET: rwl@cs.virginia.edu -OR- | | University of Virginia rwl%uvacs@uvaarpa.virginia.edu |
ken@cs.rochester.edu (Ken Yap) (05/07/88)
|Has anyone successfully implemented a run-length-encoding scheme for |compressing pixel information sent to the image operator? Several attempts Ray, Have you tried byte level run-length encoding, i.e. 00 00 00 00 00 13 13 13 13 24 is encoded as 5 * 00, 4 * 13, 24 in some scheme. I know of some screen dump programs that do this. I don't know exactly how much this wins. Obviously downloading is faster but processing is slower. The other thing I know is that rotating an image 90 degress in PostScript is slow. Best to do it in your dump program if you can. Ken
don@brillig.umd.edu (Don Hopkins) (05/07/88)
In article <2387@uvacs.CS.VIRGINIA.EDU> rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) writes: >Has anyone successfully implemented a run-length-encoding scheme for >compressing pixel information sent to the image operator? Several attempts >I have made actually *increased* the processing time of large images on the >Apple LaserWriter. I'd love to here about a method for speeding up the >throughput of images. If you're interested in what I've tried, read on... [...] >If the usual processor for PostScript engines (I suppose my LaserWriter's >68000 is the usual) can't handle all those manipulations, I think that Adobe >should include a compressed-data read operator in a future release of >PostScript. As far as I can tell, it can't be implemented in the interpreter >with any efficiency to make it worth while. I can't believe a text/graphics >page description language worth its salt could not afford to make a concession >to the reality of the systems in which it is used. > >Well, that's one to think about Adobe... If anyone has any suggestions (short >of getting faster printer or a parallel interface) I'd appreciate hearing about >them. > >-- >| Ray Lubinsky, UUCP: ...!uunet!virginia!uvacs!rwl | >| Department of BITNET: rwl8y@virginia | >| Computer Science, CSNET: rwl@cs.virginia.edu -OR- | >| University of Virginia rwl%uvacs@uvaarpa.virginia.edu | The NeWS window system has a byte-encoding format for sending compressed data such as small integers, fixed point numbers, floats, strings, tokens in systemdict, user defined tokens, and tags, over the network connection, between the window system client and the NeWS server. You can also send and receive run length encoded sun raster files (color or b/w) with the writecanvas and readcanvas operators. (A canvas in NeWS is an arbitrarily shaped drawing surface, i.e. the window hierarchy is made up of nested canvases.) Readcanvas takes a file name or an open file object as an argument, and returns a canvas with no parent. There are the two handy primitives, imagecanvas and imagemaskcanvas, just like image and imagemask, except that they take a canvas object as an argument. There is a primitive buildimage that takes the same arguments as image, to read in (or whatever) an image in hex (or whatever), except that it return a canvas object, instead of imaging it right then and there on the spot. Canvases are a *VERY* useful extension to PostScript! If you want to put down several copies of a large image on one page, you can read it just once, store it away in some dictionary, and re-use the canvas again and again! You can image 1, 8, and 24 bit images onto a color or monochrome screen, and NeWS automatically scales, interpolates and dithers appropriatly. You can draw on a canvas, and then use it as a scalable (and rotatable, shearable, and colorful) stamp pad, using imagecanvas! Canvases look to the PostScript programmer just like dictionaries, with fields such as /Mapped, /Parent, /CanvasAbove, /CanvasBelow, /Retained, /SaveBehind, /Transparent, /Color, /Interests, and /EventsConsumed. You can get and put the values of the canvas fields (some are read-only), put canvases on the dictionary stack, or anything else you can do with a dictionary. (Canvas fields are magic: for example, to manipulate the window hierarchy, you can change a canvas's /Parent field; to make a canvas disappear from the screen, you can go "can /Mapped false put". Poof.) There are other operators that take canvases as arguments, to move them around in the window hierarchy, reshape them to the current path (establishing their default coordinate system), set their clipping shape, set their cursor to any character of any font, and set the current canvas in the graphics state. At the PostScript Birds of a Feather session (BOF) held at the last X conference, the Adobe representative said that Display PostScript would use a byte encoding format for sending compressed data over the network. Steve Evans, of the Window Systems Group at Sun, said that Sun could probably adopt whatever byte-encoding format for PostScript data Adobe eventually comes out with, but right now NeWS has its own. -Don
nelson@sun.soe.clarkson.edu (Russ Nelson) (05/07/88)
In article <9440@sol.ARPA> ken@cs.rochester.edu (Ken Yap) writes: >|Has anyone successfully implemented a run-length-encoding scheme for >|compressing pixel information sent to the image operator? Several attempts >Ray, >Have you tried byte level run-length encoding, i.e. > 00 00 00 00 00 13 13 13 13 24 encoded as 5 * 00, 4 * 13, 24 I don't know about Ray, but I've tried it, and it is indeed slower. Arrrgh! -- char *reply-to-russ(int network) { if(network == BITNET) return "NELSON@CLUTX"; else return "nelson@clutx.clarkson.edu"; }
rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) (05/07/88)
In article <9440@sol.ARPA>, ken@cs.rochester.edu (Ken Yap) writes: > Have you tried byte level run-length encoding, i.e. > > 00 00 00 00 00 13 13 13 13 24 > > is encoded as > > 5 * 00, 4 * 13, 24 Yes (I'm sorry I didn't state that earlier -- I did the work last year and forgot to list all the things I tried). The lynch-pin in the whole process is the high cost of interpretively handling either character-at-a-time input (via read) or translating a string input via readhexstring/readstring into pixel data. -- | Ray Lubinsky, UUCP: ...!uunet!virginia!uvacs!rwl | | Department of BITNET: rwl8y@virginia | | Computer Science, CSNET: rwl@cs.virginia.edu -OR- | | University of Virginia rwl%uvacs@uvaarpa.virginia.edu |
chrisc@augean.OZ (Chris Clarkson) (05/09/88)
In article <2387@uvacs.CS.VIRGINIA.EDU>, rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) writes: > Has anyone successfully implemented a run-length-encoding scheme for > compressing pixel information sent to the image operator? Several attempts > I have made actually *increased* the processing time of large images on the > Apple LaserWriter. I'd love to here about a method for speeding up the > throughput of images. If you're interested in what I've tried, read on... It has been tried here by our (former - he left to greener pastures) TeX and Postscript guru Andrew Trevorrow. He found the same result. The whole thing took *CONSIDERABLY* longer to process. He formed the opinion that it couldn't be done to improve speed only make it worse. It apparently is tied up with some interaction in the Postscript interpreter in the Lasewriter. Chris Clarkson chrisc@augean.oz