Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <me...@uw...> - 2021-11-16 07:18:44
|
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
|
|
From: Petr M. <mi...@ph...> - 2021-11-22 00:42:36
|
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
|
Thanks for helping keep SourceForge clean.
X