Double sphere model

[anlif]

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

[dkogan]

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.

[anlif]

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.

[dkogan]

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

[dkogan]

Also don't worry about

• test/test-convert-lensmodel.py
• test/test-cameramodel.py

[anlif]

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.

[dkogan]

Greetings! Are yall still thinking about doing this at some point? I can help, if you ask. Otherwise, I'll close this report.