@EugeneKalentev By numeric quadrature,

evalf(Flux(vv, Sphere(<0, 0, 0>, 2.3), inert));
                          79.86766283

evalf(Flux(ee, Sphere(<0, 0, 0>, 2.3), inert));
                          79.86766283

@Carl Love I was pretty sure that's what you meant, sure.

However for this example it is faster to do evalhf(map(...)) than map[evalhf](...) on my 64bit Maple 2015 for Linux at least.

restart;
with(ImageTools):
img := Scale(Read(cat(kernelopts(datadir), "/tree.jpg")),10.0):

cimg:=CodeTools:-Usage( Complement(img) ):
memory used=243.56MiB, alloc change=241.09MiB, cpu time=190.00ms, real time=206.00ms, gc time=10.00ms

fimg:=CodeTools:-Usage( FitIntensity(img,1..0) ):
memory used=0.71GiB, alloc change=0.71GiB, cpu time=2.96s, real time=993.00ms, gc time=50.00ms

eimg:=CodeTools:-Usage( evalhf(map(x->1-x,img)) ):
memory used=243.53MiB, alloc change=243.53MiB, cpu time=2.90s, real time=2.21s, gc time=0ns

mimg:=CodeTools:-Usage( map[evalhf](x->1-x,img) ):
memory used=1.90GiB, alloc change=-243.53MiB, cpu time=7.08s, real time=6.67s, gc time=1.20s

One may also observe that neither map(x->1-x,img) nor evalf(map(x->1-x,img)) produce a result that Maple accepts as an image, since the result lacks the float[8] datatype. So I don't know what the OP intended -- there may even have been a typo.

And neither is as fast as FitItensity, which in turn is not as fast as Complement. Somewhat interestingly the former appears to be using multiple cores -- see the "cpu time" versus "real time". I ran the above on a quad-core machine. Perhaps with many more CPU cores I'd see FitIntensity perform more like Complement. Perhaps Complement could be multithreaded.

The Complement command computes faster than the other suggestions, as the color image size gets large.

Using 64bit Maple for Linux with Maple 2015,

restart;
with(ImageTools):
img := Scale(Read(cat(kernelopts(datadir), "/images/tree.jpg")),10.0):

CodeTools:-Usage( Complement(img) ):
memory used=243.56MiB, alloc change=241.09MiB, cpu time=200.00ms, real time=210.00ms, gc time=10.00ms

CodeTools:-Usage( FitIntensity(img,1..0) ):
memory used=0.71GiB, alloc change=0.71GiB, cpu time=2.99s, real time=988.00ms, gc time=50.00ms

CodeTools:-Usage( map[evalhf](x->1-x,img) ):
memory used=1.90GiB, alloc change=-243.53MiB, cpu time=8.05s, real time=6.74s, gc time=1.27s

Also, the Complement command leaves the alpha channel alone for an RGBA image. The other two suggestions made produce results that are less useful, IMHO. Those other two methods already seem more complicated to use, and fixing them up to only affect the first three channels of a color RGBA image would make then more complicated still.

restart;
with(ImageTools):

img := Scale(Read(cat(kernelopts(datadir), "/images/tree.jpg")),0.6):

L := [[img, Complement(img)],
     [FitIntensity(img,1..0), map[evalhf](x->1-x,img)]]:

Embed(L, exterior=none, interior=none);

Aimg:=ToRGBA(img);
Aimg[1..160,1..100,4]:=Array(1..160,1..100,0.7,datatype=float[8]):

AL := [[Aimg, Complement(Aimg)],
       [FitIntensity(Aimg,1..0), map[evalhf](x->1-x,Aimg)]]:

Embed(AL, exterior=none, interior=none);

ps. Thanks, Thomas, I must have pasted from the wrong sheet.

@ccAndrew How is that different from ImageTools:-Complement, where complementary colors are exchanged?

@vv Here is a hot fix to a running session, which I believe achieves your edit to the procedure (in Maple 2015.1, of course).

Download shade_hotfix.mw

The `option` on a procedure can be seen with, say,

kernelopts(opaquemodules=false):
interface(verboseproc=3):

op(3,eval(plottools:-`transform/object`));

      Copyright (c) 1997 by Waterloo Maple Inc. All rights reserved.

print(plottools:-`transform/object`);

@vv That Library routine has option `Copyright (c) 1997 by Waterloo Maple Inc. All rights reserved.`.  Your (only slightly) edited version is missing the copyright.

You could alternately post a FromInert(...,ToInert(...)...) call that modifies the procedure in-session, without violating copyright.

For this example the lower curve may be added. It makes the lower edge appear smoother.

The code already included the curve along the upper boundary (which is why it seems a little darker). This now even closer to what plots:-shadebetween does internally.

(f,g) := 2, 1/sqrt(1-x^2):

plots:-display(plot(g,x=0..sqrt(3)/2),
   plottools:-transform(unapply([x,y+g],x,y))(plot(f-g,x=0..sqrt(3)/2,filled=true)));

@Carl Love Good eye! I had forgotten about that aspect of the calling sequence.

An empty set suffices to designate lack of inequality constraints. So in this example below the operator designates the equality constraint x+y=2 .

Optimization:-Minimize((x,y)->x, {}, {(x,y)->x+y-2}, -1..1, -2..2);          

                                    -15  [                     -15]
           [-0.111022302462515654 10   , [-0.111022302462516 10   ]]
                                         [                        ]
                                         [           2.           ]

An example showing this clearly on the help-page would be nice.

@Markiyan Hirnyk I followed the instruction for inequality constraints, as that is what your examples contain. 

That piece of documentation does not make much sense to me either, as far as equality constraints go.

But we can test that the form I used is being interpreted as an ineqaulity constraint (and for the examples you gave... that is relevant).

Optimization:-Minimize(x, {x+y=2}, x=-1..1, y=-2..2);          

                             -8                            -8
       [-0.103259778874000 10  , [x = -0.103259778874000 10  , y = 2.]]

Optimization:-Minimize(x, {x+y<=2}, x=-1..1, y=-2..2);

                           [-1., [x = -1., y = 0.]]

Optimization:-Minimize((x,y)->x, {(x,y)->x+y-2}, -1..1, -2..2);     

                                       [-1.]
                                 [-1., [   ]]
                                       [0. ]

The above indicates that the form of operator (for a given inequality constraint) that I used is being interpreted as the documentation describes for inquality constraints (converted to operator form). I do agree with you that the documentation that describes how equality constraints ought to be handled is quite unclear.

If I had an equality constraint in expression form then I might approach it as follows, using a pair of inequality constraints (that together imply the equality constraint).

Optimization:-Minimize((x,y)->x, {(x,y)->x+y-2,
                                  (x,y)->-(x+y-2)},
                        -1..1, -2..2);

                                    -15  [                     -15]
           [-0.111022302462515654 10   , [-0.111022302462516 10   ]]
                                         [                        ]
                                         [           2.           ]

So I will submit a but report that the documentation for expressing equality constraints in operator form is unclear and incomplete (missing).

@Markiyan Hirnyk I suspect that you have not properly realized that an inequality constraint has to be put into the form v(x1,x2,...,xn)≤0 before taking its left-hand-side as the expression to use inside the procedure.

Here is an example that roughly uses the approach that Carl described.

Of course if there is more than just one constraint then they would have to be handled (stored) separately.

My use of the colorscheme option below likely requires Maple 2015. (In an older version, remove that option.)

Download objfun.mw

@Markiyan Hirnyk I replaced the inequality constraint 8 - x*(y^2+1) <=0 by 8 - x*(y^2+1) in a procedure.

In your followup example you should replace {8 >= x*(y^2+1)} by {(x,y)->x*(y^2+1) - 8} to get the operator form for that inequality constraint.

That's because (as documented) the constraint form to use is f(x,y)<=0 and so 8 >= x*(y^2+1) should be considered as x*(y^2+1) - 8 <=0 .

Optimization:-Minimize(x^2+(y-1)^2, {8 >= x*(y^2+1)});

                              -39                           -19
      [0.183670992315982423 10   , [x = 0.135525271560688 10   , y = 1.]]

Optimization:-Minimize((x,y)->x^2+(y-1)^2, {(x,y)->x*(y^2+1) - 8}); 

                                       [0.]
                                  [0., [  ]]
                                       [1.]

@Markiyan Hirnyk Your usage is incorrect.

Optimization:-Minimize( (x-1)^2+(x-y)^2 , { 8 <= x*(y^2+1) });               

     [0.517128660129716033, [x = 1.62561974988123, y = 1.98020202339228]]

Optimization:-Minimize( (x, y)->(x-1)^2+(x-y)^2 ,
                        { (x, y) ->8 - x*(y^2+1) });

                                         [1.62561979191297]
                  [0.517128660127401107, [                ]]
                                         [1.98020199126056]

See the section "Constraints" in the Optimization,General,OperatorForm help-page.

@John Dolese Great. The new Figure 2 is much better. There's still a lot more green than there ought to be. But the new Figure 2 jives visually with my own similar experiment using the current WavelengthToColor.

I already understood the point of the execise, as I've previously worked out much of this and more in Maple myself. But I'm sure that the extra explanation will help other readers.

I should find time to polish my sheets that produce a more accurate edge of the visual gamut in xy(Y). The generated colors agree quite a bit more with reference material, as a function of wavelength. I made a function which interpolates from the 1931 CIE data itself. Of course I must regress back to the displayable RGB gamut, to show it on a plot. But the `spectrum` it produces seems relatively accurate (visually and numerically), compared to online references. Really I should go further and produce a corrected WavelengthToColor procedure.

There is also an old `MathApp` that shows wavelength and color. The last I looked it used a crude piecewise linear approximation in three channels, so the spectrum it can produce is a bit clunky and artifically flat in places. The piecewise approx. it uses seems to be found a few places on the web (the earliest place I saw it was in some Matlab code...).

I'm not sure if it's documented, but when I last dug into the hard-coded conversion data internal to ColorTools I saw values that correspond to D65. I believe that a much earlier (first?) version of ColorTools might have used D50 conversion data, but that was sensibly changed quite soon after.

I too have wondered which "RGB" we get from the Java GUI. At least one of my LCD monitors offers a choice between Adode vs other RGB variants (and/or "temperature"). I'd like experiment with matching that up with the RGB variant that Maple's Standard (Java) GUI is displaying.

Another thing I'd like to do it adjust/wrap/hack ColorTools:-SpatterPlot to optionally show a full view of a highly translucent implicit surface of the visible gamut, to put some perspective on what it shows. Of course that surface would need to correspond to the value one chooses for the colorspace option of that command.

There were some interesting bits of new functionality for working with color in Maple 2015. (Hmm, maybe there's enough for a few posts.)

@John Dolese 

The WavelengthToColor command produces quite wrong values for the yellow-through-blue sections, and the green is particularly out of whack. I've known this for a while now, and have constructed a repaired scheme one using the 1931 CIE data and some techniques a bit like in the link I gave (but less coarse). It produces a "visible spectrum" more like what one usually sees in references (although of course it is generally not clear what source might be expected to emit such a light).

I notice that you haven't really explained why your Figures 1 and 2 show those colors which don't come close to  matching the popularly shown visible gamut usually shown in diagrams in xy(Y) space. How are you normalizing or projecting, with repect to Y? Since we seem to agree about where the current WavelengthToColor results go awry I wonder whether I am just misunderstanding something simple about the colors used to shade the curves in your Figures 1 and 2. I looked at the code hidden in your Tables. It seems to me that the degree to which WavelengthToColor is innaccurate does not accomodate the degree to which your curve's colors differ from stock references. But perhaps I misunderstand what you've intended to show. What do you mean by "D65_data_Monochromes"? Do you not mean the fully saturated pure colors that lie at the edge of the visible gamut? Why do they not match the visible `spectrum', in your Figure 1 and 2?

Perhaps I should as a simpler question. You appear to be trying to color the outer edge of the visible gamut in (projected) xyY, where the boundary contains the fully saturated "pure" colors. Since you are making a plot for display on computer monitors that are (usually) limited to some (flavor of) RGB displayable gamut then how generally do you intend on handling the colors outside the triangular RGB gamut but inside the visible gamut? Is it your intention to simply chop R, G, or B values that lie outside of 0.0..1.0? Or are you chopping/restricting in XYZ? Or do you intend to regress toward the D65 white point? Or something else entirely?

Thanks for bearing with me. I'd just like to understand your methodology a bit more.