Timeline for Is it possible to improve a code related with iterative closest point (ICP) algorithm?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 11, 2022 at 6:30 | history | edited | Henrik Schumacher | CC BY-SA 4.0 |
edited body
|
| Nov 29, 2021 at 9:04 | history | edited | Henrik Schumacher | CC BY-SA 4.0 |
deleted 20 characters in body
|
| Nov 29, 2021 at 9:03 | comment | added | Henrik Schumacher | Glad to hear that! You're welcome! | |
| Nov 29, 2021 at 8:06 | vote | accept | GaAs | ||
| Nov 29, 2021 at 8:05 | comment | added | GaAs | Thank you for the discussion of Newton's method and the writing the new code. This code is very fast and the result is good!! Also, your detailed comments made the code easy to understand for me. | |
| Nov 26, 2021 at 18:21 | history | edited | Henrik Schumacher | CC BY-SA 4.0 |
added 2092 characters in body
|
| Nov 26, 2021 at 16:47 | comment | added | GaAs | JFYI, when I use my ICP-algorithm code in practice, I first set a wide shift range and process X→Y→Z, then narrow the shift range and step width and process X→Y→Z again. In some cases, a third X→Y→Z process is also performed. The purpose of the above flow is to avoid convergence to a local min. | |
| Nov 26, 2021 at 16:34 | comment | added | Henrik Schumacher | @DanielLichtblau Yes, I think there are plenty of local minima with this type of fitting problems. =/ | |
| Nov 26, 2021 at 16:08 | comment | added | Daniel Lichtblau | Good point. So maybe it converges to a local min? | |
| Nov 26, 2021 at 15:42 | comment | added | Henrik Schumacher |
@DanielLichtblau Nah, one should never use the the objective as residual. In here, F can typically never be 0 because it is not guaranteed to find a perfect fit. u is the Newton search direction, so its norm is very, very good residual to be used for the stopping criterion. (If the Newton search direction is zero then one has to be in a critical point.
|
|
| Nov 26, 2021 at 14:54 | comment | added | Daniel Lichtblau | The residual u.u looks suspicious. Maybe should be F/Length[z]^2? | |
| Nov 26, 2021 at 13:03 | comment | added | Henrik Schumacher |
Hmm. DF=Total[Abs[Y-Z]] doesn't make sense. I have to look into this later...
|
|
| Nov 26, 2021 at 12:23 | comment | added | GaAs |
Even in the modified version, the target data after the shift does not seem to match the reference data well. At least, I thought the DF=Total[Y-Z] should be DF=Total[Abs[Y-Z]], what do you think? However, even with this modification, I did not get a successful result.
|
|
| Nov 26, 2021 at 10:59 | comment | added | Henrik Schumacher | Ah, I think I found the issue. I posted a second algorithm. | |
| Nov 26, 2021 at 10:54 | history | edited | Henrik Schumacher | CC BY-SA 4.0 |
added 2076 characters in body
|
| Nov 26, 2021 at 9:50 | comment | added | GaAs | I thought your code might be an algorithm to match the center of gravities of the reference and target data. The algorithm I want is one that shifts the target data so that "a part of" the target data matches the reference data well. This implies that I know in advance that "a part of" the target data has a similar shape to the reference data, but there is unknown xyz-offset in their relative positions. | |
| Nov 26, 2021 at 8:27 | comment | added | GaAs | Thank you for considering my question and writing the new code. I'm still trying to figure out what your code does due to my writing skill level, but I checked the results first. The speed it took to execute was significantly faster than my code (even with a data size on the order of 10000, it was fast!). On the other hand, compared the result with my code, the degree of match with the reference data seems to be better in my code. Do I need to adjust the hard-coded parameters? | |
| Nov 26, 2021 at 7:57 | history | edited | Henrik Schumacher | CC BY-SA 4.0 |
added 59 characters in body
|
| Nov 26, 2021 at 7:36 | history | answered | Henrik Schumacher | CC BY-SA 4.0 |