The Asker happened to use a grayscale conversion, sure, but he particulaly wrote of wanting to plot "intensity levels" and did not write of wanting B&W per se.

In the absence of clarification it is somewhat dubious to try to deduce or state categorically that any of the distinct technical color space terms lightness, brightness, luminance, or intensity is what was being requested in particular. Lab, HSV, YUV, HSI... these are all amongst the possibilities. Sure, perceptual intensity might well be the front-runner.

It is possible that the OP is not aware of the differences, or does not consider that they matter much.

I chose V=value (brightness) of HSV mostly just because I happened to have the converted HSV structure alreadty at hand. I was trying to make suggestions about Components, mostly. I didn't even bother to optimize the code w.r.t. extraneous copies, fastest mapped operations, etc.

The Asker happened to use a grayscale conversion, sure, but he particulaly wrote of wanting to plot "intensity levels" and did not write of wanting B&W per se.

In the absence of clarification it is somewhat dubious to try to deduce or state categorically that any of the distinct technical color space terms lightness, brightness, luminance, or intensity is what was being requested in particular. Lab, HSV, YUV, HSI... these are all amongst the possibilities. Sure, perceptual intensity might well be the front-runner.

It is possible that the OP is not aware of the differences, or does not consider that they matter much.

I chose V=value (brightness) of HSV mostly just because I happened to have the converted HSV structure alreadty at hand. I was trying to make suggestions about Components, mostly. I didn't even bother to optimize the code w.r.t. extraneous copies, fastest mapped operations, etc.

I feel silly for not having noticed that the original exponent had 11 significant digits, so that naturally the behaviour at default Digits=10 is not as I wrote was expected. Carl has a sharp eye.

acer

I feel silly for not having noticed that the original exponent had 11 significant digits, so that naturally the behaviour at default Digits=10 is not as I wrote was expected. Carl has a sharp eye.

acer

@Christopher2222 Note that the hues appearing at the "bottom" (back) of your 3D plot get obscured by those on "top" (front).

Compare your original orientation=[0,0] with the scene you get viewing at orientation=[180,-180]. Viewed from the front then the purples are hidden. And so on, for most any angle. I don't know whether this effect is related to `symbolsize`.

Viewing instead the flat image from the H-layer replacement gets quite different behaviour in this regard.

ps. You likely ought not attempt style=patchnogrid unless the grid size is smaller.

@Christopher2222 Note that the hues appearing at the "bottom" (back) of your 3D plot get obscured by those on "top" (front).

Compare your original orientation=[0,0] with the scene you get viewing at orientation=[180,-180]. Viewed from the front then the purples are hidden. And so on, for most any angle. I don't know whether this effect is related to `symbolsize`.

Viewing instead the flat image from the H-layer replacement gets quite different behaviour in this regard.

ps. You likely ought not attempt style=patchnogrid unless the grid size is smaller.

@herclau So, you have a plot at the end. Is it your goal to place (or "draw") a red circular arc on the original image, and show that?

@Alejandro Jakubi I wonder whether the auto-simplification of  '(2^(1/2))^29.403243784' is an oversight, which I why I mention it in particular.

In contrast, I do expect the following result, where float-contagion leaves the 2^(1/2) alone,

'(2^(1/2))*29.403243784';

                                    (1/2)
                      29.403243784 2     

Even the example involving 4^(1/2) is a bit strange. I do expect this, though,

 '(4^(1/2))*29.403243784';

                                    (1/2)
                      29.403243784 4     

@Alejandro Jakubi I wonder whether the auto-simplification of  '(2^(1/2))^29.403243784' is an oversight, which I why I mention it in particular.

In contrast, I do expect the following result, where float-contagion leaves the 2^(1/2) alone,

'(2^(1/2))*29.403243784';

                                    (1/2)
                      29.403243784 2     

Even the example involving 4^(1/2) is a bit strange. I do expect this, though,

 '(4^(1/2))*29.403243784';

                                    (1/2)
                      29.403243784 4     

Are you thinking of implementing an application that does some sort of detection of circles in an image?

Do you intend an application which (somehow, more interactively in a mouse-pointer sense perhaps) implements something like this or this? If so, then would it be appropriate to first implement a Maple procedure which provides the functionality of Matlab's imfindcircles function? Once the programmatic functionality is available then one might develop an interactive application which connects optional parameters for sensitivity, etc, with embedded Sliders.

Sorry if I have guessed wrongly. Giving URL links showing what you intend would help at least as much as uploaded text documents here.

If you are trying to build an interactive application that ties together Slider embedded components with ImageTools images (Arrays) then you might consider using Label components. This has worked ok for me in the past, where fractal images on Labels were updated quite quickly for smaller sizes. On a fast machine updating  a 300x300 pixel image on a Label can be reasonably smooth in practice, even though it necessitates file system i/o. Two of Maple 17's Math Apps (link, link) act similarly.

acer

What platform are you using, for your Maple 15?

Is it 64bit Windows? If so, then see this note.

On 64bit Maple for MS-Windows, the functionality of the Finance package is quite incomplete in releases before Maple 17, which is mentioned in a note at the very bottom of the ?Finance help-page (note capitalization of "Finance"). A warning should also be emitted, when loading that package using `with`.

acer

@tiradentes Did you mean k*(1-m_r) as a product?

It looks as if you have input just a function application, but perhaps you intended a multiplication?

Notice,

0.5(1-2.2);

                              0.5

0.5*(1-2.2);

                             -0.60

@tiradentes Did you mean k*(1-m_r) as a product?

It looks as if you have input just a function application, but perhaps you intended a multiplication?

Notice,

0.5(1-2.2);

                              0.5

0.5*(1-2.2);

                             -0.60

Here are the integrals, which succeed symbolically under assumptions that match the plotting ranges.

You could thus plot these instead (using the approriate ranges, for the scaled or unscaled version). That would very likely be the fastest way to produce the plot of the particular integral.

You might also want to consider raising the working precision, if you believe that you are still encountering numeric roundoff error.

I did these symbolic integrals using your original floating-point coefficients. You may wish to try it with exact rational coefficients instead.

Download dropsymbolic.mw

I might hazard a guess that the (successful) symbolic value of the rescaled integral Rnew might have better numerical evaluation behaviour under its plotting ranges than does the (successful) symbolic value of the integral R under its plotting ranges.

acer

Here are the integrals, which succeed symbolically under assumptions that match the plotting ranges.

You could thus plot these instead (using the approriate ranges, for the scaled or unscaled version). That would very likely be the fastest way to produce the plot of the particular integral.

You might also want to consider raising the working precision, if you believe that you are still encountering numeric roundoff error.

I did these symbolic integrals using your original floating-point coefficients. You may wish to try it with exact rational coefficients instead.

Download dropsymbolic.mw

I might hazard a guess that the (successful) symbolic value of the rescaled integral Rnew might have better numerical evaluation behaviour under its plotting ranges than does the (successful) symbolic value of the integral R under its plotting ranges.

acer