The inverse of the gradient function. I've provided versions that work on 1-d vectors, or 2-d or 3-d arrays. In the 1-d case I offer 5 different methods, from cumtrapz, and an integrated cubic spline, plus several finite difference methods.
In higher dimensions, only a finite difference/linear algebra solution is provided, but it is fully vectorized and fully sparse in its approach. In 2-d and 3-d, if the gradients are inconsistent, then a least squares solution is generated.
(I'll enhance the 2-d and 3d tools if there is any interest. Currently they are set to be 2nd order methods on uniform grids.)
Please notify me of any bugs.
Hi John, it seems like intgrad2 is shifting the solution by a certain amount. I checked this using a simple known 2D gaussian. I computed its gradient and then used intgrad2 to reconstruct the 2D gaussian. Then after comparing the reconstructed surface and the original gaussian, I found that the two were shifted from each other.
figure(1); subplot(1,3,1); surf(X,Y,fhat2); subplot(1,3,2); surf(X,Y,g); subplot(1,3,3); surf(X,Y,log10(abs(fhat2-g)))
will show the problem; g is the original gaussian.
Will really appreciate your help.
Hi John, I'm using intgrad2 to reconstruct a surface from 2D gradient data and the results are very good! However, the entire domain is slanting/has been rotated which means that a constant of integration is being added at every step unintentionally. Any suggestions on how this might be happening? I plotted my 2D gradient data to check if the error is cascading from there but they turned out fine. Will really appreciate if you could get back to me on this.
I actually modified this function for a domain in polar coordinates... indeed while the radial direction can be solved with central differences in the middle and backward and forward differences at the borders, in the tangential direction in order to guarantee the continuity of the function we need to apply everywhere central differences. The function as I said in 2015, can be used transforming everything in polar coordinates but when inversed back in the cartesian system present a discontinuity in theta=0!
First, let me say thank you for this great script. I have found it to be very useful for some research that I am working on. I read through the comments and I was wondering if you would mind making a few suggestions on how to make the code compatible with NaN values, or more specifically with a non-rectangular region of interest.
I saw you do not want to update your code, which I entirely respect. I was hoping to implement a change myself, but I would really appreciate some guidance.
Specifically, I use intgrad2 to integrate z-values over a surface in x,y space. There are regions of bad data that I would like for the algorithm to ignore, without using interpolation. It feels intuitive to somehow code these regions as NaNs and then have the least squares algorithm ignore those data points, but I am not sure what implementation might look like and would really value your opinion.
Your code is very great,and thank you for your share! However I met a problem. Lately I'm dealing with circular domain and I met the same problem which has been solved by Alessia, the upstairs. But I did not know how to do the transformation as my sensor is in cartesian coordinate system. Can you give me some advice? Thank you!
Hi, I just realized that I was wrong: your function can be used anyway even if my domain is circular.
I just need first to transform everything in polar coordinates and then still using your function.
Thanks a lot for that!
I personally find your function really great! It is useful, clean and simple to understand also for me that I'm not fully familiar in developing numerical methods.
I used it for free surface reconstruction from gradient map (see Moisy publication in EIF in which you are cited!)
Lately I'm dealing with circular domain and I'm wondering if at your knowledge someone (or you) implemented already the integration in cylindrical coordinates!
Indeed I have meaning data only in a circular region while around it is masked(being meaningless... Can be whatever value for me...), which means that the border of the circular region are affected by meaningless data around due to the integration scheme.
In your opinion, is it challenging to try to implement this integration in cylindrical coordinates or it exists a simpler solution?
Thanks and Regards!
I'm sorry, but It cannot handle NaNs, nor will I make it do so. You should fill them in FIRST using an interpolation scheme, and THEN use these tools.
Since there are multiple ways to fill in NaN elements in arrays, I see no reason to add that feature to an existing clean code, thus making it considerably more complex. Certainly if I chose one method to do the fill-in, then you would probably complain that I did not give you the way you preferred to see done. And if I offered every possible way I knew to fill in the NaN elements (I can quickly think of at least three methods) then the interface will get too complex.
The code does exactly what it is designed to do, and it does that very well. If you don't like it because it does not solve problems it was never designed to handle, then feel free not to use it, or feel free to write your own code, if you think you can do the job better.
Of Course, the integrated surface will have NaN points on the same places as the gradient since there's no gradient information there.
And the case of leading and forward edges fully equal to NaN for both x and y should also be considered.
Hi, your file is great, but here is something to make it perfect : managing NaN's in the gradient arrays' !
Especially for intgrad2 : I would like to generate a surface from a 2-arrays gradient where some point are set to NaN (same points in both arrays). I Imagine the function should then only solve the Least Square Problem on non-NaN points ?
Is it possible to have an update ? I wasn't able to make intgrad2 solve correctly the Least Square Problem skipping NaN's without generating big deviations on the rest of the surface. I would be glad to have some help ! I would put five stars for that :)
There is a bug in intgrad3 where the parameter checks in lines 84 to 96 check nargin against values that are -1 of the correct value, ie on line 84 (nargin<3) should be (nargin<4), etc.
I have tried your tool but it perhaps fails in case of functions with singularities..like (x+iy)...plz chek and update...
Thank you for this excellent tool. Should be included in Matlab.
I caught the bug in the example usage for the release I submitted this morning. Good point too about author and creation dates. I'll add them to all my files. Thanks, John
Rating =1 must be substantiated according to the ?Guidelines for Reviewing a Submission?- (provide specific information on what you like and dislike about the submission, use examples to illustrate your point... etc..). I would suggest to File Review Team to remove all ratings=1 that do not have specific critique as irrelevant and misleading.
Now, the specific critique :-)
1) help files are good, however they lack information about author and creation date.
2) minor -in intgrad2 help section function is called intgrad
Fixed bug for complex inputs
Upgrades to the 1-d cumulative integration code, for both accuracy and speed in the finite difference methods.
This release upgrades the finite difference approximations used in intgrad1. Higher accuracy is now achieved for non-uniform spacing, as well as the addition of a 4th order method.