-
-
Notifications
You must be signed in to change notification settings - Fork 73
Pinhole camera with distortion #320
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
Pinhole camera with distortion #320
Conversation
|
Hi @asmaloney , Thanks again! |
|
Hi Vladislav! Thank you for your PR. This library is not a priority for me, so I may not get to a full review for a while. (And I have been away/mostly offline for a couple of months.)
I think I would prefer a pointer to a struct that's allocated if the extension is active. I have ideas on how extensions should be handled in the "simple api" case. The current method of just piling everything into the main structs is not a great plan. A pointer would make changes easier for people later on if I get around to handling this properly.
You can do a pull request in the other repo or we can arrange for you to send me the file(s) and I can add them. The key problem with the test repo is going to be the size, so I would prefer the smallest examples you have that are useful for testing. |
|
Hey Vladislav. I mentioned a couple of things in my last response: (1) switching this code to using a pointer to a struct that's allocated if the extension is active and (2) submitting test files for the test repo. If you have the time to do that, I can take a look at reviewing & merging this in the next release (3.4). |
|
Hello @asmaloney, I’ve updated the code, and it now uses a pointer to the struct instead of the Regarding the second point: the writer test in the About the generated test file: its size is 122K. Is that acceptable? If not, the main storage cost comes from the attached image file, which isn’t needed for this test. Currently, I reused the existing Lastly, in the official extension specification code examples, they always first check if a field is defined before reading it: if(distortion.isDefined("dist:CV_P1"))
CV_P1 = FloatNode(distortion.get("dist:CV_P1")).value();What do you think—should I follow this pattern, or is my current implementation sufficient? |
|
Thanks Vladislav! I'll make some time to review this (and answer your questions) over the next couple of weeks. |
|
@kidal5 Could you please rebase this onto master? |
0d756db to
894d8e3
Compare
|
Sure, just rebased. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes I'm requesting are mostly naming. I want to ensure that it's clear when data is from an extension. (The normals stuff should have been handled like this as well, alas that ship has sailed for now...)
If you have a 1x1 PNG or JPEG handy, we should add that to the test data repo and use it for creating these test files.
|
All requested changes are added. Also created pull request into test-data repository with test files. |
|
Updated the code - now all CI checks should finish. |
|
Thanks Vladislav! 🎆 |
Hello @asmaloney,
I have implemented the functionality to both read and write pinhole camera distortion parameters in accordance with the standard extension. You can refer to the specification here: E57_LEICA_Camera_Distortion.txt.
Additionally, I have added tests to verify the correctness of my implementation. I have also tested reading other files, although I cannot share them publicly.
I do have one question regarding your library's design choices. To handle the optional nature of the distortion parameters, I introduced an
initializedfield within thePinholeCameraDistortionstruct to indicate whether the distortion parameters have been set. Would you consider this the correct approach? I would have preferred to usestd::optional<PinholeCameraDistortion>, but this requires C++17 support.Also, what is the workflow for adding test data into test data repository.
I hope you find this pull request useful and look forward to its review and possible merge.