bugGNU Octave - Bugs: bug #44861, Image display in a 3D view

 
 

bug #44861: Image display in a 3D view

Submitted by:  Guillaume <gyom>
Submitted on:  Fri 17 Apr 2015 10:58:41 AM UTC  
 
Category:  Plotting Severity:  2 - Minor
Priority:  3 - Low Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Guillaume Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

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)

Fri 15 Feb 2019 09:01:13 AM UTC, comment #8: 

This has been fixed on the development branch.

Closing report.

Pantxo Diribarne <pantxo>
Project Member
Wed 06 Dec 2017 04:09:36 PM UTC, comment #7: 

I'd forgotten all about this bug report.

Your solution seems to work very well in OpenGL.  The response time isn't too bad.  Translating that internally for image routines might take some work though.

One peculiar behavior is rotating with the mouse.  For FLTK and Qt, if I point the cursor in the positive z space and click then rotate the image seems to rotate in one direction.  If I point the cursor in the negative z space and click then the image seems to rotate in the opposite direction.

Dan Sebald <sebald>
Wed 06 Dec 2017 02:19:48 PM UTC, comment #6: 

A partial workaround to be able to display images in 3D is to use surfaces:

load penny
[nx, ny] = size (P);
surface (1:nx, 1:ny, zeros (nx, ny), "cdata", P,
         "facecolor", "texturemap", "edgecolor", "none")
view (3)

There are important limitations though:

  • rgb images are not handled (only indexed or scaled images)
  • gl2ps does not handle textures so the figure is not printable.
Pantxo Diribarne <pantxo>
Project Member
Sun 10 May 2015 05:41:50 PM UTC, comment #5: 

We've added capability for images to hide lines to gnuplot.  That should make the this feature look a tad better in the gnuplot graphics toolkit.

Dan Sebald <sebald>
Wed 22 Apr 2015 08:25:09 AM UTC, comment #4: 

Attached is a changeset that is a step in the direction of the described behavior for the gnuplot toolkit.  Here are some commands to test its operation:

graphics_toolkit ('gnuplot');
figure;
imgrad = repmat([0:31], 32, 1) + repmat([0:31]', 1, 32);
hi = imagesc(imgrad);

view(3);

get(hi, 'zdatamode')
get(hi, 'zdata')
set(hi, 'zdata', 20);
get(hi, 'zdatamode')
get(hi, 'zdata')

set(hi, 'zdatamode', 'auto');
get(hi, 'zdatamode')
get(hi, 'zdata')

set(hi, 'zdata', [])

I'm not so keen on the idea of the data determining the type of plot, i.e., 2D or 3D, at such a low level as the data itself.  That is, in graphics.cc is a function calc_dimensions (_calc_dimensions_) which does the following:

  else if ((go.isa ("line") || go.isa ("patch") || go.isa ("image"))
           && ! go.get ("zdata").is_empty ())
    nd = 3;

Then in the script file _go_draw_axes_.m is the following test:

  nd = __calc_dimensions__ (h);
[snip]
    if (nd == 2)
      plot_cmd = "plot";
    else
      plot_cmd = "splot";

The reason that is problematic is that "view(2)" and "view(3)" aren't really what is controlling the plot type when it seems they should be.  If one changes the "zdata" of an image, it affects the plot view if zdata = [].  (But I have forced zdata to be 0 when in "auto" mode, so one has to take the image out of "auto" mode and then set the value to [].)  That seems odd to me.  If someone can think of something more straightforward, we could change that.

It all depends upon how one views things, I guess, i.e., whether a 2D plot is a different animal than a 3D plot.  In some sense it is nice to have 2D plot just be an orthographic view of a 3D plot, i.e., viewing so that one of the axes is perpendicular to the view.  On the other hand, a 2D plot offers more control over 3D for key placement, axes labels, etc.

I added a function in graphics.in.h,

    void update_zdatamode (void)
    {
      update_zdata ();
    }

but that doesn't get called.  I wanted the zdata to go back to the auto data default when set(hi, 'zdatamode', 'auto').

Modifying graphics.in.h touches so many files in the project, thereby mods take a long time to recompile.

(file #33737)

Dan Sebald <sebald>
Fri 17 Apr 2015 04:25:19 PM UTC, comment #3: 

Lowering the severity and the priority of this bug since there is the obvious workaround of not using a 2D image in 3D.

I don't particularly care whether we display the image or not.  If we display it, I find that adding zlim ([-1, 1]) makes the plot look a bit nicer.  Still not quite as nice as that from Matlab, but

Rik <rik5>
Project Administrator
Fri 17 Apr 2015 12:18:16 PM UTC, comment #2: 

You are right it didn't use to be the case for images with older versions of MATLAB but it is different now (see attached screenshot with R2015a).
From what I can see, texts are displayed in 3D mode, even with old MATLAB versions (this seems to be OK in Octave).
SO, I guess the decision is either not to display images when in 3D mode, or reproduce something like that last screenshot.


Guillaume <gyom>
Fri 17 Apr 2015 11:54:45 AM UTC, comment #1: 

Hi,

Images (like texts) are 2d objects, which are not supposed to be rotated with the axes.
I tried your example in Matlab 2013a (on a remote unix server, may be relevant) and images are simply not drawn at all when not in 2D mode. Maybe we should do the same?

Pantxo Diribarne <pantxo>
Project Member
Fri 17 Apr 2015 10:58:41 AM UTC, original submission:  

When displayed in 3D, an image does not appear as expected (see attached PNG screenshot):

figure
imagesc(rand(32))
view(3)

Furthermore, when the figure is saved as a PDF file, there is also a discrepancy with the way it appears on screen (see second attachment).

Guillaume <gyom>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33737:  octave-image_in_3d-djs2015apr22.patch added by sebald (6KiB - application/octet-stream)
file #33701:  image_display_3D.png added by gyom (15KiB - image/png)
file #33702:  image_display_3D.pdf added by gyom (6KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sebald (Updated the item)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by gyom (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-15 pantxo StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2017-12-06 pantxo StatusNone => Confirmed
    2015-04-22 rik5 Carbon-CopyRemoved 72865 => -
    2015-04-22 sebald Attached File- => Added octave-image_in_3d-djs2015apr22.patch, #33737
    2015-04-17 rik5 Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 3 - Low
        Item GroupIncorrect Result => Matlab Compatibility
    2015-04-17 gyom Attached File- => Added image_display_3D_MATLAB.png, #33703
    2015-04-17 pantxo CategoryPlotting with OpenGL => Plotting
    2015-04-17 gyom Attached File- => Added image_display_3D.png, #33701
        Attached File- => Added image_display_3D.pdf, #33702

    Back to the top


    Powered by Savane 3.5