In Octave 6.0.90, when calling the image fct with a too large image (using opengl32.dll), the warning is issued only for the first call.
This may be annoying. Is this desired?

@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)

set (gcf, "paperpositionmode", "auto")
print -dpdfcrop file5.pdf

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

hax = get (gcf, "children");
set (hax(isaxes (hax)), "activepositionproperty", "outerposition")
print file6.pdf

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.

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)

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.

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.

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.

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

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?

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.