bugGNU Octave - Bugs: bug #55999, Display images larger than...


bug #55999: Display images larger than GL_MAX_TEXTURE_SIZE

Submitted by:  Charles Praplan <charprap>
Submitted on:  Mon 25 Mar 2019 05:41:41 PM UTC  
Category:  Plotting with OpenGL Severity:  2 - Minor
Priority:  3 - Low Item Group:  Feature Request
Status:  None Assigned to:  None
Originator Name:  Charles Praplan Open/Closed:  Open
Release:  5.1.0 Operating System:  Microsoft Windows

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)

Sun 07 Apr 2019 10:48:20 AM UTC, comment #16:

Thank you for your help.

The first method you propose works correctly, also to save images (I tried png and jpg). The saved files correspond to the figure.

However to get a correct output, the size of the figure must be restored before printing, using

The reason why the size of the picture changed is illustrated by the 2 appended figures, obtained executing following code from an m-file (not step by step).
The difference between the 2 pictures is a small delay generated with pause(0).

Then, executing following code reduces the size of fig2.

I fully agree that this is outside the scope of this report.

Should I post a report for this delay problem?

(file #46732, file #46733)

Charles Praplan <charprap>
Sat 06 Apr 2019 08:16:04 PM UTC, comment #15:

@Charles:I think what you observe is expected.
By default, the figure size in printout is given by the figure's "paperposition" property. This means, prior to printing, Octave resizes the figure which does not do well with axes created this way ("subplot ("position", POS)").

You could try to change the default and obtain more or less the same as onscreen (but it won't fit in a "usletter" page)

or let the "activepositionproperty" of subplots be "outerposition"

or just leave more room for text when positioning axes manually. For annotation objects, the problem is the same.

Anyway, I think this is out of the scope of this report since the behavior you observe has nothing to do with displaying large images.

Pantxo Diribarne <pantxo>
Project Member
Sat 06 Apr 2019 07:33:09 AM UTC, comment #14:

Could you reproduce this?

Charles Praplan <charprap>
Fri 29 Mar 2019 05:47:54 PM UTC, comment #13:

You will find as attachment the code which generates the plots.

This m-file also saves the figure on 4 different ways with different quality of result.

The 4 generated files are also appended.

Saving the plot from the menu seems to correspond to methods 2 and 3 which seem to be equivalent.

We can see the following problems (not in all files)
- most left label is truncated
- annotations on bottom are overlapping
- title of fig 4 overlaps x axis of fig 2
- x axis of fig 2 and 4 are not easily lisible (police to large)
- text on the right is truncated

On the screen the figure looks good when resizing to original size with
set(gcf, 'Position', [x0 y0 w0 h0])

I guess that the annotation command reduces the size of the on scree figure.

(file #46663)

Charles Praplan <charprap>
Fri 29 Mar 2019 10:48:30 AM UTC, comment #12:

The fact that the image is exported correctly to vector formats is expected (gl2ps does not have the same limitations as your OpenGL driver). What I don't understand is that the title and axes are misplaced. Can you attach an SVG file that show this behavior together with the commands you used to produce and print the images?

Pantxo Diribarne <pantxo>
Project Member
Thu 28 Mar 2019 05:49:51 PM UTC, comment #11:

If the picture is a for example a spectrogram, the axes must be adapted too.
Using gnuplot, as Mike suggests, is simpler.

Some more infos :

In the case of the incomplete image, when saving it as pdf, the image in the pdf file is complete!

However, when saving the image (pdf or png ... ), the size and position of the titles, axes, axes labels etc. are not as expected, so that these texts overlap and the result is not usable.

Selecting gnuplot as graphic toolkit leads to correct exported images.

Charles Praplan <charprap>
Wed 27 Mar 2019 06:12:55 PM UTC, comment #10:

Should the warning, or the documentation, also talk about downsampling? For the example code,

the following is a workaround

Rik <rik5>
Project Administrator
Wed 27 Mar 2019 05:55:02 PM UTC, comment #9:

I was a little confused, so just posting to make it clear that the fix for bug #54680 only applies to Octave version 6.

In Octave 5, the plot will be attempted regardless of the limit, and will appear truncated, no warning message is printed.

In Octave 6, with the software driver, I can verify that a warning message is shown and the plot only generates an empty axes.

There are several workarounds available to users, including using an accelerated graphics driver, or using gnuplot instead of OpenGL to handle these types of plots.

Mike Miller <mtmiller>
Project Administrator
Tue 26 Mar 2019 05:00:27 PM UTC, comment #8:

Octave's Windows installer ships the software OpenGL renderer llvmpipe. We can't just "increase the limit of 8192 points". This is a property of that driver.

If you have a decent graphics card with current drivers, you can try to rename "C:\Octave\Octave-5.1.0\mingw64\bin\opengl32.dll" and test if your proprietary graphics card driver can do better.

Markus M├╝tzel <mmuetzel>
Project Member
Tue 26 Mar 2019 03:15:19 PM UTC, comment #7:

Already now with max 8192 points, some sub-sampling is implemented.

I would simply keep the same method.

I used the image command to plot large spectrograms. The result is good (similar to matlab) if I make abstraction of the white band on the right side of the figure.

I guess that the only required change is to increase the limit of 8192 points.

Charles Praplan <charprap>
Tue 26 Mar 2019 11:38:27 AM UTC, comment #6:

@Charles: Done, I updated the title accordingly. Now the question is wether basic sub-sampling is enough (display 1 pixel out of 2,3,..): I think this would be OK since even very large screens with high pixel density seldom have more than 8000 pixels width or height.

Pantxo Diribarne <pantxo>
Project Member
Tue 26 Mar 2019 08:25:36 AM UTC, comment #5:

Ok for me if you turn this report into a feature request!
Thank you!

Charles Praplan <charprap>
Mon 25 Mar 2019 07:51:12 PM UTC, comment #4:

@Mike: Just saw your post :-).

Pantxo Diribarne <pantxo>
Project Member
Mon 25 Mar 2019 07:49:26 PM UTC, comment #3:

I think this is a duplicate of bug bug #54680. Octave currently can't render images with either dimension larger than GL_MAX_TEXTURE_SIZE. This constant depends on the OpenGL driver in use.

We ended up closing the report after changing the behavior in case an image can't be rendered: now Octave won't render the image at all and a warning about this limitation will be displayed.

@Charles: Do you want to turn this report into a feature request about supporting larger images?

Pantxo Diribarne <pantxo>
Project Member
Mon 25 Mar 2019 07:17:07 PM UTC, comment #2:

I think this is the same as bug #54680.

I can reproduce on GNU/Linux with the LIBGL_ALWAYS_SOFTWARE environment variable set.

Mike Miller <mtmiller>
Project Administrator
Mon 25 Mar 2019 07:10:55 PM UTC, comment #1:

This works fine on Linux.

It may be something to do either with your particular hardware (if OpenGL rendering is being done through your video card) or with the software renderer if it is not being hardware accelerated. If it is the software renderer then the version that is shipped with Octave should be changed to allow support for large images.

Rik <rik5>
Project Administrator
Mon 25 Mar 2019 05:41:41 PM UTC, original submission:

When running following command :

image(repmat([ones(100,200), 100*ones(100,200)],1,25))

the image is not completely displayed. The columns at positions greater than 8192 (TBV) are not displayed (white band on the right).

Try moving the image horizontally with the mouse using the pan tool and see what happens. It is likely if the total number of points cannot exceed 8192.

This happens on windows 10, but also windows 7 and with octave 5.1.0 but also with 4.4.1.

Charles Praplan <charprap>


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

Attach Files:

Attached Files
file #46732:  Screenshot_fig2.png added by charprap (14KiB - image/png)
file #46733:  Screenshot_fig3.png added by charprap (17KiB - image/png)
file #46664:  file1.png added by charprap (131KiB - image/png)
file #46665:  file2.pdf added by charprap (711KiB - application/pdf)
file #46666:  file3.pdf added by charprap (711KiB - application/pdf)
file #46667:  file4.pdf added by charprap (711KiB - application/pdf)
file #46663:  testcase_for_plot_saving.m added by charprap (3KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by charprap (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 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-04-07 charprap Attached File- => Added Screenshot_fig2.png, #46732
        Attached File- => Added Screenshot_fig3.png, #46733
    2019-03-29 charprap Attached File- => Added file1.png, #46664
        Attached File- => Added file2.pdf, #46665
        Attached File- => Added file3.pdf, #46666
        Attached File- => Added file4.pdf, #46667
    2019-03-29 charprap Attached File- => Added testcase_for_plot_saving.m, #46663
    2019-03-26 mtmiller CategoryPlotting => Plotting with OpenGL
        Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 3 - Low
    2019-03-26 pantxo Item GroupIncorrect Result => Feature Request
        SummaryImage not completely displayed => Display images larger than GL_MAX_TEXTURE_SIZE
    2019-03-25 pantxo CategoryPlotting with OpenGL => Plotting
    2019-03-25 mtmiller CategoryPlotting => Plotting with OpenGL

    Back to the top

    Powered by Savane 3.4