gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Status update - version 5.2.2, cvs->git conversion, plans

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

Eric S. Raymond <es...@th...> writes:

> sfeam <sf...@us...>:
>
>> I'm still learning how to rethink my work flow for git, so please
>> help me out.   For instance, does it make any sense to continue
>> to maintain the ChangeLog file?   So far I'm having little success in
>> keeping it in sync with the git commit messages.  Is there some
>> tool to help with that, or is the normal practice with git to rely
>> only on the commit messages? I know you can dump a log of commits,
>> so I guess one possibility is to use that to update the ChangeLog every
>> now and then (1 month intervals? 6 months?) but not try to touch it
>> for every commit.  Advice?
>
> I recommend no longer keeping a ChangeLog.  In fact. I recommend deleting it
> from the tip version.  It will, of course, still be available to anyone
> who cares to check out the last pre-conversion revision.
>
> In the presence of changeset comments with author attributions. Changelog
> comments are duplicative and the requirement to do them becomes increasingly
> annoying.  Better to write changeset comments and browse those with
> gitk or equivalent.

Agreed. My feeling is that you want some sort of NEWS file that
describes a very high-level list of changes so that somebody can clearly
see the big differences between releases. But for finer-grained stuff,
the version control should be the master record.

Re: Status update - version 5.2.2, cvs->git conversion, plans

[Eric S. R. <es...@th...>]

sfeam <sf...@us...>:
> But really I think it all looks promising. 
> Not perfect but "good enough".

I'm available to help with any dinal changes that need to be made.

I believe you big decision is whether drop the somewjat incorrect 3.7
branch - tip content doesn't match the tarballs.  I recommend dropping
it.

> Questions
> =========
> 
> I'm still learning how to rethink my work flow for git, so please
> help me out.   For instance, does it make any sense to continue
> to maintain the ChangeLog file?   So far I'm having little success in
> keeping it in sync with the git commit messages.  Is there some
> tool to help with that, or is the normal practice with git to rely
> only on the commit messages? I know you can dump a log of commits,
> so I guess one possibility is to use that to update the ChangeLog every
> now and then (1 month intervals? 6 months?) but not try to touch it
> for every commit.  Advice?

I recommend no longer keeping a ChangeLog.  In fact. I recommend deleting it
from the tip version.  It will, of course, still be available to anyone
who cares to check out the last pre-conversion revision.

In the presence of changeset comments with author attributions. Changelog
comments are duplicative and the requirement to do them becomes increasingly
annoying.  Better to write changeset comments and browse those with
gitk or equivalent.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Status update - version 5.2.2, cvs->git conversion, plans

[sfeam <sf...@us...>]

Version 5.2.2
=============

A tarball for release 5.2.2 is now in the usual place on sf.net:
     https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.2/
This will be the last gnuplot release prepared from the CVS repository.

Anything you commit to cvs between now and whenever sourceforge pulls
the plug on it will not make it into future gnuplot releases.

cvs->git conversion
===================

A snapshot of the cvs repository from 04-November-2017 was converted
to git with the help of Eric S Raymond [Thanks!]
Since then we have been evaluating the state of the converted source tree.
At the moment there are two copies on sf.net, one slightly cleaner than
the other.  A handful of commits have gone in to these, but it remains
true that the existing git content on sf.net may be wiped clean and
re-created from the 04-Nov-2017 snapshot if we find that there were
annoying but correctable errors from the previous conversion[s].
So far the "correctable" part has been a sticking point.

plans
=====

I will be travelling for most of the next month, so I would prefer that
we make a yes/no decision by next Monday (20 November) as to whether the
current converted code base is good enough to work with.  If it is not,
then the repository is likely to remain volatile until at least the end
of the year.  You'll be able to read from it, but if you make copies
you may have to rebase or re-clone if we do the entire conversion over
again.

But really I think it all looks promising. 
Not perfect but "good enough".

Questions
=========

I'm still learning how to rethink my work flow for git, so please
help me out.   For instance, does it make any sense to continue
to maintain the ChangeLog file?   So far I'm having little success in
keeping it in sync with the git commit messages.  Is there some
tool to help with that, or is the normal practice with git to rely
only on the commit messages?  I know you can dump a log of commits,
so I guess one possibility is to use that to update the ChangeLog every
now and then (1 month intervals? 6 months?) but not try to touch it
for every commit.  Advice?

	Ethan

Re: gnuplot 5.2.2

[sfeam <sf...@us...>]

On Wednesday, 15 November 2017 14:50:56 Mojca Miklavec wrote:
> Hi,
> 
> I'm maintaining a package for gnuplot for a package manager that keeps
> reminding me of an apparent new version of gnuplot 5.2.2 which can
> only be found under the testing directory.
> 
> The source of information:
>     https://sourceforge.net/projects/gnuplot/rss
> 
> Is there any chance to remove the misleading source of information
> that keeps confusing both me and our package manager?

In what way is that information confusing?
There is a testing version of 5.2.2 and it is in the "testing" area.
There is one known issue reported against it that I may or may not
fix before placing a copy in the official release area.

If you are asking how the rss feed is generated - I have no idea.
I didn't even know it existed.

	Ethan

gnuplot 5.2.2

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

Hi,

I'm maintaining a package for gnuplot for a package manager that keeps
reminding me of an apparent new version of gnuplot 5.2.2 which can
only be found under the testing directory.

The source of information:
    https://sourceforge.net/projects/gnuplot/rss

Is there any chance to remove the misleading source of information
that keeps confusing both me and our package manager?

Thank you,
    Mojca

Re: non-color-scaled rgbimage plots

[Ethan A M. <sf...@us...>]

On Tuesday, November 14, 2017 2:12:05 PM PST Daniel J Sebald wrote:
> On 11/14/2017 03:19 PM, Ethan A Merritt wrote:
> > On Tuesday, November 14, 2017 12:03:09 PM PST Daniel J Sebald wrote:
> >> On 11/14/2017 12:27 PM, Ethan A Merritt wrote:
> >>> There are no "rgb axes".
> >>> And no, it does not make sense to autoscale RGB components of an image.
> >>> Suppose you are displaying a photograph that for whatever reason does
> >>> not contain any regions with Green==0.   Rescaling the Green component
> >>> would distort all the colors everywhere, leaching the green out of things
> >>> that really are green.  The _representation_ requires the range to run
> >>> [0:255] even if this particular image doesn't happen to contain pixels
> >>> with small Green component values.
> >>
> >> rgb components aren't necessarily treated independently.  This code
> >>
> >> -  image[i_sub_image++] = cb2gray( points[i_image].CRD_R );
> >> -  image[i_sub_image++] = cb2gray( points[i_image].CRD_G );
> >> -  image[i_sub_image++] = cb2gray( points[i_image].CRD_B );
> >>
> >> was combining all component values into one.
> > 
> > You lost me.
> > That code, which no longer exists, was copying the R G and B components
> > sequentially.  They were all being scaled by the same range from the
> > palette definition, which was weird since they are not palette colors.
> > There was no "combine into one".
> 
> Right, I'm pointing that out.  All were scaled with the same formula. 
> You initially gave a counter example saying that if the Green channel is 
> an all zero channel it is going to leach across color channels in some 
> way.  There's nothing weird about the use of cb2range.  The palette 
> didn't apply, not until someone wanted to combine palettes and images. 
> The cb2gray() is just a linear transformation using the parameters 
> cbaxis->min and cbaxis->max.  Call the function something more 
> generalized, linearmap(), whatever.  And if the code were more 
> object-oriented, the linearmap() routine could be applied to xyz-axis, 
> colorbar, alpha channel, rgb, i.e., code reuse.
> 
> In terms of syntatx, it's more confusing to not continue the paradigm 
> from one axis type to another.

We'll have to agree to disagree on that point.
I find it strange to consider RGB color assignments an "axis" at all.

Anyhow, I believe that the most common transformations applied to
color components are nonlinear and cannot be applied to a single
component in isolation, e.g. gamma-correction, color balance,
visual temperature.

min/max linear scaling is not a good model for color manipulation.

    Ethan

Re: non-color-scaled rgbimage plots

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

On 11/14/2017 03:19 PM, Ethan A Merritt wrote:
> On Tuesday, November 14, 2017 12:03:09 PM PST Daniel J Sebald wrote:
>> On 11/14/2017 12:27 PM, Ethan A Merritt wrote:
>>> There are no "rgb axes".
>>> And no, it does not make sense to autoscale RGB components of an image.
>>> Suppose you are displaying a photograph that for whatever reason does
>>> not contain any regions with Green==0.   Rescaling the Green component
>>> would distort all the colors everywhere, leaching the green out of things
>>> that really are green.  The _representation_ requires the range to run
>>> [0:255] even if this particular image doesn't happen to contain pixels
>>> with small Green component values.
>>
>> rgb components aren't necessarily treated independently.  This code
>>
>> -  image[i_sub_image++] = cb2gray( points[i_image].CRD_R );
>> -  image[i_sub_image++] = cb2gray( points[i_image].CRD_G );
>> -  image[i_sub_image++] = cb2gray( points[i_image].CRD_B );
>>
>> was combining all component values into one.
> 
> You lost me.
> That code, which no longer exists, was copying the R G and B components
> sequentially.  They were all being scaled by the same range from the
> palette definition, which was weird since they are not palette colors.
> There was no "combine into one".

Right, I'm pointing that out.  All were scaled with the same formula. 
You initially gave a counter example saying that if the Green channel is 
an all zero channel it is going to leach across color channels in some 
way.  There's nothing weird about the use of cb2range.  The palette 
didn't apply, not until someone wanted to combine palettes and images. 
The cb2gray() is just a linear transformation using the parameters 
cbaxis->min and cbaxis->max.  Call the function something more 
generalized, linearmap(), whatever.  And if the code were more 
object-oriented, the linearmap() routine could be applied to xyz-axis, 
colorbar, alpha channel, rgb, i.e., code reuse.

In terms of syntatx, it's more confusing to not continue the paradigm 
from one axis type to another.

Dan

Re: non-color-scaled rgbimage plots

[Ethan A M. <sf...@us...>]

On Tuesday, November 14, 2017 12:03:09 PM PST Daniel J Sebald wrote:
> On 11/14/2017 12:27 PM, Ethan A Merritt wrote:
> > There are no "rgb axes".
> > And no, it does not make sense to autoscale RGB components of an image.
> > Suppose you are displaying a photograph that for whatever reason does
> > not contain any regions with Green==0.   Rescaling the Green component
> > would distort all the colors everywhere, leaching the green out of things
> > that really are green.  The _representation_ requires the range to run
> > [0:255] even if this particular image doesn't happen to contain pixels
> > with small Green component values.
> 
> rgb components aren't necessarily treated independently.  This code
> 
> -  image[i_sub_image++] = cb2gray( points[i_image].CRD_R );
> -  image[i_sub_image++] = cb2gray( points[i_image].CRD_G );
> -  image[i_sub_image++] = cb2gray( points[i_image].CRD_B );
> 
> was combining all component values into one.  

You lost me.
That code, which no longer exists, was copying the R G and B components
sequentially.  They were all being scaled by the same range from the
palette definition, which was weird since they are not palette colors.
There was no "combine into one".

The whole point of the change was to disentangle RGB colors from the
grayscale palette.

You are still free to scale RGB as you like in the current code, but 
you'll have to do it via explicit transforms in the using spec.

	Ethan


> Hence, if Red and Green 
> channel was all zero, and Blue happened to have a range of 17 to 234, 
> all components would be scaled to that range.  I don't think we'd want 
> to treat components individually, at least by default, because that 
> really distorts the color.  Only if all components are 0 would there be 
> a scaling (likely to either all black image or all white image).
> 
> 
> >> The most consistent syntax that retains features would have been an
> >> rgbrange independent from cbrange, just as there is an xrange, yrange,
> >> zrange, cbrange and to retain autoscaling for rgb (separate from cb
> >> autoscaling).
> > 
> > I did consider that.  But I decided it was better not to confuse people
> > because so many of the normal "set range" options would be
> > invalid in this one case.
> 
> Here's what Matlab does
> 
> https://www.mathworks.com/help/matlab/ref/image.html
> 
> They appear to use the data type int8, int16, double, etc. to determine 
> the range for RGB images:
> 
> double --> [0 0 0] black, [1 1 1] white
> uint8  --> [0 0 0] black, [255 255 255] white
> int8   --> [-128 -128 -128] black, [127 127 127] white
> etc.
> 
> Interestingly, they treat the alpha channel ('scaled' option) similar to 
> gnuplot's cbrange:
> 
> "
> 'AlphaDataMapping' — Interpretation of AlphaData values
> 'none' (default) | 'scaled' | 'direct'
> 'scaled' — Map the values into the figure’s alphamap. The minimum and 
> maximum alpha limits of the axes determine the alpha data values that 
> map to the first and last elements in the alphamap, respectively. For 
> example, if the alpha limits are [3 5], then alpha data values less than 
> or equal to 3 map to the first element in the alphamap. Alpha data 
> values greater than or equal to 5 map to the last element in the 
> alphamap. The ALim property of the axes contains the alpha limits. The 
> Alphamap property of the figure contains the alphamap.
> "
> 
> More generally, Matlab supplies adjustment for color images via a 
> special function (example of a picture of a football given):
> 
> https://www.mathworks.com/help/images/ref/imadjust.html
> 
> "
> RGB2 = imadjust(RGB,___) performs the adjustment on each plane (red, 
> green, and blue) of the RGB intensity image RGB. You can apply the same 
> mapping to the red, green, and blue components of the image or specify 
> unique mappings for each color component.
> "
> 
> with default being something called stretchlim(I).
> 
> In GIMP there is a wealth of color scalings; just import an image and 
> look under "Colors" drop-down menu.  The majority of them are linear 
> stretching of RGB, Hue/Lightness/Saturation in some form or another, and 
> GIMP takes it one step further with arbitrary curve alteration.
> 
> If one were to search the Internet, there are probably other 
> applications that can map image color components--at least linearly. 
> (Searching will likely turn up more cases where "scale" refers to the 
> spatial dimensions such as in autoscaling the size of an image in HTML 
> browsers.)
> 
> Anyway, the point is that something like
> 
>    set rgbrange [A:B]
> 
> or even
> 
>    set rgbrange [A1,A2,A3:B1,B2,B3]
> 
> in gnuplot doesn't seem an unreasonable syntax.  (Note that gnuplot 
> doesn't keep track of the input variable type.)  But I do agree with 
> Matlab a bit that alpha channel seems like a different animal, so
> 
>    set alpharange [A:B]
> 
> seems logical as well, where with no alpha channel specified the default 
> is that alpha for a particular RGB object is B.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: non-color-scaled rgbimage plots

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

On 11/14/2017 12:27 PM, Ethan A Merritt wrote:
> On Tuesday, November 14, 2017 10:09:51 AM PST Daniel J Sebald wrote:
>> On 11/13/2017 05:45 PM, Petr Mikulik wrote:
>>>> Someone on Octave's bug tracker noticed a change in image color
>>>> scaling behavior:
>>>>
>>>> https://savannah.gnu.org/bugs/?52401
>>>
>>>
>>> Hm, it seems Octave needs to add this gnuplot command:
>>>
>>> if (GPVAL_VERSION >= "5.2") set rgbmax NNN
>>>
>>> where NNN is "size(colormap,1)"
>>
>> But the only options are rgbmax 1.0 and 255,
> 
> That is simply not true.  Here is the source:
> 
> set.c:4546
> %%%%%%%%%%
> static void
> set_rgbmax()
> {
>      c_token++;
>      if (END_OF_COMMAND)
>          rgbmax = 255;
>      else
>          rgbmax = real_expression();
>      if (rgbmax <= 0)
>          rgbmax = 255;
> }
> %%%%%%%%

I just read documentation:

"
gnuplot> help rgbmax
  Syntax:
       set rgbmax {1.0 | 255}
       unset rgbmax
  The red/green/blue color components of an rgbimage plot are by default
  interpreted as integers in the range [0:255].  `set rgbmax 1.0` tells the
  program that data values used to generate the color components of a plot
  with `rgbimage` or `rgbalpha` are floating point values in the range 
[0:1].
  `unset rgbmax` returns to the default integer range [0:255].
"

I see options 1.0 or 255.


>> However, the bigger issue is that the rgbimage/rgbalpha now have a
>> syntax not consistent with the gnuplot concept and they've lost the
>> autoscaling feature.  Recall, image/rgbimage/rgbalpha, these have more
>> to do with the underlying graphics library support (e.g., drawing with
>> PostScript's inherent image support as opposed to polygons as does pm3d).
>>
>> It sounds to me as though someone wanted to create more sophisticated
>> plots that combine images and colorbar data.  In other words, he wanted
>> to decouple the rgb data axes from the colorbar axis.
> 
> Correct.
> 
>> But that doesn't
>> mean there shouldn't be autoscaling of rgb axes, as that is what the
>> gnuplot paradigm is, whether it's spatial or color components.
> 
> There are no "rgb axes".
> And no, it does not make sense to autoscale RGB components of an image.
> Suppose you are displaying a photograph that for whatever reason does
> not contain any regions with Green==0.   Rescaling the Green component
> would distort all the colors everywhere, leaching the green out of things
> that really are green.  The _representation_ requires the range to run
> [0:255] even if this particular image doesn't happen to contain pixels
> with small Green component values.

rgb components aren't necessarily treated independently.  This code

-  image[i_sub_image++] = cb2gray( points[i_image].CRD_R );
-  image[i_sub_image++] = cb2gray( points[i_image].CRD_G );
-  image[i_sub_image++] = cb2gray( points[i_image].CRD_B );

was combining all component values into one.  Hence, if Red and Green 
channel was all zero, and Blue happened to have a range of 17 to 234, 
all components would be scaled to that range.  I don't think we'd want 
to treat components individually, at least by default, because that 
really distorts the color.  Only if all components are 0 would there be 
a scaling (likely to either all black image or all white image).


>> The most consistent syntax that retains features would have been an
>> rgbrange independent from cbrange, just as there is an xrange, yrange,
>> zrange, cbrange and to retain autoscaling for rgb (separate from cb
>> autoscaling).
> 
> I did consider that.  But I decided it was better not to confuse people
> because so many of the normal "set range" options would be
> invalid in this one case.

Here's what Matlab does

https://www.mathworks.com/help/matlab/ref/image.html

They appear to use the data type int8, int16, double, etc. to determine 
the range for RGB images:

double --> [0 0 0] black, [1 1 1] white
uint8  --> [0 0 0] black, [255 255 255] white
int8   --> [-128 -128 -128] black, [127 127 127] white
etc.

Interestingly, they treat the alpha channel ('scaled' option) similar to 
gnuplot's cbrange:

"
'AlphaDataMapping' — Interpretation of AlphaData values
'none' (default) | 'scaled' | 'direct'
'scaled' — Map the values into the figure’s alphamap. The minimum and 
maximum alpha limits of the axes determine the alpha data values that 
map to the first and last elements in the alphamap, respectively. For 
example, if the alpha limits are [3 5], then alpha data values less than 
or equal to 3 map to the first element in the alphamap. Alpha data 
values greater than or equal to 5 map to the last element in the 
alphamap. The ALim property of the axes contains the alpha limits. The 
Alphamap property of the figure contains the alphamap.
"

More generally, Matlab supplies adjustment for color images via a 
special function (example of a picture of a football given):

https://www.mathworks.com/help/images/ref/imadjust.html

"
RGB2 = imadjust(RGB,___) performs the adjustment on each plane (red, 
green, and blue) of the RGB intensity image RGB. You can apply the same 
mapping to the red, green, and blue components of the image or specify 
unique mappings for each color component.
"

with default being something called stretchlim(I).

In GIMP there is a wealth of color scalings; just import an image and 
look under "Colors" drop-down menu.  The majority of them are linear 
stretching of RGB, Hue/Lightness/Saturation in some form or another, and 
GIMP takes it one step further with arbitrary curve alteration.

If one were to search the Internet, there are probably other 
applications that can map image color components--at least linearly. 
(Searching will likely turn up more cases where "scale" refers to the 
spatial dimensions such as in autoscaling the size of an image in HTML 
browsers.)

Anyway, the point is that something like

   set rgbrange [A:B]

or even

   set rgbrange [A1,A2,A3:B1,B2,B3]

in gnuplot doesn't seem an unreasonable syntax.  (Note that gnuplot 
doesn't keep track of the input variable type.)  But I do agree with 
Matlab a bit that alpha channel seems like a different animal, so

   set alpharange [A:B]

seems logical as well, where with no alpha channel specified the default 
is that alpha for a particular RGB object is B.

Dan

Re: non-color-scaled rgbimage plots

[Ethan A M. <sf...@us...>]

On Tuesday, November 14, 2017 10:09:51 AM PST Daniel J Sebald wrote:
> On 11/13/2017 05:45 PM, Petr Mikulik wrote:
> >> Someone on Octave's bug tracker noticed a change in image color 
> >> scaling behavior:
> >>
> >> https://savannah.gnu.org/bugs/?52401
> > 
> > 
> > Hm, it seems Octave needs to add this gnuplot command:
> > 
> > if (GPVAL_VERSION >= "5.2") set rgbmax NNN
> > 
> > where NNN is "size(colormap,1)"
> 
> But the only options are rgbmax 1.0 and 255,

That is simply not true.  Here is the source:

set.c:4546
%%%%%%%%%%
static void
set_rgbmax()
{
    c_token++;
    if (END_OF_COMMAND)
        rgbmax = 255;
    else
        rgbmax = real_expression();
    if (rgbmax <= 0)
        rgbmax = 255;
}
%%%%%%%%

> However, the bigger issue is that the rgbimage/rgbalpha now have a 
> syntax not consistent with the gnuplot concept and they've lost the 
> autoscaling feature.  Recall, image/rgbimage/rgbalpha, these have more 
> to do with the underlying graphics library support (e.g., drawing with 
> PostScript's inherent image support as opposed to polygons as does pm3d).
> 
> It sounds to me as though someone wanted to create more sophisticated 
> plots that combine images and colorbar data.  In other words, he wanted 
> to decouple the rgb data axes from the colorbar axis.  

Correct.

> But that doesn't 
> mean there shouldn't be autoscaling of rgb axes, as that is what the 
> gnuplot paradigm is, whether it's spatial or color components.

There are no "rgb axes".
And no, it does not make sense to autoscale RGB components of an image.
Suppose you are displaying a photograph that for whatever reason does
not contain any regions with Green==0.   Rescaling the Green component
would distort all the colors everywhere, leaching the green out of things
that really are green.  The _representation_ requires the range to run
[0:255] even if this particular image doesn't happen to contain pixels
with small Green component values.

> The most consistent syntax that retains features would have been an 
> rgbrange independent from cbrange, just as there is an xrange, yrange, 
> zrange, cbrange and to retain autoscaling for rgb (separate from cb 
> autoscaling).

I did consider that.  But I decided it was better not to confuse people
because so many of the normal "set range" options would be 
invalid in this one case.

	Ethan

Re: non-color-scaled rgbimage plots

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

On 11/13/2017 05:45 PM, Petr Mikulik wrote:
>> Someone on Octave's bug tracker noticed a change in image color 
>> scaling behavior:
>>
>> https://savannah.gnu.org/bugs/?52401
> 
> 
> Hm, it seems Octave needs to add this gnuplot command:
> 
> if (GPVAL_VERSION >= "5.2") set rgbmax NNN
> 
> where NNN is "size(colormap,1)"

But the only options are rgbmax 1.0 and 255, so it's more like

     if (GPVAL_VERSION >= "5.2") {
         set rgbmax 1.0;
         <scale the data to the range 0 to 1.0>
     else
         set cbrange [1:6.400000000000000e+01];
     end

where the latter is what Octave is currently doing because that's its 
scheme (data starts with 1, rather than 0).

However, the bigger issue is that the rgbimage/rgbalpha now have a 
syntax not consistent with the gnuplot concept and they've lost the 
autoscaling feature.  Recall, image/rgbimage/rgbalpha, these have more 
to do with the underlying graphics library support (e.g., drawing with 
PostScript's inherent image support as opposed to polygons as does pm3d).

It sounds to me as though someone wanted to create more sophisticated 
plots that combine images and colorbar data.  In other words, he wanted 
to decouple the rgb data axes from the colorbar axis.  But that doesn't 
mean there shouldn't be autoscaling of rgb axes, as that is what the 
gnuplot paradigm is, whether it's spatial or color components.

The most consistent syntax that retains features would have been an 
rgbrange independent from cbrange, just as there is an xrange, yrange, 
zrange, cbrange and to retain autoscaling for rgb (separate from cb 
autoscaling).

Dan

Re: non-color-scaled rgbimage plots

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

> Someone on Octave's bug tracker noticed a change in image color scaling 
> behavior:
>
> https://savannah.gnu.org/bugs/?52401


Hm, it seems Octave needs to add this gnuplot command:

if (GPVAL_VERSION >= "5.2") set rgbmax NNN

where NNN is "size(colormap,1)"

---
PM

Re: non-color-scaled rgbimage plots

[Ethan A M. <sf...@us...>]

On Monday, November 13, 2017 12:45:02 PM PST Daniel J Sebald wrote:
> Someone on Octave's bug tracker noticed a change in image color scaling 
> behavior:
> 
> https://savannah.gnu.org/bugs/?52401
> 
> 
> On 08/17/2017 03:54 PM, Dima Kogan wrote:
>  > Ethan A Merritt <sf...@us...> writes:
> [snip]
>  >> If backward compatibility with current behaviour is a concern
>  >> (not sure it is in this case), then the default could be
>  >> to use the cbrange if the user has not set something else.
>  >
>  > OK, that sounds like a plan. In the meantime I'm going to apply the
>  > attached patch to my own builds. This detaches the rgb colors from the
>  > palette entirely, both for autoscaling and for rendering. Works OK in
>  > initial testing.
> 
> This patch/changeset divides by 255.0.  That assumes that the user has 
> an image with 8-bit color depth, does it not?  (The cb-autoscaling takes 
> assumptions about depth out of the equation.)  What happens if someone 
> uses an image format that is different from 8-bit, such as newer JPEG 
> with 12-bit depth?

Answer 1:
gnuplot currently uses libgd to read in png or jpeg image files.
So far as I know libgd cannot handle any depth other than 8-bit, so
if you wanted to do this you'd have to re-write the input stage anyhow.
At that point you can do whatever you want about scaling.

Answer 2:
There is a new command "set rgbmax" that sets the range of the
color components to something other than 255.   That works for
reading in raw numbers or generating them in the using spec.
It does not, however, have any effect of the "binary filetype=foo"
options, since those are hard-coded.

	Ethan


> 
> https://www.popphoto.com/news/2014/01/jpeg-standard-91-will-bring-12-bit-color-lossless-compression
> 
> https://laurashoe.com/2011/08/09/8-versus-16-bit-what-does-it-really-mean/
> 
> 
> On 08/16/2017 01:43 PM, Ethan A Merritt via gnuplot-beta wrote:
> > On Wednesday, 16 August, 2017 10:24:16 Dima Kogan wrote:
> >> Ethan A Merritt <sf...@us...> writes:
> [snip]
> > I agree that it makes no sense to apply the palette range (cbrange)
> > to rgb data.
> > For example this just seems wrong to me:
> > 
> >      # looks nice
> >      plot 'nicepicture.jpeg' binary filetype=auto with rgbimage
> >      # messed up
> >      set cbrange [50:100]
> >      replot
> >      # lost altogether
> >      set log cb
> >      replot
> 
> Was it much different than this behavior?
> 
> gnuplot> splot sin(sqrt(x**2+y**2))/sqrt(x**2+y**2) with pm3d
> gnuplot> splot 500*sin(sqrt(x**2+y**2))/sqrt(x**2+y**2) with pm3d
> gnuplot> set cbrange [50:100]
> gnuplot> replot
> 
> Autoscaling of cbrange is similar to mapping the histogram of the pixel 
> colors into the usable range, but often one wants to change that range. 
> For example, if one scans a newspaper article it often has yellowish 
> tint but expanding the range will map the yellowish background to near 
> white but still retain reasonably facsimile of the foreground image. 
> XSane image scanner software (see attached) has just such a simple 
> scaling to enhance contrast, etc.
> 
> https://en.wikipedia.org/wiki/Contrast_(vision)
> 
> Sure, one can apply a math formula to the image data input to do 
> autoscaling and so on, but the same can be said for pm3d and other modes 
> that use cbrange auto-scaling.
> 
> Dan
> 

Re: non-color-scaled rgbimage plots

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

Someone on Octave's bug tracker noticed a change in image color scaling 
behavior:

https://savannah.gnu.org/bugs/?52401


On 08/17/2017 03:54 PM, Dima Kogan wrote:
 > Ethan A Merritt <sf...@us...> writes:
[snip]
 >> If backward compatibility with current behaviour is a concern
 >> (not sure it is in this case), then the default could be
 >> to use the cbrange if the user has not set something else.
 >
 > OK, that sounds like a plan. In the meantime I'm going to apply the
 > attached patch to my own builds. This detaches the rgb colors from the
 > palette entirely, both for autoscaling and for rendering. Works OK in
 > initial testing.

This patch/changeset divides by 255.0.  That assumes that the user has 
an image with 8-bit color depth, does it not?  (The cb-autoscaling takes 
assumptions about depth out of the equation.)  What happens if someone 
uses an image format that is different from 8-bit, such as newer JPEG 
with 12-bit depth?

https://www.popphoto.com/news/2014/01/jpeg-standard-91-will-bring-12-bit-color-lossless-compression

https://laurashoe.com/2011/08/09/8-versus-16-bit-what-does-it-really-mean/


On 08/16/2017 01:43 PM, Ethan A Merritt via gnuplot-beta wrote:
> On Wednesday, 16 August, 2017 10:24:16 Dima Kogan wrote:
>> Ethan A Merritt <sf...@us...> writes:
[snip]
> I agree that it makes no sense to apply the palette range (cbrange)
> to rgb data.
> For example this just seems wrong to me:
> 
>      # looks nice
>      plot 'nicepicture.jpeg' binary filetype=auto with rgbimage
>      # messed up
>      set cbrange [50:100]
>      replot
>      # lost altogether
>      set log cb
>      replot

Was it much different than this behavior?

gnuplot> splot sin(sqrt(x**2+y**2))/sqrt(x**2+y**2) with pm3d
gnuplot> splot 500*sin(sqrt(x**2+y**2))/sqrt(x**2+y**2) with pm3d
gnuplot> set cbrange [50:100]
gnuplot> replot

Autoscaling of cbrange is similar to mapping the histogram of the pixel 
colors into the usable range, but often one wants to change that range. 
For example, if one scans a newspaper article it often has yellowish 
tint but expanding the range will map the yellowish background to near 
white but still retain reasonably facsimile of the foreground image. 
XSane image scanner software (see attached) has just such a simple 
scaling to enhance contrast, etc.

https://en.wikipedia.org/wiki/Contrast_(vision)

Sure, one can apply a math formula to the image data input to do 
autoscaling and so on, but the same can be said for pm3d and other modes 
that use cbrange auto-scaling.

Dan

Re: AW: 4.6.3 tag in git repository

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

On 11/13/2017 05:16 AM, Bastian Märkisch wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Daniel J Sebald [mailto:dan...@ie...]
> (snip)
>> That is, delete tag [4.6.3] and add a new tag [4.6.3] on the new branch
>> (stub) which has the patch.  This puts version tagged [4.6.3] in line with
> cvs-
>> repository and the tarball.  Add a new tag [4.6.3-Windows] to signify that
> is the
>> release that Bastian has published for 4.6.3 that includes everything in
> the
>> 4.6.3 tagged version plus the mods to four Windows-related files.
>>
>> Dan
> 
> Not sure about the necessity for a Windows tag.  The missing change only
> affects the installer, not gnuplot itself, in that it modifies the numbers
> and filename there to reflect the patchlevel.
> 
>    Bastian

Right.  These small touchups just before release that aren't in the 
repository can be recreated by branching a stub of the labeled release 
and expanding the tarball if one wants to do so.

This archive

https://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.3/gp463-win32.zip/download

appears to match what I suggested be [4.6.3-Windows]; that's why I 
suggested adding the tag, i.e., resolve confusion.

Dan

PS: I forgot the comparison script (attached), if you want to run it there.

AW: 4.6.3 tag in git repository

[Bastian M. <bma...@we...>]

> -----Ursprüngliche Nachricht-----
> Von: Daniel J Sebald [mailto:dan...@ie...]
(snip)
> That is, delete tag [4.6.3] and add a new tag [4.6.3] on the new branch
> (stub) which has the patch.  This puts version tagged [4.6.3] in line with
cvs-
> repository and the tarball.  Add a new tag [4.6.3-Windows] to signify that
is the
> release that Bastian has published for 4.6.3 that includes everything in
the
> 4.6.3 tagged version plus the mods to four Windows-related files.
> 
> Dan

Not sure about the necessity for a Windows tag.  The missing change only
affects the installer, not gnuplot itself, in that it modifies the numbers
and filename there to reflect the patchlevel.

  Bastian

4.6.3 tag in git repository

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

Attached is a script file that will compare a CVS repository against a 
git repository using the numeric tags.

I've found reasonable agreement with all but the git version tagged 
4.6.3, which is tested against CVS version tagged Release_4_6_3.  For 
this particular case, I've also compared against the tarball archived here:

https://sourceforge.net/projects/gnuplot/files/gnuplot/4.6.3/gnuplot-4.6.3.tar.gz/download

Let me first compare CVS Release_4_6_3 against that tarball for a 
benchmark.  The differences I see are:

diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' 
gnuplot-cvs-checkout/gnuplot/docs/pdffigures.tex 
/home/sebald/src/gnuplot/gnuplot-4.6.3/docs/pdffigures.tex
--- gnuplot-cvs-checkout/gnuplot/docs/pdffigures.tex	2010-03-08 
17:41:15.000000000 -0600
+++ /home/sebald/src/gnuplot/gnuplot-4.6.3/docs/pdffigures.tex 
2013-04-12 12:26:25.000000000 -0500
@@ -1,7 +1 @@
-%
-% $Id: pdffigures.tex,v 1.1 2010/03/08 23:41:15 sfeam Exp $
-%
-% This file is modified dynamically by "make" depending on whether or not
-% figures are to be included in the documentation
-% \usepackage{graphicx}
-% \usepackage{picins}
+
diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' 
gnuplot-cvs-checkout/gnuplot/src/version.c 
/home/sebald/src/gnuplot/gnuplot-4.6.3/src/version.c
--- gnuplot-cvs-checkout/gnuplot/src/version.c	2017-11-12 
23:37:09.492098620 -0600
+++ /home/sebald/src/gnuplot/gnuplot-4.6.3/src/version.c	2013-04-12 
12:24:08.000000000 -0500
@@ -41,7 +41,7 @@

  const char gnuplot_version[] = "4.6";
  const char gnuplot_patchlevel[] = "3";
-const char gnuplot_date[] = "April 2013";
+const char gnuplot_date[] = "2013-04-12 ";
  const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
2007-2013";

  const char faq_location[] = FAQ_LOCATION;

The difference is an automatically generated file (I'm not sure what the 
ramifications of that are, but as far as the actual program goes it 
doesn't change anything) and what looks to be a touched-up version date 
that didn't make its way into the repository.

Now the git repository (as gotten from 
https://git.code.sf.net/p/gnuplot/git-main.  There are the following 
changesets near the 4.6.3 tag in the list:

fix memory allocation for large matrices    Ethan A Merritt
[4.6.3] Release 4.6 patchlevel 3            Bastian Maerkisch
bump patchlevel to 4.6.3                    Ethan A Merritt
*** empty log message ***                   Ethan A Merritt

Suffice it to say that all of these changeset versions show mis-matches 
of a half-dozen lines of code or more.  Rather than show these diff 
hunks, let me just explain.  It looks like Ethan created the 
gnuplot-4.6.3.tar.gz tarball including the changesets above with his 
name attached.  In the mean time, Bastian probably created changes to 
the Windows files (which Ethan isn't familiar with) but that changeset 
([4.6.3] above) didn't find its way into the tarball, although it is 
part of the 4.6.3 release (for Windows).

cvs2git resolved this by putting in an extra branch commit (the one 
listed [Release_4_6_3] below):

fix memory allocation for large matrices    Ethan A Merritt
Release 4.6 patchlevel 3                    Bastian Maerkisch
[Release_4_6_3] This commit was manufactured by cvs2svn to create tag 
'Release_4_6_3'.  cvs2git<>
bump patchlevel to 4.6.3                    Ethan A Merritt
*** empty log message ***                   Ethan A Merritt

That extra commit (on a stub branch) is the exact same differences as 
that for the changeset "fix memory allocation for large matrices".

Given that, it looks like you'll need to add something there to get 
release 4.6.3 in line with the tarball.  And the easiest thing is 
probably to mimic what cvs2git did as follows:

1) Create a branch from "bump patchlevel to 4.6.3" version

git checkout c21a99aa6caecac5f125219e791665953c816b37
git checkout -b Release_4_6_3_tarball_stub (or some similar name)

2) Merge changeset "fix memory allocation for large matrices" to the 
newly created stub branch:

git cherry-pick 7d0989dd8cf3b3c18a1fa7181c8a1d38ab14d0b3

3) Change the tags as follows (where the indentation means a different 
branch, however the viewer chooses to display the graph):

       [4.6.3] fix memory allocation for large matrices    Ethan A Merritt

[4.6.3-Windows] fix memory allocation for large matrices    Ethan A Merritt
Release 4.6 patchlevel 3            Bastian Maerkisch
bump patchlevel to 4.6.3                    Ethan A Merritt
*** empty log message ***                   Ethan A Merritt

That is, delete tag [4.6.3] and add a new tag [4.6.3] on the new branch 
(stub) which has the patch.  This puts version tagged [4.6.3] in line 
with cvs-repository and the tarball.  Add a new tag [4.6.3-Windows] to 
signify that is the release that Bastian has published for 4.6.3 that 
includes everything in the 4.6.3 tagged version plus the mods to four 
Windows-related files.

Dan

Re: Short vectors are not plotted

[sfeam <sf...@us...>]

On Sunday, 12 November 2017 13:24:28 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > That allows me to test before/after applying 0005 so that I can evaluate
> > the intended change by itself.  Here's what I see.
> >
> > 1) Something has gone wrong with the arrowhead direction.
> >     Try running arrowstyle.dem.   All the arrows at the page bottom have
> >     inverted arrowheads.
> >
> > 2) The patch has lost the distinction between "fixed" arrowhead size and
> >      the default variable arrowhead size.  Many of the arrows in the
> >      arrowstyle demo look strange because their heads are too big.
> >
> > I attach a revised version of your patch 0005 that addresses 1 + 2.
> >
> > It adds a parameter to draw_clip_arrow that passes the fixed/variable
> > arrowhead size state.  I changed most the call sites to match.
> > This change is in patch 0006
> 
> Hold on. I don't understand this. What is "fixed"? The docs say ONLY
> 
>   By default the size of the arrow head is reduced for very short
>   arrows. This can be disabled using the `fixed` keyword after the
>   `size` command.
> 
> I don't know what that means. 

"fixed" means "fixed arrowhead size".  The arrow head is always the same
size regardless of the vector length.  Without this keyword the arrowhead
size for short vectors is scaled down in proportion with the length.

> A bit of testing with the demo you
> mentioned revealed a few bugs with my draw_clip_arrow(). The best one I
> have is attached. Note that it doesn't have "fixed" path since I can't
> tell what it's supposed to do. If nothing else, the way you implemented
> that path suffers from the truncation issue.

That's not "suffering".  That's the intended behaviour :-)
By default the arrowhead scales with the vector length, so as the length
goes to zero the size of the head does  also.
I don't think truncation is relevant.

> With that function, the arrowstyle.dem demo looks "correct", except the
> line-through-should-be-empty arrowhead problem you mentioned. Some
> arrowheads are shorter than I'd expect, but adding "fixed" to the
> arrowstyle in the demo makes it consistent. Is this the "fixed" you're
> talking about?

Yes, but the new code has to handle both the default case and the
"fixed size" case.   Adding "fixed" to the demo hides the problem.

With regard to the code you attached, I think this part can never happen:

    bool drawbody = true;
    if( head < 0 )
    {
        drawbody = false;
        head = -head;
    }

Unless I overlooked a code path, draw_clip_arrow() is never called with (head < 0).
That convention "negative means only draw the arrowhead" is used only by the
term->arrow() entry, and draw_clip_arrow  itself is the only remaining caller of
term->arrow.   So I think the code I sent previously in 
0005-EAM-draw_clip_arrow-with-double-precision.patch
was correct.

Re: Short vectors are not plotted

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

sfeam <sf...@us...> writes:

> That allows me to test before/after applying 0005 so that I can evaluate
> the intended change by itself.  Here's what I see.
>
> 1) Something has gone wrong with the arrowhead direction.
>     Try running arrowstyle.dem.   All the arrows at the page bottom have
>     inverted arrowheads.
>
> 2) The patch has lost the distinction between "fixed" arrowhead size and
>      the default variable arrowhead size.  Many of the arrows in the
>      arrowstyle demo look strange because their heads are too big.
>
> I attach a revised version of your patch 0005 that addresses 1 + 2.
>
> It adds a parameter to draw_clip_arrow that passes the fixed/variable
> arrowhead size state.  I changed most the call sites to match.
> This change is in patch 0006

Hold on. I don't understand this. What is "fixed"? The docs say ONLY

  By default the size of the arrow head is reduced for very short
  arrows. This can be disabled using the `fixed` keyword after the
  `size` command.

I don't know what that means. A bit of testing with the demo you
mentioned revealed a few bugs with my draw_clip_arrow(). The best one I
have is attached. Note that it doesn't have "fixed" path since I can't
tell what it's supposed to do. If nothing else, the way you implemented
that path suffers from the truncation issue.

With that function, the arrowstyle.dem demo looks "correct", except the
line-through-should-be-empty arrowhead problem you mentioned. Some
arrowheads are shorter than I'd expect, but adding "fixed" to the
arrowstyle in the demo makes it consistent. Is this the "fixed" you're
talking about?

Re: Short vectors are not plotted

[sfeam <sf...@us...>]

On Saturday, 11 November 2017 21:58:48 sfeam via gnuplot-beta wrote:
> Very good.
> That allows me to test before/after applying 0005 so that I can evaluate
> the intended change by itself.  Here's what I see.
> 
> 1) Something has gone wrong with the arrowhead direction.
>     Try running arrowstyle.dem.   All the arrows at the page bottom have
>     inverted arrowheads.
> 
> 2) The patch has lost the distinction between "fixed" arrowhead size and
>      the default variable arrowhead size.  Many of the arrows in the
>      arrowstyle demo look strange because their heads are too big.
> 
> 3) Arrowstyle 6 in the demo is supposed to show open unfilled heads.
>     After patch 0005 the arrow shaft extends through the head so it no
>     longer appears unfilled.

[snip]

> I have no clue what is going on with bug (3).  Maybe you can spot the error.
> Otherwise I think this is converging rapidly on a nice improvement.


Found it. 
The old code adjusted the shaft length so that it stopped short of the head.
The adjustment depends on the head style.
The new code always calls (*t->arrow)(sx, sy, ex, ey, NOHEAD)
and then draws the head separately. 
This means that the shaft is never corrected for the head length because
the head style is not known at that point. 

	Ethan

Aw: Re: Re: State of the CVS conversion

[Bastian M. <bma...@we...>]

> Von: "Eric S. Raymond" <es...@th...>
> "Bastian Märkisch" <bma...@we...>:
> > But I am getting error messages:
> > reposurgeon: couldn't match a name at <bma...@we...!2014-06-01T11:26:58+02:00>
> > 
> > It does not help to revert the order of time and email. What am I doing wrong?
> 
> Possibly nothing.  I recently found a bug in the way the action-stamp table
> was being built; you should get the repo-tip version of reposurgeon and
> see if it solves that problem.

Unfortunately, that didn't fix the problem. Searching for the date in the converted repo like

git log --before="2014-06-01T11:26:58+02:00" -1 

finds the correct entry. So I think the date is correct.
More ideas?

  Bastian

Re: Short vectors are not plotted

[sfeam <sf...@us...>]

On Saturday, 11 November 2017 17:50:18 you wrote:
> Ethan A Merritt <EAM...@gm...> writes:
> 
> > On Saturday, 04 November 2017 21:43:09 Dima Kogan wrote:
> >
> >> 1. This patch uncovered an inconsistency in much of our code: when
> >> converting a floating-point terminal coordinate to an integer one,
> >> sometimes we round (either with (int)(x+0.5) or by calling
> >> axis_map_toint()) and sometimes we floor ( (int)(x) ). Looks like it's
> >> more or less random which one we pick. We should always round, I
> >> suspect. This patch series doesn't attempt to resolve this, but a future
> >> set of patches should.
> >
> > Your patch set definitely runs aground on that point.
> > I tried to compare results before/after the patches but there are so many
> > single-digit coordinate changes throughout that it's impossible.
> > Yes it may be worth it to review the double->termcoord conversion
> > everywhere in the program, but let's disentangle that from changes to
> > handling short vectors.
> >
> > Here's how I tested:
> >     ./gnuplot-before -e 'set term post color' all.dem < /bin/yes > all_before.ps
> >     ./gnuplot-after -e 'set term post color' all.dem < /bin/yes > all_after.ps
> >
> >     diff -ur all_before.ps all_after.ps > all.diff
> >     diffstat all.diff
> >
> >     diffstat all.diff
> >      all_after.ps |234431 +++++++++++++++++++++++++++++++-----------------------------
> >      1 file changed, 121820 insertions(+), 112611 deletions(-)
> 
> That is a great way to test this! Definitely keeping that in mind for
> the future.
> 
> I have new patches (attached). This is a similar series from before,
> except with finer granularity. The bulk of the main patch lives in patch
> 0003. This is the same as before except:
> 
> - The meat of the changes in draw_clip_arrow() has been left out
> - The previous round/truncate behavior was carefully preserved
> 
> Thus your all.dem test results after applying patch 0003 should match
> those before applying any of these patches.
> 
> Then patch 0004 is a short one that removes the compatibility off-by-one
> changes and patch 0005 actually updates draw_clip_arrow() to handle the
> short vectors.

Very good.
That allows me to test before/after applying 0005 so that I can evaluate
the intended change by itself.  Here's what I see.

1) Something has gone wrong with the arrowhead direction.
    Try running arrowstyle.dem.   All the arrows at the page bottom have
    inverted arrowheads.

2) The patch has lost the distinction between "fixed" arrowhead size and
     the default variable arrowhead size.  Many of the arrows in the
     arrowstyle demo look strange because their heads are too big.

3) Arrowstyle 6 in the demo is supposed to show open unfilled heads.
    After patch 0005 the arrow shaft extends through the head so it no
    longer appears unfilled.

4) Not a result of your patch but I realized while testing - The code in
    post.trm that was messing up was intended to enforce solid lines 
    when drawing an arrowhead (dotted arrowheads look terrible).
    Since version 5 introduced dash patterns to all terminals, all terminals
    now suffer from this.  Any fix to replace the one in post.trm will have
    to catch all terminals.   But maybe it's not worth it.

I attach a revised version of your patch 0005 that addresses 1 + 2.

It adds a parameter to draw_clip_arrow that passes the fixed/variable
arrowhead size state.  I changed most the call sites to match.
This change is in patch 0006

0005-EAM is to be applied instead of your previous 0005
0006-EAM is to be applied on top of it
(these are not git patch-format.  I'm still getting up to speed with that).


I consider this an imperfect solution to be used for debugging.
A cleaner solution would be to pass a pointer
to the structure containing the arrowhead style.  E.g. instead of
      draw_clip_arrow(x1, y1, x2, y2, ap.head, ap.head_fixedsize);
it would be
      draw_clip_arrow(x1, y1, x2, y2, &ap);

I didn't change the call sites in util3d.c (draw3d_line_unconditional)
you'll have to dummy those up for testing.  I think that routine will
need additional changes eventually.

> Clearly patches 0004 and 0005 WILL produce rendering differences.
> To be clear, these patches still don't try to clean up the
> round/truncate differences, but at least make it obvious where the
> questionable spots are regarding this patch series: in all the things
> that patch 0004 touches.

I understand.  I will disregard the 1-pixel change side effects for now.

[snip fixed problem with post.trm]
> I don't see this. Could it be because I applied the postscript-terminal
> patch you sent out?
Yes.

> I can think of one piece of the new code that could be producing an
> overflow, though. In draw_clip_arrow() I have this:
> 
>     // Direction vector in (dex,dey). I need to convert this to integers
>     // with a scale that's large-enough to give me good angular resolution,
>     // but small-enough to not overflow the data type. Let's aim for the
>     // vectors to be on the order of 1e6 ~ 2^20
>     dex -= dsx;
>     dey -= dsy;
> 
>     double delta_largest = fmax( fabs(dex), fabs(dey) );
>     double scale_want    = (double)(1U << 20);
>     double scale = scale_want / delta_largest;
> 
>     dex *= scale_want;
>     dey *= scale_want;
> 
> Maybe 2^20 is too large for some terminals?

Yes.  See revised code in my version of 0005 that uses a
terminal-specific scale.

I have no clue what is going on with bug (3).  Maybe you can spot the error.
Otherwise I think this is converging rapidly on a nice improvement.

As noted above I am suspicious that the 3D code may trip other problems
but I have not looked at it very hard.

	Ethan

Re: Short vectors are not plotted

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

Ethan A Merritt <EAM...@gm...> writes:

> On Saturday, 04 November 2017 21:43:09 Dima Kogan wrote:
>
>> 1. This patch uncovered an inconsistency in much of our code: when
>> converting a floating-point terminal coordinate to an integer one,
>> sometimes we round (either with (int)(x+0.5) or by calling
>> axis_map_toint()) and sometimes we floor ( (int)(x) ). Looks like it's
>> more or less random which one we pick. We should always round, I
>> suspect. This patch series doesn't attempt to resolve this, but a future
>> set of patches should.
>
> Your patch set definitely runs aground on that point.
> I tried to compare results before/after the patches but there are so many
> single-digit coordinate changes throughout that it's impossible.
> Yes it may be worth it to review the double->termcoord conversion
> everywhere in the program, but let's disentangle that from changes to
> handling short vectors.
>
> Here's how I tested:
>     ./gnuplot-before -e 'set term post color' all.dem < /bin/yes > all_before.ps
>     ./gnuplot-after -e 'set term post color' all.dem < /bin/yes > all_after.ps
>
>     diff -ur all_before.ps all_after.ps > all.diff
>     diffstat all.diff
>
>     diffstat all.diff
>      all_after.ps |234431 +++++++++++++++++++++++++++++++-----------------------------
>      1 file changed, 121820 insertions(+), 112611 deletions(-)

That is a great way to test this! Definitely keeping that in mind for
the future.

I have new patches (attached). This is a similar series from before,
except with finer granularity. The bulk of the main patch lives in patch
0003. This is the same as before except:

- The meat of the changes in draw_clip_arrow() has been left out
- The previous round/truncate behavior was carefully preserved

Thus your all.dem test results after applying patch 0003 should match
those before applying any of these patches.

Then patch 0004 is a short one that removes the compatibility off-by-one
changes and patch 0005 actually updates draw_clip_arrow() to handle the
short vectors.

Clearly patches 0004 and 0005 WILL produce rendering differences.

To be clear, these patches still don't try to clean up the
round/truncate differences, but at least make it obvious where the
questionable spots are regarding this patch series: in all the things
that patch 0004 touches.



> That let me look for problem areas, and I found some. There are many
> cases where the coordinates passed to the terminal driver have
> overflowed. For example the "Let's smile with parametric filled
> curves" plot in the filledcurves demo ends like this:
>
>     gsave [] 0 setdash
>     3980 1811 M
>     0 -221 V
>     -218 37 V
>     -653259491 771754262 M
>     3980 1590 L
>     stroke
>     grestore
>
> The coordinates in that last move (M) command are nonsense.

I don't see this. Could it be because I applied the postscript-terminal
patch you sent out?

I can think of one piece of the new code that could be producing an
overflow, though. In draw_clip_arrow() I have this:

    // Direction vector in (dex,dey). I need to convert this to integers
    // with a scale that's large-enough to give me good angular resolution,
    // but small-enough to not overflow the data type. Let's aim for the
    // vectors to be on the order of 1e6 ~ 2^20
    dex -= dsx;
    dey -= dsy;

    double delta_largest = fmax( fabs(dex), fabs(dey) );
    double scale_want    = (double)(1U << 20);
    double scale = scale_want / delta_largest;

    dex *= scale_want;
    dey *= scale_want;

Maybe 2^20 is too large for some terminals?

Re: Re: State of the CVS conversion

[Eric S. R. <es...@th...>]

"Bastian Märkisch" <bma...@we...>:
> But I am getting error messages:
> reposurgeon: couldn't match a name at <bma...@we...!2014-06-01T11:26:58+02:00>
> 
> It does not help to revert the order of time and email. What am I doing wrong?

Possibly nothing.  I recently found a bug in the way the action-stamp table
was being built; you should get the repo-tip version of reposurgeon and
see if it solves that problem.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Aw: Re: State of the CVS conversion

[Bastian M. <bma...@we...>]

> Von: "Eric S. Raymond" <es...@th...>
> sfeam <sf...@us...>:
> > On Saturday, 04 November 2017 17:17:39 Eric S. Raymond wrote:
> > > sfeam <sf...@us...>:
> > > > On Saturday, 04 November 2017 10:30:34 Eric S. Raymond wrote:
> > > > > "Bastian Märkisch" <bma...@we...>:
> > > > > > There are a few cases which we probably would like to fix because the
> > > > > > ChangeLog was modified in an "atypical" way.  Should this be done now
> > > > > > or can this be corrected after the conversion (sorry, not really 
> > > > > > familiar with git yet)?
> > > > > 
> > > > > It can be done either way.  Safest to do it before the cutover, so the
> > > > > changest get recorded in reconvert and not lost if we do some other
> > > > > modification.
> > > > 
> > > > Could you provide a recipe for making such a correction?
> > > 
> > > If you have a speification for a changeset, like say
> > > 
> > >    <es...@th...!2017-11-04T16:44:25>
> > > 
> > > you can say
> > > 
> > > reposurgeon
> > > reposrgeon> read gnuplot
> > > reposurgeon> <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly <fr...@fo...>"
> > > reposurgeon rebuild
> > > 
> > > Of course, you can do more tham one of these per session.

I am having trouble with the syntax.  I was trying to add a few lines to the reconvert script at the end of the reposurgeon inline script, before the "dedup" statement.  Like this:
<bma...@we...!2014-06-01T11:26:58+02:00> setfield author "Tatsuro Matsuoka <tma...@ya...>"
But I am getting error messages:
reposurgeon: couldn't match a name at <bma...@we...!2014-06-01T11:26:58+02:00>

It does not help to revert the order of time and email. What am I doing wrong?
   
  Bastian