bugGNU Octave - Bugs: bug #44415, OpenGL plotted image has vertical...

 
 

bug #44415: OpenGL plotted image has vertical line every 4096 pixels

Submitter:  Dan Sebald <sebald>
Submitted:  Tue 03 Mar 2015 08:22:07 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 31 Mar 2015 06:36:06 PM UTC, comment #23: 

This is an upstream bug then.  Closing report (although it will always be searchable).

Rik <rik5>
Group administrator
Tue 31 Mar 2015 05:26:08 PM UTC, comment #22: 

What follows is a summary of the Mesa/OpenGL driver issue, and with this we can close this bug and label it something appropriate.  Technically, I would call it fixed or maybe in-progress, but it's in the hands of Mesa developers:

I've been able to compile Mesa and work with the drivers a bit.  (For details on how to compile Mesa, send me an email.)  Exactly what driver everyone has is hard to say, but from the comments below I gather several of us (probably those with Nvidia hardware) end up with the swrast_dri.so driver--the fallback when there isn't an accelerated Mesa driver specific to the video card--and I point out that this is the legacy version of the driver, as there is now a new Mesa driver in the works under a project called Gallium which also takes the name of swrast_dri.so when it is compiled.

For reference, details are here:

https://bugs.freedesktop.org/show_bug.cgi?id=89586

The legacy swrast_dri.so driver is illustrated with some figures here:

https://bugs.freedesktop.org/attachment.cgi?id=114712

where one can see the vertical lines (positive scaling only) at the texture width GL_MAX_TEXTURE_SIZE intervals just as https://savannah.gnu.org/bugs/?44415#comment3 surmised.  A patched version of the driver corrects this and is illustrated here:

https://bugs.freedesktop.org/attachment.cgi?id=114713

I don't know what the roadmap is for Mesa, but my guess is that over the years Gallium swrast_dri.so will find more use in Linux distributions.  My assessment is that Gallium is an improvement, but not without problems just yet.  For example, that driver right now has a limit of GL_MAX_TEXTURE_SIZE for an image, as shown here:

https://bugs.freedesktop.org/attachment.cgi?id=114714

Dan Sebald <sebald>
Tue 17 Mar 2015 07:44:13 PM UTC, comment #21: 

There has been activity here to correct some things in the OpenGL drivers, so not stagnant.  I'll report back within a week.

Dan Sebald <sebald>
Thu 05 Mar 2015 09:56:20 AM UTC, comment #20: 

Yeah, I guess FLTK also has the problem.  The gl2ps extension routine creates a good EPS file with no lines in the image.  So, it would be on the rendering side of things.  I'll have a look this weekend, and post here again when I'm ready to cry uncle.

Dan Sebald <sebald>
Thu 05 Mar 2015 02:54:47 AM UTC, comment #19: 

Mike, Michael, and Rik all report the same thing--the white lines are present in both FLTK and Qt and can be made to appear/disappear by changing the window size.  I was only reacting to Dan's comment #15 in which he said that FLTK was working.

Rik <rik5>
Group administrator
Thu 05 Mar 2015 02:11:18 AM UTC, comment #18: 

I see exactly what Michael reports. I can resize the plot window and get white lines to appear and disappear at different points in the image depending on the plot size. The same holds for both FLTK and Qt.

Mike Miller <mtmiller>
Group Member
Thu 05 Mar 2015 02:00:50 AM UTC, comment #17: 

Rik:  Did you try resizing the plot?
I can turn the white lines on and off and move
them around by adjusting the plot size.

This as been the case ever since FLTK became
operational. So, it is not a regression.

4.0 blockers might usefully take precedence.
I would like to see this problem "fixed" as much
as anyone, but it will take a very long time and will
require testing with a large set of software
versions and graphics drivers and graphics hardware.
Do active developers have enough equipment and
configuration choices to do this?


Michael Godfrey <godfrey>
Group Member
Thu 05 Mar 2015 01:49:40 AM UTC, comment #16: 

FLTK doesn't work for me, it shows the same white vertical lines.  I think this is basic to OpenGL rather than how we are calling it from FLTK or from Qt.

Rik <rik5>
Group administrator
Wed 04 Mar 2015 09:56:30 PM UTC, comment #15: 

Don't close this report.  FLTK appears to work fine and is an interface to OpenGL so I would assume there is something that can be done.  It's just that it might be more work than we hope, i.e., not something so trivial as just changing GL_THIS_OPTION to GL_THAT_OPTION.

Images of size greater than 4096 are definitely not something out of the norm, so this seems fairly important.  Right now there are enough bugs in Qt/FLTK to put V4.0 off a while.  There's no hurry to close this one.

Dan Sebald <sebald>
Wed 04 Mar 2015 05:39:58 PM UTC, comment #14: 

Rik: Right, there appears to be nothing to be done. But,
it also appears that the various "problems" reported
here are due to some of the many anomalies in various parts
of current graphics software and hardware. The chance that
there will ever be a time such that graphics works consistently
across platforms is extremely small. We have learned to live with
this since the beginning of computer graphics.

So, as is said: this is a feature, not a bug.

Best to close the report.

Michael Godfrey <godfrey>
Group Member
Wed 04 Mar 2015 04:38:34 PM UTC, comment #13: 

So is there nothing much to be done here?  It sounds like this is a limitation of OpenGL that one just accepts.

I applied the patch to correctly calculate the height of 'th' here (http://hg.savannah.gnu.org/hgweb/octave/rev/2eed41ae3b64).

Rik <rik5>
Group administrator
Wed 04 Mar 2015 06:33:33 AM UTC, comment #12: 

What am I thinking?  That tessellation bug was in a PDF file, not on-screen.

I can't find many settings for glDrawPixels() that would control this.  The whole image data is being sent to OpenGL at once.  If it is a hardware bug, perhaps calling glDrawPixels() with MAX_TEXTURE_SIZE x MAX_TEXTURE_SIZE hunks works, but I'd sort of like to confirm that's the issue before going down that path.

Dan Sebald <sebald>
Wed 04 Mar 2015 03:40:37 AM UTC, comment #11: 

I'm starting to feel this bug and the tessellation bug are related.  The answer to this person's question illustrates what is likely the issue:

http://stackoverflow.com/questions/19611745/opengl-black-lines-in-between-tiles?answertab=active#tab-top

In order for OpenGL to generate a pixel value to display on the screen it has to get that value from what lies in the vicinity of the pixel translated to the underlying image.  The underlying image and the display can have different dimensions (i.e., scaling).  To do this OpenGL will do some kind of filtering which averages surrounding pixels.  In the case of a edge, there is a good chance OpenGL will use some substitute value--maybe 0xffffff or, hopefully not, some bogus value pulled from memory--as part of the average.  My guess is that texture size limits an image section to 4096x4096 pixels.  At edges of those regions is where the pixel mathematics doesn't work out so nicely.

Why is the line only on the east edge of the region?  I don't know; maybe it's just at that point the interpolation math works out strange.

The link above talks about supplying pixels around the borders (how that is done when there is a MAX_TEXTURE_SIZE, I don't know), or perhaps changing the type of filtering used to generate the on-screen pixels.  I'll investigate this line of thought a bit.

Dan Sebald <sebald>
Wed 04 Mar 2015 12:37:51 AM UTC, comment #10: 

Hmm, I wonder if this vertical line bug is the same as this tesselation line bug:

https://savannah.gnu.org/bugs/?44181

If OpenGL is programmed for a maximum texture size is 4096 (8192) and that corresponds to the largest patch it can do, a large image will be broken into a number of subregions.  If a bogus tesselation line in done on one side of that region, could it produce what looks like lines running through the image?

Dan Sebald <sebald>
Wed 04 Mar 2015 12:29:31 AM UTC, comment #9: 

I believe I found one innocuous (so far) bug related to the computation for next power of two for the height in the texture routine.  See the attached diff file.  However, it doesn't fix this issue.  Maybe nothing with textures is being done in the sample I gave.


(file #33240)

Dan Sebald <sebald>
Tue 03 Mar 2015 11:48:14 PM UTC, comment #8: 

After patching file:


>> N = 30000;
>> grd = repmat((1:N)/N, 20, 1);
>> image(32*grd);
GL_MAX_TEXTURE_SIZE: 4096
GL_MAX_TEXTURE_SIZE: 4096
GL_MAX_TEXTURE_SIZE: 4096
>> GL_MAX_TEXTURE_SIZE: 4096
GL_MAX_TEXTURE_SIZE: 4096


Dan Sebald <sebald>
Tue 03 Mar 2015 10:31:44 PM UTC, comment #7: 

@Dan: Apply the attached patch and rebuild Octave.  This will print out the texture size whenever a new OpenGL context is created.

On my machine, the texture size is 8192 which corresponds to the width between lines.



(file #33238)

Rik <rik5>
Group administrator
Tue 03 Mar 2015 10:05:29 PM UTC, comment #6: 

I'm not sure what my settings are:


[@ ~]$ glxinfo | grep TEXTURE_SIZE
[@ ~]$


Maybe the default is 4096, not sure.

Dan Sebald <sebald>
Tue 03 Mar 2015 09:50:07 PM UTC, comment #5: 

I tried this on an Intel graphics system. In this case the vertical (white) lines are a function of the
size of the plot. Growing or shrinking the plot causes the lines to move or disappear.
This is a long-standing feature of Intel graphics (mine is HD Graphics 5000).

Michael

Michael Godfrey <godfrey>
Group Member
Tue 03 Mar 2015 09:48:16 PM UTC, comment #4: 

The lines are white.  The 'gnuplot' toolkit doesn't show any data issues.  I tried printing using the gl2ps route but the postscript plot results in an error, although the Ascii code looks reasonable good.  However, I've noticed a bug with images and printing

https://savannah.gnu.org/bugs/index.php?44418

For what it's worth, I searched the file with the 20x30000 image and saw no ffffff which might correspond to a white line and found none.

Dan Sebald <sebald>
Tue 03 Mar 2015 09:16:01 PM UTC, comment #3: 

Can you check if this is related to Bug #43873

Is GL_MAX_TEXTURE_SIZE=8192 on Riks and 4096 on Daniels system?

Andreas Weber <andy1978>
Group Member
Tue 03 Mar 2015 09:09:56 PM UTC, comment #2: 

What color is the plotted line?  Mine is white and occurs ever 8,192 pixels.  By changing the size of the window I can get the white bars to disappear and reappear.  So it definitely seems like a rendering issue with OpenGL.  Still, it doesn't mean we aren't doing something incorrect in our calls.

Rik <rik5>
Group administrator
Tue 03 Mar 2015 08:30:44 PM UTC, comment #1: 

Oh, version number.  I'm learning here the various OpenGL utilities for Linux/Fedora, but I believe the critical utility for OpenGL is

mesa-dri-drivers : 7.9-5
mesa-libGL : 7.9-5

Dan Sebald <sebald>
Tue 03 Mar 2015 08:22:07 PM UTC, original submission:  

I'm seeing for both FLTK and Qt graphics toolkits vertical lines in an image plot every 4096 pixels.  See the attached image for the result after running the commands


N = 30000;
grd = repmat((1:N)/N, 20, 1);
image(32*grd);


My guess is that this might be an OpenGL bug, but I just want to confirm.  So could someone please try the above lines and let me know if the same thing is happening for others.

Why OpenGL?  Well, the data isn't an issue as the pixels seem all in their proper locations.  If one changes the size of the window, the underlying image is affected but the white lines aren't.  If those lines were in the data, the lines would alias (i.e., sometimes be nonvisible), but they are always present.  It seems to me the only way it could be an Octave bug is if the Octave isn't setting up OpenGL correctly somehow.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33240:  octave-texture_height-djs2015mar03.patch added by sebald (795B - application/octet-stream)
file #33238:  max_texture_size.diff added by rik5 (532B - application/x-download)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-31 rik5 StatusConfirmed Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2015-03-04 sebald Attached File- Added octave-texture_height-djs2015mar03.patch, #33240
    2015-03-03 rik5 Attached File- Added max_texture_size.diff, #33238
    2015-03-03 rik5 StatusNone Confirmed
    2015-03-03 sebald Attached File- Added Screenshot-Figure 1-1.png, #33236

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code