Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #870

Re: (embarrassingly) simple showpage question

Show all headers | View raw

ken <ken@spamcop.net> wrote:
> john@please.see.sig.for.email.com says...
> 
>> The reason I mention all that is because the gif's
>> 5MB, and convert took 6mins to render it from ps
>> on an i7-920 (though only utilizing one core).
> 
> Well it is 100 pages of output, and each page is of
> steadily increasing complexity.

I suppose...just can't quite wrap my head around
anything taking 6mins on an i7.

>>    That's at least partly because I couldn't originally
>> figure out how to get a transparent background.
>> So the first %%Page contains one lineto, the second page
>> contains two, ..., the hundredth/last contains 100 (total 5050).
>> A smaller and faster version using
>>   convert -transparent "#FFFFFF" -delay 0 -loop 0 input.ps output.gif
>> whose input/output is at
>>   http://www.forkosh.com/decorative/decofweek-v2.ps
>>   http://www.forkosh.com/decorative/decofweek-v2.gif
>> works with each %%Page containing only one line (total 100),
>> and the transparent background lets those lines build up.
> 
> Hmm, PostScript doesn't support transparency, not at all. So ImageMagick 
> must be treating the untouched background as transparent, I've no idea 
> how it is doing that.

If I understand (emphasize if), -transparent "#FFFFFF" (r=g=b=FF=255)
renders anything white as transparent. So it's not distinguishing
bg/fg, per se, just white/non-white, and bg happens to be white,
and fg happens never to be white in this case.

> Also, of course, PostScript doesn't output animations, since its 
> intended as a printing langage, so the animated GIF is presumably 
> assembled by ImageMagick. I don't know anything about the application 
> I'm afraid.

Yes, IM does some nifty stuff. And it conveniently interprets
each ps %%Page as a frame. You'd otherwise have to supply it
with a whole separate input file for each frame (100 input files
in this case).

>> But the v2-file's still 350KB and convert takes 31secs,
>> which is still too slow for online world use. ImageMagick
>> convert runs gs for its ps-->gif conversion, driven by a
>> delegates.xml file (in /usr/lib/ImageMagick-6.4.3/config/
>> on my box) containing the line
>>   <delegate decode="ps:color" command="---see below---"/>
>> where command is
>>   gs -q -dQUIET -dPARANOIDSAFER -dBATCH -dNOPAUSE -dNOPROMPT
>>      -sDEVICE=pnmraw
>>      -and-some-other-stuff
>> Trying to speed it up, I naively tried psrgb instead of pnmraw,
>> but that just took longer. Is there any way for gs to
>> more quickly (i.e., less slowly) run this ps-->gif conversion
>> with a transparent background?
> 
> Well my first thought is that you haven't really identified GS as the 
> bottleneck here. I personally would invoke GS from the shell, using the 
> command given, and time how long it takes. I suspect this may show that 
> GS is doing its bit quite quickly.

Okay, I'll give that a try (later because today's actual workday
begins soon), and see if my times resemble your 18secs reported
below (perhaps scaled for your 5yo PC, though my i7's 2.5yo).

> I'd also ned to see the 'and-some-other-stuff' parts of the command 
> line, since the bits you've quoted are really almost entirely irrelevant 
> :-) Only the DEVICE switch from there is useful....

Well, the complete xml <tag> is (I've only added some newlines and spaces)
  <delegate decode="ps:color" stealth="True"
  command="&quot;gs&quot; -q -dQUIET -dPARANOIDSAFER -dBATCH -dNOPAUSE
  -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=0
  &quot;-sDEVICE=pnmraw&quot; -dTextAlphaBits=%u -dGraphicsAlphaBits=%u
  &quot;-r%s&quot; %s &quot;-sOutputFile=%s&quot;
  &quot;-f%s&quot; &quot; -f%s&quot;"/>
which IM's apparently using as a format string, so it's not entirely
clear what the command looks like when executed. The -r%s, presumably
for -r<X>x<Y>, seems to be followed by an all-alone %s that could
be filled in with pretty much anything IM's little heart desires,
or just filled in with " ".

> My suspicion would be that assembling an animated GIF from 100 PNM files 
> is the slow bit, especially if ImageMagick is doing any kind of 
> filtering on the data.

Hard to tell precisely what IM's doing when. I tried watching it
with "top", but couldn't quite keep track of the stuff it fork()'ed off.
I'll have to put some more effort into that kind of thing.

> A quick test on my (5 year old) PC here ran your v2 test in 18 seconds, 
> producing 100 pages, each of which is 1.5Mb in size. So I'm seeing data 
> produced by GS at ~7MB/second, which isn't bad, though it is slower than 
> I woudld expect. Of course assembling the animated GIF means that 
> ImageMagick has to read 150MB of data and presumably remove the white 
> space.
> 
> Two things spring immediatley to mind:
> 
> 1) Reduce the resolution. I can't recall what the default resolution for 
> pnmraw is, and you command line doesn't tell me what's being used.

Maybe in that all-alone %s. But IM does have switches
   -resample geometry   change the resolution of an image
   -resize geometry     resize the image
that I haven't played with (yet). I'll give them a try and
see what effect they have.

> 2) Reduce the page size. There's a *lot* of white space on the page, 
> even when you consider the total drawing rather than each individual 
> page. You don't seem to be setting the page size anywhere, but relying 
> on the default. Moving the drawing so that the lower and left parts of 
> the drawing are at x=0 and y=0, and then reducing the media size so that 
> the media is just large enough to contain the drawing woudl reduce the 
> amount of white space. This would reduce the amount of data GS produces 
> and also (of course) the amount of data ImageMagick has to process.

Okay, I can put that in as an option. Right now the scale/translate
are meant to center images on letter or a4 paper, which is quite
irrelevant for these animation pages that aren't meant for printing.
(This whole thing's basically a toy that's gotten somewhat out of hand.)

> On the PostScript front, you should bind your procedures. You clearly 
> don't intend to have them change at run-time (which is the reason why 
> you wouldn't bind them). Bound procedures run faster, as the interpreter 
> doesn't have to lookup and execute the PostScript each time. Doing this 
> with your file reduced the execution time from 18 secs to 3 seconds on 
> my PC. Your mileage may vary of course.
>  Ken

That's easy enough. I'll edit it into the emitted text, and see
if it makes any noticeable difference in the overall IM runtime.
18-to-3 is obviously an enormous difference.
Thanks so much for your time and advice.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

Back to comp.lang.postscript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

(embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-08 04:58 +0000
  Re: (embarrassingly) simple showpage question ken <ken@spamcop.net> - 2012-08-08 07:59 +0100
    Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-08 08:54 +0000
      Re: (embarrassingly) simple showpage question ken <ken@spamcop.net> - 2012-08-08 10:17 +0100
        Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-08 10:08 +0000
          Re: (embarrassingly) simple showpage question tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2012-08-08 22:07 -0400
            Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-09 05:40 +0000
              Re: (embarrassingly) simple showpage question ken <ken@spamcop.net> - 2012-08-09 08:44 +0100
                Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-09 09:38 +0000
                Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-10 06:24 +0000

csiph-web