in reply to Re: Abstract image registration or feature detection
in thread Abstract image registration or feature detection [UPDATED w examples]
Thanks!
This looks interesting, but unfortunately it dies for me with Dim mismatch in matmult of 3x3 x 3x2: 3 != 2 at the print my $P = inv($G) x $Q; line. PDL version 2.057 on Perl 5.34.1, if that matters.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^3: Abstract image registration or feature detection
by pryrt (Abbot) on Jul 04, 2022 at 19:57 UTC | |
These are the outputs for my run (adding a print "perl version $]";print "PDL version $PDL::VERSION"; at the beginning to print the versions): <Reveal this spoiler or all in this thread> Mathematically speaking, a [3x3] x [3x2] is the right balance of dimensions for a successful matrix multiplication (resulting in a [3x2] matrix). The use of PDL::Matrix used to be the way to make PDL match mathematical order for the dimensions, but maybe they've changed that between 2.019 and 2.057. (I don't think I can test, because the Strawberry Perl PDL setup is rather dependent on the libraries that Strawberry bundles, and I don't know if upgrading PDL will work... maybe I'll try in a sandbox to avoid ruining my "main" installation). I tried getting rid of the use PDL::Matrix, but then that gets rid of the mpdl command, causing errors during perl's compile stage, and I'm not sure what hoops I would need to jump through to make my script compatible with both 2.019 and 2.057. | [reply] [d/l] [select] |
by pryrt (Abbot) on Jul 04, 2022 at 20:54 UTC | |
But I was able to install PDL 5.080 with Perl 5.32.1, to get slightly newer PDL but slightly older Perl than you. But it showed the same dimensional difference. So I did some debug to make it work without PDL::Matrix
This shows the 12-ish pixel error, but will hopefully work with your 2.057 (and definitely worked with my 2.080). | [reply] [d/l] |
by kikuchiyo (Hermit) on Jul 04, 2022 at 21:01 UTC | |
Minimal pair:
vs.
This looks like a bug in PDL::Matrix, specifically with inv. | [reply] [d/l] [select] |
by etj (Priest) on Jul 05, 2022 at 20:51 UTC | |
I would strongly encourage you not to use PDL::Matrix, because somewhat similar to PDL::Complex, it is full of gotchas. Even though after some head-scratching it became clear what exactly was happening here, it's not particularly clear how to fix it - a keyhole change to the Perl function PDL::MatrixOps::inv to make it ensure the output was the right class would resolve this exact issue. But since that uses lu_backsub for its work, and that is an eye-wateringly complicated Perl function as well, it will not be easy. That function's output variable comes from some PDL::Slices operations. If someone were minded to at least use git bisect to identify the commit that broke it, that would be very helpful. Even better would be a pull-request that fixes this (obviously with a test, in t/matrix.t), that will use our amazing CI to check it doesn't break anything else in main PDL or known downstreams. A top tip would be that make coretest runs t/matrix.t, with a very minimal build otherwise that allows a very quick dev cycle. As a hopefully practical (as well as better-performance, because it uses LAPACK) alternative, have you taken a look at PDL::LinearAlgebra? | [reply] [d/l] [select] |
by pryrt (Abbot) on Jul 05, 2022 at 19:28 UTC | |
Thanks for that SSCCE. I included it in a bug report | [reply] |
by etj (Priest) on Jul 05, 2022 at 21:26 UTC | |
| [reply] [d/l] [select] |