Re: Historical question about gnuplot's PostScript terminal

[Petr M. <mi...@ph...>]

Hello Ethan & others,

well, that's really history...

I have coded "pm3d" algorithm for postscript in 1995 as a stand-alone C++ 
program of the same name, and later made it as an splot mode for gnuplot in 
1999. The main idea was to visualize large synchrotron scan series (reciprocal 
space maps) without gridding (very slow and memory expensive at that time), 
print them via postscript on colour printers as fast as possible during/after 
the experiment. (Actually, I had such an algorithm in a Pascal program in 
1994, but it was low-resolution for DOS screen only, thus I had to rewrite it 
for high-res so I have selected postscript.)

One of my favourite testing data ("GaAs fish") had almost 40000 measured 
points, thus postscript header was always much smaller than the data part. 
Speed of printers was never a problem - anyway, in 90's, there only few colour 
postscript printers per institute and you need to walk there :-)


Thus, requirements for the program:

1. Smallest postscript size possible: disks were small and LaTeX postscript 
file size with included many figures was growing fast.

2. The postscript header should be readable & editable by any text editor in 
order to easily change the gray <=> colour version of the same file (gray 
version for a publication, colour for a poster), or change your preferable 
colour sequence without the need to process the original data again.


Thus the g command with 4 digits precision and various rgbformulae so that the 
file owner can play with/change easily an own set of colour mapping formulae.


Well, now I can see that one byte per line can be saved by change of
.1234 g
=>
1234 g
using  1000 div setgray   :-) Wow, unnoticed for 25 years...


Further postscript file size decrease for regular (e.g. image) data can be 
done via scripts
 	pm3dCompress.awk
 	pm3dConvertToImage.awk

They compress information about quadrangle sizes, but not of same successive 
colours. That was actually not necessary - experimental data are noisy and 
calculated data are continuous, thus sequent colours are diffent; and missing 
data (forbidden regions, such as those outside of the Ewald sphere) need not 
to be written in the input data file at all. Omitting repetive .xxxx g would 
save some space if pm3d mode is used for plotting of some geometries.

The gray/gamma/colour and rgbformulae palettes were in gnuplot the only option 
for a long time. Much later other palettes were added so that gnuplot can have 
same palettes as in AFM, Matlab, etc.

That's the summary about the pm3d & rgbformulae history. I hope this shows 
that the colour coding was/is not that complicated.

Greetings, Petr



On Mon, 15 Nov 2021, Ethan A Merritt wrote:

> The PostScript terminal implements palette colors in a complicated way.
> Or at least it seems complicated to me in retrospect.
> I'm wondering if there was a reason it was done the way it was.
>
> The way it was (and still is)
> =============================
>
> If the palette mode is "rgbformulae"
>   - PostScript implementations of the 3 formulae are written in the output
>   - the function \g is defined to convert gray->rgb using them analytically
> If the palette mode is "functions"
>   - The terminal writes out an approximation table for each function
>   - the function \g is defined to convert gray->rgb using interpolation
>     between table entries
> If the palette mode is "defined"
>   - The terminal writes the gradient definitions
>   - the function \g is defined to convert gray->rgb using interpolation
>
> In all cases the actual "change color" command in the PostScript output
> ends up looking like this
>      .1234 g
> where ".1234" is the gray value for conversion, and the \g function
> converts this into the native PostScript command
>      .rrr .ggg. .bbb  setrgbcolor
>
> As I understand it, the original idea was that ".1234 g" uses only
> 5 characters for the gray value rather than approximately 15-18 characters
> if the driver were to write out the .rrr .ggg .bbb values separately.
> So it saves some space in the output file.
>
> On the other hand, the interpolation tables take up a lot of space too.
> And the burden of converting every single gray value into RGB was borne
> by the printer, which I imagine was pretty slow back in the day...
>
> Also, the four digit precision of the gray value means that the driver
> cannot skip writing a "change color" sequence to the output even if it
> turns out that successive similar gray values will all map to the same RGB.
>
> Why wasn't it this instead?
> ===========================
>
> The driver always writes a 24bit hex-encoded RGB color:
>    0xAABBCC g
> As before, the function \g is defined to unpack this into
>    .rrr .ggg .bbb setrgbcolor
>
> That's 8 characters for the color rather than 5, so slightly worse.
> But not much worse.
>
> Since the conversion from gray->RGB is done by gnuplot rather than
> by a PostScript interpreter running in a printer, it's much faster.
>
> Bonus 1: The terminal driver knows exactly what the RGB value will be,
> and can choose not to write it if it duplicates the previous value.
>
> Bonus 2: No need to write out analytical functions or interpolation
> tables that are specific to a single pm3d plot.  The gray->RGB
> conversion has already been done at the time of file creation.
>
> 	just curious
>
> 		Ethan
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta