donc@cognos.UUCP (Don Campbell) (06/28/90)
I have found that sending large bitmaps to my PostScript printer is one of my
biggest bottlenecks. I read in the 'green' book that compressing a bitmap
first and decompressing it in the data acquisition procedure could save some
time. The green book says ...
"This may drastically reduce transmission time, but it is quite
difficult to make the procedure fast enough to realize a net gain in
overall evaluation time."
Has anybody written such a procedure? I would like to try it out on my sample
data to see if it would gain me anything.
Any code or ideas would be appreciated.
Don
--
Don Campbell uucp: uunet!mitel!sce!cognos!donc
Cognos Incorporated mail: P.O. Box 9707, 3755 Riverside Drive,
(613) 738-1440 Ottawa Ontario, Canada. K1G 3Z4d87-jse@garbo.bion.kth.se (Joakim Sernbrant) (07/06/90)
In article <8561@cognos.UUCP> donc@cognos.UUCP () writes: >I have found that sending large bitmaps to my PostScript printer is one of my >biggest bottlenecks. I read in the 'green' book that compressing a bitmap >first and decompressing it in the data acquisition procedure could save some >time. The green book says ... > "This may drastically reduce transmission time, but it is quite > difficult to make the procedure fast enough to realize a net gain in > overall evaluation time." > >Has anybody written such a procedure? I would like to try it out on my sample >data to see if it would gain me anything. > Any code or ideas would be appreciated. > > Don I have spend many hours on this matter. I have tried runlength encoding and packing six bits into each byte in the image. The result have been dissapointing. Everything I've tried has actually been mush slower than normal. This has been tried mostly with 256 colors GIF images; special images with large white/black areas can be handled with runlength encoding with good results. Jocke -- Joakim Sernbrant, Royal Institute of Technology, Stockholm, Sweden -- Internet: d87-jse@nada.kth.se --
lee@sq.sq.com (Liam R. E. Quin) (07/09/90)
donc@cognos.UUCP wrote: > [...] sending large bitmaps to my PostScript printer is one of my biggest > bottlenecks. I read in the 'green' book that compressing a bitmap first > and decompressing it in [the printer] could save some time. d87-jse@kth.se (Joakim Sernbrant) warned: > I have spent many hours on this matter. I have tried runlength encoding > and packing six bits into each byte in the image. [...] Everything I've > tried has actually been mush slower than normal. Also, if you don't give _image_ a single lump of data, you might get visible horizontal streaks or lines at the border between the bands. On the other hand, if you send the data and build up data to give to image in one huge lump, beware of having two copies lying around, or you might run out of stack space. It is very hard to make the printer run fast enough for this to be worth while, particularly if you use 19200 baud or faster... Of course, on the faster printers such as the Agfa PS400, or maybe Xerox's new printer, this shouldn't be a problem... Lee -- Liam R. E. Quin, lee@sq.com, {utai,utzoo}!sq!lee, SoftQuad Inc., Toronto ``Sun. n.s., Any thing eminently splendid'' [Johnson's dictionary (1837)]
dave@chelgraph.CO.UK (dave harris) (07/10/90)
In article <1990Jul8.215653.22633@sq.sq.com> lee@sq.sq.com (Liam R. E. Quin) writes: >Also, if you don't give _image_ a single lump of data, you might get visible >horizontal streaks or lines at the border between the bands. On the other >hand.... I have always assumed that _image_ just assembles the data in memory before output. This "electronic paste-up" should leave no streaks or lines between the sections. There is no warning about this in the Red or Green Books, but perhaps there are PS implementations out there that have this drawback ? David Harris
rwl@amber.cs.Virginia.EDU (Ray Lubinsky) (07/12/90)
In article <1990Jul5.205445.8084@kth.se>, d87-jse@garbo.bion.kth.se (Joakim Sernbrant) writes: |> In article <8561@cognos.UUCP> donc@cognos.UUCP () writes: |> >Has anybody written such a procedure? I would like to try it out on my sample |> >data to see if it would gain me anything. |> > Any code or ideas would be appreciated. |> > |> > Don |> |> I have spend many hours on this matter. I have tried runlength |> encoding and packing six bits into each byte in the image. |> The result have been dissapointing. Everything I've tried has |> actually been mush slower than normal. This has been tried mostly |> with 256 colors GIF images; special images with large white/black |> areas can be handled with runlength encoding with good results. I guess this is a perennial question in this newsgroup. Probably three years ago, I worked on this problem with similar results. The upshot is that you can certainly decrease transmission time by encoding, but the cost of looking at each and every character within the *interpreted* PostScript program running in the printer will make just about any strictly-software scheme prohibitive. Adobe needs to get its act in gear, develop and publish an adequate encoding scheme, and add a built-in operator to the language that decodes input based on that encoding scheme. | Ray Lubinsky rwl@uvacs.cs.Virginia.EDU (Internet) | | rwl@virginia (BITnet) | | Department of Computer Science, ...!uunet!virginia!uvacs!rwl (UUCP) | | University of Virginia (804) 982-2219 (voice) |