bugGNU Octave - Bugs: bug #53073, OpenGL color LUT seems incorrect...

 
 

bug #53073: OpenGL color LUT seems incorrect after a print() for the Qt graphics toolkit

Submitter:  Dan Sebald <sebald>
Submitted:  Tue 06 Feb 2018 01:07:53 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed 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

Sun 03 Mar 2019 07:26:04 AM UTC, comment #15: 

Marking as fixed and closing report.

Rik <rik5>
Group administrator
Sun 03 Mar 2019 06:42:27 AM UTC, comment #14: 

I don't see the color-change effect anymore.  I verified that 'graphicssmoothing' is on.  Looks like we are getting a lot of freebie fixes due to resolving other bugs.

Dan Sebald <sebald>
Sun 03 Mar 2019 05:10:32 AM UTC, comment #13: 

@Dan: Could you re-verify?  This works for me now using the dev branch and 5.1.0.

Rik <rik5>
Group administrator
Wed 07 Feb 2018 07:50:52 PM UTC, comment #12: 

I too noticed the FLTK toolkit doesn't exhibit this problem.  It does do a redraw of the whole framework window (and presumably the plot as well) but I don't see any sort of momentary change in the interior plot area appearance.

Then again, FLTK isn't quite the same setup as the Qt setup, is it?  I think the Qt toolkit might be essentially no more than switching the OpenGL context from nVidia driver to gl2ps driver, whereas FLTK's graphics engine might be more indirect in the sense that there are drawing routines that then call opengl routines.

I'm not 100% sure, and I really don't want to dig that far into graphics, so the extra "drawnow()" route is fine, but in a way that avoids an additional drawnow() for FLTK or gnuplot toolkits because those two already seem to redraw after the print for one reason or another.

Dan Sebald <sebald>
Tue 06 Feb 2018 11:52:39 PM UTC, comment #11: 

The very simplest fix is probably to put in a drawnow() or some such call after the print has completed.  That would quickly resolve what we are seeing.  It wouldn't be much of a performance hit since print isn't exactly a critical function like matrix multiply.

Still, the FLTK toolkit mananges not to have this issue so it should be possible to prevent the Qt toolkit from exhibiting this as well.

Rik <rik5>
Group administrator
Tue 06 Feb 2018 06:49:41 PM UTC, comment #10: 

Hey, nice find.  What you described makes sense.  The off-screen printing to file may not have filtering applied, except as a secondary operation as part of its definition.

BTW, turning off graphicssmoothing makes the marker problem

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

even more obvious.

Dan Sebald <sebald>
Tue 06 Feb 2018 06:35:28 PM UTC, comment #9: 

The issue is not present if anti-aliasing is disabled.  This works:


plot (1, 'o-', 'linewidth', 4)
set (gcf, 'graphicssmoothing', 'off')
print test.pdf


It may be due to another change where one of two graphics backplanes is changed in color value only during printing.  Presumably after printing it may revert back to its value of black and possibly be mixed in through the anti-aliasing mechanism.

Rik <rik5>
Group administrator
Tue 06 Feb 2018 06:33:22 PM UTC, comment #8: 

Comment #6
I'm not sure that changeset introduced the bug per se, more that it took away the action that was covering it up.  The drawing at the PaperPosition size and then redrawing back to the Position size probably effectively did a refresh().  For the rolled-back version, is there a momentary color shift when doing a "print test.pdf"?  The equivalent solution would be to apply a "refresh()".

It's not the worst thing that the figure would momentary shift or flash (sort of like modern digital cameras that introduce a fake SLR shutter sound, ha-ha), but the effect shouldn't hang around.  Do you think somewhere in the Qt toolkit code someone might have introduced this slight shift effect intentionally?

Dan Sebald <sebald>
Tue 06 Feb 2018 06:18:27 PM UTC, comment #7: 

The patch example doesn't change color.  It seems to only be the lines that are affected, which I find strange.  I loaded a color picker, but I don't think it is much help because filtering is applied to those lines on screen and there isn't one set RGB value for which I can position the cursor and say "the color went from RGB1 to RGB2".

Yes, refresh() corrects the colors.  Position the mouse over the plot does it as well, but the mouse has to go within the plot boundaries.  Positioning the mouse outside the borders and on top of axis annotation isn't enough.  Maybe it is because of some interactive behavior between acquiring axis location based upon cursor position.

You're right, the border lines and axis notation also become darker.  Seeing as those are supposed to be black, it wouldn't be that the color is changing.  It must be that some extra black pixels are being drawn (which of course causes a perceived color shift for anything non-black).  Or maybe the low-level filtering is wrong during that time.

Dan Sebald <sebald>
Tue 06 Feb 2018 06:12:50 PM UTC, comment #6: 

Using hg bisect, the cset that introduced this issue was


parent: 24687:8b935067a257
 Allow printing without updating qt visible or invisible figures (bug #52940).
branch: default



Rik <rik5>
Group administrator
Tue 06 Feb 2018 05:54:40 PM UTC, comment #5: 

Also confirmed that just about any action, for me pressing the 'Alt' key, was enough to cause a re-paint.

Rik <rik5>
Group administrator
Tue 06 Feb 2018 05:53:52 PM UTC, comment #4: 

Confirmed.  Apparently when printing a few black pixels get mixed in which causes the overall color to appear darker.

As a test I used


plot (1, 'o-', 'linewidth', 4)


I used a screen magnifier to zoom in on the Qt window and then used a screenshot tool to capture the magnified window.  Attached are the pre- and post-print pictures.



Rik <rik5>
Group administrator
Tue 06 Feb 2018 05:41:41 PM UTC, comment #3: 

LUT means "look-up-table".  It's analogous to the colormap() of Octave but it's at the graphics hardware level.  The graphics memory is passed through a LUT to generate the signal levels to display on the color monitor.  Type "graphics LUT" in an Internet search engine and a lot of graphics card info will turn up.  Back in the early days of linux and computer OS's, there would be all sorts of strange color issues when, say, one window would go out of focus--having to do with immature drivers, limited graphics memory, etc.  My point is that the reported bug isn't something to do with Octave figure redrawing, it has to do with some low-level setup of OpenGL...as though the on-screen OpenGL is acquiring the off-screen's LUT until that memory area associated with the plot window is refreshed.

Dan Sebald <sebald>
Tue 06 Feb 2018 05:31:02 PM UTC, comment #2: 

LUT usually stands for Look Up Table.

@Dan: Could you create at even clearer example.  This might work.


close all
graphics_toolkit qt
hp = patch ('facecolor', 'm');
# Record screen capture of just Qt plot window
print test.pdf
# Record screen capture of just Qt plot window


We should be able to use a color picker to get the exact RGB values and see what sort of difference there is.

Also, does something like refresh() work to change the color back?  Or is it only a command or movement (such as window resizing) that causes the correct color to return?

If you use software rendering rather than Nvidia, do you still see the same result?

Rik <rik5>
Group administrator
Tue 06 Feb 2018 11:26:37 AM UTC, comment #1: 

@Dan: What is a LUT?

Anyway, there is no such thing like a "context switch". gl2ps uses whatever opengl context is current (here the one provided by the QOpengGLWidget). It momentarily switches the glRenderMode to GL_FEEDBACK, in order to record the primitives that are drawn in a buffer instead of drawing onscreen.

Pantxo Diribarne <pantxo>
Group Member
Tue 06 Feb 2018 01:07:53 AM UTC, original submission:  

With the Qt toolkit, after a print there is a shift in the color of a visible plot that remains present until positioning the mouse or something else over the figure window that causes a refresh of the graphics memory.  Note that it doesn't have to be something that causes a redraw of the figure, just a refresh of the memory.  I suspect that the LUT (or something similar) for the graphics memory color map is somehow altered with the context switch from the graphics driver device to the gl2ps print-driver device.  This does not happen for FLTK.

Attached are two screenshots of


graphics_toolkit qt
plot(1:50, "-o")
print test.pdf


prior to the print() and after the print (without positioning the mouse over a figure header button, activating the figure, etc.).

I would guess that something needs to be done after the print to refresh the video memory buffer, e.g., some openGl command to reactivate the current context.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2018-02-06 rik5 Attached File- Added Blue_dot.preprint.png, #43193
        Attached File- Added Blue_dot.postprint.png, #43194
        StatusNone Confirmed
    2018-02-06 sebald Attached File- Added pre-print-Screenshot_from_2018-02-05_18-56-47.png, #43188
        Attached File- Added post-print-Screenshot_from_2018-02-05_18-58-18.png, #43189

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code