I am trying to save an ellipsoid drawn using Octave. Unfortunately, the figure window hangs upon trying to save the figure. Following is the code:
AR = 2.5;
nseg = 200;
[X, Y, Z] = ellipsoid(0,0,0,AR/2,0.5,0.5, nseg);
hf = figure();
shading interp;
surf(X,Y,Z, 'edgecolor','none','facecolor',[.8 .8 .8]);
axis equal;
%plotcube([AR 1 1],[-AR/2 -0.5 -0.5],.8,[1 0 0]);
light('Position', [1 1 1]);
view([1, 1., 1]);
set(gca,'visible','off');
print (hf, "figure1.eps")
I tried different graphics_toolkit options such as qt, fltk, and gnuplot. The gnuplot option does not render properly since I believe it supports only 2D objects. However, the qt and fltk renders the object properly but I could not save the figure.
Related
% create GMM
mu = [0; 5];
sigma = cat(3, 1, 2);
p = [0.5; 0.5];
gmm = gmdistribution(mu, sigma, p);
% view PDF
ezplot(#(x) pdf(gmm,x));
I'm trying to run this small tutorial code since i'm new to octave
but everytime I run this code it gives me error
error: gmdistribution.pdf: X has 500 columns instead of 1
what does this error mean?
How do I fix it?
The error is effectively telling you that you passed a horizontal vector to the gmmdistribution.pdf function, instead of a vertical one, which is what it expects.
This is because ezplot internally generates a horizontal vector of 500 points on the x-axis to plot your graph.
Therefore you can 'transpose' x when you use it in your anonymous function to, get it in the right orientation:
ezplot(#(x) pdf(gmm,x.'));
Let's say your Starling display-list is as follows:
Stage
|___MainApp
|______Canvas (filter's target)
Then, you decide your MainApp should be rotated 90 degrees and offset a bit:
mainApp.rotation = Math.PI * 0.5;
mainApp.x = stage.stageWidth;
But all of a sudden, the filter keeps on applying itself to the target (canvas) in the angle it was originally (as if the MainApp was still at 0 degrees).
(notice in the GIF how the Blur's strong horizontal value continues to only apply horizontally although the parent object turned 90 degrees).
What would need to be changed to apply the filter to the target object before it gets it's parents transform? That way (I'm assuming) the filter's result would get transformed by the parent objects.
Any guess as to how this could be done?
https://github.com/bigp/StarlingShaderIssue
(PS: the filter I'm actually using is custom-made, but this BlurFilter example shows the same issue I'm having with the custom one. If there's any patching-up to do in the shader code, at least it wouldn't necessarily have to be done on the built-in BlurFilter specifically).
I solved this myself with numerous trial and error attempts over the course of several hours.
Since I only needed the shader to run in either at 0 or 90 degrees (not actually tweened like the gif demo shown in the question), I created a shader with two specialized sets of AGAL instructions.
Without going in too much details, the rotated version basically requires a few extra instructions to flip the x and y fields in the vertex and fragment shader (either by moving them with mov or directly calculating the mul or div result into the x or y field).
For example, compare the 0 deg vertex shader...
_vertexShader = [
"m44 op, va0, vc0", // 4x4 matrix transform to output space
"mov posOriginal, va1", // pass texture positions to fragment program
"mul posScaled, va1, viewportScale", // pass displacement positions (scaled)
].join("\n");
... with the 90 deg vertex shader:
_vertexShader = [
"m44 op, va0, vc0", // 4x4 matrix transform to output space
"mov posOriginal, va1", // pass texture positions to fragment program
//Calculate the rotated vertex "displacement" UVs
"mov temp1, va1",
"mov temp2, va1",
"mul temp2.y, temp1.x, viewportScale.y", //Flip X to Y, and scale with viewport Y
"mul temp2.x, temp1.y, viewportScale.x", //Flip Y to X, and scale with viewport X
"sub temp2.y, 1.0, temp2.y", //Invert the UV for the Y axis.
"mov posScaled, temp2",
].join("\n");
You can ignore the special aliases in the AGAL example, they're essentially posOriginal = v0, posScaled = v1 variants and viewportScale = vc4constants, then I do a string-replace to change them back to their respective registers & fields ).
Just a human-readable trick I use to avoid going insane. \☻/
The part that I struggled with the most was calculating the correct scale to adjust the UV's scale (with proper detection to Stage / Viewport resize and render-texture size shifts).
Eventually, this is what I came up with in the AS3 code:
var pt:Texture = _passTexture,
dt:RenderTexture = _displacement.texture,
notReady:Boolean = pt == null,
star:Starling = Starling.current;
var finalScaleX:Number, viewRatioX:Number = star.viewPort.width / star.stage.stageWidth;
var finalScaleY:Number, viewRatioY:Number = star.viewPort.height / star.stage.stageHeight;
if (notReady) {
finalScaleX = finalScaleY = 1.0;
} else if (isRotated) {
//NOTE: Notice how the native width is divided with height, instead of same side. Weird, but it works!
finalScaleY = pt.nativeWidth / dt.nativeHeight / _imageRatio / paramScaleX / viewRatioX; //Eureka!
finalScaleX = pt.nativeHeight / dt.nativeWidth / _imageRatio / paramScaleY / viewRatioY; //Eureka x2!
} else {
finalScaleX = pt.nativeWidth / dt.nativeWidth / _imageRatio / viewRatioX / paramScaleX;
finalScaleY = pt.nativeHeight / dt.nativeHeight / _imageRatio / viewRatioY / paramScaleY;
}
Hopefully these extracted pieces of code can be helpful to others with similar shader issues.
Good luck!
I was having fun with image processing and hough transforms on Octave but the results are not the expected ones.
Here is my edges image:
and here is my hough accumulator (x-axis is angle in deg, y-axis is radius):
I feel like I am missing the horizontal streaks but there is no local maximum in the accumulator for the 0/180 angle values.
Also, for the vertical streaks, the value of the radius should be equal to the x value of the edge's image, but instead the values of r are very high:
exp: the first vertical line on the left of the image has an equation of x=20(approx) -> r.r = x.x + y.y -> r=x -> r=20
The overall resulting lines detected do not match the edges at all:
Acculmulator with detected maxima:
Resulting lines:
As you can see the maximas of the accumulator are satisfyingly detected but the resulting lines' radius values are too high and theta values are missing.
It almost looks like the hough transform accumulator does not correspond to the image...
Can someone help me figure out why and how to correct it?
Here is my code:
function [r, theta] = findScratches (img, edge)
hough = houghtf(edge,"line", pi*[0:360]/180);
threshHough = hough>.5*max(hough(:));
[r, theta] = find(threshHough>0);
%deg to rad for the trig functions
theta = theta/180*pi;
%according to octave doc r range is 2*diagonal
%-> bring it down to 1*diagonal or all lines are out of the picture
r = r/2;
%coefficients of the line y=ax+b
a = -cos(theta)./sin(theta);
b = r./sin(theta);
x = 1:size(img,2);
y = a * x + b;
figure(1)
imagesc(edge);
colormap gray;
hold on;
for i=1:size(y,1)
axis ij;
plot(y(i,:),x,'r','linewidth',1);
end
hold off;
endfunction
Thank you in advance.
You're definitely on the right track. Blurring the accumulator image would help before looking for the hotspots. Also, why not do a quick erode and dilate before doing the hough transform?
I had the same issue - detected lines had the correct slope but were shifted. The problem is that the r returned by the find(threshHough>0) function call is in the interval of [0,2*diag] while the Hough transform operates with values of r from the interval of [-diag,diag]. Therefore if you change the line
r=r/2
to
r=r-size(hough,1)/2
you will get the correct offset.
Lets define a vector of angles (in radians):
angles=pi*[0:360]/180
You should not take this operation: theta = theta/180*pi.
Replace it by: theta = angles(theta), where theta are indices
Some one commented above suggesting adjusting r to -diag to +diag range by
r=r-size(hough,1)/2
This worked well for me. However another difference was that I used the default angle to compute Hough Transform with angles -90 to +90. The theta range in the vector is +1 to +181. So It needs to be adjusted by -91, then convert to radian.
theta = (theta-91)*pi/180;
With above 2 changes, rest of the code works ok.
I want to create a plot of 2D data that is generated using different parameters. Something like this:
figure;
hold on;
parameters = [1:10];
for param = parameters;
x = [1:10];
y = ones(10) * param;
plot(x, y);
endfor
hold off;
Instead of cluttering the graph with a legend (the range of param might become large, and then it would look similar to plotting color codded graph in matlab), I'd like to add a color map to the right of the graph. Something similar to this: gnuplot linecolor variable in matplotlib? How do I do this?
I found the "colorbar" command, but that only visualizes the range [0:1] of the current color map. The "caxis" command can help then. See also: http://cresspahl.blogspot.de/2012/04/octave-quickies-customizing-colorbar.html
Sorry, found the answer myself:
figure;
hold on;
parameters = [1:10];
for param = parameters;
x = [1:10];
y = ones(10) * param;
plot(x, y);
endfor
colorbar();
caxis([min(parameters), max(parameters)]);
hold off;
Also note that the gnuplot graphics toolkit doesn't work well with such a plot (zooming etc. breaks the plot). If you instead use the flkt toolkit, it works nicely though.
How would you plot these in SciLab or MatLab? I am new to these and have no idea how the software works. Please help.
$Plot following functions with different colors in Scilab or MatLab
– f2(x) = logn
– f3(x) = n
– f4(x) = nlogn
– f5(x) = n2
– f6(x) = nj (j > 2)
– f7(x) = cn (c > 1)
– f8(x) = n!
where x = linspace(1, 50, 50).
Well, a lot of these are built-in functions. For example
>> x = linspace(1,50,50);
>> plot(x,log(x))
>> plot(x,x)
>> plot(x,x.*log(x))
>> plot(x,x.^2)
I don't know what nj (j > 2) and cn (c > 1) are supposed to mean.
For the last one, you should look at the function factorial.
It's not clear from the context whether you're supposed to plot them on different graphs or all on the same graph. If all on the same graph, then you can use
>> hold on;
to freeze the current axes - that means that any new lines will get drawn on top of the old ones, instead of being drawn on a fresh set of axes.
In Matlab (and probably in Scilab) you can supply a "line spec" argument to the plot function, which tells it what color and style to draw the line in. For example,
>> figure
>> hold on
>> plot(x,log(x),'b')
>> plot(x,x/10,'r')
>> plot(x,x.^2/1000,'g')
Tells Matlab to plot the function f(x)=log(x) in blue, f(x)=x/10 in red and f(x)=x^2/1000 in green, which results in this plot:
I can't comment or upvote yet but I'd add to Chris Taylor's answer that in Scilab the hold on and hold off convention isn't used. All plot commands output to the current axes, which are 'held on' all the time. If you want to generate a new figure or change the current axes you can use figure(n), where n can be any (nonconsecutive) positive integer - just a label really.
See also clf(n), gcf() and gca() - Scilab's figure handling differs quite a bit from Matlab's, though the matplotlib ATOMS module goes some way towards making Scilab look and behave more like Matlab.
In Scilab, it will be
x = 1:50;
clf
plot("ll", x,log, x,x, x,x.*log(x), x,x.^2)
gca().sub_ticks(2) = 8;
xgrid(color("grey"))
legend("$"+["ln(x)", "x", "x.ln(x)", "x^2"]+"$", "in_upper_left")