I have a parametric surface in 3D. I would like to observe parts of this surface, specifically, the part with z > 0 and the part with x2 + y2 + z2 < c.
A few methods that I tried:
Naïvely throwing away the rest of the data, for instance setting X[Z<0] = nan etc. Since this does not line up with the parametrization that I chose, it would create ragged edges. Is there some sort of "antialiasing" interpolation options that I can choose? I would be grateful for a pointer to the docs for numpy or plotly.
Trying to set the alpha of the color scale. This sort of works, it seems to introduce some incorrect rendering. In the picture below, the dark green lump should be at the front of the light green disk. Is there something that I did wrong?
On the other hand, I couldn't locate in the manual a way to set "two dimensional" color scales, so that I can simultaneously set the opacity according to the z value and the hue according to some other quantity of interest. Is this possible?
Is there a convenient method to achieve my goal? Or can I improve my attempts above? Any help is appreciated!
Can SSRS make a graded colour scale (like Excel). I am attatching an image to explain what I mean.
Regards.
Yes, but it's not very easy. You can use an expression to dynamically set the fill color of a cell. The colors can be specified with their hex representation like "#AC9494". You will have to come up with a formula to define which colors the scale goes through.
Red is "#FF0000" and green is "#00FF00". So your formula would have to scale the amount of green and red (and maybe some blue) you want, convert that to hex, and then concatenate them into this format. If you search for terms like "smooth color gradient" you will get some helpful examples to point you in the right direction.
I'm constructing a graph plot in Julia and need to color each edge of the graph differently, based on some weighting factor. I can't find a way to get a specific RGB (or HSV, it doesn't matter) value from a colormap. Let's say I'd like to get the RGB value on 'jet' that would correspond to a data value of n on imshow plot.
In python, I would just use jet(n), where n is the value along the colormap in which I am interested. PyPlot in Julia doesn't seem to have wrapped this functionality. I've also already tried indexing into the cmap object returned from get_cmap(). Any advice?
I'm stumped, so even an approximate solution would help. Thanks!
Maybe you can look at the Colors.jl package (https://github.com/JuliaGraphics/Colors.jl):
using Colors
palette = colormap("Oranges", 100)
Then you can access each color with palette[n]. Or are you using PyCall? A code describing what you're trying to do would help.
I need to know how to get the inverse color by lesscss.
Example: I have #000, i need #FFF.
And i need the detail explanation of spin(). And necessary links where i can see a color wheel where i can understand how spin() works.
Thanks.
Why it is not working as you expect
The spin() function only deals with hue (color), not value (grey scale changes are a value change). Take a look at Figures 9 and 10 on this page from North Carolina State University's site. Those figures help show the difference. The spin() function is rotating only in the two dimensional space of the hue circle of color, not along the axis of the third dimensional space dealing with saturation; i.e. the gray scale itself, which is what differentiates white from black, both of which have no color saturation).
This is why on the LESS site we read of spin() (emphasis added):
Note that colors are passed through an RGB conversion, which doesn't
retain hue value for greys (because hue has no meaning when there is
no saturation)
And
Colors are always returned as RGB values, so applying spin to a grey
value will do nothing.
Getting what you want (Color Inversion)
See #seven-phases-max's answer.
The spin function changes the Hue property of a colour. Shades of grey (incl. white and black) are achromatic colours (i.e. they have the same "undefined" hue value).
To simply invert a colour use either difference function:
difference(white, #colour)
or the simple colour arithmetic:
(#fff - #colour)
I'm struggling with a problem when making plots with filledcurves. Between the filled areas, there seems to be a "gap". However, these artifacts do not appear on the print, but depend on the viewer and zoom-options. In Gnuplot I use the eps terminal, the eps-files look great, but the lines appear when I'm converting to pdf. The conversion it either done directly after plotting or when converting the latex-document from dvi to pdf. As most of the documents are here on the display nowadays, this is an issue. The problem also appears when I'm directly using the pdfcairo terminal in Gnuplot, so it's not caused by the conversion (tried epstopdf and ps2pdf) alone.
I attached a SCREENSHOT of a plot displayed in "acroread" (same problem in other pdf-viewers).
Has anybody an idea how to get rid of it but keeping the graphic vectorized?
I just ran into the same issue. Apparently the filling between two curves
is done as a set of polygons that do not exactly touch one another, thus
the thin white lines visible on some PDF viewers.
One way to fix the issue is to draw over these polygon boundaries. First
define min and max functions in gnuplot:
min(x, y) = x < y ? x : y
max(x, y) = x > y ? x : y
Then, assuming that column 1 of "datafile" contains your x values and
that columns 2 and 3 contain the y values of curves 2 and 3, write:
plot "datafile" using 1:2:3 with filledcurves lc rgb "gray", \
"" using 1:2:(min($2, $3)):(max($2, $3)) with yerrorbars ps 0 lt 1 \
lc rgb "gray" lw 0.5
The first plot instruction fills the spaces between the curves in gray.
The second plot instruction draws points of zero size (ps 0) at each
x value (1) on curve (2) with thin (lw 0.5), continuous (lt 1), gray
(lc rgb "gray"), vertical errorbars (yerrorbars) from the lower to
the higher of curves 2 and 3.
This covers the white lines. To get best results you may need to
experiment with the thickness of the bars (e.g., lw 0.6, lw 0.2).
This issue is fixed with gnuplot 5.2, see https://sourceforge.net/p/gnuplot/patches/749/
The actual problem was, that filled curves were previously plotted as many quadrilaterals, which leads to artifacts (white stripes) in many viewers due to antialiasing.
Since version 5.2 filled curves are rendered as single polygon, which prevents these problems (see issue linked above).
The problem is still present in Gnuplot 5.0.4 and at least the cairolatex terminal which I use to output PDFs.
I also wanted to color the area between two curves, in my case defined as functions.
When I used something like
f(x) = 2 + sin(x)
g(x) = cos(x)
plot '+' using 1:(f($1)):(g($1)) with filledcurves closed
I got the same vertical white lines as in the question.
A simple solution for curves where one is always above the other is to let Gnuplot fill the area from the upper curve to the x-axis with the desired color and then paint it over with white from the lower curve downwards:
f(x) = 2 + sin(x)
g(x) = cos(x)
plot f(x) with filledcurves x1, g(x) w filledc x1 fs lc rgb "white"
Apparently this filledcurves style (not between curves but between a curve and an axis) avoids the trapezoid artifacts.
This can be readily extended for plotting data files and multiple stacked cures like in the question. Just paint from top to bottom and finish with white for the empty area between the lowest curve and the x-axis.
For overlapping curves a construction of minimum and maximum curves like in the answer from françois-tonneau might do the trick.
If you're talking about the red and cyan bits the gap could be an illusion caused by the Red + Cyan = White on a RGB screen. Maybe there's no gap, but the border areas appear as white due to the proximity of the pixels.
Take the screenshot and blow it up so you can see the individual pixels around the perceived gap.
If this is the case, maybe selecting a different colour scheme for the adjacent colurs would get rid of the effect. I certainly can't see anything matching your description on anywhere but the red and cyan bits.
From https://groups.google.com/forum/#!topic/comp.graphics.apps.gnuplot/ivRaKpu5cJ8, it seemed to be a pure Gostscript issue.
Using the eps terminal of Gnuplot and converting the eps file to pdf with
epstopdf -nogs <file.eps> -o <file.pdf>
solved the problem on my system. From the corresponding Man page, the "-nogs" option instructs epstopdf not to use Gostscript.