gnuplot-beta

pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Hi. I'm seeing ugly lines between the bars in the colorbox when making
.pdf files. Trivial plot to demo this:

  set terminal pdf
  set output "/tmp/tst.pdf"
  plot 5 with points palette

This isn't a new issue, and I was wondering if anybody here had insight
about fixing it.

gp_cairo.c says this:

  /* By default, Cairo uses an antialiasing algorithm which may
   * leave a seam between polygons which share a common edge.
   * Several solutions allow to workaround this behaviour :
   * - don't antialias the polygons
   *   Problem : aliased lines are ugly
   * - stroke on each edge
   *   Problem : stroking is a very time-consuming operation
   * - draw without antialiasing to a separate context of a bigger size
   *   Problem : not really in the spirit of the rest of the drawing.
   * - enlarge the polygons so that they overlap slightly
   *   Problem : It is really more time-consuming that it may seem.
   *   It implies inspecting each corner to find which direction to move it
   *   (making the difference between the inside and the outside of the polygon).
   * - using CAIRO_OPERATOR_SATURATE
   *   Problem : for each set of polygons, we have to draw front-to-back
   *   on a separate context and then copy back to this one.
   *   Time-consuming but probably less than stroking all the edges.
   *
   * The last solution is implemented if plot->polygons_saturate is set to TRUE
   * Otherwise the default (antialiasing but may have seams) is used.
   */

And the gnuplot code today already does the "enlarge the polygons so
that they overlap slightly" thing. color.c has:

  draw_inside_colorbox_bitmap_smooth() {
    ...
    for (i = 0, xy2 = xy_from; i < steps; i++) {

	xy = xy2;
	xy2 = xy_from + (int) (xy_step * (i + 1));

        ...
	if (color_box.rotation == 'v') {
	    corners[0].y = corners[1].y = xy;
	    corners[2].y = corners[3].y = GPMIN(xy_to,xy2+1);
	} else {
	    corners[0].x = corners[3].x = xy;
	    corners[1].x = corners[2].x = GPMIN(xy_to,xy2+1);
	}
    ...
    }

Note the "+1". I still see the ugly bars in the resulting .pdf file
though. I can run experiments, but before I do anything, does anybody
have a comment? The draw_inside_colorbox_bitmap_smooth() stuff changed
in 2020, so maybe looking deeper at the effects of that patch would be
an interesting thing to do.

Thanks

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

It is likely that the artefact is due to the viewing program rather
than being intrinsic to the pdf file output by gnuplot.  I see no such
effect when viewing with the current version of okular, although at
various times in the past I have found that toggling anti-alias in the
viewer settings can make a difference in some cases.  "gv" used to be
quite bad in this regard but has improved since then.

The quadrangles making up a pm3d surface can have the same, or
similar, problem.  That was mitigated by adding an option "set pm3d
border retrace", which can reduce or remove this artifact for solid
fill areas at the cost of introducing a "phantom grid" artifact for
semi-transparent fill areas.   I do not remember at the moment if a
similar treatment was added, or could be added, to the quadrangles
making up the color box.

On Sat, Jun 10, 2023 at 12:56 PM Dima Kogan
<gn...@di...> wrote:
>
> !-------------------------------------------------------------------|
>   This Message Is From an Untrusted Sender
>   You have not previously corresponded with this sender.
>   See https://itconnect.uw.edu/email-tags for additional
>   information.  Please contact the UW-IT Service Center,
>   he...@uw... 206.221.5000, for assistance.
> |-------------------------------------------------------------------!
>
> Hi. I'm seeing ugly lines between the bars in the colorbox when making
> .pdf files. Trivial plot to demo this:
>
>   set terminal pdf
>   set output "/tmp/tst.pdf"
>   plot 5 with points palette
>
> This isn't a new issue, and I was wondering if anybody here had insight
> about fixing it.
>
> gp_cairo.c says this:
>
>   /* By default, Cairo uses an antialiasing algorithm which may
>    * leave a seam between polygons which share a common edge.
>    * Several solutions allow to workaround this behaviour :
>    * - don't antialias the polygons
>    *   Problem : aliased lines are ugly
>    * - stroke on each edge
>    *   Problem : stroking is a very time-consuming operation
>    * - draw without antialiasing to a separate context of a bigger size
>    *   Problem : not really in the spirit of the rest of the drawing.
>    * - enlarge the polygons so that they overlap slightly
>    *   Problem : It is really more time-consuming that it may seem.
>    *   It implies inspecting each corner to find which direction to move it
>    *   (making the difference between the inside and the outside of the polygon).
>    * - using CAIRO_OPERATOR_SATURATE
>    *   Problem : for each set of polygons, we have to draw front-to-back
>    *   on a separate context and then copy back to this one.
>    *   Time-consuming but probably less than stroking all the edges.
>    *
>    * The last solution is implemented if plot->polygons_saturate is set to TRUE
>    * Otherwise the default (antialiasing but may have seams) is used.
>    */
>
> And the gnuplot code today already does the "enlarge the polygons so
> that they overlap slightly" thing. color.c has:
>
>   draw_inside_colorbox_bitmap_smooth() {
>     ...
>     for (i = 0, xy2 = xy_from; i < steps; i++) {
>
>         xy = xy2;
>         xy2 = xy_from + (int) (xy_step * (i + 1));
>
>         ...
>         if (color_box.rotation == 'v') {
>             corners[0].y = corners[1].y = xy;
>             corners[2].y = corners[3].y = GPMIN(xy_to,xy2+1);
>         } else {
>             corners[0].x = corners[3].x = xy;
>             corners[1].x = corners[2].x = GPMIN(xy_to,xy2+1);
>         }
>     ...
>     }
>
> Note the "+1". I still see the ugly bars in the resulting .pdf file
> though. I can run experiments, but before I do anything, does anybody
> have a comment? The draw_inside_colorbox_bitmap_smooth() stuff changed
> in 2020, so maybe looking deeper at the effects of that patch would be
> an interesting thing to do.
>
> Thanks
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!gvmIXc1ZjdPjHB_McnIXjBk792CcUxJIsyISfkYLL-khZyZZpKxIltBsw8-8FEqW9sKJr2ZQwh0CDRgiIi_iCkB-blo_0w$



-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> It is likely that the artefact is due to the viewing program rather
> than being intrinsic to the pdf file output by gnuplot.  I see no such
> effect when viewing with the current version of okular

Interesting. I tried mupdf and evince prior to writing the email, and
they both don't look right. I just tried okular, and like you say, it
looks ok. And gv looks ok too.

I'd like it to look right in the others. Is this a BUG in the other
viewers? I.e. is this something that a bug can be filed about?

What if we change the code from

  calling term->filled_polygon() for each colorbox slice

to

  calling term->image() once for the whole colorbox

Would that break something?

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Actually, okular doesn't fully work either.

I'm currently writing a presentation where I'm using pdflatex and I'm
including gnuplot figures. In that context okular shows the bands also.
Maybe pdflatex is also buggy, but if mupdf AND evince AND pdflatex have
this bug, maybe we should try to work around it. gv is still ok.

You can see this for yourself probably. I downloaded this figure that
was generated by gnuplot:

  http://mrcal.secretsauce.net/external/figures/diff/diff-radius0-heatmap-splined-opencv8.pdf

And ran "pdflatex tst.tex" where tst.tex is:

  \documentclass[presentation]{beamer}
  \begin{document}
  \includegraphics[keepaspectratio,width=0.9\textwidth,height=0.7\textheight]{/tmp/diff-radius0-heatmap-splined-opencv8.pdf}
  \end{document}

The result is attached. I see the bands even with okular.

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

On Saturday, 10 June 2023 17:04:49 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > It is likely that the artefact is due to the viewing program rather
> > than being intrinsic to the pdf file output by gnuplot.  I see no such
> > effect when viewing with the current version of okular
> 
> Interesting. I tried mupdf and evince prior to writing the email, and
> they both don't look right. I just tried okular, and like you say, it
> looks ok. And gv looks ok too.
> 
> I'd like it to look right in the others. Is this a BUG in the other
> viewers? I.e. is this something that a bug can be filed about?

Many years ago I identified the bug in gv and suggested a fix;
I do not know whether my suggestion was eventually adopted or some
other change was made.  That was years ago and I do not recall
the exact details. I have never looked at the code for evince or mupdf.

Okular and Evince both claim to use the poppler library for rendering
pdf files, so I am a bit surprised thay behave differently.
Is it possible that the installations you tested were linked against
different versions of poppler?

> What if we change the code from
>   calling term->filled_polygon() for each colorbox slice
> to
>   calling term->image() once for the whole colorbox

In the case of pdf output it would mean going through the cairo library
either way.  I wouldn't necessarily expect a difference. 

    Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

> I have never looked at the code for evince or mupdf. Okular and Evince
> both claim to use the poppler library for rendering pdf files, so I am
> a bit surprised thay behave differently. Is it possible that the
> installations you tested were linked against different versions of
> poppler?

I'm using the vanilla debian builds. Neither uses poppler today, for
what it's worth.


>> What if we change the code from
>>   calling term->filled_polygon() for each colorbox slice
>> to
>>   calling term->image() once for the whole colorbox
>
> In the case of pdf output it would mean going through the cairo
> library either way. I wouldn't necessarily expect a difference.

I would expect it to fix things because gnuplot images look good with
all pdf readers. Can you think of reasons such a patch wouldn't be a
good idea? The fact that it wasn't done this way to begin with makes me
think there's some reason.

Thanks

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

On Sunday, 11 June 2023 14:14:27 PDT Dima Kogan wrote:
> 
> > I have never looked at the code for evince or mupdf. Okular and Evince
> > both claim to use the poppler library for rendering pdf files, so I am
> > a bit surprised thay behave differently. Is it possible that the
> > installations you tested were linked against different versions of
> > poppler?
> 
> I'm using the vanilla debian builds. Neither uses poppler today, for
> what it's worth.

https://wiki.gnome.org/Apps/Evince/PopplerBugs[1]
https://www.mail-archive.com/kde...@kd.../msg795457.html[2]

	Ethan



--------
[1] https://wiki.gnome.org/Apps/Evince/PopplerBugs
[2] https://www.mail-archive.com/kde...@kd.../msg795457.html

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Oh, and two more notes, where the old code had off-by-one errors

- There old code was set up to overlap each colorbox by extending the
  bottom/right edge of each slice: GPMIN(xy_to,xy2+1)

  But that logic applies to all the slices, even the last one. This
  resulted in the last slice being one unit out-of-bounds

- The old code was computing the colors for each slice like this:

    for (i = 0; i < steps; i++)
      gray = i / (double)steps;

  This is another off-by-one error. The colors in the colorbox spanned
  [0,1-1/steps] instead of [0,1]. My patch fixes this one.

  There's some funky logic in quanize_gray() that maybe is trying to
  deal with this in the limited-max-colors case, but it's not commented,
  and applies to only this case. Code:

    qgray = floor(gray * sm_palette.use_maxcolors)
		        / (sm_palette.use_maxcolors-1);

  That should be made unnecessary

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Sorry for yet another email. I was dogfooding the patch, and found a
minor bug. Sometimes term->image is not available, and the new colorbox
implementation crashes in that case. I added a check to the top of the
function, and it's good now:

  static void
  draw_inside_colorbox_bitmap_smooth()
  {
      if(term->image == NULL)
          return;
  .....

I hit this with the "dumb" terminal. I think not rendering the colorbox
at all in that case is fine. Are there other terminals where term->image
is unavailable, but drawing discrete slices would still have produced
good output?

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

On Sunday, 11 June 2023 20:44:31 PDT Dima Kogan wrote:

> Sorry for yet another email. I was dogfooding the patch, and found a
> minor bug. Sometimes term->image is not available, and the new colorbox
> implementation crashes in that case. I added a check to the top of the
> function, and it's good now:
> 
>   static void
>   draw_inside_colorbox_bitmap_smooth()
>   {
>       if(term->image == NULL)
>           return;
>   .....
> 
> I hit this with the "dumb" terminal. I think not rendering the colorbox
> at all in that case is fine. Are there other terminals where term->image
> is unavailable, but drawing discrete slices would still have produced
> good output?

It will take a while for me to work my way through your proposed changes.
But this much I can answer quickly -
Yes there are terminals that support smooth palette color but not term->image().
At a minimum they include
 block
 cgm
 emf
 fig
 sixeltek

	Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

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

> Oh, and two more notes, where the old code had off-by-one errors
>
> - There old code was set up to overlap each colorbox by extending the
>  bottom/right edge of each slice: GPMIN(xy_to,xy2+1)

Please try also "set term postscript color" output to see what your pdf 
viewers do there. These "write stripes issue" and antialiasing was an issue 
two decades ago. It depended whether you have switched on or off antialising 
in the pdf/ps viewer. Hm, I see that current viewer do not have such an option 
any longer (even though ghostscript can be run with different options), so you 
cannot check the problem directly in the viewer.

What you can try as the lowest-level approach is

gs a.pdf
gs -dDOINTERPOLATE a.pdf

Pdf itself can manipulate antialiasing directly, such as 
3 0 obj
<</AntiAlias false>>
but that's probably possible to insert directy in the poppler or 
cairo library?

> - The old code was computing the colors for each slice like this:
>
>    for (i = 0; i < steps; i++)
>      gray = i / (double)steps;
>
>  This is another off-by-one error. The colors in the colorbox spanned
>  [0,1-1/steps] instead of [0,1]. My patch fixes this one.
>
>  There's some funky logic in quanize_gray() that maybe is trying to
>  deal with this in the limited-max-colors case, but it's not commented,
>  and applies to only this case. Code:
>
>    qgray = floor(gray * sm_palette.use_maxcolors)
> 		        / (sm_palette.use_maxcolors-1);

The colorbox code must work correctly for limited number of colors, try
 	set palette maxcolors 4
 	splot x*y with pm3d
Thus I think the code is correct, if you see exactly 4 color boxes in the 
colorbox.

---
Petr Mikulik

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

On Sunday, 11 June 2023 14:14:27 PDT Dima Kogan wrote:
> >> What if we change the code from
> >>   calling term->filled_polygon() for each colorbox slice
> >> to
> >>   calling term->image() once for the whole colorbox
> >
> > In the case of pdf output it would mean going through the cairo
> > library either way. I wouldn't necessarily expect a difference.
> 
> I would expect it to fix things because gnuplot images look good with
> all pdf readers. Can you think of reasons such a patch wouldn't be a
> good idea? The fact that it wasn't done this way to begin with makes me
> think there's some reason.

I may not understand what you are suggesting.

Right now in order to create pdf output the code is calling 
cairotrm_filled_polygon() to render pixels into a cairo surface which
is eventually output as a pdf file.

I understood your suggestion to be that the program would instead
create a separate cairo png surface, use cairotrm_filled_polygon() to render
the pixels, then copy the pixels from the png surface to the pdf surface.

It is not obvious to me that the extra step would change the final output.
The same calls to cairotrm_filled_polygon() would be rendered
either way.  Copying the block of rendered pixels from one cairo surface to
another should not, I would think, change anything.

Anyhow, such a change would be specific to the cairo terminals.
We would not want to introduce a dependence on cairo image creation
when drawing the color box from other terminal types.

	Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> I may not understand what you are suggesting.

Hi. I guess I wasn't clear. The suggestion was that instead of creating
128 discrete bars with different colors we create a 128x1 bitmap and
draw it as an image. The thought was that this would work because images
look correct in pdfcairo, without the ugly border lines.

I implemented this in the attached patch, and it works and looks good. I
tried several gnuplot terminals (x11, qt, wxt, pdfcairo, png, svg), and
it looks like it works there too. I haven't found anything that this
breaks. The script I used to test:

  plot 'demo/blutux.rgb' binary array=(128,128) flipy format='%uchar' with rgbimage, 5 with points palette

I don't understand the gnuplot codebase deeply, so I might have missed
things. Some questions:

- I patched draw_inside_colorbox_bitmap_smooth() only. There are other
  flavors of this function (look where it is called), and I don't know
  if the others should be updated in this way as well

- I have an extra "gray = 1 - gray;" that I don't understand. It makes
  things correct, though

- The patch uses rgb unconditionally. I that going to break something in
  some terminal?

- I copied most of the logic from the old function without an
  understanding of what it does. Am I handling these properly?

    - sm_palette.use_maxcolors
    - sm_palette.gradient_num
    - sm_palette.positive

- If I "set colorbox horizontal" then the colorbox stays in the same
  spot with the same shape, but I change the color sequence to move
  horizontally. This happens even before my patch. I'm here:

    ae7dfa3f3..: Ethan A Merritt 2023-06-09 qt:  qt4 was apparently weak at int->double promotion

  Shouldn't the colorbox move below or above the plot, and reorient
  itself? Or is it the user's job to set the geometry?

This makes my PDFs look nice. It'd be good if some version of this patch
was merged.

Thanks

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

On Saturday, 10 June 2023 17:24:37 PDT Dima Kogan wrote:
> 
> Actually, okular doesn't fully work either.
> 
> I'm currently writing a presentation where I'm using pdflatex and I'm
> including gnuplot figures. In that context okular shows the bands also.
> Maybe pdflatex is also buggy, but if mupdf AND evince AND pdflatex have
> this bug, maybe we should try to work around it. gv is still ok.
> 
> You can see this for yourself probably. I downloaded this figure that
> was generated by gnuplot:
> 
>   https://urldefense.com/v3/__http://mrcal.secretsauce.net/external/figures/diff/diff-radius0-heatmap-splined-opencv8.pdf__;!!K-Hz7m0Vt54!lfFwuvLqC5ID1P35DtMpTPxIqwIhHjrPNe0d_k_Uqz17nVeq07BR5n-UHuapjVlxgaL_-jJNDFaxrT6V_3nGHg$ 
> 
> And ran "pdflatex tst.tex" where tst.tex is:
> 
>   \documentclass[presentation]{beamer}
>   \begin{document}
>   \includegraphics[keepaspectratio,width=0.9\textwidth,height=0.7\textheight]{/tmp/diff-radius0-heatmap-splined-opencv8.pdf}
>   \end{document}
> 
> The result is attached. I see the bands even with okular.

I do not see any such problem in the output from either pdflatex or lualatex as run here.

    [~/temp] pdflatex --version 
    pdfTeX 3.141592653-2.6-1.40.24 (TeX Live 2022/Mageia)
    [~/temp] lualatex --version 
    This is LuaHBTeX, Version 1.15.0 (TeX Live 2022/Mageia) 
    Development id: 7509
So again, I do not think the problem is in gnuplot but rather in the
pdf processing stage that comes after that.

... Which is not to say it is impossible to change gnuplot in such
a way that it does not trigger bugs in other programs.
But I'm not all that hopeful;  variations of this sort of aliasing glitch
persisted for years (decades?) in ghostview / gv despite it being a known
and well-characterized bug.

Output from pdflatex attached.

    Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> I do not see any such problem in the output from either pdflatex or lualatex as run here.
>
>     [~/temp] pdflatex --version 
>     pdfTeX 3.141592653-2.6-1.40.24 (TeX Live 2022/Mageia)
>     [~/temp] lualatex --version 
>     This is LuaHBTeX, Version 1.15.0 (TeX Live 2022/Mageia) 
>     Development id: 7509
>
> Output from pdflatex attached.

My bad. I gave you a pdf link in the last email that showed the issue.
But since then I've been working on my presentation, and in that process
re-generated my figures with the patched gnuplot, so the link in the
last email now points to a fixed image. This is what you used in your
attachment just now, and that's why it looks nice. You can confirm like
this:

  dima@shorty:~/projects/gnuplot$ pdfimages -list /tmp/dima.pdf

  page   num  type   width height color comp bpc  enc interp  object ID x-ppi y-ppi size ratio
  --------------------------------------------------------------------------------------------
     1     0 image      60    40  rgb     3   8  image  no        42  0    25    29 3602B  50%
     1     1 image       1   128  rgb     3   8  image  no        43  0     8    96  395B 103%

The 1x128 bitmap embedded in the .pdf is the colorbar, and its presence
indicates a patched gnuplot.

I'm attaching the pre-fix pdf file. I suspect you will see issues with
it if you pdflatex and the okular the output.


> So again, I do not think the problem is in gnuplot but rather in the
> pdf processing stage that comes after that.

Maybe. But if the issues in the surrounding tools are so pervasive that
things are broken more often than not, I'd be interested in tweaking
gnuplot to work well in the world that we have.


> But I'm not all that hopeful; variations of this sort of aliasing
> glitch persisted for years (decades?) in ghostview / gv despite it
> being a known and well-characterized bug

I haven't been fighting it for as long, so I remain optimistic :)

You raised some great points in your other email. I'll need a few days
to look at those.

Thanks much.

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

New information:

I found a chunk of code in cairo terminal driver from way back when
that was intended to deal with an old version of the cairo library
(2010 or earlier).

good news:
The one line patch below fixes or at least improves the banding
artifact in pdf output for almost all plots I have tried.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff --git a/term/cairo.trm b/term/cairo.trm
index 9df11cc79..8ab9698cb 100644
--- a/term/cairo.trm
+++ b/term/cairo.trm
@@ -775,7 +775,7 @@ void cairotrm_init()
 		/* disable OPERATOR_SATURATE, not implemented in cairo pdf backend.
 		 * Unfortunately the can result in noticeable seams between adjacent
 		 * polygons. */
-		plot.polygons_saturate = FALSE;
+		plot.polygons_saturate = TRUE;
 		/* Empirical correction to make pdf output look more like wxt and png */
 		plot.dashlength /= 2;
 	} else if (!strcmp(term->name,"pngcairo") || !strcmp(term->name, "kittycairo")) {
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

bad news:
It degrades text rendering in the pdf output.  I don't know why.
For at least one plot (walls.dem) it introduces a much worse artifact.
I don't know why on that one either.

There are other places in the cairo.trm code that were also
added apparently to accommodate this old cairo libary.
I will try to trace back what changed in cairo and why the
gnuplot terminal driver was trying to work around it.
The bad text rendering side effect is a show-stopper at the moment.
If I can disentangle that from the change to polygon rendering
I would be inclined to make the change in the gnuplot development
source and work on the resulting artifact in walls.dem separately.

I am dubious about the large block of code in gp_cairo.c that begins 
  /* this is meant to test Full-Scene-Anti-Aliasing by supersampling,
   * in association with CAIRO_ANTIALIAS_NONE a few lines below
   */
Before the change to plot.polygons_saturate it was never executed for
pdf output. Now it is.  Perhaps it can be replaced by something simpler?
The "supersampling" idea was never implemented, so maybe this code
never did work correctly.  On the other hand it is also used by
the wxt terminal and I haven't noticed problems there, so ....?

Anyhow, if you have any ideas or can find a way to remove the
text-rendering side effect that would be great.

   cheers,
      Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

On Sunday, 11 June 2023 16:22:01 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > I may not understand what you are suggesting.
> 
> Hi. I guess I wasn't clear. The suggestion was that instead of creating
> 128 discrete bars with different colors we create a 128x1 bitmap and
> draw it as an image. The thought was that this would work because images
> look correct in pdfcairo, without the ugly border lines.

This is already possible in current gnuplot, although to be fair it is not
hooked up automatically to colorbox generation and maybe not well
enough documented.   See "named_palettes.dem" for an example.
In a nutshell:
1) Define your palette ("set palette ...")
2) Save it as a colormap ("set colormap new NAME")
3) Use the colormap as a pixmap
   ("set pixmap 1 colormap NAME at screen 0.92, 0.3  size screen 0.03, 0.4")

Because it is not hooked up automatically to colorbox generation,
you would have to position the pixmap on top of the colorbox.
I admit that would be a nuisance.  Maybe you would like to look into
adding it as a colorbox option?

However this approach has at least two limitations,
whether done via colormap+pixmap or via your proposed new code.
1) Not all terminals support it
2) It does not handle nonlinear color mappings,
   e.g. "set log cb"

There is a third issue also that would apply to using it for
svg or canvas output.  See the 7th plot in heatmaps.dem.
The display programs for these modes apply an averaging/blurring
function across image pixels, which means that discrete palette
colors would be muddied or mangled entirely if represented by
image pixels rather than by separate solid color rectangles.

For these reasons I do not think this approach is suitable as
a replacement for the current colorbox code.

On the other hand if you can figure out some change to the
cairo + pdf pathway that avoids triggering bugs in poppler or
other external pdf-handling programs, that would be a good thing.
Of course fixing or at least filing bug reports for those
external programs would also be a good thing.

    Ethan

> 
> I implemented this in the attached patch, and it works and looks good. I
> tried several gnuplot terminals (x11, qt, wxt, pdfcairo, png, svg), and
> it looks like it works there too. I haven't found anything that this
> breaks. The script I used to test:
> 
>   plot 'demo/blutux.rgb' binary array=(128,128) flipy format='%uchar' with rgbimage, 5 with points palette
> 
> I don't understand the gnuplot codebase deeply, so I might have missed
> things. Some questions:
> 
> - I patched draw_inside_colorbox_bitmap_smooth() only. There are other
>   flavors of this function (look where it is called), and I don't know
>   if the others should be updated in this way as well
> 
> - I have an extra "gray = 1 - gray;" that I don't understand. It makes
>   things correct, though
> 
> - The patch uses rgb unconditionally. I that going to break something in
>   some terminal?
> 
> - I copied most of the logic from the old function without an
>   understanding of what it does. Am I handling these properly?
> 
>     - sm_palette.use_maxcolors
>     - sm_palette.gradient_num
>     - sm_palette.positive
> 
> - If I "set colorbox horizontal" then the colorbox stays in the same
>   spot with the same shape, but I change the color sequence to move
>   horizontally. This happens even before my patch. I'm here:
> 
>     ae7dfa3f3..: Ethan A Merritt 2023-06-09 qt:  qt4 was apparently weak at int->double promotion
> 
>   Shouldn't the colorbox move below or above the plot, and reorient
>   itself? Or is it the user's job to set the geometry?
> 
> This makes my PDFs look nice. It'd be good if some version of this patch
> was merged.
> 
> Thanks
> 

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Hi Ethan. Thanks for looking at this.

If possible I'd like to get the colorbox-as-bitmap logic integrated. I'm
all for filing bugs in popper and mupdf and all those, but I don't have
an understanding of what's going on there at all, or if these are even
bugs. So hopefully we can get another implementation of gnuplot colorbox
rendering we're happy with.

The patches I'm proposing are here:

  https://github.com/dkogan/gnuplot/tree/colorbox_smooth

This is the "colorbox_smooth" branch of that repo. There are several
no-op cleanup patches that consolidate duplicated logic. And one patch
to use the colorbox-as-bitmap path if term->image is available. If it's
not available we fall back to the existing implementation.

I think this works. I tested it with horizontal/vertical colorboxes and
logscales. Before/after patch behavior is the same, except for the
anti-aliasing artifacts we're trying to get rid of.

More notes inline.


Ethan A Merritt <me...@uw...> writes:

> On Sunday, 11 June 2023 16:22:01 PDT Dima Kogan wrote:

> This is already possible in current gnuplot, although to be fair it is not
> hooked up automatically to colorbox generation and maybe not well
> enough documented.   See "named_palettes.dem" for an example.
> In a nutshell:
> 1) Define your palette ("set palette ...")
> 2) Save it as a colormap ("set colormap new NAME")
> 3) Use the colormap as a pixmap
>    ("set pixmap 1 colormap NAME at screen 0.92, 0.3  size screen 0.03, 0.4")

OK. Yes. I have confirmed that this uses a bitmap for the colorbox. I'm
not sure what bearing this has. Are you saying the code that does this
should be consolidated with the new code that does the bitmap colorbox?


> However this approach has at least two limitations,
> whether done via colormap+pixmap or via your proposed new code.
> 1) Not all terminals support it

The patches above fall back on the discrete slices if term->image==NULL


> 2) It does not handle nonlinear color mappings,
>    e.g. "set log cb"

I just tested it. It looks the same before/after. The logscale affects
the tic marks on the colorbox, not the color box image.


> There is a third issue also that would apply to using it for svg or
> canvas output. See the 7th plot in heatmaps.dem. The display programs
> for these modes apply an averaging/blurring function across image
> pixels, which means that discrete palette colors would be muddied or
> mangled entirely if represented by image pixels rather than by
> separate solid color rectangles.

I don't see this. I'm looking at

  https://gnuplot.sourceforge.net/demo/heatmaps.html

The 7th plot is the last one. I don't think that's what you mean. If I
run the "headtmaps.dem" script with the current gnuplot in git (the
website should match!) I see a different sequence. The 7th one is the
one with the two images without any colorboxes at all. But they all look
right in any case.

Can you try the patches?

Thanks

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

On Wednesday, 14 June 2023 10:43:26 PDT Dima Kogan wrote:
> Hi Ethan. Thanks for looking at this.
> 
> If possible I'd like to get the colorbox-as-bitmap logic integrated. I'm
> all for filing bugs in popper and mupdf and all those, but I don't have
> an understanding of what's going on there at all, or if these are even
> bugs. So hopefully we can get another implementation of gnuplot colorbox
> rendering we're happy with.
> 
> The patches I'm proposing are here:
> 
>   https://github.com/dkogan/gnuplot/tree/colorbox_smooth

I do not know how to generate the relevant patches via github.
It says:  "master and colorbox_smooth are entirely different commit histories"
Could you please send me the relevant patch series as generated by
"git format-patch"?
  
> > This is already possible in current gnuplot, although to be fair it is not
> > hooked up automatically to colorbox generation and maybe not well
> > enough documented.   See "named_palettes.dem" for an example.
> > In a nutshell:
> > 1) Define your palette ("set palette ...")
> > 2) Save it as a colormap ("set colormap new NAME")
> > 3) Use the colormap as a pixmap
> >    ("set pixmap 1 colormap NAME at screen 0.92, 0.3  size screen 0.03, 0.4")
> 
> OK. Yes. I have confirmed that this uses a bitmap for the colorbox. I'm
> not sure what bearing this has. Are you saying the code that does this
> should be consolidated with the new code that does the bitmap colorbox?

Mostly I meant that the good/bad effects of this approach can be tested
using the code already there.  

> > However this approach has at least two limitations,
> > whether done via colormap+pixmap or via your proposed new code.
> > 1) Not all terminals support it
> 
> The patches above fall back on the discrete slices if term->image==NULL

OK.  The other alternative is to make this specific to cairopdf.
Unless you know of other terminals that suffer from the same problem?

> > 2) It does not handle nonlinear color mappings,
> >    e.g. "set log cb"
> 
> I just tested it. It looks the same before/after. The logscale affects
> the tic marks on the colorbox, not the color box image.

You are right.  I was thinking of something else, but never mind.

> > There is a third issue also that would apply to using it for svg or
> > canvas output. See the 7th plot in heatmaps.dem. The display programs
> > for these modes apply an averaging/blurring function across image
> > pixels, which means that discrete palette colors would be muddied or
> > mangled entirely if represented by image pixels rather than by
> > separate solid color rectangles.
> 
> I don't see this. I'm looking at
> 
>   https://gnuplot.sourceforge.net/demo/heatmaps.html

That is the png version; it doesn't show the effect I'm talking about.
Have a look at the svg version
    https://gnuplot.sourceforge.net/demo_svg/heatmaps.html

In particular the plot with title
    Compare "image" and "image pixels"

> Can you try the patches?

If you send them as patches, yeah.
Or upload them to the patch tracker
    https://sourceforge.net/p/gnuplot/patches/

	Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

>> The patches I'm proposing are here:
>> 
>>   https://github.com/dkogan/gnuplot/tree/colorbox_smooth
>
> I do not know how to generate the relevant patches via github. It
> says: "master and colorbox_smooth are entirely different commit
> histories" Could you please send me the relevant patch series as
> generated by "git format-patch"?

I'm only two patches out-of-date:

  dima@shorty:~/projects/gnuplot$ git show-branch HEAD origin/master
  ! [HEAD] smooth colorbox: render as a bitmap if the terminal supports it
   ! [origin/master] Do not report terminal type to user until after initialization is complete
  --
  +  [HEAD] smooth colorbox: render as a bitmap if the terminal supports it
  +  [HEAD^] no-op cleanup: consolidated next-colorbox-slice logic
  +  [HEAD~2] no-op cleanup: consolidated draw-colorbox-slice logic
  +  [HEAD~3] no-op cleanup: consolidated colorbox bounds logic
  +  [HEAD~4] no-op cleanup: consolidated steps-in-colorbox logic
   + [origin/master] Do not report terminal type to user until after initialization is complete
   + [origin/master^] VMS cleanup
  ++ [HEAD~5] qt:  qt4 was apparently weak at int->double promotion

I'm attaching the patches to this email.


> OK. The other alternative is to make this specific to cairopdf. Unless
> you know of other terminals that suffer from the same problem?

Actually.... You're right. It's only semi-related to THIS discussion,
but let me bring that up.

The svg terminal currently produces images with no image-rendering
annotations. And most browsers render images with bilinear interpolation
by default, which makes low-res images look very wrong. I looked at this
a while back, and, there was no browser-independent way to turn that
off. And I think there still isn't. I'm attaching an svg of this gnuplot
script made WITH the new patches AND by manually adding
image-rendering="crisp-edges" to it:

  set output "/tmp/tst-colorbox-log.svg"
  set terminal svg
  set palette maxcolors 5
  set logscale cb
  set cbrange [1:10]
  plot 5 with points palette

If you open that in firefox, it should look good, but if you open it in
chrome, it won't. To make it work in chrome, "crisp-edges" needs to
become "pixelated". I don't know how to make it work with both. So if we
can fix this, I'd say we should do the colorbox-image thing whenever
available. But if we can't, maybe limiting it to only cairopdf (or NOT
svg) is the answer.

Let me ask a web-dev friend about how to make svg work right in all
browsers. There's probably a way.

The current set of attached patches does NOT limit itself to cairopdf


>> I don't see this. I'm looking at
>> 
>>   https://gnuplot.sourceforge.net/demo/heatmaps.html
>
> That is the png version; it doesn't show the effect I'm talking about.
> Have a look at the svg version
>     https://gnuplot.sourceforge.net/demo_svg/heatmaps.html
>
> In particular the plot with title
>     Compare "image" and "image pixels"

Ah yes. This is exactly what I mentioned above. I don't remember any
terminal other than svg having this problem. But I certainly haven't
touched all of them.

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

On Thursday, 15 June 2023 15:39:22 PDT Dima Kogan wrote:
> 
>   dima@shorty:~/projects/gnuplot$ git show-branch HEAD origin/master
>   ! [HEAD] smooth colorbox: render as a bitmap if the terminal supports it
>    ! [origin/master] Do not report terminal type to user until after initialization is complete
>   --
>   +  [HEAD] smooth colorbox: render as a bitmap if the terminal supports it
>   +  [HEAD^] no-op cleanup: consolidated next-colorbox-slice logic
>   +  [HEAD~2] no-op cleanup: consolidated draw-colorbox-slice logic
>   +  [HEAD~3] no-op cleanup: consolidated colorbox bounds logic
>   +  [HEAD~4] no-op cleanup: consolidated steps-in-colorbox logic
>    + [origin/master] Do not report terminal type to user until after initialization is complete
>    + [origin/master^] VMS cleanup
>   ++ [HEAD~5] qt:  qt4 was apparently weak at int->double promotion
> 
> I'm attaching the patches to this email.

I like it so far.
I will try to think of more tests to run.

> > OK. The other alternative is to make this specific to cairopdf. Unless
> > you know of other terminals that suffer from the same problem?

[snip descroption of svg problems with small number of image pixels]
> So if we
> can fix this, I'd say we should do the colorbox-image thing whenever
> available. But if we can't, maybe limiting it to only cairopdf (or NOT
> svg) is the answer.
> 
> Let me ask a web-dev friend about how to make svg work right in all
> browsers. There's probably a way.
> 
> The current set of attached patches does NOT limit itself to cairopdf

I think it benefits all the cairo terminals, or at least doesn't hurt.
Beyond that, well - that's what I am trying to test.
I will add a FIXME comment.
 
> Ah yes. This is exactly what I mentioned above. I don't remember any
> terminal other than svg having this problem. But I certainly haven't
> touched all of them.

The HTML5 canvas terminal has the same problem: browsers apply
inter-pixel interpolation, details of which are poorly documented.

   cheers
   Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

OK, it's pushed to the development branch for 6.1.

I revised the top-level criterion for choosing the new method that
uses term->image rather than the old method that uses term->fille_polygon.
Commit message:

    Rather than selecting the colorbox-as-image code for all terminals
    that support term->image, make it dependent on a terminal flag.
    Instead of
        if (term->image) ...
    use
        if ((term->flags & TERM_COLORBOX_IMAGE))
    
    The svg, domterm, and canvas terminals definitely do not want this flag.
    The pdfcairo terminal definitely does want it.
    
    For now the flag is set by these terminals
            epscairo cairolatex pdfcairo qt
    
    Other terminals can be added later by setting TERM_COLOR_BOX_IMAGE in the
    corresponding driver source.  Possible candidates
            tikz wxt

The PostScript-based terminals are not affected since colorbox generation
code is done in the PostScript header code rather than in the core C code.

Thanks for working on this.

    Ethan

On Thursday, 15 June 2023 22:13:47 PDT Ethan A Merritt wrote:
> On Thursday, 15 June 2023 15:39:22 PDT Dima Kogan wrote:
> > 
> >   dima@shorty:~/projects/gnuplot$ git show-branch HEAD origin/master
> >   ! [HEAD] smooth colorbox: render as a bitmap if the terminal supports it
> >    ! [origin/master] Do not report terminal type to user until after initialization is complete
> >   --
> >   +  [HEAD] smooth colorbox: render as a bitmap if the terminal supports it
> >   +  [HEAD^] no-op cleanup: consolidated next-colorbox-slice logic
> >   +  [HEAD~2] no-op cleanup: consolidated draw-colorbox-slice logic
> >   +  [HEAD~3] no-op cleanup: consolidated colorbox bounds logic
> >   +  [HEAD~4] no-op cleanup: consolidated steps-in-colorbox logic
> >    + [origin/master] Do not report terminal type to user until after initialization is complete
> >    + [origin/master^] VMS cleanup
> >   ++ [HEAD~5] qt:  qt4 was apparently weak at int->double promotion
> > 
> > I'm attaching the patches to this email.
> 
> I like it so far.
> I will try to think of more tests to run.
> 
> > > OK. The other alternative is to make this specific to cairopdf. Unless
> > > you know of other terminals that suffer from the same problem?
> 
> [snip descroption of svg problems with small number of image pixels]
> > So if we
> > can fix this, I'd say we should do the colorbox-image thing whenever
> > available. But if we can't, maybe limiting it to only cairopdf (or NOT
> > svg) is the answer.
> > 
> > Let me ask a web-dev friend about how to make svg work right in all
> > browsers. There's probably a way.
> > 
> > The current set of attached patches does NOT limit itself to cairopdf
> 
> I think it benefits all the cairo terminals, or at least doesn't hurt.
> Beyond that, well - that's what I am trying to test.
> I will add a FIXME comment.
>  
> > Ah yes. This is exactly what I mentioned above. I don't remember any
> > terminal other than svg having this problem. But I certainly haven't
> > touched all of them.
> 
> The HTML5 canvas terminal has the same problem: browsers apply
> inter-pixel interpolation, details of which are poorly documented.
> 
>    cheers
>    Ethan
> 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Thanks for merging those. My friend figured out how to get svg to work
in both firefox and chrome, and I'm attaching a patch that does that.
The description is in the patch.