Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.graphics.apps.gnuplot > #3304

Re: Ticket 1782: plot with image broken in CVS

Show all headers | View raw

Stephan Böttcher wrote:

This afternoon's CVS should have a fix that handles your data file.
The PDF file I get from it is the same size as with 5.0.3

	Ethan


> 
> Hi Ethan,
> 
> Ethan A Merritt <sfeam@users.sourceforge.net> writes:
> 
>> Stephan Böttcher wrote:
>>
>>> Ethan A Merritt <EAMerritt@gmail.com> writes:
>>> 
>>>> Patch and possible work-around attached to the original Bug Report.
>>>> https://sourceforge.net/p/gnuplot/bugs/1782/
>>> 
>>> Thanks.
>>> 
>>> Well, when I specify which column shall go to the x-coordinate and
>>> which column contains y-coodinates, there shall be no room for
>>> misunderstanding that.  "using x:y:cb" is umambiguous, isn't it?
>>
>> Image data is not normally provide point-by-point.
>> A *.png file or a *.bmp file or whatever is a stream of
>> intensity/color values with some meta-information that indicates
>> how to split that stream into rows and columns.
>>
>> Obviously you can specify the content of an image by describing
>> each pixel in terms of its individual coordinates, but that is
>> not the normal case.
>>
>>
>>> The only workaround I see is sticking with 5.0.3 until this is
>>> fixed.
>>
>> That may be a solution for your particular input data stream, but
>> 5.0.3 is known to incorrectly handle similar streams.
>> See in particular Bug #1767.
>>
>>> I understand that the image plots may have a hard time to figure out
>>> the binning of the data.  That is why my scripts produce very
>>> unambiguous data files:
>>> 
>>> x1 y1 z11
>>> x2 y1 z12
>>> x3 y1 z13
>>> x4 y1 0
>>> 
>>> x1 y2 z21
>>> x2 y2 z22
>>> x3 y2 z23
>>> x4 y2 0
>>> 
>>> x1 y3 z31
>>> x2 y3 z32
>>> x3 y3 z33
>>> x4 y3 0
>>> 
>>> x1 y4 0
>>> x2 y4 0
>>> x3 y4 0
>>> x4 y4 0
>>> 
>>> These worked fine since the early days of "pm3d corners2color c1".
>>
>> Plot styles "with pm3d" and "with image" are very different things!
> 
> Since "image" exists, I use it instead of pm3d with great success.
> Since my use of pm3d was always really meant to be "image". (set pm3d
> map corners2color c1)
> 
>> It might be that your plot would come out correctly if treated as
>> pm3d data. You could try it.
> 
> It is still the same old script I use today, long before "image" was
> implemented.  So yes, I expect pm3d to work.  But I need a 2D plot. 
> For me, pm3d was always a hack.
> 
>> You could also try plotting "with points pointtype 5 linecolor
>> variable"
>>
>>> If the new image parser misunderstands these files it is very
>>> broken.
>>
>> What is obvious to you may not be so obvious to a stupid program.
>> The file layout you describe above does not match any image
>> convention
>> that gnuplot knows about.  It can read each line as a an [x,y,z]
>> point,
> 
> That is exactly what my files are.
> 
> $ gnuplot help image
> ...
> The `image` style handles input pixels containing a grayscale or color
> palette value. Thus 2D plots (`plot` command) require 3 columns of
> data (x,y,value) ...
>  
>> or read each blank-line-separated block as a line segment.  In pm3d
>> mode it can fit individual points onto a gridded surface, but that is
>> not part of normal image processing.
> 
> Well, when the datafile says (x,y,value), I expect the pixel at x:y to
> be
> colored by value.  Did I completely misunderstand the semantics?
> 
>>> I do not see how a transpose option is needed with this kind of
>>> datafile.  As long as it is needed something is broken.  Matrix type
>>> data may be a different issue, I never used that, yet.
>>
>> In the case of the earlier bugs, transposing the internal values of
>> x and y restored the "correct" image.  That may not be the case for
>> your data but I thought it was worth a try as a quick work-around.
> 
> Sure, thanks. But 5.0.3 works, and for now I will stick to it.
> 
>>> And why did the PDF output filesize blow up out of proportion with
>>> 5.1 compared to 5.0.3?
>>
>> So far as I know, it has not.  If you can provide a script (with data
>> if needed) that shows a drastically different file size for the same
>> plot I will look into it.
> 
> http://tmp.psjt.org/2016-04-19-fm1-post-tct-coldnonop-functest-Bi207-xray-nom_C1H.2dhist
> 
> set log cb
> set cbr [0.5:*]
> plot
> "2016-04-19-fm1-post-tct-coldnonop-functest-Bi207-xray-nom_C1H.2dhist"
> with image
> 
> Not exactly a minimal example.  The datafile (output of that awk
> script) is 3.4MByte.
> 
> set term pdf size 11in,7.8in
> gnuplot HEAD of today: 2961420 bytes
> gnuplot 5.0.3        :   78655 bytes
> 
>> The pair of files you attached to your bug report clearly do not
>> contain the same plot, so it's not fair to compare file sizes.
> 
> Oh yes, they are the same plot.  The same script, the same data.  Both
> made with gnuplot from CVS configured and compiled the same way on the
> same day (yesterday), with the same libraries, one with the HEAD
> revision, one with the 5.0.3 branch.
> 
> The datafile linked above contains a few more hours of data (x) than
> the
> plots in the bugreport.  Apart from that its the same plot.
> 

Back to comp.graphics.apps.gnuplot | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Ticket 1782: plot with image broken in CVS boettcher@physik.uni-kiel.de (Stephan I Böttcher) - 2016-04-19 23:19 +0200
  Re: Ticket 1782: plot with image broken in CVS Ethan A Merritt <EAMerritt@gmail.com> - 2016-04-19 21:07 -0700
    Re: Ticket 1782: plot with image broken in CVS boettcher@physik.uni-kiel.de (Stephan Böttcher) - 2016-04-20 17:06 +0200
      Re: Ticket 1782: plot with image broken in CVS Ethan A Merritt <sfeam@users.sourceforge.net> - 2016-04-20 12:13 -0700
        Re: Ticket 1782: plot with image broken in CVS boettcher@physik.uni-kiel.de (Stephan Böttcher) - 2016-04-20 22:36 +0200
          Re: Ticket 1782: plot with image broken in CVS Ethan A Merritt <EAMerritt@gmail.com> - 2016-04-20 21:15 -0700
            Re: Ticket 1782: plot with image broken in CVS boettcher@physik.uni-kiel.de (Stephan Böttcher) - 2016-04-21 12:42 +0200

csiph-web