You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue though is the process for installing Octave and oct2py is more complex than other things we rely on, requiring a separate install and a correctly configured PATH variable. This is also an issue for our CICD system since we do need to test this transform. The library you're using, oct2py, also seems like a rather small project whose long term support is not assured. I'd still recommend we look into some other solver (something wrapping eigen?) to avoid this dependency.
Hello, for now I've removed the octave dependency, now the code only uses scipy solver.
As far as my knowledge goes, there is no decomposition or iterative method that would make
the algorithm faster while preserving the results. I am also sharing some metrics for the comparison
of octave and scipy. I believe SciPy is not all bad, considering they also would optimize their sparse solver
over time.
For an image with 118677 pixels (around 350 x 350), using i7-13700K with 10 runs each:
Scipy mean time: 5.763958525657654 +- 0.2072540601999276
Octave mean time: 0.7772286891937256 +- 0.018855939984020915
I actually achieved satisfactory results with "Conjugate Gradients" method recently, it is of course not deterministicly solving the system so there will be some minor differences compared to the original one, yet I believe it is close enough and even not so, the user always can trade between accuracy and speed according to their need if the parameters controlling that is also given. I will soon push the new version.
Basically the 2 parameters controlling the algorithm are max_iter: maximum number of iterations taken by the algorithm, tol floating point numerical error to chech convergence, lower tol means better accuracy and slower operation. max_iter can also be used to put an upper limit for time required.
If you have any comments now, I can follow them before the initial commit, for example how to implement these "2-mode" behaviour one deterministic and the other iterative best in MONAI. You can of course also wait until initial commit if it makes more sense.
follow up of #6709
Hello, for now I've removed the octave dependency, now the code only uses scipy solver.
As far as my knowledge goes, there is no decomposition or iterative method that would make
the algorithm faster while preserving the results. I am also sharing some metrics for the comparison
of octave and scipy. I believe SciPy is not all bad, considering they also would optimize their sparse solver
over time.
For an image with 118677 pixels (around 350 x 350), using i7-13700K with 10 runs each:
Originally posted by @MrGranddy in #6709 (comment)
The text was updated successfully, but these errors were encountered: