gnuplot-beta

enhancing image capabilities of postscript terminal

[Benjamin L. <lin...@gm...>]

Hello,

I am trying to enhance the image capabilities of the postscript terminal.

I'd like to add basically two new features
  *) compression of image data for the /FlateDecode filter as avilable 
in PS Level 3 (using libz)
  *) Binary enconding of image data

The objective is to significantly reduce the size of the output file 
with image data in it.

So I wanted to ask the developers here, if such additions would be of 
interest to be added to the gnuplot sources?

Implementing these features would require quite some changes in the 
current postscript image code, in order to disentangle the three steps
  1) pack image data in a bit-tight manner
  2) (possibly) compress the packed data
  3) encode the (possibly) compressed data
which are currently done all-in-one in PS_encode_image()

So instead of throwing around with large patches, I'd thought I'd ask 
beforehand ...

My idea would be to add new options to the postscript terminal
  ) "level2" to set PS level to 2 (the current default), an alias of 
"leveldefault"
  ) "level3" to enable PS Level 3 related features
  ) "imgcompression" to define whether to compress the image data 
(currently only inflate/deflate)
  ) "imgencoding" to define which method of encoding should be used 
(hex, ascii85 or binary)

The default settings should resemble the current behaviour, i.e. "level2 
imgcomression none imgencoding ascii85"

I could provide currently an implementation for inflate/deflate image 
compression and binary image encoding. By changing the postscript image 
code structure it should then be relatively easy to later add different 
compression methods or encoding methods (if of interest)

comments?

benjamin

Re: enhancing image capabilities of postscript terminal

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 25 February 2009 12:58:43 Benjamin Lindner wrote:
> Hello,
> 
> I am trying to enhance the image capabilities of the postscript terminal.
> 
> I'd like to add basically two new features
>   *) compression of image data for the /FlateDecode filter as avilable 

That sounds quite reasonable.
Note that the PDF terminal already does this by default.

> in PS Level 3 (using libz)
>   *) Binary enconding of image data

I don't know enough to offer an opinion on the feasibility of that one.
Is that something that is commonly done in the PostScript world?

> The objective is to significantly reduce the size of the output file 
> with image data in it.
>
> So I wanted to ask the developers here, if such additions would be of 
> interest to be added to the gnuplot sources?
> 
> Implementing these features would require quite some changes in the 
> current postscript image code, in order to disentangle the three steps
>   1) pack image data in a bit-tight manner
>   2) (possibly) compress the packed data
>   3) encode the (possibly) compressed data
> which are currently done all-in-one in PS_encode_image()
> 
> So instead of throwing around with large patches, I'd thought I'd ask 
> beforehand ...
> 
> My idea would be to add new options to the postscript terminal
>   ) "level2" to set PS level to 2 (the current default), an alias of 
> "leveldefault"
>   ) "level3" to enable PS Level 3 related features
>   ) "imgcompression" to define whether to compress the image data 
> (currently only inflate/deflate)
>   ) "imgencoding" to define which method of encoding should be used 
> (hex, ascii85 or binary)
> 
> The default settings should resemble the current behaviour, i.e. "level2 
> imgcomression none imgencoding ascii85"
> 
> I could provide currently an implementation for inflate/deflate image 
> compression and binary image encoding. By changing the postscript image 
> code structure it should then be relatively easy to later add different 
> compression methods or encoding methods (if of interest)
> 
> comments?

A Flate option sounds perfectly reasonable to me.
Would further binary compression offer any advantage over simply
compressing the resulting file with gzip or bzip2 (or rar or pkzip or ...)?

No matter what you do, PostScript will remain a poor choice for
storing pixel images.

-- 
Ethan A Merritt

Re: enhancing image capabilities of postscript terminal

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> On Wednesday 25 February 2009 12:58:43 Benjamin Lindner wrote:
>> Hello,
>>
>> I am trying to enhance the image capabilities of the postscript terminal.
>>
>> I'd like to add basically two new features
>>   *) compression of image data for the /FlateDecode filter as avilable 
> 
> That sounds quite reasonable.
> Note that the PDF terminal already does this by default.

Maybe, I cannot test the pdf terminal, since the libpdf license does not 
allow commercial use.
I tested the cairopdf terminal, but its output is (IMO) not better than 
postscript, especially when it comes to font issues. I found also, that 
ps+ghostscript yields generally smaller pdf than the cairopdf terminal 
(and it comes for free). So for me the postscript terminal is the 
preferred choice.

> 
>> in PS Level 3 (using libz)
>>   *) Binary enconding of image data
> 
> I don't know enough to offer an opinion on the feasibility of that one.
> Is that something that is commonly done in the PostScript world?

I cannot judge for the whole Postscript world, but it is done when 
converting images to postscript, e.g. png2eps, jpeg2ps, tif2eps, where 
postscript natively supports the respective compression algorithm used 
in the graphics format.
Granted, this is not postscript's prime application, but is supported by 
the language, and a nice feature.

The problem with the ascii encoding is it bloats the image data size. By 
a factor 2 for ascii hex (2 output bytes for every input byte) and by 
20% for ascii85 (a 5-tuple output for every 4-tuple input).
Using binary encoding, image data is written simply 1:1 into the 
postscript file. This reduces portability, true, but if portability is 
not the issue, e.g. because the postscript graph is embedded in latex 
and processed further anyway, it's an easy way to reduce size.

>> The objective is to significantly reduce the size of the output file 
>> with image data in it.
>>
>> So I wanted to ask the developers here, if such additions would be of 
>> interest to be added to the gnuplot sources?
>>
>> Implementing these features would require quite some changes in the 
>> current postscript image code, in order to disentangle the three steps
>>   1) pack image data in a bit-tight manner
>>   2) (possibly) compress the packed data
>>   3) encode the (possibly) compressed data
>> which are currently done all-in-one in PS_encode_image()
>>
>> So instead of throwing around with large patches, I'd thought I'd ask 
>> beforehand ...
>>
>> My idea would be to add new options to the postscript terminal
>>   ) "level2" to set PS level to 2 (the current default), an alias of 
>> "leveldefault"
>>   ) "level3" to enable PS Level 3 related features
>>   ) "imgcompression" to define whether to compress the image data 
>> (currently only inflate/deflate)
>>   ) "imgencoding" to define which method of encoding should be used 
>> (hex, ascii85 or binary)
>>
>> The default settings should resemble the current behaviour, i.e. "level2 
>> imgcomression none imgencoding ascii85"
>>
>> I could provide currently an implementation for inflate/deflate image 
>> compression and binary image encoding. By changing the postscript image 
>> code structure it should then be relatively easy to later add different 
>> compression methods or encoding methods (if of interest)
>>
>> comments?
> 
> A Flate option sounds perfectly reasonable to me.
> Would further binary compression offer any advantage over simply
> compressing the resulting file with gzip or bzip2 (or rar or pkzip or ...)?

Well, the advantage is that the postscript file is still ascii, thus 
readable and processable, just the image data is compressed and/or binary.

When looking purely at the resulting file size, the result depends on 
the actual image data. I did a test using
  a)  250x250x8bpp colour palette data
  b)  582x582x8bpp colour palette data
  c) 'blutux.rgb' from the demo code, 128x128x3x8bpp RGB data
and compared the following settings
  1) PS Level 1, asciihex encoding, no    compression
  2) PS Level 2, ascii85  encoding, no    compression
  3) PS Level 3, ascii85  encoding, flate compression
  4) PS Level 3, binary   ancoding, flate compression

a) and b) being examples of data I use, obtained by surface topography 
(i.e. a height map)

scenario 1) is for the sake of completness only, and no reasonable 
choice in reality - PS level 2 should be easily avilable nowadays.

Data a)

      File size          gzipped file size (bytes)
  1)   149239
  2)   102027            69587
  3)    88172 (-13%)     60003 (-14%)
  4)    74437 (-27%)     58736 (-15%)

Data b)

      File size          gzipped file size (bytes)
  1)   708749
  2)   451714            338364
  3)   361760 (-20%)     282636 (-16%)
  4)   290532 (-35%)     274968 (-19%)

Data c)

      File size          gzipped file size (bytes)
  1)   117389
  2)    80318            16081
  3)    23901 (-70%)      9293 (-42%)
  4)    22659 (-72%)      9303 (-42%)


Three conclusions:
  *) without gzipping the output, file size is significantly reduced
  *) gzipping the output without flate/binary also yields significant 
compression
  *) combining flate/binary with gzippping the output squeezes some 
additional bytes.

The usefulness of flate/binary will certainly depend on the actual 
application.
In my case, I deal a lot with surface topography data, and include 
either in latex or postprocess into pdf output and here I can gain in 
file size while still having ascii postscript code, which is why I 
brought the topic up in the first place.


> No matter what you do, PostScript will remain a poor choice for
> storing pixel images.
> 

I disagree. If one can put the image data into postscript without unduly 
bloating its size, postscript is a very powerful instrument.

Anyway, I will post my patches here, and if there is interest, use it as 
base for discussions.

benjamin

Re: enhancing image capabilities of postscript terminal

[Daniel J S. <dan...@ie...>]

Benjamin Lindner wrote:
>>No matter what you do, PostScript will remain a poor choice for
>>storing pixel images.
>>
> 
> 
> I disagree. If one can put the image data into postscript without unduly 
> bloating its size, postscript is a very powerful instrument.

If it is just an image, yes, but the advantage with PostScript is
the ability to add other elements like scalable fonts, arrows, etc.
However, there's the poor alpha-image/blending support; that's
disappointing.

Dan