bugGNU Octave - Bugs: bug #55632, display of image pixels and axis...


bug #55632: display of image pixels and axis limits

Submitted by:  Rik <rik5>
Submitted on:  Sun 03 Feb 2019 02:48:26 AM UTC  
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Wed 13 Feb 2019 05:21:25 PM UTC, comment #10: 

I corrected a run-away string (lacking a closing ") which was stopping compilation, and then checked in your cset here https://hg.savannah.gnu.org/hgweb/octave/rev/f034b29320ad.

This looks good, and now I'm in the midst of tidying up the on-screen display of markers.

Rik <rik5>
Project Administrator
Tue 12 Feb 2019 09:32:17 PM UTC, comment #9: 

@Rik: I attached an updated, documented, patch in which I fixed a few regressions caused by the previous one (including the garbage pixels after printing and corrupted uint16 images).

(file #46246)

Pantxo Diribarne <pantxo>
Project Member
Sat 09 Feb 2019 10:48:40 PM UTC, comment #8: 

@Rik: Yes, on-screen the manual clipping is not necessary anymore, but gl2ps still has this limitation (it doesn't handle textures and only emulates glDrawPixels). So I moved the complicated manual clipping code to gl2ps_renderer::draw_image.

The timings are the same for me too and I guess this is because the bottleneck is passing pixel data to the graphics card.

As for the ugly pixels when printing to pdf, I can confirm.
I'll look into this.

Pantxo Diribarne <pantxo>
Project Member
Fri 08 Feb 2019 10:19:41 PM UTC, comment #7: 

@Pantxo: I dumped all of the demos and compared them pre/post patch.  It doesn't seem that anything is drawn incorrectly.  Also, I ran 'make check' and all tests still pass.

If I understand the patch correctly, draw_image in gl-render.cc became much simpler, but draw_image in gl2ps-print.cc became much more complicated.

I would have thought using textures over gl2psDrawPixels would have been slower, but it seems not to be.  I tested with a 10MB image and display times as caluclated by

tic; imshow (img); toc

were the same.

Printing to a vector format like PDF leaves some weird pixels behind, but these are cleaned up if the image is resized which forces a re-paint.  It would be nice to clean that up at some point.

Sample code

demo image 1
print tst.pdf

Rik <rik5>
Project Administrator
Fri 08 Feb 2019 05:08:40 PM UTC, comment #6: 

The attached version of the patch now handles 1 pixel wide/high images.

(file #46217)

Pantxo Diribarne <pantxo>
Project Member
Fri 08 Feb 2019 05:01:40 PM UTC, comment #5: 

First regression with the patch: colorbar don't show.

Pantxo Diribarne <pantxo>
Project Member
Fri 08 Feb 2019 04:37:53 PM UTC, comment #4: 

I attached a preliminary patch that fixes the undrawn partial pixels issue on-screen (not when printing to verctor formats). Performance-wise I see no benefit but no drop down either: we would still need to cache image data. A side effect I had not foreseen is that it is possible to rotate images by changing the view, like in Matlab.

@Rik: When you find some time, can you test the patch and see if you can uncover a regression?

(file #46215)

Pantxo Diribarne <pantxo>
Project Member
Tue 05 Feb 2019 06:58:36 PM UTC, comment #3: 

I think this is a duplicate of bug #42435.  In any case, I'm going to leave this one open as another reminder to work on this.

Rik <rik5>
Project Administrator
Mon 04 Feb 2019 02:03:10 AM UTC, comment #2: 

Since images are primitive graphics objects in Matlab and Octave, it seems that we probably need to change the rendering code in gl-render.cc.  Maybe we can take some of the code from the implementation of surfaces with texturemaps and apply it to images, although that might be excessively complicated.  I haven't looked.

Here is the documentation about the xdata property for images in Matlab.

XData — Placement along x-axis
[1 size(CData,2)] (default) | two-element vector | scalar

Placement along the x-axis, specified in one of these forms:

    Two-element vector — Use the first element as the location for the center of CData(1,1) and the second element as the location for the center of CData(m,n), where [m,n] = size(CData). Evenly distribute the centers of the remaining CData elements between those two points.

    The width of each pixel is determined by the expression:


    If XData(1) > XData(2), then the image is flipped left-right.

    Scalar — Center CData(1,1) at this location and each following element one unit apart.

It is very clear that the property specifies the centers of the pixels and that the pixels extend to either side of the center.  So if I put a pixel at location 1, and then make the axis start at location 1, I really should have something drawn.

Here is slightly different code I used to test the extension of pixels in Matlab.

colormap (gray (64));
image (1:64, linspace (0, 1, 64), repmat ((1:64)', 1, 64));
axis ([-2, -2, -1, 2], "xy");

I've attached the result as pixel.png.  It shows that the pixel does extend to 0.5 as expected.

Rik <rik5>
Project Administrator
Sun 03 Feb 2019 09:24:50 PM UTC, comment #1: 

Yes, that doesn't look good. Using textures to project image pixels on would probably help overcome this limitation, as it would help supporting rotated text. See how using texture mapping (undocumented well hidden Octave feature :-)) on a surface object looks much better:

cdata = get (0, "defaultimagecdata");
h = surface ("xdata", linspace (0.5, 64.5, 3) , ...
             "ydata", linspace (-1/128, 1+1/128, 3)', "zdata", ones (3), ...
             "facecolor", "texturemap", "cdata", flipud (cdata), ...
             "edgecolor", "none");
axis ([1, 64, 0, 1], "xy");
## Zoom and look at the borders

Pantxo Diribarne <pantxo>
Project Member
Sun 03 Feb 2019 02:48:26 AM UTC, original submission:  

Octave "pixels" extend +/- 0.5 a grid point of their position.  This leads to oddities, where part of a pixel would be outside the axes and is clipped.  Matlab does not do this.

Sample code below is taken from the demo for brighten().

colormap (gray (64));
image (1:64, linspace (0, 1, 64), repmat ((1:64)', 1, 64));
axis ([1, 64, 0, 1], "xy");

This leaves a small white border around the image object which is not present when using gnuplot or Matlab.

This may be a deep issue that needs to be resolved in the OpenGL renderer.

Rik <rik5>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #46246:  im_texture_4.patch added by pantxo (25KiB - text/x-patch)
file #46217:  im_texture_2.patch added by pantxo (23KiB - text/x-patch)
file #46215:  im_texture.patch added by pantxo (23KiB - text/x-patch)
file #46174:  pixel.png added by rik5 (5KiB - image/png)
file #46169:  image.png added by rik5 (12KiB - image/png)


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-13 rik5 StatusPatch Reviewed => Fixed
        Open/ClosedOpen => Closed
    2019-02-12 pantxo Attached File- => Added im_texture_4.patch, #46246
    2019-02-08 rik5 StatusPatch Submitted => Patch Reviewed
    2019-02-08 pantxo Attached File- => Added im_texture_2.patch, #46217
    2019-02-08 pantxo Attached File- => Added im_texture.patch, #46215
        StatusDuplicate => Patch Submitted
    2019-02-05 rik5 StatusConfirmed => Duplicate
        Dependencies- => Depends on bugs #42435
    2019-02-04 rik5 Attached File- => Added pixel.png, #46174
    2019-02-03 pantxo StatusNone => Confirmed
    2019-02-03 rik5 Attached File- => Added image.png, #46169

    Back to the top

    Powered by Savane 3.5