gnuplot-beta

smooth shading & terminal specialities

[Mojca M. <moj...@gm...>]

Hello,


In color.c I noticed the following code:

    if (gppsfile)
=09draw_inside_color_smooth_box_postscript(out);
    else
=09draw_inside_color_smooth_box_bitmap(out);

I need my own version of drawing "smooth_box" (the terminal supports
vector graphic format, so drawing a whole lot of rectangles of single
color is extremely inefficient). Should I say

    if (gppsfile)
=09draw_inside_color_smooth_box_postscript(out);
    else if(term->name =3D=3D "my terminal")
        MY_TERMINAL_draw_inside_color_smooth_box();
    else
        ...

or is there a better (more consistent) solution? I hate touching the
code outside my own (new) terminal, but in this case I probably can't
avoid it.

draw_inside_color_smooth_box_postscript could be rewritten as well to
produce smooth shading instead of 1000 single-color boxes (smooth
liear shading with a stitching function). I know exactly what has to
be done, but I would need some thinking to implement it properly. If
someone knows PostScript language better than I do, I'm ready to
describe the procedure more precisely. (A better and more efficient
code can be produced using a new approach.)


Many plot on http://gnuplot.sourceforge.net/demo_4.1/pm3d.html could
be drawn more efficiently if I knew in advance that I'm able to draw
an NxM image as opposed to drawing NxM rectangles. Even the 4th and
the 5th example could be simplified considerably, but the examples
6-12 are obvious examples of such inefficient graphic, which could be
stored as a bitmap image. At which places in the source should
(colud?) this be improved?

Thanks a lot,
    Mojca

Re: smooth shading & terminal specialities

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

Mojca Miklavec wrote:
> Hello,
> 
> 
> In color.c I noticed the following code:
> 
>    if (gppsfile)
>     draw_inside_color_smooth_box_postscript(out);
>    else
>     draw_inside_color_smooth_box_bitmap(out);
> 
> I need my own version of drawing "smooth_box" (the terminal supports
> vector graphic format, so drawing a whole lot of rectangles of single
> color is extremely inefficient). Should I say
> 
>    if (gppsfile)
>     draw_inside_color_smooth_box_postscript(out);
>    else if(term->name == "my terminal")
>        MY_TERMINAL_draw_inside_color_smooth_box();
>    else
>        ...

No.

> or is there a better (more consistent) solution?

Yes.  Your intuition is probably correct on this one.

My opinion is that this "gppsfile" variable should be eliminated.  From what I understand, the purpose of this is a flag in the main code that indicates a PostScript comment can be added to the file for later use.  This is for the purpose of later running an awk script to look for repeated postscript strings and redefine them as shorter strings for purposes of compression.

The goal is laudable, but oh how convoluted this is.  Not clean code.  Why not just write the PostScript version of these "draw one" routines with short definitions in the first place?  Plus, why would this have to be done at the core code level?  Also, why couldn't someone just gzip the file in question after the fact?  That will pretty much accomplish this "substitute long string with short string" approach.  (Files with greater repetition have better compression in general.)

It's OK, in my mind, to write routines in the C files that the "trm" files can "callback", and there certainly is some planning to do here.  For example, in the case of images, PostScript has a very nice feature in which images can have an angle in 3D space associated with them.  I didn't use that feature (not yet anyway).  Instead I wrote an image projection routine that constructs an image from little rhombus-es (rhombi?) for each pixel.  Now, that rhombus method should be the routine that the terminal driver falls back on if there is no whole image projection feature as in PostScript (i.e., the terminal driver can call a routine that happens to be in the src directory, no big deal).  I didn't know any language or library would have such a feature so didn't account for it originally, so a lack of foresight on my part.  That can be fixed easily, if developers decide to do so.

> draw_inside_color_smooth_box_postscript could be rewritten as well to
> produce smooth shading instead of 1000 single-color boxes (smooth
> liear shading with a stitching function). I know exactly what has to
> be done, but I would need some thinking to implement it properly. If
> someone knows PostScript language better than I do, I'm ready to
> describe the procedure more precisely. (A better and more efficient
> code can be produced using a new approach.)

Think of how best to do this before embarking on it.  PostScript is the most feature rich language I'm aware of.  (The Adobe language reference should be consulted first.)

Are you saying you have a method that does shading in general?  Or just for PostScript?

> Many plot on http://gnuplot.sourceforge.net/demo_4.1/pm3d.html could
> be drawn more efficiently if I knew in advance that I'm able to draw
> an NxM image as opposed to drawing NxM rectangles. Even the 4th and
> the 5th example could be simplified considerably, but the examples
> 6-12 are obvious examples of such inefficient graphic, which could be
> stored as a bitmap image. At which places in the source should
> (colud?) this be improved?

I agree.  Regarding the PostScript image projection, in fact, even the images with non-square parallelograms can be done efficiently with image data, so long as each element has four sides of the same size.  We just removed from the image routine a test to verify that every element is of the same size.  Such code could be used to check if the pm3d image would fit the bill.  (Yes, it will slow the code slightly, but as soon as it fails then things speed up again because the code would stop checking.)

That would mean that

* somewhere in the pm3d code would be this test to check if the pm3d drawing constitutes a flat 2D surface.

* if flat surface, call the "image" terminal routine having a new projection angle input

* For those terminals not supporting projected images, they can callback the routine that draws projected images with individual rhombus-es (or rhombi?)

I guess I've never completely understood the convention of "default routine" in the terminal driver concept.  Someone will have to explain this.  (I can think of two essentially the same, but slightly different approaches.)

Dan

Re: smooth shading & terminal specialities

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

> My opinion is that this "gppsfile" variable should be eliminated.  From what 
> I understand, the purpose of this is a flag in the main code that indicates a 
> PostScript comment can be added to the file for later use.  This is for the 
> purpose of later running an awk script to look for repeated postscript 
> strings and redefine them as shorter strings for purposes of compression.

No; the term_api.h says:

/* Output file where the PostScript output goes to.
    In particular:
 	gppsfile == gpoutfile
 		for 'set term': postscript, pstex
 	gppsfile == PSLATEX_auxfile
 		for 'set term': pslatex
 	gppsfile == 0
 		for all other terminals
    It is non-zero for for the family of postscript terminals, thus making
    this a unique check for postscript output (pm3d has some code optimized
    for PS, for instance).
*/


> The goal is laudable, but oh how convoluted this is.  Not clean code.  Why 
> not just write the PostScript version of these "draw one" routines with short 
> definitions in the first place?  Plus, why would this have to be done at the 
> core code level?  Also, why couldn't someone just gzip the file in question 
> after the fact?

The code is clean and optimized for the postscript language. Current 
colorbox drawing takes 7 lines for any number of maxcolors, while otherwise 
it would be `maxcolors`lines.

> That will pretty much accomplish this "substitute long string with short 
> string" approach.

This is a completely different topic (code produced by PS_filled_polygon).

> * somewhere in the pm3d code would be this test to check if the pm3d drawing 
> constitutes a flat 2D surface.
>
> * if flat surface, call the "image" terminal routine having a new projection 
> angle input
>
> * For those terminals not supporting projected images, they can callback the 
> routine that draws projected images with individual rhombus-es (or rhombi?)

Thus you mean to automagically change "with pm3d" into "with image" without 
knowing it to user? That's not a good idea I think.

---
PM

Re: smooth shading & terminal specialities

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

Petr Mikulik wrote:
>> My opinion is that this "gppsfile" variable should be eliminated.  
>> From what I understand, the purpose of this is a flag in the main code 
>> that indicates a PostScript comment can be added to the file for later 
>> use.  This is for the purpose of later running an awk script to look 
>> for repeated postscript strings and redefine them as shorter strings 
>> for purposes of compression.
> 
> 
> No; the term_api.h says:
> 
> /* Output file where the PostScript output goes to.
>    In particular:
>     gppsfile == gpoutfile
>         for 'set term': postscript, pstex
>     gppsfile == PSLATEX_auxfile
>         for 'set term': pslatex
>     gppsfile == 0
>         for all other terminals
>    It is non-zero for for the family of postscript terminals, thus making
>    this a unique check for postscript output (pm3d has some code optimized
>    for PS, for instance).
> */

Oh, yeah.  The postscript/latex split.  Forgot about that.


>> That will pretty much accomplish this "substitute long string with 
>> short string" approach.
> 
> 
> This is a completely different topic (code produced by PS_filled_polygon).

Yes, I think so.  That is the code I'm wondering about.

> 
>> * somewhere in the pm3d code would be this test to check if the pm3d 
>> drawing constitutes a flat 2D surface.
>>
>> * if flat surface, call the "image" terminal routine having a new 
>> projection angle input
>>
>> * For those terminals not supporting projected images, they can 
>> callback the routine that draws projected images with individual 
>> rhombus-es (or rhombi?)
> 
> 
> Thus you mean to automagically change "with pm3d" into "with image" 
> without knowing it to user? That's not a good idea I think.

Well, yes and no.  The point is, there are several images where the underlying image routine can be used for the plots that pm3d creates but the image routine is a much more compact manner of representing that plot.  (For example, the 2D map mode with rectangular grid is the perfect example.)  From the standpoint of the user, what is the difference in how that is represented?  (I'm thinking if there is a difference, myself.)

HOWEVER, there is still a slight difference in behavior that can't be changed.  It has to do with that "original grid points" demo you created.  The one that shows a 4x4 set of points results in a 3x3 set of colored rectangles.  I.e., the images on the pm3d.html page have to look exactly as they are regardless of whether the underlying plot is an image or rhombuses.  The advantage of the image is that in most display scenarios, I think, there is no introduced aliasing effect where a line shows up.  (Recall that "bug" from a few years back?)

Dan

Re: smooth shading & terminal specialities

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

>> Thus you mean to automagically change "with pm3d" into "with image" without 
>> knowing it to user? That's not a good idea I think.
>
> Well, yes and no.  The point is, there are several images where the 
> underlying image routine can be used for the plots that pm3d creates but the 
> image routine is a much more compact manner of representing that plot.  (For 
>
> HOWEVER, there is still a slight difference in behavior that can't be 
> changed.  It has to do with that "original grid points" demo you created. 
> The one that shows a 4x4 set of points results in a 3x3 set of colored 
> rectangles.  I.e., the images on the pm3d.html page have to look exactly as

The pm3d drawing routine would call image drawing routine with a calculated 
matrix if the surface has_grid_topology. This would probably be easy to 
implement.

---
PM

Re: smooth shading & terminal specialities

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

Petr Mikulik wrote:
>>> Thus you mean to automagically change "with pm3d" into "with image" 
>>> without knowing it to user? That's not a good idea I think.
>>
>>
>> Well, yes and no.  The point is, there are several images where the 
>> underlying image routine can be used for the plots that pm3d creates 
>> but the image routine is a much more compact manner of representing 
>> that plot.  (For
>> HOWEVER, there is still a slight difference in behavior that can't be 
>> changed.  It has to do with that "original grid points" demo you 
>> created. The one that shows a 4x4 set of points results in a 3x3 set 
>> of colored rectangles.  I.e., the images on the pm3d.html page have to 
>> look exactly as
> 
> 
> The pm3d drawing routine would call image drawing routine with a 
> calculated matrix if the surface has_grid_topology. This would probably 
> be easy to implement.

Well, in prinicple easy.  Let me summarize as part of brainstorming.  We have a lower level terminal call:

		    (*term->image) (M, N, image, corners, pixel_planes);

and what need be done is put the data in the array image *in the correct orientation*.  If we were to use this, we'd probably have to put some work into finding the correct orientation, effectively repeating some work in the function below.  It isn't the simplest of routines when you think of all possible orientations.

And we also have a higher level routine:

plot_image_or_update_axes(void *plot, t_imagecolor pixel_planes, TBOOLEAN project_points, TBOOLEAN update_axes)

which looks at the grid point positions in the plot data and finds the correct orientation, bounding box, etc.  The plot pointer "plot" can be either surface points or curve points.  If somehow you collapse your K by L data down into a K-1 by L-1 data via "combining" (e.g., average, pick one of the four) corner locations and "combining" element values, that would avoid a lot of work.

Which do you think would be preferred?

Dan

Re: smooth shading & terminal specialities

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

On Monday 08 May 2006 12:26 pm, Daniel J Sebald wrote:
> 
> My opinion is that this "gppsfile" variable should be eliminated.  
> From what I understand, the purpose of this is a flag in the main 
> code that indicates a PostScript comment can be added to the file 
> for later use.  

Your understanding is wrong.  No post-processing is involved.
The gppsfile is the PostScript output stream itself.
If the current terminal driver is "post", this is only output
stream (gppsfile == gpoutfile).  But for epslatex, pslatex, etc,
it is a secondary output stream parallel to the TeX output.

> PostScript is the most feature rich language I'm aware of.  
> (The Adobe language reference should be consulted first.) 

It's beginning to show its age.  Poor support for UTF8 for
one thing, but more to the point in the present discussion --
it doesn't support gradient fill.  That puts it behind 
several of the other output drivers.

> I guess I've never completely understood the convention of 
> "default routine" in the terminal driver concept.  
> Someone will have to explain this.

Easy.  Some output devices have special requirements, or
special capabilities. So the corresponding terminal driver
needs a private routine to implement these requirements
or features.  But it would be silly to write a private
routine for every single driver, because most of them can
share a generic default routine.

For instance, some of the TeX variants support a "draw arrow"
command as a native operation, and can produce snazzier arrows
than gnuplot's generic do_arrow() routine.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: smooth shading & terminal specialities

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

Ethan Merritt wrote:
> On Monday 08 May 2006 12:26 pm, Daniel J Sebald wrote:
> 
>>My opinion is that this "gppsfile" variable should be eliminated.  
>>From what I understand, the purpose of this is a flag in the main 
>>code that indicates a PostScript comment can be added to the file 
>>for later use.  
> 
> 
> Your understanding is wrong.  No post-processing is involved.
> The gppsfile is the PostScript output stream itself.
> If the current terminal driver is "post", this is only output
> stream (gppsfile == gpoutfile).  But for epslatex, pslatex, etc,
> it is a secondary output stream parallel to the TeX output.

Well, that's true.  But ultimately, I think the purpose here is more one of being a flag, i.e.,

    /* for pm3dCompress.awk */
    if (gppsfile)
	fputs("%pm3d_map_begin\n", gppsfile);

[snip]

    /* for pm3dCompress.awk */
    if (gppsfile)
	fputs("%pm3d_map_end\n", gppsfile);

> 
> 
>>PostScript is the most feature rich language I'm aware of.  
>>(The Adobe language reference should be consulted first.) 
> 
> 
> It's beginning to show its age.  Poor support for UTF8 for
> one thing, but more to the point in the present discussion --
> it doesn't support gradient fill.  That puts it behind 
> several of the other output drivers.

OK.  How about PDF, does that have more features like gradient fill than does P.S.?

...  Forgot to mention desires for compression in images that have come up.  (That really has no significance to recent discussion about terminal commands.)  And also the colorbox can be done with an image.

> 
> 
>>I guess I've never completely understood the convention of 
>>"default routine" in the terminal driver concept.  
>>Someone will have to explain this.
> 
> 
> Easy.  Some output devices have special requirements, or
> special capabilities. So the corresponding terminal driver
> needs a private routine to implement these requirements
> or features.  But it would be silly to write a private
> routine for every single driver, because most of them can
> share a generic default routine.
> 
> For instance, some of the TeX variants support a "draw arrow"
> command as a native operation, and can produce snazzier arrows
> than gnuplot's generic do_arrow() routine.

Let's see if I can fit the image stuff into this context.  The terminal specific driver is "image_for_term" in which we add some angle.  (We're still in "experimental stage", right?):

->image_for_term(<current vars>, angle_struct)

where <current vars> is the current list of variables.  Then I supply the routine in cases where a driver can't use projection:

generic_image_with_rhombus()
{

  /* If projection implies pixels will be rectangular then can use the terminal driver's image drawing routine, but how to now access this?

  if (<rectangular projection tests>)
    term->rectangular_image_for_term()  /* Some other terminal routine? */
  else
    <this code already exists in plot2d.c and would simply need repackaging in function form>

}

Then the terminal driver could put ->generic_image_with_rhombus() in place of ->image_for_term()?

My quandary is that the slot in the terminal driver list gets used by the generic function, but there is still some terminal specific code to come after that.  Then what?  The result would be two slightly different terminal image routines?

The alternative would be, as you say, each terminal driver has it's own test like "generic_image_with_rhombus()" does above.  It's a repetitive way of addressing that, but not too bad.  In fact, that <rectangular projection tests> code could be gathered as a simply routine and reused to make things more compact.

I have no strong opinion on how it should be; just not certain on how to go about this.

Dan

Re: smooth shading & terminal specialities

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

On Monday 08 May 2006 01:19 pm, you wrote:
> Ethan Merritt wrote:
> > The gppsfile is the PostScript output stream itself.
> > If the current terminal driver is "post", this is only output
> > stream (gppsfile == gpoutfile).  But for epslatex, pslatex, etc,
> > it is a secondary output stream parallel to the TeX output.
> 
> Well, that's true.  But ultimately, I think the purpose here is more one of being a flag

No. It *must* have a separate output file descriptor, because if you
were to send it to gpoutfile it would get intermingled with the TeX
output stream.

> , i.e., 
>     /* for pm3dCompress.awk */
>     if (gppsfile)
> 	fputs("%pm3d_map_begin\n", gppsfile);

Yeah, but that is just an added nicety.  The gppsfile
mechanism is necessary in any case.

Getting back to the case at hand, the reason post.trm has a
private routine for this is that we encode the color palette
mapping equations into PostScript and include it in the output file.
So the requisite colors can be generated at print time, taking
into consideration the capabilities of the printer, without the
core routines having to know anything about the eventual 
printer properties.  

> > Easy.  Some output devices have special requirements, or
> > special capabilities. So the corresponding terminal driver
> > needs a private routine to implement these requirements
> > or features.  But it would be silly to write a private
> > routine for every single driver, because most of them can
> > share a generic default routine.
> > 
> > For instance, some of the TeX variants support a "draw arrow"
> > command as a native operation, and can produce snazzier arrows
> > than gnuplot's generic do_arrow() routine.
> 
> Let's see if I can fit the image stuff into this context.

I'm not sure it makes any sense to have a generic fallback for
the image code.  You *could*  write a generic routine that draws
each pixel as a single dot, turning an HP2648 pen-plotter into
a latter day pointiliste successor to Seurat.  But I don't think
we need to go there :-)



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: smooth shading & terminal specialities

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

Ethan Merritt wrote:

> 
>>, i.e., 
>>    /* for pm3dCompress.awk */
>>    if (gppsfile)
>>	fputs("%pm3d_map_begin\n", gppsfile);
> 
> 
> Yeah, but that is just an added nicety.

:-)

>  The gppsfile
> mechanism is necessary in any case.
> 
> Getting back to the case at hand, the reason post.trm has a
> private routine for this is that we encode the color palette
> mapping equations into PostScript and include it in the output file.
> So the requisite colors can be generated at print time, taking
> into consideration the capabilities of the printer, without the
> core routines having to know anything about the eventual 
> printer properties.  

I see that now.

Dan

Re: smooth shading & terminal specialities

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

>   if (gppsfile)
> 	draw_inside_color_smooth_box_postscript(out);
>   else
> 	draw_inside_color_smooth_box_bitmap(out);
>
> I need my own version of drawing "smooth_box" (the terminal supports
> vector graphic format, so drawing a whole lot of rectangles of single
> color is extremely inefficient). Should I say

Use "plot .. with image" instead.

> draw_inside_color_smooth_box_postscript could be rewritten as well to
> produce smooth shading instead of 1000 single-color boxes (smooth
> liear shading with a stitching function).

this routine must respect "set palette maxcolors"; your proposal means 
adding a code just for the case maxcolors == 0.

> Many plot on http://gnuplot.sourceforge.net/demo_4.1/pm3d.html could
> be drawn more efficiently if I knew in advance that I'm able to draw
> an NxM image

I think you request that "with image" should support also functions and not 
only datafile as it currently does, e.g.
 	(s)plot x*x-y*y with image


Notice that "with pm3d" is optimized for non-matricial data; e.g., the 
following masked function would have troubles "with image":
 	set pm3d map
 	f(x,y)=(x*x+y*y>5) ? x*y : 1/0
 	splot f(x,y)

---
PM

Re: smooth shading & terminal specialities

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

On Sunday 07 May 2006 07:53 pm, Mojca Miklavec wrote:
> I need my own version of drawing "smooth_box" (the terminal supports
> vector graphic format, so drawing a whole lot of rectangles of single
> color is extremely inefficient). 

I don't quite understand what you mean by that. 
How does a "vector graphic format" avoid having to draw filled
rectangles?  Do you mean there is native support for gradient fill?
In any case...

> Should I say 
> 
>     if (gppsfile)
> 	draw_inside_color_smooth_box_postscript(out);
>     else if(term->name == "my terminal")
>         MY_TERMINAL_draw_inside_color_smooth_box();
>     else
>         ...

Yes. 
The idea is that there is a generic routine draw_inside_color_smooth_box_bitmap
that can be used by any terminal.  However, some terminals may be able
to do the job more efficiently using some private routine. The only
driver to implement this so far is the postscript driver.  The test
"if (gppsfile)..." is a short way of testing for the driver; it might
be more proper to say
  if (!strcmp(term->name,"post") || !strcmp(term->name,"epslatex")
     || !strcmp(term->name,"pslatex") ....

> or is there a better (more consistent) solution? I hate touching the
> code outside my own (new) terminal, but in this case I probably can't
> avoid it.

There was some small amount of discussion on the list about creating
a new terminal entry point that would draw an area (triangle? rectangle?)
with a gradient fill.  The above calls would then become

   if (term->gradient_fill_box)
       term->gradient_fill_box(  some set of parameters  );

> draw_inside_color_smooth_box_postscript could be rewritten as well to
> produce smooth shading instead of 1000 single-color boxes (smooth
> liear shading with a stitching function). I know exactly what has to
> be done, but I would need some thinking to implement it properly. If
> someone knows PostScript language better than I do, I'm ready to
> describe the procedure more precisely. (A better and more efficient
> code can be produced using a new approach.)

That would be nice, particularly because the current PostScript
implementation triggers anti-aliasing artifacts on some versions
of ghostscript.  But are you sure there is a better way in
PostScript? I know this could be done in SVG, but I am unaware
of any way to do gradients in PostScript other than lots of little
single-color boxes.

> Many plot on http://gnuplot.sourceforge.net/demo_4.1/pm3d.html could
> be drawn more efficiently if I knew in advance that I'm able to draw
> an NxM image as opposed to drawing NxM rectangles. 

If you know that, you maybe should be using "plot with image" instead.

> Even the 4th and the 5th example could be simplified considerably,
> but the examples 6-12 are obvious examples of such inefficient graphic,
> which could be stored as a bitmap image.

You mis-understand the purpose of the demo.  It is not trying to
show an efficient way of plotting a rectangular image. It is simply
demonstrating different color schemes possible by changing the
palette definition.

> At which places in the source should  (colud?) this be improved?

If I understand correctly what you want, it was already implemented
by Dan Sebald and others as plot styles "with image" and
"with rgbimage".  But there is probably room for improving the
code. One recent request (# 1480115) is to add support for an
alpha channel.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: smooth shading & terminal specialities

[Mojca M. <moj...@gm...>]

I'm sending a sample .ps file with gradient fill for the default palette.

I calculated the values at 11 equally spaced points and converted them
into hex numbers, now stored in /data. PostScript terminal currently
draws 1024 single-color rectangles. Does anyone notice any difference
in the palette produced by gradient fill and the one produced by 1024
samples? (I've read that sinus can be represented using 10 samples
with only 1% of mistake.) Well, the number of samples for making
gradient fill can be increased, but defining the color in 20 points is
still far less than drawing 1024 rectangles, not counting the
inefficiency and antialiasing artefacts that arise in the current
approach.

I don't know enough about PostScript language to be able to tell how
/data can be calculated in the PostScript file itself, but I'm almost
sure that it is possible. In any case gnuplot can calculate those 11
(or more) values if needed.

Could someone with some more inspect into PS terminal implement such
gradient fills for draw_inside_color_smooth_box_postscript(...)? I can
explain the details if needed.


On 5/8/06, Ethan Merritt (and others) wrote:

> > I need my own version of drawing "smooth_box" (the terminal supports
> > vector graphic format, so drawing a whole lot of rectangles of single
> > color is extremely inefficient).
>
> I don't quite understand what you mean by that.
> How does a "vector graphic format" avoid having to draw filled
> rectangles?  Do you mean there is native support for gradient fill?
> In any case...

Yes, native support for gradient fill.

> PostScript? I know this could be done in SVG, but I am unaware
> of any way to do gradients in PostScript other than lots of little
> single-color boxes.

I'm attaching an example showing gradients in PS.

> You mis-understand the purpose of the demo.  It is not trying to
> show an efficient way of plotting a rectangular image. It is simply
> demonstrating different color schemes possible by changing the
> palette definition.

Sure, but that doesn;t mean that it couldn't be rendered more
efficiently. (One would loose the ability to manualy change the
palette in the PostScript file afterwards (since gnuplot should
calculate the colors before drawing an image as opposed to the current
situation where PostScript calculates the proper color), but I don't
think that this would be a serious reason for not implementing better
rendering. How many people are manual editin PostScript code and how
many are suffering from GhostScript antialiasing "bug"?)

> Thus you mean to automagically change "with pm3d" into "with image" witho=
ut
> knowing it to user? That's not a good idea I think.

The user shouldn't notice any difference.

> OK.  How about PDF, does that have more features like gradient fill than =
does P.S.?

PS *does have* gradient fill.

> ...  Forgot to mention desires for compression in images that have come u=
p.
> (That really has no significance to recent discussion about terminal comm=
ands.)
> And also the colorbox can be done with an image.

I wanted to implement that behaviour in my driver (if maxcolors>0 use
image instead of gradient fill), but I would be glad if gnuplot would
be clever enough to take care about that.


> >>Even the 4th and the 5th example could be simplified considerably,
> >>but the examples 6-12 are obvious examples of such inefficient graphic,
> >>which could be stored as a bitmap image.
> >
> >
> > You mis-understand the purpose of the demo.  It is not trying to
> > show an efficient way of plotting a rectangular image. It is simply
> > demonstrating different color schemes possible by changing the
> > palette definition.
>
> Mojca, could you explain a bit more about what you meant.  I think we're =
trying to guess here a bit too much.

OK. Let me try to explain, For drawing the "plotting area" in this
image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
nothing else but a bitmap image, gnuplot calls my terminal
    term->set_color(...)
    term->fillbox(...)
49 x 49 times. For bitmap teminal this doesn't really matter, but for
my terminal it means constructing 49x49 paths and fill each one of
them separately (bot at compile time of the image and when displaying
it in GhostView or Acrobat), not to mention aliasing-artefacts (I
don't know how they are called, but GhostView shows white stripes all
over the plot). This is extremely inefficient. It would be much better
if gnuplot would call a routine
    term->image(49,49, ....)
The result would be the visually the same (only better since no
artefacts would occur) and both compiling and rendering would be more
efficient. If the driver doesn't support "images", it can still draw
49 times 49 filled rectangles.

Mojca

Re: smooth shading & terminal specialities

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

On Tuesday 09 May 2006 03:52 pm, you wrote:
> I'm sending a sample .ps file with gradient fill for the default palette.
> 
> I calculated the values at 11 equally spaced points and converted them
> into hex numbers, now stored in /data. PostScript terminal currently
> draws 1024 single-color rectangles. Does anyone notice any difference
> in the palette produced by gradient fill and the one produced by 1024
> samples?

Aha.  You are using Level 3 extensions to PostScript.

They are not mentioned in the PostScript Language Reference Manual 
(2nd Edition) that I have on my shelf.
Your test file displays on my older machines, which surprises me,
but the result looks truly awful.  My new machines have a newer gs
installed that does indeed support these extensions.

I guess I should go out and buy a new copy of the Language
Reference Manual.

If we were to adopt this approach, we would have to wrap it in a test
for level capabilities so that Level 1/2/3 devices would all do 
something reasonable.  That is certainly possible, but could be done
more easily by an expert.  Harald Harders and I muddled our way 
through something similar for the pattern-fill support, which is a
Level 2 extension, but it was a struggle.

> > OK.  How about PDF, does that have more features like gradient fill than does P.S.?
> 
> PS *does have* gradient fill.

Sufficiently new versions of it [Level 3].

> OK. Let me try to explain, For drawing the "plotting area" in this
> image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
> nothing else but a bitmap image, gnuplot calls my terminal
>     term->set_color(...)
>     term->fillbox(...)
> 49 x 49 times. For bitmap teminal this doesn't really matter, but for
> my terminal it means constructing 49x49 paths and fill each one of
> them separately (bot at compile time of the image and when displaying
> it in GhostView or Acrobat), not to mention aliasing-artefacts (I
> don't know how they are called, but GhostView shows white stripes all
> over the plot). 

Yeah, we know.  That is the down-side of newer versions of gs/gv/ghostview.
They have a bad aliasing bug.  It's a known bug, but even if they fix it
there will be a lot of broken installations for a long time to come.

> This is extremely inefficient. It would be much better 
> if gnuplot would call a routine
>     term->image(49,49, ....)
> The result would be the visually the same (only better since no
> artefacts would occur) and both compiling and rendering would be more
> efficient. If the driver doesn't support "images", it can still draw
> 49 times 49 filled rectangles.

But how does the higher level code tell a driver what to put in those
49x49 boxes?  In the general case each one has a different color, so
I do not see how you end up saving anything.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: smooth shading & terminal specialities

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

Ethan Merritt wrote:

>>This is extremely inefficient. It would be much better 
>>if gnuplot would call a routine
>>    term->image(49,49, ....)
>>The result would be the visually the same (only better since no
>>artefacts would occur) and both compiling and rendering would be more
>>efficient. If the driver doesn't support "images", it can still draw
>>49 times 49 filled rectangles.
> 
> 
> But how does the higher level code tell a driver what to put in those
> 49x49 boxes?  In the general case each one has a different color, so
> I do not see how you end up saving anything.

I'm not completely following, and I think I'm still wondering about the terminal function mechanism.  Perhaps I'm used to thinking of C++ where one can override the function of a class and in some cases if base object in question doesn't have an overriding function, the function falls back to the base function.

The idea would be that for terminals which don't support term->image() there would be a base version of image_rhombus() (or some such thing) that draws an image using rhombuses and effectively acts the way pm3d currently does.

If there is image support, there is a big savings because the data is compact, i.e., a matrix of numbers as opposed to all the corners of each pixel, the rendering is better and faster at the driver or system call level, no aliasing issues, etc.

Dan

Re: smooth shading & terminal specialities

[<br...@ph...>]

Daniel J Sebald wrote:

> I'm not completely following, and I think I'm still wondering about the 
> terminal function mechanism.  Perhaps I'm used to thinking of C++ where 
> one can override the function of a class and in some cases if base 
> object in question doesn't have an overriding function, the function 
> falls back to the base function.

That's quite exactly what term.c does.  But being written in C, it has 
to be done manually, instead of some C++ runtime magic doing it for us.
term/README should be clear enough, really, but here's how it works:

struct TERMENTRY is an interface (an pure abstract base class, in C++ 
jargon).  An adapter class (providing fall-back implementations for 
several of TERMENTRY's methods) is in term.c.  Viz. do_arrow(), 
do_point()...  Each terminal driver is a derived class of this adapter. 
  It will implement some methods, but doesn't have to implement all. 
Those it doesn't implement are marked by zeroes in the TERM_ENTRY part 
of the .trm file.  The "class loader" in term.c replaces those dummies 
by the adapter classes implementations.


> 
> The idea would be that for terminals which don't support term->image() 
> there would be a base version of image_rhombus() (or some such thing) 
> that draws an image using rhombuses and effectively acts the way pm3d 
> currently does.

Feel free to write a do_image(), put it in term.c, and add it do the 
adapter class by updating the "class loader".

Re: smooth shading & terminal specialities

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

Hans-Bernhard Br=F6ker wrote:

>> The idea would be that for terminals which don't support term->image()=
=20
>> there would be a base version of image_rhombus() (or some such thing)=20
>> that draws an image using rhombuses and effectively acts the way pm3d=20
>> currently does.
>=20
>=20
> Feel free to write a do_image(), put it in term.c, and add it do the=20
> adapter class by updating the "class loader".

OK, thanks.  That is sort of what I had envisioned early on, but didn't w=
ant to touch too much code initially.

Dan

Re: smooth shading & terminal specialities

[<tim...@en...>]

>> I don't quite understand what you mean by that.
>> How does a "vector graphic format" avoid having to draw filled
>> rectangles?  Do you mean there is native support for gradient fill?
>> In any case...
>
> Yes, native support for gradient fill.

Starting from Postscript level 3, which has been released in 1999
according to the date in the Adobe documentation. I don't know much about
the capabilities of printers regarding Postscript level 3.

However, the rendering is good for me with Ghostscript.

> OK. Let me try to explain, For drawing the "plotting area" in this
> image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
> nothing else but a bitmap image, gnuplot calls my terminal
>     term->set_color(...)
>     term->fillbox(...)
> 49 x 49 times. For bitmap teminal this doesn't really matter, but for
> my terminal it means constructing 49x49 paths and fill each one of
> them separately (bot at compile time of the image and when displaying
> it in GhostView or Acrobat), not to mention aliasing-artefacts (I
> don't know how they are called, but GhostView shows white stripes all
> over the plot).

This kind of artifacts due to antialiasing can sometimes be worked around
when you know that paths are adjacent. For the wxWidgets terminal which
uses Cairo to render, I had to use a different operator
(CAIRO_OPERATOR_SATURATE) to composite what you want to paint with what
already exists on the surface, so that the fill algorithm won't produce
white seams between adjacent polygons. There have been multiple threads i=
n
the cairo mailing list about that.
However, in postscript no such concept seem to exist, at least I can't
find any by looking quickly in the Adobe doc, but that may be worth
looking for.

By the way, the aquaterm terminal seems to have the same problem : see th=
e
pm3d plot on http://aquaterm.sourceforge.net/index.shtml?page=3Ds1

Finally, if gradient fills are to be used, Cairo can also do that, so it
should definitely go into a new terminal entry instead of a direct call.

Regards,

Timoth=E9e

Re: smooth shading & terminal specialities

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

> I'm sending a sample .ps file with gradient fill for the default palette.
>
> I calculated the values at 11 equally spaced points and converted them
>
> I don't know enough about PostScript language to be able to tell how
> /data can be calculated in the PostScript file itself, but I'm almost
> sure that it is possible. In any case gnuplot can calculate those 11
> (or more) values if needed.

Please how a look into scripts pm3dCompress.awk and pm3dConvertToImage.awk
how the online calculation of colors using RGB formulae can be done.

BTW, do you know these scripts? They were written ages ago exactly for the 
purpose of making the ps files smaller.

> I need my own version of drawing "smooth_box" (the terminal supports
> vector graphic format, so drawing a whole lot of rectangles of single
> color is extremely inefficient).

Well, if you need it *now*, just write an awk/sed script which replaces it 
in-place.

> Sure, but that doesn;t mean that it couldn't be rendered more
> efficiently.

Then this would require that gnuplot looks at the data *before* drawing 
them, tests pixel coordinates whether they form an equidistant grid 
(matrix), and if yes, then call the image() routine instead of the pm3d 
drawing routine.

A similar test was there for the purpose of "with image", but it was removed 
(you could not set the tolerance).

> (One would loose the ability to manualy change the
> palette in the PostScript file afterwards (since gnuplot should
> calculate the colors before drawing an image as opposed to the current
> situation where PostScript calculates the proper color)

no, see above

>> Thus you mean to automagically change "with pm3d" into "with image" without
>> knowing it to user? That's not a good idea I think.
>
> The user shouldn't notice any difference.

But how *exactly* gnuplot makes the switch? See may comments on tolerance 
above.

> OK. Let me try to explain, For drawing the "plotting area" in this
> image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
> nothing else but a bitmap image, gnuplot calls my terminal
>   term->set_color(...)
>   term->fillbox(...)
> 49 x 49 times. For bitmap teminal this doesn't really matter, but for
> my terminal it means constructing 49x49 paths and fill each one of
> them separately (bot at compile time of the image and when displaying
> it in GhostView or Acrobat), not to mention aliasing-artefacts (I
> don't know how they are called, but GhostView shows white stripes all
> over the plot). This is extremely inefficient. It would be much better
> if gnuplot would call a routine
>   term->image(49,49, ....)
> The result would be the visually the same (only better since no

I think this is user's error: he should use "with image" and not "with pm3d" 
if he wants to draw a matrix instead of individual rectangles. Given the 
documentation for both styles (see gnuplot's help), they operate exactly as 
designed and documented.
   Of course an improved performance is nice, but that's why "with image" has 
been implemented.

Thus, now there is the only question how to write the smallest code to draw 
the colour box with as short code as possible for any value of maxcolors.

---
PM

Re: smooth shading & terminal specialities

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

Ethan Merritt wrote:
> On Sunday 07 May 2006 07:53 pm, Mojca Miklavec wrote:
>>Should I say 
>>
>>    if (gppsfile)
>>	draw_inside_color_smooth_box_postscript(out);
>>    else if(term->name == "my terminal")
>>        MY_TERMINAL_draw_inside_color_smooth_box();
>>    else
>>        ...
> 
> 
> Yes. 
> The idea is that there is a generic routine draw_inside_color_smooth_box_bitmap
> that can be used by any terminal.  However, some terminals may be able
> to do the job more efficiently using some private routine. The only
> driver to implement this so far is the postscript driver.  The test
> "if (gppsfile)..." is a short way of testing for the driver; it might
> be more proper to say
>   if (!strcmp(term->name,"post") || !strcmp(term->name,"epslatex")
>      || !strcmp(term->name,"pslatex") ....

Really?  I thought we're supposed to keep terminal-specific code out of the core and override terminal functions.


>>draw_inside_color_smooth_box_postscript could be rewritten as well to
>>produce smooth shading instead of 1000 single-color boxes (smooth
>>liear shading with a stitching function). I know exactly what has to
>>be done, but I would need some thinking to implement it properly. If
>>someone knows PostScript language better than I do, I'm ready to
>>describe the procedure more precisely. (A better and more efficient
>>code can be produced using a new approach.)
> 
> 
> That would be nice, particularly because the current PostScript
> implementation triggers anti-aliasing artifacts on some versions
> of ghostscript.  But are you sure there is a better way in
> PostScript? I know this could be done in SVG, but I am unaware
> of any way to do gradients in PostScript other than lots of little
> single-color boxes.

Well, doing it as an image, one would think that the viewer driver knows to do proper anti-aliasing.  (Recall PostScript isn't bitmap based... only in its last rendering does it do that.)


>>Even the 4th and the 5th example could be simplified considerably,
>>but the examples 6-12 are obvious examples of such inefficient graphic,
>>which could be stored as a bitmap image.
> 
> 
> You mis-understand the purpose of the demo.  It is not trying to
> show an efficient way of plotting a rectangular image. It is simply
> demonstrating different color schemes possible by changing the
> palette definition.

Mojca, could you explain a bit more about what you meant.  I think we're trying to guess here a bit too much.

> 
>>At which places in the source should  (colud?) this be improved?
> 
> 
> If I understand correctly what you want, it was already implemented
> by Dan Sebald and others as plot styles "with image" and
> "with rgbimage".  But there is probably room for improving the
> code. One recent request (# 1480115) is to add support for an
> alpha channel.

Oh yeah, I forgot all about that.  (Whoever oversees that may assign that request to me, user "sebald".  I can't seem to do that without having created it.)  Am I right that the alpha would be a depth of four, one of the channels being 0/nonzero?  So maybe the syntax should be something like "with rgbaimage", or "with argbimage"?  Or is there some trick where one of the rgb colors becomes a opaque?

Dan

Re: smooth shading & terminal specialities

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

On Monday 08 May 2006 08:16 pm, Daniel J Sebald wrote:
> > be more proper to say
> >   if (!strcmp(term->name,"post") || !strcmp(term->name,"epslatex")
> >      || !strcmp(term->name,"pslatex") ....
> 
> Really?  I thought we're supposed to keep terminal-specific code 
> out of the core and override terminal functions. 

Right. I already pointed out that we had discussed making this
a terminal entry point. But since the only terminal that would
actually use it is post.trm, there wasn't much motion to add the
entry to all terminals.
 
> Well, doing it as an image, one would think that the viewer driver 
> knows to do proper anti-aliasing.  

One would think. 
But there is a known rendering bug in ghostscript's anti-aliasing code.

> >  One recent request (# 1480115) is to add support for an alpha channel.
> 
> Oh yeah, I forgot all about that.
> Am I right that the alpha would be a depth of four, one of the channels
> being 0/nonzero?  

Alpha runs from 0->1 (or 0-255 if it's a 1-byte representation).

> So maybe the syntax should be something like "with rgbaimage",
> or "with argbimage"?

You already wrote code to support in on input -

    binary filetype=avs with rgbimage

AVS files contains 4 bytes per pixel, ARGB.
But right now the Alpha byte is thrown away on input.

Suppose you were to keep the alpha byte in parallel with the
RGB bytes.  A few drivers (gd, svg) can use it directly.
But we'd have to add custom code in order to get most drivers to
handle transparency.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: smooth shading & terminal specialities

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

>> driver to implement this so far is the postscript driver.  The test
>> "if (gppsfile)..." is a short way of testing for the driver; it might
>> be more proper to say
>>   if (!strcmp(term->name,"post") || !strcmp(term->name,"epslatex")
>>      || !strcmp(term->name,"pslatex") ....

if (gppsfile)  has replaced that strcmp(...->name,...) comparison which was 
there earlier. Thus, use (gppsfile) to test for an PS output stream.

---
PM

Re: smooth shading & terminal specialities

[Mojca M. <moj...@gm...>]

On 5/10/06, Ethan Merritt wrote:
> On Tuesday 09 May 2006 03:52 pm, you wrote:
> > I'm sending a sample .ps file with gradient fill for the default palett=
e.
> >
> > I calculated the values at 11 equally spaced points and converted them
> > into hex numbers, now stored in /data. PostScript terminal currently
> > draws 1024 single-color rectangles. Does anyone notice any difference
> > in the palette produced by gradient fill and the one produced by 1024
> > samples?
>
> Aha.  You are using Level 3 extensions to PostScript.
>
> They are not mentioned in the PostScript Language Reference Manual
> (2nd Edition) that I have on my shelf.
> Your test file displays on my older machines, which surprises me,
> but the result looks truly awful.  My new machines have a newer gs
> installed that does indeed support these extensions.
>
> I guess I should go out and buy a new copy of the Language
> Reference Manual.

I downloaded the documentation and examples of files with smooth
shading from Adobe (it's not meant to be taken on holidays as reading
for relaxation ;). I'm sorry - I didn't thought about older machines
(Level3 is from the last century, but I agree that mostly older PS
printers might experience problems with it.) Level-dependent code
generation would be great!

> > OK. Let me try to explain, For drawing the "plotting area" in this
> > image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
> > nothing else but a bitmap image, gnuplot calls my terminal
> >     term->set_color(...)
> >     term->fillbox(...)
> > 49 x 49 times. For bitmap teminal this doesn't really matter, but for
> > my terminal it means constructing 49x49 paths and fill each one of
> > them separately (bot at compile time of the image and when displaying
> > it in GhostView or Acrobat), not to mention aliasing-artefacts (I
> > don't know how they are called, but GhostView shows white stripes all
> > over the plot).
>
> Yeah, we know.  That is the down-side of newer versions of gs/gv/ghostvie=
w.
> They have a bad aliasing bug.  It's a known bug, but even if they fix it
> there will be a lot of broken installations for a long time to come.
>
> > This is extremely inefficient. It would be much better
> > if gnuplot would call a routine
> >     term->image(49,49, ....)
> > The result would be the visually the same (only better since no
> > artefacts would occur) and both compiling and rendering would be more
> > efficient. If the driver doesn't support "images", it can still draw
> > 49 times 49 filled rectangles.
>
> But how does the higher level code tell a driver what to put in those
> 49x49 boxes?  In the general case each one has a different color, so
> I do not see how you end up saving anything.

Well ... storing 2500 boxes means 7500 lines of output like this for
my terminal (which also renders awfully):

gp_set_color_frac(0.1641);
p :=3D (104.66,20.10)--(108.91,20.10)--(108.91,20.47)--(104.66,20.47)--cycl=
e;
gp_fill(p,1);

Storing a field of 2500 RGB tripples means 7500 bytes instead and is
also rendered much more efficiently and with no antialiasing problems.

In the first case you also have to save coordinates, not only the
color (I could save some space with shorter names and such, but that
woudn't have much influence on efficiency).

Mojca

Re: smooth shading & terminal specialities

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

> Well ... storing 2500 boxes means 7500 lines of output like this for
> my terminal (which also renders awfully):

if these boxes don't have the same size, or non-rect final shape, then you 
must really save them. See e.g.

http://gnuplot.sourceforge.net/demo_4.1/pm3d.29.png
http://www.sci.muni.cz/~mikulik/figs/gp-pm3d-GaAsFish.gif

Could you store it more effiently (even when processed by pm3dCompress.awk?)

---
PM