SURFACE Fitter?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

SURFACE Fitter?

Kenneth Sloan-3
Flushed with success using CurveFitter, I'm becoming greedy.

Is there a corresponding SURFACE Fitter?  Or, some clever technique for posing a surface fitting task as curve fitting?

I want to fit z=f(x,y) to sampled data.

The bounds of x,y are finite (say, inside a disc centered at (0,0) with a known maximum R.

My first thought was to encode (x,y) as
 u = K*y + x, with K > maxR,  
and then fitting a "curve" to z=f2(u).

Anything wrong with this idea?   Problems at the breakpoints?  x and y probably have to be converted to integers:

 u = K*discretize(y) + discretize(x)

Would it help to work with g(rho,theta) and g2(v), with v = PI*rho + theta?

Or, is there a package that understands f(x,y)? or g(rho,theta)?

This feels "too easy" - leading me to believe that it's either dead wrong, or that someone has already implemented it.


--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: SURFACE Fitter?

Michael Schmid-3
Hi Kenneth,

if you have a rectangular area, you can use
   u = K*y + x
with K being the width (in x direction) of the rectangle.

For non-rectangular areas, you can iterate over the points inside the
area once to count them, and assign four arrays with length according to
this count.
Array number one should be filled by numbers 0...n-1 (array index),
array two should be x-x_center,
array three should be y-y_center,
and number four the pixel value.
If you want to do the fit as a function of rho and phi, have arrays for
index, rho, phi, and the value.

For the CurveFitter, take the array index as 'x', and the pixel value as
'y'. The user function should retrieve the corresponding coordinates
(x&y or rho&phi) using the array index that it gets as 'x' from the
CurveFitter.
You can still eliminate an offset and a 'multiply' parameter by linear
regression, but not a slope (because the 'x' is just an array index).

I hope this description is not too confusing...

Michael
________________________________________________________________


On 27/03/2018 17:19, Kenneth Sloan wrote:

> Flushed with success using CurveFitter, I'm becoming greedy.
>
> Is there a corresponding SURFACE Fitter?  Or, some clever technique for posing a surface fitting task as curve fitting?
>
> I want to fit z=f(x,y) to sampled data.
>
> The bounds of x,y are finite (say, inside a disc centered at (0,0) with a known maximum R.
>
> My first thought was to encode (x,y) as
>   u = K*y + x, with K > maxR,
> and then fitting a "curve" to z=f2(u).
>
> Anything wrong with this idea?   Problems at the breakpoints?  x and y probably have to be converted to integers:
>
>   u = K*discretize(y) + discretize(x)
>
> Would it help to work with g(rho,theta) and g2(v), with v = PI*rho + theta?
>
> Or, is there a package that understands f(x,y)? or g(rho,theta)?
>
> This feels "too easy" - leading me to believe that it's either dead wrong, or that someone has already implemented it.
>
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: SURFACE Fitter?

Kenneth Sloan-3
Yes - I used the first option.  My implementation is a bit hairy because I need to deal with non-integer x,y values and also allow for non-rectangular data.  The issue was inverting the (x,y)->u function.  I considered the parallel array approach, and may switch to that.  Instead, I essentially discretize y and use:

      u = k*v*dy + x

k and v are integers, which makes it easy to invert.  When I have a spare hour, I think I'll experiment with the parallel array method - because my data will not ALWAYS come in nice neat rows with y==constant.  I wasn't sure initially if the minimizer would ever ask to evaluate a u = f(x,y) location that was NOT in the set of data points.  If I can be sure that it won't, the parallel array method avoids the necessity of discretizing y, which might introduce some noise.

Right now, I'm confused by the output.

First - some explanation.  The function I'm fitting is a 2D DoG.  This has 11 parameters, one of which is an offset:
A1,A2 - amplitudes
Z     - offset
mux1, muy1, mux2, muy2 - centers
sigmax1, sigmay1, sigmax2, sigmay2 - stdDevs

Before squashing all bugs, doCustomFit crunched forever.  I now think that's because of some (unknown) typo, somewhere.
Cleaning up, making changes, etc. made this behavior go away.

I started restricting the range of the parameters (is returning NaN from the UserFunction the right way to do that?), and
also decided to take advantage of the previous 1D DoG fit that I do for a 1D slice (more or less) through the center of the
data (where the centers of the two Gaussians are expected to be).  That gives me a good estimate on location (in x, I have a separate estimator for the center y), amplitudes, offset, and sigma for the two 1D Gaussians.  The 2D DoG fit is allowed to break the symmetry, but the symmetric values are excellent hints.

So...now I get the following output, which seems "too good to be true" - so I'm staring at it trying to figure out what I did wrong:

First - the initial hints from the 1D DoG:  (plotting this shows that the fit is excellent)
fitDoG: A1     =   0.439986
fitDoG: A2     =   0.129684
fitDoG: Z      =  -0.046806
fitDoG: mu1    =   0.395004
fitDoG: mu2    =   0.032452
fitDoG: sigma1 =   4.329109
fitDoG: sigma2 =   0.387059

and now, the output from the 2D DoG fit: (it returns instantaneously)

FitDoG2D: there are 74629 data points
FitDoG2D: doCustomFit took 4 iterations
FitDoG2D: doCustomFit took 2 restarts
FitDoG2D: R^2                = 0.000000
FitDoG2D: Goodness of Fit    = -0.000147
FitDoG2D: Sum of Residuals^2 = 71.817633
FitDoG2D: SD of Residuals    = 0.056753
fitDoG2: A1     =   0.439539
fitDoG2: A2     =   0.127244
fitDoG2: Z      =   0.341972
fitDoG2: mux1    =   0.422567
fitDoG2: muy1    =   0.408254
fitDoG2: mux2    =   0.033034
fitDoG2: muy2    =   0.032668
fitDoG2: sigmax1 =   4.224204
fitDoG2: sigmay1 =   4.283156
fitDoG2: sigmax2 =   0.407647
fitDoG2: sigmay2 =   0.373676


I have not yet plotted the original data against the fit (another project beckons...) but the results look encouraging.
I even widened the "acceptable range" for all of the parameters, trying to reproduce the earlier long solving times, without changing the results.

4 iterations???  - that's very good!

R^2 = 0.0???? - that looks very bad!

I *have* plotted the 1D DoG fit to the 1D slice, and the fit is very, very good (sorry - no R^2, yet...).  So, the results
of the 2D DoG are not surprising (except perhaps for the offset, Z).

Any ideas?  If it matters, the z values are in (0.3, 0.6) (approximate) and the range of x,y is (-6.0, 6.0)

Obviously(?) the question is: do the answers look good because they are very close to my original estimates?  Or, are they close to the original estimates because the minimizer ran into some difficulty?

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.





> On 27 Mar 2018, at 13:34 , Michael Schmid <[hidden email]> wrote:
>
> Hi Kenneth,
>
> if you have a rectangular area, you can use
>  u = K*y + x
> with K being the width (in x direction) of the rectangle.
>
> For non-rectangular areas, you can iterate over the points inside the area once to count them, and assign four arrays with length according to this count.
> Array number one should be filled by numbers 0...n-1 (array index),
> array two should be x-x_center,
> array three should be y-y_center,
> and number four the pixel value.
> If you want to do the fit as a function of rho and phi, have arrays for index, rho, phi, and the value.
>
> For the CurveFitter, take the array index as 'x', and the pixel value as 'y'. The user function should retrieve the corresponding coordinates (x&y or rho&phi) using the array index that it gets as 'x' from the CurveFitter.
> You can still eliminate an offset and a 'multiply' parameter by linear regression, but not a slope (because the 'x' is just an array index).
>
> I hope this description is not too confusing...
>
> Michael
> ________________________________________________________________
>
>
> On 27/03/2018 17:19, Kenneth Sloan wrote:
>> Flushed with success using CurveFitter, I'm becoming greedy.
>> Is there a corresponding SURFACE Fitter?  Or, some clever technique for posing a surface fitting task as curve fitting?
>> I want to fit z=f(x,y) to sampled data.
>> The bounds of x,y are finite (say, inside a disc centered at (0,0) with a known maximum R.
>> My first thought was to encode (x,y) as
>>  u = K*y + x, with K > maxR,
>> and then fitting a "curve" to z=f2(u).
>> Anything wrong with this idea?   Problems at the breakpoints?  x and y probably have to be converted to integers:
>>  u = K*discretize(y) + discretize(x)
>> Would it help to work with g(rho,theta) and g2(v), with v = PI*rho + theta?
>> Or, is there a package that understands f(x,y)? or g(rho,theta)?
>> This feels "too easy" - leading me to believe that it's either dead wrong, or that someone has already implemented it.
>> --
>> Kenneth Sloan
>> [hidden email]
>> Vision is the art of seeing what is invisible to others.
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: SURFACE Fitter?

Michael Schmid-3
Hi Kenneth,

when transforming pixel coordinates to a single variable via
   u = width*(y-yMin) + (x-xMin)
this works nicely for a rectangular region. For other regions, if you
make integer coordinates, beware that some pixels may be appear twice.
In the fit, they will then get twice the weight or the other pixels.

Fitting a sum (or difference) of Gaussians (no matter whether 1D or 2D):
You can have eliminate both an offset and a multiplyParam by linear
regressions:

   y = offset + multiplyParam*(Gaussian1 + c* Gaussian2)

where Gaussian1 and Gaussian2 have no prefactor, and the parameter 'c'
is the amplitude ratio.
As usual, the fewer parameters you leave for the fitting algorithm, the
better...

--

4 iterations: This definitely sounds incorrect. For a 9-parameter fit,
you should expect at least thousands of iterations. I would not be
astonished if it runs almost forever.
What does the full curveFitter.getResultString() say?

Maybe the convergence criterion (setMaxError) was set such that it stops
prematurely?
Or your coordinate transformation is incorrect, and you access always
the same pixel, so almost all functions are equally good or bad?


Michael
________________________________________________________________
On 30/03/2018 19:51, Kenneth Sloan wrote:

> Yes - I used the first option.  My implementation is a bit hairy because I need to deal with non-integer x,y values and also allow for non-rectangular data.  The issue was inverting the (x,y)->u function.  I considered the parallel array approach, and may switch to that.  Instead, I essentially discretize y and use:
>
>        u = k*v*dy + x
>
> k and v are integers, which makes it easy to invert.  When I have a spare hour, I think I'll experiment with the parallel array method - because my data will not ALWAYS come in nice neat rows with y==constant.  I wasn't sure initially if the minimizer would ever ask to evaluate a u = f(x,y) location that was NOT in the set of data points.  If I can be sure that it won't, the parallel array method avoids the necessity of discretizing y, which might introduce some noise.
>
> Right now, I'm confused by the output.
>
> First - some explanation.  The function I'm fitting is a 2D DoG.  This has 11 parameters, one of which is an offset:
> A1,A2 - amplitudes
> Z     - offset
> mux1, muy1, mux2, muy2 - centers
> sigmax1, sigmay1, sigmax2, sigmay2 - stdDevs
>
> Before squashing all bugs, doCustomFit crunched forever.  I now think that's because of some (unknown) typo, somewhere.
> Cleaning up, making changes, etc. made this behavior go away.
>
> I started restricting the range of the parameters (is returning NaN from the UserFunction the right way to do that?), and
> also decided to take advantage of the previous 1D DoG fit that I do for a 1D slice (more or less) through the center of the
> data (where the centers of the two Gaussians are expected to be).  That gives me a good estimate on location (in x, I have a separate estimator for the center y), amplitudes, offset, and sigma for the two 1D Gaussians.  The 2D DoG fit is allowed to break the symmetry, but the symmetric values are excellent hints.
>
> So...now I get the following output, which seems "too good to be true" - so I'm staring at it trying to figure out what I did wrong:
>
> First - the initial hints from the 1D DoG:  (plotting this shows that the fit is excellent)
> fitDoG: A1     =   0.439986
> fitDoG: A2     =   0.129684
> fitDoG: Z      =  -0.046806
> fitDoG: mu1    =   0.395004
> fitDoG: mu2    =   0.032452
> fitDoG: sigma1 =   4.329109
> fitDoG: sigma2 =   0.387059
>
> and now, the output from the 2D DoG fit: (it returns instantaneously)
>
> FitDoG2D: there are 74629 data points
> FitDoG2D: doCustomFit took 4 iterations
> FitDoG2D: doCustomFit took 2 restarts
> FitDoG2D: R^2                = 0.000000
> FitDoG2D: Goodness of Fit    = -0.000147
> FitDoG2D: Sum of Residuals^2 = 71.817633
> FitDoG2D: SD of Residuals    = 0.056753
> fitDoG2: A1     =   0.439539
> fitDoG2: A2     =   0.127244
> fitDoG2: Z      =   0.341972
> fitDoG2: mux1    =   0.422567
> fitDoG2: muy1    =   0.408254
> fitDoG2: mux2    =   0.033034
> fitDoG2: muy2    =   0.032668
> fitDoG2: sigmax1 =   4.224204
> fitDoG2: sigmay1 =   4.283156
> fitDoG2: sigmax2 =   0.407647
> fitDoG2: sigmay2 =   0.373676
>
>
> I have not yet plotted the original data against the fit (another project beckons...) but the results look encouraging.
> I even widened the "acceptable range" for all of the parameters, trying to reproduce the earlier long solving times, without changing the results.
>
> 4 iterations???  - that's very good!
>
> R^2 = 0.0???? - that looks very bad!
>
> I *have* plotted the 1D DoG fit to the 1D slice, and the fit is very, very good (sorry - no R^2, yet...).  So, the results
> of the 2D DoG are not surprising (except perhaps for the offset, Z).
>
> Any ideas?  If it matters, the z values are in (0.3, 0.6) (approximate) and the range of x,y is (-6.0, 6.0)
>
> Obviously(?) the question is: do the answers look good because they are very close to my original estimates?  Or, are they close to the original estimates because the minimizer ran into some difficulty?
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
>
>
>
>
>> On 27 Mar 2018, at 13:34 , Michael Schmid <[hidden email]> wrote:
>>
>> Hi Kenneth,
>>
>> if you have a rectangular area, you can use
>>   u = K*y + x
>> with K being the width (in x direction) of the rectangle.
>>
>> For non-rectangular areas, you can iterate over the points inside the area once to count them, and assign four arrays with length according to this count.
>> Array number one should be filled by numbers 0...n-1 (array index),
>> array two should be x-x_center,
>> array three should be y-y_center,
>> and number four the pixel value.
>> If you want to do the fit as a function of rho and phi, have arrays for index, rho, phi, and the value.
>>
>> For the CurveFitter, take the array index as 'x', and the pixel value as 'y'. The user function should retrieve the corresponding coordinates (x&y or rho&phi) using the array index that it gets as 'x' from the CurveFitter.
>> You can still eliminate an offset and a 'multiply' parameter by linear regression, but not a slope (because the 'x' is just an array index).
>>
>> I hope this description is not too confusing...
>>
>> Michael
>> ________________________________________________________________
>>
>>
>> On 27/03/2018 17:19, Kenneth Sloan wrote:
>>> Flushed with success using CurveFitter, I'm becoming greedy.
>>> Is there a corresponding SURFACE Fitter?  Or, some clever technique for posing a surface fitting task as curve fitting?
>>> I want to fit z=f(x,y) to sampled data.
>>> The bounds of x,y are finite (say, inside a disc centered at (0,0) with a known maximum R.
>>> My first thought was to encode (x,y) as
>>>   u = K*y + x, with K > maxR,
>>> and then fitting a "curve" to z=f2(u).
>>> Anything wrong with this idea?   Problems at the breakpoints?  x and y probably have to be converted to integers:
>>>   u = K*discretize(y) + discretize(x)
>>> Would it help to work with g(rho,theta) and g2(v), with v = PI*rho + theta?
>>> Or, is there a package that understands f(x,y)? or g(rho,theta)?
>>> This feels "too easy" - leading me to believe that it's either dead wrong, or that someone has already implemented it.
>>> --
>>> Kenneth Sloan
>>> [hidden email]
>>> Vision is the art of seeing what is invisible to others.
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: SURFACE Fitter?

Kenneth Sloan-3
For the moment, I have a rectangular region, with dense samples occurring on sparse lines of constant y - but I'm coding to allow for the case where the region may be circular, with sampling lines arranged radially.

The x,y values are floats.  I didn't want to specialize the code for the current case, so I specify a precision for y and define:

     y = v*dy (where dy is the precision, and v is an integer.

and
 
     u = K*v*dy + x

For this particular dataset, the precision was far smaller than the spacing between slices.

I may have to do that for x as well, once I go to radial sampling.  More to your point, the radial sampling puts a lot of samples near the center.  I haven't decided yet if that is a bug, or a feature.  Most likely, I'll end up turning the raw data into an image (see below) and re-sampling that image, paying attention to sample density.

My function looks like:

      y = Z + A1*Gaussian1 + A2*Gaussian2

Where each Gaussian has:

       muX, muY, sigmaX, sigmaY

So, I count 11 parameters, one of which is an offset.

If I factor it as:

      y = Z + multiplyParam*(Gaussian1 + C*Gaussian2)

that does seem to help, a bit.  I'll try that when I return to this approach.  Based on preliminary results (shown below), I'm going to explore a slightly different approach, instead: take many radial re-samplings of the data, compute a 1D DoG fit to each radial slice, and then create an explicit (non-parametric) mesh from the fit curves.  That's my task for the weekend...  It was fun figuring out how to turn CurveFitter into a SurfaceFitter, and I don't regret putting in the time - but it may not be the right idea for the current project.

I suspect that the small number of iterations is because of:

a) the hints I provide are very good - these come from a 1D DoG fit to a slice through the center.  
b) the final fit is not really all that good.  (that is, the 2D DoG is not a particularly good model)

Note that the fit values for the various x,y and sigma values are all CLOSE TO the hints, but they are definitely different.  So, Curve Fitter did *something* in those 4 iterations.  One parameter that changed a LOT was the offset.  Perhaps the Amplitudes, as well.  The locations of the centers look really good (no surprise) and the sigmas look OK (I haven't really evaluated them, yet).

Attached are are plots. I haven't learned all the ins and outs of the Interactive 3D Surface Plot plugin, so the orientation seems reversed, but you should get the idea.  The first general observation is that the fit surface is generally HIGHER than the data.  The (not shown) pit at the center is much deeper in the data than it is in the fit surface.


--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

 
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Fitting2DDoG.jpg (975K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SURFACE Fitter?

Michael Schmid-3
Hi Kenneth,

the 3D plots in your attached image look very suspicious. If the right
plot is supposed to be the fit to the left one, there is something
wrong. The absolute values (z axis) are clearly different!

Without seeing the curveFitter.getResultString(), I have no clue what
had happened.

By the way, the general 2D Gaussian is given by

    a * exp (-b*(x-x0)^2 -c*(y-y0)^2 -d*(x-x0)*(y-y0))

so there is not only a sigma x and sigma y but also a mixed term.
Seen from the top, contour lines of the 2D Gaussian appear as ellipses;
the mixed term d*x*y is nonzero if the axes of the ellipse are not
parallel to x and y but under some angle.

But I fear that you have already too many fitting parameters without the
mixed terms. Your image looks like fitting with the same sigma for x & y
(and the mixed term being zero) would be quite good.


[Your attached image was not displayed by the Thunderbird mail program,
the Nabble mailing list site and probably also some other mailers. It
seems to be due to the old bug of Apple's Mail.app, which marks
attachments as "Content-Disposition: inline" instead of
"Content-Disposition: attachment"]


Michael
________________________________________________________________
On 03/04/2018 17:59, Kenneth Sloan wrote:

> For the moment, I have a rectangular region, with dense samples occurring on sparse lines of constant y - but I'm coding to allow for the case where the region may be circular, with sampling lines arranged radially.
>
> The x,y values are floats.  I didn't want to specialize the code for the current case, so I specify a precision for y and define:
>
>       y = v*dy (where dy is the precision, and v is an integer.
>
> and
>    
>       u = K*v*dy + x
>
> For this particular dataset, the precision was far smaller than the spacing between slices.
>
> I may have to do that for x as well, once I go to radial sampling.  More to your point, the radial sampling puts a lot of samples near the center.  I haven't decided yet if that is a bug, or a feature.  Most likely, I'll end up turning the raw data into an image (see below) and re-sampling that image, paying attention to sample density.
>
> My function looks like:
>
>        y = Z + A1*Gaussian1 + A2*Gaussian2
>
> Where each Gaussian has:
>
>         muX, muY, sigmaX, sigmaY
>
> So, I count 11 parameters, one of which is an offset.
>
> If I factor it as:
>
>        y = Z + multiplyParam*(Gaussian1 + C*Gaussian2)
>
> that does seem to help, a bit.  I'll try that when I return to this approach.  Based on preliminary results (shown below), I'm going to explore a slightly different approach, instead: take many radial re-samplings of the data, compute a 1D DoG fit to each radial slice, and then create an explicit (non-parametric) mesh from the fit curves.  That's my task for the weekend...  It was fun figuring out how to turn CurveFitter into a SurfaceFitter, and I don't regret putting in the time - but it may not be the right idea for the current project.
>
> I suspect that the small number of iterations is because of:
>
> a) the hints I provide are very good - these come from a 1D DoG fit to a slice through the center.
> b) the final fit is not really all that good.  (that is, the 2D DoG is not a particularly good model)
>
> Note that the fit values for the various x,y and sigma values are all CLOSE TO the hints, but they are definitely different.  So, Curve Fitter did *something* in those 4 iterations.  One parameter that changed a LOT was the offset.  Perhaps the Amplitudes, as well.  The locations of the centers look really good (no surprise) and the sigmas look OK (I haven't really evaluated them, yet).
>
> Attached are are plots. I haven't learned all the ins and outs of the Interactive 3D Surface Plot plugin, so the orientation seems reversed, but you should get the idea.  The first general observation is that the fit surface is generally HIGHER than the data.  The (not shown) pit at the center is much deeper in the data than it is in the fit surface.
>
>
> --
> Kenneth Sloan
> [hidden email]
> Vision is the art of seeing what is invisible to others.
>
>  
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: SURFACE Fitter?

Kenneth Sloan-3
Thanks - looks like I have work to do..

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.





> On 3 Apr 2018, at 12:45 , Michael Schmid <[hidden email]> wrote:
>
> Hi Kenneth,
>
> the 3D plots in your attached image look very suspicious. If the right plot is supposed to be the fit to the left one, there is something wrong. The absolute values (z axis) are clearly different!
>
> Without seeing the curveFitter.getResultString(), I have no clue what had happened.
>
> By the way, the general 2D Gaussian is given by
>
>   a * exp (-b*(x-x0)^2 -c*(y-y0)^2 -d*(x-x0)*(y-y0))
>
> so there is not only a sigma x and sigma y but also a mixed term.
> Seen from the top, contour lines of the 2D Gaussian appear as ellipses; the mixed term d*x*y is nonzero if the axes of the ellipse are not parallel to x and y but under some angle.
>
> But I fear that you have already too many fitting parameters without the mixed terms. Your image looks like fitting with the same sigma for x & y (and the mixed term being zero) would be quite good.
>
>
> [Your attached image was not displayed by the Thunderbird mail program, the Nabble mailing list site and probably also some other mailers. It seems to be due to the old bug of Apple's Mail.app, which marks attachments as "Content-Disposition: inline" instead of "Content-Disposition: attachment"]
>
>
> Michael
> ________________________________________________________________
> On 03/04/2018 17:59, Kenneth Sloan wrote:
>> For the moment, I have a rectangular region, with dense samples occurring on sparse lines of constant y - but I'm coding to allow for the case where the region may be circular, with sampling lines arranged radially.
>> The x,y values are floats.  I didn't want to specialize the code for the current case, so I specify a precision for y and define:
>>      y = v*dy (where dy is the precision, and v is an integer.
>> and
>>         u = K*v*dy + x
>> For this particular dataset, the precision was far smaller than the spacing between slices.
>> I may have to do that for x as well, once I go to radial sampling.  More to your point, the radial sampling puts a lot of samples near the center.  I haven't decided yet if that is a bug, or a feature.  Most likely, I'll end up turning the raw data into an image (see below) and re-sampling that image, paying attention to sample density.
>> My function looks like:
>>       y = Z + A1*Gaussian1 + A2*Gaussian2
>> Where each Gaussian has:
>>        muX, muY, sigmaX, sigmaY
>> So, I count 11 parameters, one of which is an offset.
>> If I factor it as:
>>       y = Z + multiplyParam*(Gaussian1 + C*Gaussian2)
>> that does seem to help, a bit.  I'll try that when I return to this approach.  Based on preliminary results (shown below), I'm going to explore a slightly different approach, instead: take many radial re-samplings of the data, compute a 1D DoG fit to each radial slice, and then create an explicit (non-parametric) mesh from the fit curves.  That's my task for the weekend...  It was fun figuring out how to turn CurveFitter into a SurfaceFitter, and I don't regret putting in the time - but it may not be the right idea for the current project.
>> I suspect that the small number of iterations is because of:
>> a) the hints I provide are very good - these come from a 1D DoG fit to a slice through the center.
>> b) the final fit is not really all that good.  (that is, the 2D DoG is not a particularly good model)
>> Note that the fit values for the various x,y and sigma values are all CLOSE TO the hints, but they are definitely different.  So, Curve Fitter did *something* in those 4 iterations.  One parameter that changed a LOT was the offset.  Perhaps the Amplitudes, as well.  The locations of the centers look really good (no surprise) and the sigmas look OK (I haven't really evaluated them, yet).
>> Attached are are plots. I haven't learned all the ins and outs of the Interactive 3D Surface Plot plugin, so the orientation seems reversed, but you should get the idea.  The first general observation is that the fit surface is generally HIGHER than the data.  The (not shown) pit at the center is much deeper in the data than it is in the fit surface.
>> --
>> Kenneth Sloan
>> [hidden email]
>> Vision is the art of seeing what is invisible to others.
>>  --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html