#1873 Error in Image Rendering With Specified Axis Values [PATCH ATTACHED]

None
pending-fixed
nobody
None
2016-11-08
2016-11-01
No

The "record" treatment of binary image data yields incorrect plotting. Since "record" is used (in parallel with other plotting methods) to set the scale, aspect ratio, rotation, and skew of an image, this is a serious problem. "array" input works OK, but for certain size values "record" causes duplicate copies of the output image. This occurs for many output terminals -- I have tested with pngcairo, png, x11, wxt, and pdfcairo. I attach sample output and a datafile that reproduce the problem, along with the script below.

[dhcp-10-227:~/Documents/Projects/jets] zowie% gnuplot

        G N U P L O T
        Version 5.0 patchlevel 3    last modified 2016-02-21

        Copyright (C) 1986-1993, 1998, 2004, 2007-2016
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot> set terminal pngcairo size 800,800
Terminal type set to 'pngcairo'
Options are ' background "#ffffff" enhanced fontscale 1.0 size 800, 800 '
gnuplot> set output "ok.png"
gnuplot> set title "Array processing (implicit index) is OK"
gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 3 with image
gnuplot> set output "bad.png"
gnuplot> set title "Record processing (explicit index) is bad"
gnuplot> plot "imdump2.dat" binary record=(200,400) format="%double%double%double" using 1:2:3 with image
gnuplot> set output "x.png"
gnuplot> set title "X index is as expected"
gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 1 with image
gnuplot>
1 Attachments

Related

Bugs: #1873

Discussion

  • Craig DeForest

    Craig DeForest - 2016-11-01

    (note that the X and Y fields in the attached binary file simply echo the index value of each pixel, so the "ok.png" and "bad.png" should produce exactly the same output).

     
  • Craig DeForest

    Craig DeForest - 2016-11-02

    I have fixed the problem. The following patch fixes it. The problem was that the "record" specifier was causing (e.g.) a 200x400 array to be read as if it were a 400x200 array. This would not be a problem if each pixel were being individually read and parsed by the "with image" code, since each pixel would then be individually placed. But "with image" uses a shortcut of calculating a single Jacobian matrix for the transform (assuming the image-coord -> pixel-coord transformation is linear). That yielded strange duplicates and skewed copies of the image.

    datafile.c.old Wed Nov 2 14:20:41 2016
    --- datafile.c Wed Nov 2 14:21:02 2016
    ***
    3535,3542 ****
    df_matrix_file = FALSE;
    plot_option_array();
    set_record = TRUE;
    ! df_xpixels = df_bin_record[df_num_bin_records - 1].cart_dim[1];
    ! df_ypixels = df_bin_record[df_num_bin_records - 1].cart_dim[0];
    FPRINTF((stderr,"datafile.c:%d record dimensions %d x %d\n", LINE,
    df_xpixels, df_ypixels));
    continue;
    --- 3535,3542 ----
    df_matrix_file = FALSE;
    plot_option_array();
    set_record = TRUE;
    ! df_xpixels = df_bin_record[df_num_bin_records - 1].cart_dim[0];
    ! df_ypixels = df_bin_record[df_num_bin_records - 1].cart_dim[1];
    FPRINTF((stderr,"datafile.c:%d record dimensions %d x %d\n", LINE,
    df_xpixels, df_ypixels));
    continue;

     
  • Craig DeForest

    Craig DeForest - 2016-11-02
    • summary: Error in Image Rendering With Specified Axis Values --> Error in Image Rendering With Specified Axis Values [PATCH ATTACHED]
    • Group: -->
    • Priority: -->
     
  • Craig DeForest

    Craig DeForest - 2016-11-02

    The following patch fixes this problem. It is due to an incorrect assignment of xpixels and ypixels sizes in the binary matrix read code: an NxM matrix is read as if it were an MxN matrix, but ONLY with the “record” specifier. The “array” specifier had the correct order.

    3538,3539c3538,3539
    < df_xpixels = df_bin_record[df_num_bin_records - 1].cart_dim[1];
    < df_ypixels = df_bin_record[df_num_bin_records - 1].cart_dim[0];


          df_xpixels = df_bin_record[df_num_bin_records - 1].cart_dim[0];
          df_ypixels = df_bin_record[df_num_bin_records - 1].cart_dim[1];
    

    On Nov 1, 2016, at 11:23 AM, Craig DeForest zowie@users.sf.net wrote:

    [bugs:#1873] https://sourceforge.net/p/gnuplot/bugs/1873/ Error in Image Rendering With Specified Axis Values

    Status: open
    Priority:
    Created: Tue Nov 01, 2016 05:23 PM UTC by Craig DeForest
    Last Updated: Tue Nov 01, 2016 05:23 PM UTC
    Owner: nobody
    Attachments:

    bug.zip https://sourceforge.net/p/gnuplot/bugs/1873/attachment/bug.zip (616.1 kB; application/zip)
    The "record" treatment of binary image data yields incorrect plotting. Since "record" is used (in parallel with other plotting methods) to set the scale, aspect ratio, rotation, and skew of an image, this is a serious problem. "array" input works OK, but for certain size values "record" causes duplicate copies of the output image. This occurs for many output terminals -- I have tested with pngcairo, png, x11, wxt, and pdfcairo. I attach sample output and a datafile that reproduce the problem, along with the script below.

    [dhcp-10-227:~/Documents/Projects/jets] zowie% gnuplot

        G N U P L O T
        Version 5.0 patchlevel 3    last modified 2016-02-21
    
        Copyright (C) 1986-1993, 1998, 2004, 2007-2016
        Thomas Williams, Colin Kelley and many others
    
        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')
    

    Terminal type set to 'qt'
    gnuplot> set terminal pngcairo size 800,800
    Terminal type set to 'pngcairo'
    Options are ' background "#ffffff" enhanced fontscale 1.0 size 800, 800 '
    gnuplot> set output "ok.png"
    gnuplot> set title "Array processing (implicit index) is OK"
    gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 3 with image
    gnuplot> set output "bad.png"
    gnuplot> set title "Record processing (explicit index) is bad"
    gnuplot> plot "imdump2.dat" binary record=(200,400) format="%double%double%double" using 1:2:3 with image
    gnuplot> set output "x.png"
    gnuplot> set title "X index is as expected"
    gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 1 with image
    gnuplot>
    Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gnuplot/bugs/1873/ https://sourceforge.net/p/gnuplot/bugs/1873/
    To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #1873

  • Ethan Merritt

    Ethan Merritt - 2016-11-03

    I hate the binary file handling code.

    I'll apply your patch because it's obvious that the two adjacent code sections handling "record=(a,b)" and "array=(a,b)" disagree with each other about the interpretation of a and b.

    On the other hand I'm at a loss to explain why the "record=(a,b)" variant even cares what a and b are. The whole point of this mode (at least according to the docs) is that the file itself contains x and y coordinates, and that should be definitive. And indeed if you simply leave out the record keyword altogether it seems to work fine other than issuing a warning. WIth plot styles other than "image" it doesn't even issue the warning. So I'm wondering why/when the "record" keyword is needed in the first place? Do you know?

     
    • Craig DeForest

      Craig DeForest - 2016-11-03

      Thanks!

      The issue is that the relative locations of the points in the record array matter for some plot styles. In “with points” plots, it really doesn’t matter — the points get plotted in a different order if you get the matrix shape wrong, but they look the same in the end. But “with lines” in 3-D plots a grid connecting the data points, so getting the order wrong would give you a few stray lines here and there.

      The image plotting methods are, I think, the only 2-D ones where the shape matters. What’s going on is that the image plotting code doesn’t just place pixels in random locations — for speed it assumes they’re supposed to be a uniform grid in data space. The code looks at the coordinates of the origin, the lower-right point, and the upper-left point, and uses that to create a linear transformation converting between pixel location in the matrix and dataspace location to be rendered. Then the rest of the rendering code treats the record matrix as some kind of implicit array matrix: it ignores the ordinate values and calculates them using that linear transformation.

      That’s a useful hack, even though it means you can’t input an arbitrarily-distorted image: most of the time linear transformations are enough; and truly arbitrary distortions are something like 1,000 times slower. (I spent a long time implementing arbitrary resampling for PDL — it’s a bear to get right). (For fully arbitrary image distortions with Gnuplot one currently has to go to a 3-D plot with the viewpoint looking down from above.)

      All the best,
      Craig

      On Nov 3, 2016, at 12:40 AM, Ethan Merritt sfeam@users.sf.net wrote:

      I hate the binary file handling code.

      I'll apply your patch because it's obvious that the two adjacent code sections handling "record=(a,b)" and "array=(a,b)" disagree with each other about the interpretation of a and b.

      On the other hand I'm at a loss to explain why the "record=(a,b)" variant even cares what a and b are. The whole point of this mode (at least according to the docs) is that the file itself contains x and y coordinates, and that should be definitive. And indeed if you simply leave out the record keyword altogether it seems to work fine other than issuing a warning. WIth plot styles other than "image" it doesn't even issue the warning. So I'm wondering why/when the "record" keyword is needed in the first place? Do you know?

      [bugs:#1873] https://sourceforge.net/p/gnuplot/bugs/1873/ Error in Image Rendering With Specified Axis Values [PATCH ATTACHED]

      Status: open
      Priority:
      Created: Tue Nov 01, 2016 05:23 PM UTC by Craig DeForest
      Last Updated: Wed Nov 02, 2016 08:30 PM UTC
      Owner: nobody
      Attachments:

      bug.zip https://sourceforge.net/p/gnuplot/bugs/1873/attachment/bug.zip (616.1 kB; application/zip)
      The "record" treatment of binary image data yields incorrect plotting. Since "record" is used (in parallel with other plotting methods) to set the scale, aspect ratio, rotation, and skew of an image, this is a serious problem. "array" input works OK, but for certain size values "record" causes duplicate copies of the output image. This occurs for many output terminals -- I have tested with pngcairo, png, x11, wxt, and pdfcairo. I attach sample output and a datafile that reproduce the problem, along with the script below.

      [dhcp-10-227:~/Documents/Projects/jets] zowie% gnuplot

          G N U P L O T
          Version 5.0 patchlevel 3    last modified 2016-02-21
      
          Copyright (C) 1986-1993, 1998, 2004, 2007-2016
          Thomas Williams, Colin Kelley and many others
      
          gnuplot home:     http://www.gnuplot.info
          faq, bugs, etc:   type "help FAQ"
          immediate help:   type "help"  (plot window: hit 'h')
      

      Terminal type set to 'qt'
      gnuplot> set terminal pngcairo size 800,800
      Terminal type set to 'pngcairo'
      Options are ' background "#ffffff" enhanced fontscale 1.0 size 800, 800 '
      gnuplot> set output "ok.png"
      gnuplot> set title "Array processing (implicit index) is OK"
      gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 3 with image
      gnuplot> set output "bad.png"
      gnuplot> set title "Record processing (explicit index) is bad"
      gnuplot> plot "imdump2.dat" binary record=(200,400) format="%double%double%double" using 1:2:3 with image
      gnuplot> set output "x.png"
      gnuplot> set title "X index is as expected"
      gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 1 with image
      gnuplot>
      Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gnuplot/bugs/1873/ https://sourceforge.net/p/gnuplot/bugs/1873/
      To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #1873

  • Ethan Merritt

    Ethan Merritt - 2016-11-03

    More thoughts:

    • You are correct that if the coordinates stored in the array do not describe a regular grid then the current "with image" code will not notice this. You can, however, plot them as individual pixels using

    plot foo binary format="%double%double%double" using 1:2:3 with points pt 5 lc palette z

    • In the current case however, the coordinates do describe a regular grid. So here the image code could look at the actual coordinate values to decide what the grid dimensions are.

    • Non-linear image distortions are now handled fairly easily, so long as you can describe the distortion by an invertable equation. See the demos for the recently added nonlinear scaling code. The nonlinear mappings work in either 2D or 3D.

      http://skuld.bmsc.washington.edu/people/merritt/gnuplot/nonlinear3.html

     
    Last edit: Ethan Merritt 2016-11-03
    • Craig DeForest

      Craig DeForest - 2016-11-04

      Very cool!

      How do you implement the distortion onto the output pixel grid? Are you using the inverse transform to sample the input image? Or are you doing some sort of spatial filtering? If the former, I can offer some code I wrote for PDL, to carry out the resample. It’s a bit expensive — it calculates the discrete Jacobian at every point and uses that to generat a spatially variable input filter - but it yields photometric/scientific quality output.

      Best,
      Craig

      On Nov 3, 2016, at 10:12 AM, Ethan Merritt sfeam@users.sf.net wrote:

      More thoughts:

      You are correct that if the coordinates stored in the array do not describe a regular grid then the current "with image" code will not notice this. You can, however, plot them as individual pixels using
      plot foo binary format="%double%double%double" using 1:2:3 with points pt 5 lc palette z

      In the current case however, the coordinates do describe a regular grid. So here the image code could look at the actual coordinate values to decide what the grid dimensions are.
      Non-linear image distortions are now handled fairly easily, so long as you can describe the distortion by an invertiable equation. See the demos for the recently added nonlinear scaling code. The nonlinear mappings work in either 2D or 3D.

      http://skuld.bmsc.washington.edu/people/merritt/gnuplot/nonlinear3.html http://skuld.bmsc.washington.edu/people/merritt/gnuplot/nonlinear3.html
      [bugs:#1873] https://sourceforge.net/p/gnuplot/bugs/1873/ Error in Image Rendering With Specified Axis Values [PATCH ATTACHED]

      Status: open
      Priority:
      Created: Tue Nov 01, 2016 05:23 PM UTC by Craig DeForest
      Last Updated: Thu Nov 03, 2016 06:40 AM UTC
      Owner: nobody
      Attachments:

      bug.zip https://sourceforge.net/p/gnuplot/bugs/1873/attachment/bug.zip (616.1 kB; application/zip)
      The "record" treatment of binary image data yields incorrect plotting. Since "record" is used (in parallel with other plotting methods) to set the scale, aspect ratio, rotation, and skew of an image, this is a serious problem. "array" input works OK, but for certain size values "record" causes duplicate copies of the output image. This occurs for many output terminals -- I have tested with pngcairo, png, x11, wxt, and pdfcairo. I attach sample output and a datafile that reproduce the problem, along with the script below.

      [dhcp-10-227:~/Documents/Projects/jets] zowie% gnuplot

          G N U P L O T
          Version 5.0 patchlevel 3    last modified 2016-02-21
      
          Copyright (C) 1986-1993, 1998, 2004, 2007-2016
          Thomas Williams, Colin Kelley and many others
      
          gnuplot home:     http://www.gnuplot.info
          faq, bugs, etc:   type "help FAQ"
          immediate help:   type "help"  (plot window: hit 'h')
      

      Terminal type set to 'qt'
      gnuplot> set terminal pngcairo size 800,800
      Terminal type set to 'pngcairo'
      Options are ' background "#ffffff" enhanced fontscale 1.0 size 800, 800 '
      gnuplot> set output "ok.png"
      gnuplot> set title "Array processing (implicit index) is OK"
      gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 3 with image
      gnuplot> set output "bad.png"
      gnuplot> set title "Record processing (explicit index) is bad"
      gnuplot> plot "imdump2.dat" binary record=(200,400) format="%double%double%double" using 1:2:3 with image
      gnuplot> set output "x.png"
      gnuplot> set title "X index is as expected"
      gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 1 with image
      gnuplot>
      Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gnuplot/bugs/1873/ https://sourceforge.net/p/gnuplot/bugs/1873/
      To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #1873

      • Ethan Merritt

        Ethan Merritt - 2016-11-04

        There is no sampling involved. The coordinate system itself is mapped through an arbitrary pair of functions f(x) and g(y). So each pixel (x,y) is printed at output coordinate (f(x),g(y)) The inverse functions are needed so that you can recover the orginal coordinates from the position in the output image. This works for all plot types, not just image plots. Depending on the purpose of the whole exercise, you might want to label the axes in the orginal coordinate system or the transformed one.

         
        • Craig DeForest

          Craig DeForest - 2016-11-04

          I’ll have a look at it, thanks! Sounds very, very useful.

          On Nov 3, 2016, at 9:31 PM, Ethan Merritt sfeam@users.sf.net wrote:

          There is no sampling involved. The coordinate system itself is mapped through an arbitrary pair of functions f(x) and g(y). So each pixel (x,y) is printed at output coordinate (f(x),g(y)) The inverse functions are needed so that you can recover the orginal coordinates from the position in the output image. This works for all plot types, not just image plots. Depending on the purpose of the whole exercise, you might want to label the axes in the orginal coordinate system or the transformed one.

          [bugs:#1873] https://sourceforge.net/p/gnuplot/bugs/1873/ Error in Image Rendering With Specified Axis Values [PATCH ATTACHED]

          Status: open
          Priority:
          Created: Tue Nov 01, 2016 05:23 PM UTC by Craig DeForest
          Last Updated: Thu Nov 03, 2016 04:12 PM UTC
          Owner: nobody
          Attachments:

          bug.zip https://sourceforge.net/p/gnuplot/bugs/1873/attachment/bug.zip (616.1 kB; application/zip)
          The "record" treatment of binary image data yields incorrect plotting. Since "record" is used (in parallel with other plotting methods) to set the scale, aspect ratio, rotation, and skew of an image, this is a serious problem. "array" input works OK, but for certain size values "record" causes duplicate copies of the output image. This occurs for many output terminals -- I have tested with pngcairo, png, x11, wxt, and pdfcairo. I attach sample output and a datafile that reproduce the problem, along with the script below.

          [dhcp-10-227:~/Documents/Projects/jets] zowie% gnuplot

              G N U P L O T
              Version 5.0 patchlevel 3    last modified 2016-02-21
          
              Copyright (C) 1986-1993, 1998, 2004, 2007-2016
              Thomas Williams, Colin Kelley and many others
          
              gnuplot home:     http://www.gnuplot.info
              faq, bugs, etc:   type "help FAQ"
              immediate help:   type "help"  (plot window: hit 'h')
          

          Terminal type set to 'qt'
          gnuplot> set terminal pngcairo size 800,800
          Terminal type set to 'pngcairo'
          Options are ' background "#ffffff" enhanced fontscale 1.0 size 800, 800 '
          gnuplot> set output "ok.png"
          gnuplot> set title "Array processing (implicit index) is OK"
          gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 3 with image
          gnuplot> set output "bad.png"
          gnuplot> set title "Record processing (explicit index) is bad"
          gnuplot> plot "imdump2.dat" binary record=(200,400) format="%double%double%double" using 1:2:3 with image
          gnuplot> set output "x.png"
          gnuplot> set title "X index is as expected"
          gnuplot> plot "imdump2.dat" binary array=(200,400) format="%double%double%double" using 1 with image
          gnuplot>
          Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gnuplot/bugs/1873/ https://sourceforge.net/p/gnuplot/bugs/1873/
          To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ https://sourceforge.net/auth/subscriptions/

           

          Related

          Bugs: #1873

  • Ethan Merritt

    Ethan Merritt - 2016-11-08
    • status: open --> pending-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks