I had tried the following demo code in Matlab. I'm using Matlab 2018b
load('spiralVol.mat');
h = volshow(spiralVol);
But I'm getting a black screen.imshow() is working properly. Is it related to opengl? i tried opengl software and opengl hardware
Is it a bug in matlab 2018b? or is it related to my system configuration
The black screen is sometimes an issue due to bad graphics driver. Try updating the driver to its latest version.
Alternately, Image Processing Toolbox has a 'VolumeViewerUseHardware' preference setting which tells it not to use the graphics card while rendering. Try setting it to false and see if it resolves the issue:
iptsetpref
Related
I'm having an issue with my GigE camera whenever I'm doing image acquisition with MATLAB IMAQ. It is clearly connected as indicated by the gigecamlist and gigecam function calls, but the issue is I'm always having black images or you can say no image at all. I figured it might be an issue of the frame size.Also, my network adapter doesn't provide the option of choosing jumbo frames, so I'm not sure what I can do about it now. The camera model under question is JAI Pulnix 1405-GE and I'm using MATLAB 2014b.
If any of you have any clue about what the problem might be, please share it with me. If you can give me some clue about what I can do solve this issue, it will be much appreciated.
Thank you
Did you try the JAI SDK software to see if the camera works properly?
Once you are sure about it working, copy the parameters shown in JAI SDK to your Matlab camera object.
On a side note, GigE cameras work better with Labview.
I wonder why I have a very bad rendering when I use the Painters custom renderer in figure Export Setup?
Look at this image which has used OpenGL:
and this one, which has used Painters.
What the hell is going on here?
There's a bug in 2014b-2015a. The easiest way to fix this is to upgrade to 2015b or newer.
I had a workaround where I used matlab2tikz but that took a bit of work for my application.
I don't believe there to be a workaround that can create .png files from Matlab that works on those versions of Matlab (even export_fig has the same problem).
I have a question on the Raspberry Pi cam. I am using openCV on a raspberry Pi 2 to make a line-follower for a robot.
Basically the idea is to find the direction of a line in the image using derivatives and color segmentation.
However, I'm found some strange behaviour when I compare the results on an ordinary PC webcamera and the picam. The algorithm works well on the PC webcam, and the direction indicator sits spot on the line. On the picam there is a strange scale and offset which I don't understand.
On both platforms I have tried both the cap.set(CV_CAP_PROP_FRAME_WIDTH/HEIGHT) to rescale the image, as well as the resize function. Both of them still produce the strange offset. I use the circle(...) and line(...) methods in openCV to overlay the line and circles on the captured image.
Could anyone help to explain this behaviour? See the links below for a visual caption.
picam
webcam
Regards
I couldn't add the pictures directly because of the policies of Stackexchange, so had to provide links instead.
I eventually discovered the solution to the problem, and it involved changing the order of the taps of a derivative filter for the Windows and Linux versions of the program. Exactely why this is the case is a mystery to me, and may involve differences in compiler optimization (Visual Studio 13 vs g++ 4.6.3), or maybe a silly error on my part.
On the the PC I use {1 0 -1} filter taps, on the RP2 I have to use {-1 0 1} instead.
The filter runs on a S8 (-127..127) image, so there is no issue of a wraparound.
At any rate, I consider the issue closed.
Context
Using the GUI Layout toolbox I have created an interface which basically is divided in two parts:
A toolbar area where the user selects the way he want to see data
A preview area to display data upon selected mode in the toolbar
For the preview area I used a uietxras.CardPanel object to switch between the view modes.
Problem
After some investigations, I discovered that if I display things in 3D (or 2D) in one of the preview card using surf (or pcolor) then it alters the display in the second card. If I display data in 1D only using plot commands I have not issue!
The issue I have when using pcolor/surf in one of the preview card:
Titles and labels seem to overlay in Preview 1
Axis borders are not displayed correctly in preview 2
Legend borders (when displayed) are altered also
If I only use plot commands in both preview modes I have no issue at all and cards are switching nicely.
Test case
My real code is really long, I have thus reduced it to the minimum so you can reproduce the issue:
https://gist.github.com/CitizenInsane/54f3c1eba2293d0e5264#file-guilayoutbug-m
Simply run the code and check the checkbox "Do 3D plot in preview 1" to see the issue happening when switching between the two preview modes:
Notes
As far I know, I'm using latest version of the GUI Layout toolbox (1.17).
I'm using R2013b for Matlab
I came across this issue as well. I'm afraid I never quite worked out what the cause was exactly, and it didn't appear in a very consistent way. The issue seems to be that plots on non-selected cards are not hidden properly, and get overlaid just behind and around the edges of the plots on the selected card.
I would encourage you to raise the issue with the authors of GUI Layout Toolbox via the comments on the toolbox's page at MATLAB Central, as I do think it's a bug.
Nevertheless, the reason I never followed it up myself is that I found a fairly straightforward workaround, which may also work for you. Each time the selected card is changed, I ran a simple function that deleted all children of all cards, and then re-plotted whatever I wanted on the selected card. It seemed a bit annoying to have to do that, but it worked, and removed any of the display issues you've come across.
Ok got it, the issue has nothing to do with CardPanel themselves, it is linked to the renderer of the figure.
Trying simple code below:
figure(42);
subplot(1,2,1);
plot(rand(1,12));
subplot(1,2,2);
peaks;
shading flat;
If the figure's renderer is set to 'OpenGL' (the default) ==> there are some glitches:
If the figure's renderer is set to 'zbuffer' ==> there is no glitch:
Setting the renderer to 'zbuffer' fixes the problem.
NB: Maybe OpenGL rendering can be fixed by fine tuning graphic card acceleration settings, but I don't know ... I issued opengl software and opengl hardware commands in Matlab and software rendering is worst than hardware rendering on my machine.
EDIT: Side notes
Transparency effects are only available if the renderer is set to 'openGL'. It is thus not possible to visualize at the same time both 1D and transparent-3D data without glitches (at least with hg version 1 in R2013b).
HG2 has no issue:
I wrote some code at home to plot some 3D-data. It worked fine. Now I ran the same code at the office and I got some weird bug. It seems that there is a label for each data point inserted.
But this only happens on half of the plots. The left plot shows the real data and the right one is just a smoothed fit of this data. The left one gets the error and the right one doesn't.
I ran the code on the machine of a colleague and it worked fine too. So I saved the clean figure files on his machine and tried to open them on my PC. Still the same bug. So it's not the code but seems to be some weird displaying bug.
Did anyone see this before?
figure(1);
s1=gca;
surf(t_matrix,f_matrix,alpha_matrix)
colorbar
figure(2);
s2=gca;
surf(t_matrix2,f_matrix2,alpha_matrix2)
colorbar
It's just this code. And if I debug, the numbers appear after the first call to colorbar. But not in the second case. My Matlab version at home is 2013a, but at the office and that from my colleague are both 2012b.
This seems to be a bug. There is a thread on MATLAB Answers.
The accepted answer there by Jan Simon is
This could be cause by the OpenGL driver. Did you install the newest
drivers of your graphics cards?
Workaround might be:
set(gcf, 'renderer', 'zbuffer');
or if OpenGL looks nicer:
opengl software
or perhaps:
opengl hardware
Look for "OpenGL" in the documentation to find a bunch of switches to
consider a bunch of driver bugs.
Actually the zbuffer renderer works fine but is not enough in some cases.
I often use to work with transparent surface plot using the gca property facealpha set to 0.5 in order to superpose a contour plot to it. Face or edge alpha settings (maybe some other plot properties) are only correctly displayed with the Opengl renderer. The zbuffer cannot picture transparent surface plot.
The main issue first came to my attention when I recently switched to Win8. Bloody $Bill 'HamsterWhy' Gate.
A patch from Mathworks would be greatly appreciated.