Hello! I'd love it if this and mrcal could work together. Do you support mrcal .cameramodel files? If not, can you do that? Is your splined representation compatible with the mrcal splined stereographic model? If not, can it? Is your splined lens representation better in some way? If so, should mrcal use some of that logic? I didn't see any documentation about it. If you think the mrcal distribution methods could be improved, and are willing to help improve it, I would be very amenable. Let's collaborate to make both projects better!
Thanks for replying - I really admire your work with mrcal, and have used it for a while in my work. And lensboy is heavily inspired by mrcal.
> Is your splined representation compatible with the mrcal splined stereographic model?
No. It was a conscious design decision to only use pinhole models, at least to begin with. As I understand it, the tradeoff is that the pinhole model does not support ultra-wide lenses like the stereoscopic model does. But I have never used a lens that has a field of view close to the limits of pinhole models, so I just went with pinhole models.
However, if I understood your documentation correctly, the distortion model should be identical, it's just the core model that is different.
> Is your splined lens representation better in some way?
I'm pretty sure it's not - I based it entirely off yours, without trying to improve it. However, I did implement regularization slightly differently.
> I didn't see any documentation about it.
Unfortunately I have not written documentation as impressive as you have in mrcal, though I aim to. I wanted to get the project working as soon as possible to use it at work.
> If you think the mrcal distribution methods could be improved, and are willing to help improve it, I would be very amenable.
I actually did attempt this in this fork: https://github.com/Robertleoj/drcal (I'm sorry for the brazen phrasing in the readme, but I believe it is sligtly in the style of the name "numpysane").
The purpose of this was just to have functionality of mrcal but available on pypi, and with a build system I understand better.
However, I abandoned this, instead opting for making a library from scratch, partly because I had a hard time removing numpysane as a dependency (I want to have very minimal dependencies in this project).
I'm not sure how to reconcile this, but I'm happy to chat about what I did there.
> Do you support mrcal .cameramodel files? If not, can you do that?
I don't support them currently. I'd love to chat about doing this, even if loading them would lose some information because of different data models.
Don't hesitate to send me an email, you can find it on my github profile.
I would love for us to move past the idea that non-pinhole projections have "distortion", and we should strive to remove this "distortion" by reprojecting stuff to pinhole models. In practice, ALL projections distort straight lines and/or shapes and/or sizes, so if you use the pinhole projection everywhere, your images look like crap (see iphone wide-lens camera output for instance). Most of the normal non-pinhole projection functions work fine for wide lenses, while behaving like a pinhole lens with long lenses: https://en.wikipedia.org/wiki/Fisheye_lens#Mapping_function
This is real clunky from a browser. https://caltopo.com can do this from a map (right-click on the viewpoint, point-info, simulated view). The horizonator (https://github.com/dkogan/horizonator/) is a hackable implementation; has a FAST local gui, and can easily be extended to do other stuff.
Lots. Because many upstream projects don't have their build system set up to work within a distribution (to get dependencies form the system and to install to standard places). All distros must patch things to get them to work.
Well, there are big differences in how aggressively things are patched. Arch Linux makes a point to strictly minimize patches and avoid them entirely whenever possible. That's a good thing, because otherwise, nonsense like the Xscreensaver situation ensues, where the original developers aggressively reject distro packages for mutilating their work and/or forcing old and buggy versions on unsuspecting users.
There seems to be a serious issue with Debian (and by extension, the tens of distros based on it) having no respect whatsoever for the developers of the software their OS is based on, which ends up hurting users the most. Not sure why they cannot just be respectful, but I am afraid they are shoveling Debian's grave, as people are abandoning stale and broken Debian-based distros in droves.
Needless to say, Zawinski was more than a little frustrated with how the Debian maintainers do things.
But honestly, this took 30 seconds to Google and was highly publicized at the time. This whole "I never heard of this, link??" approach to defend a lost argument when the point made is easily verifiable serves to do nothing but detract from discussion. Which, you know, is what this place is for.
I wasn't defending anything; searching for xscreensaver debian debacle yielded links that might or might not have been what you were referring to, They did not, however, yield a link to the JWZ site.
reply