New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Double sphere model #7
Comments
Hi Andreas. Glad you're finding the tools useful.
Thanks for the paper. I have no plans to implement any more parametric
models, but if you're open to doing the work, I will gladly accept
patches. Let me know if you're interested, and we can make a plan about
what should happen.
For this model specifically, no matter how clever the double sphere
model is, 8 parameters just isn't enough to represent all lenses without
non-negligible fit errors. Unlike other toolkits, mrcal actually solves
this problem conclusively: splined models. Described here:
http://mrcal.secretsauce.net/splined-models.html
These are as rich as you want (I usually have about 500-1000 parameters
per lens), so they fit VERY well. And they produce reliable uncertainty
estimates. I encourage you to try it.
|
I will do a quick review of the codebase today with respect to implementing the double sphere and EUCM models. If you prefer another way of communicating let me know. |
Andreas Lindahl Flåten ***@***.***> writes:
I will do a quick review of the codebase today with respect to
implementing the double sphere and EUCM models. If you prefer another
way of communicating let me know.
Excellent. Thanks. I'd prefer email, but this is fine (I'm reading and
writing this in an email client anyway). Feel free to email me; the
address is in the mrcal docs.
Adding new models to mrcal is still a bit messy, but it'll be cleaned up
as more support is added. To add new models you should add
- The code itself. Projection and unprojection. With gradients. This
will live primarily in mrcal.c
- Python support. Probably this will "just work" with minimal changes,
but we should check
- Documentation
- Tests
Start with origin/master. It has a lot of stuff that the latest release
(v2.3) doesn't have.
From the paper it looks like the logic is fairly simple. And we can
compute the gradients analytically, by hand. If so, you should implement
this like "LENSMODEL_CAHVOR". Do a "git grep -i 'cahvor[^e]'", then go
through each hit (each spot where something cahvor-related happens) and
add the relevant code for your new model(s). This should cover
everything (implementation, Python support, docs, tests). Some notes:
- The "test-cahvor.c" test is cahvor-specific, and you don't need to
make a similar thing for your models.
- mrcal supports a "cahvor" file format for its models. This is
different from the "cahvor" lens model. So anything in the grep that
refers to the "cahvor" FILE FORMAT, you can ignore. Sorry, this was
necessary to be compatible with stuff. So you can ignore cahvor.py and
any hits in cameramodel.py and mrcal-to-cahvor and mrcal-from-cahvor.
- I believe the models you're talking about don't have any adjustable
parameters that shouldn't be up optimized, right? This is the
"configuration" in mrcal. This is stuff like the spline density in a
splined model. If so, doing what cahvor does is right.
If you need a bit more complexity, you can mimic the behavior of
"cahvore" instead of "cahvor". This has a configuration, and is more
complex, so the gradients are implemented with automatic
differentiation. You can choose to do that, if you like, but for simple
stuff I'd prefer to do it manually.
OK Once you update all the spots that come up in the grep, it should
work: tests should run and pass. You should be able to read and write
these models. And solve for them.
One feature of these new models you're talking about is an analytic
unprojection function. If you get it working by doing what cahvor does,
mrcal will still be doing a numerical unprojection. This works, but is
slower. I think we should get it running first, and once we're happy
with the implementation, we can make the unprojection smarter.
And, you really should try the splined models. You might discover that
they're what you REALLY want :)
Thanks for considering to work on this. Let me know if anything is
unclear
|
Also don't worry about
- test/test-convert-lensmodel.py
- test/test-cameramodel.py
|
Thanks a lot for all the info :-) I don't have any time estimate yet, but I will keep you posted. Might just keep communicating here in case anyone else is interested in the progress on this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
First of all thanks for making this software freely available. I'm impressed by both the quality of the documentation and ease of use.
Are there any plans on implementing the "double sphere" camera model as explained in this article: https://arxiv.org/pdf/1807.08957.pdf ?
edit: Or the UCM/EUCM models. It's not impossible that I delve into implementing this myself, but I would like to know what @dkogan thinks about this first.
alf
The text was updated successfully, but these errors were encountered: