Announcement: Photoropter lens correction library
Robert
in the hope that this might be of interest to some people on this
list, I am posting this announcement on hugin-ptx. Have a look, and
let me know what you think. If you are interested in Photoropter's
development, you are welcome to join the project mailing list at
https://lists.berlios.de/mailman/listinfo/photoropter-users
Regards,
Robert
=== Announcement: Photoropter lens correction library ===
Photoropter is planned as a generic image transformation library with
a strong emphasis on lens correction. It already supports PTLens
correction and Hugin-compatible vignetting compensation (more to
come). The interface is (hopefully) clean C++, allowing for easy
integration into existing projects. To further that goal, the license
of Photoropter is the MIT/X11 license (i.e., a permissive license
which is compatible with the GPL and more or less every other license
on the planet).
In the (hopefully not too distant) future, I am also planning a camera-
matching module for automatic selection of parameters, but for now I
have enough on my plate getting the transformation infrastructure to
work properly (and fast!). But a lot of the 'mechanics' is in place,
hopefully.
What already works:
- PTLens & Vignetting correction
- Bilinear reconstruction/interpolation of the image (Lanczos will be
next)
- Oversampling of the result
- Multithreading via OpenMP
- Handling of arbitrary gamma correction functions: generic gamma,
sRGB gamma and EMOR are currently implemented
- Automatic conversion of correction parameters based on crop factor
and image aspect
- Region of interest support
More to come: especially more geometric and colour correction
functions (i.e., chromatic abberation, exposure shift etc.).
If you think that Photoropter might be useful to you, please visit the
project website at
http://photoropter.berlios.de/
for further information.
Pablo d'Angelo
> === Announcement: Photoropter lens correction library ===
Seems to be very similar to lensfun:
http://lensfun.berlios.de/
I think lensfun is really good, however, it never really got of the
ground nicely (its used by ufraw though), because adding new lenses etc.
is not as straightforward as it could be.
It would be great if the database storage could be kept similar or
easily convertible, so that both projects can feed of the same data.
ciao
Pablo
Robert
> Seems to be very similar to lensfun:http://lensfun.berlios.de/
>
> I think lensfun is really good, however, it never really got of the
> ground nicely (its used by ufraw though), because adding new lenses etc.
> is not as straightforward as it could be.
I know lensfun, and while the idea of having a PTLens replacement is a
good one, I have certain problems with it which prompted me to start a
new project after all. Let's just say I strongly disagree with
lensfun's design. It's full of C-isms and hard coding, there's nearly
no encapsulation, its programming interface is non-existent, and using
it means you essentially even have to write the image transformation
loop yourself.
I do not want to belittle Andrew's efforts, far from it. But lensfun's
design just makes using it unnecessary hard-- which is precisely what
Photoropter tries to fix. Then there's the build system (apparently
trying to fix autotools' flaws by supplementing it with custom python
code) which I also find very problematic.
> It would be great if the database storage could be kept similar or
> easily convertible, so that both projects can feed of the same data.
That used to be one goal, yes. But I am not sure this will be
sustainable, since the whole idea of separating 'lens' and
'sensor' (i.e., the camera body) data is problematic. Importing and
exporting of parameter sets itself is trivial, but one cannot load a
set of lens parameters, maybe even determined at a different crop
factor and hope to achieve any meaningful results (even if the library
can compensate for different crops, as Photoropter and lensfun both
can).
The only way to reliably correct for image flaws of a given system in
a physically 'correct' way is to identify the optical system as a
whole (this means sensor _and_ lens). The most one can do really is to
regard the lens database as a set of templates. However, at the moment
Photoropter is not concerned with the lens database part at all (yet).
For a little while, this will remain on the todo list.
Regards,
Robert
Daniel Reetz
> Hi all,
>
> in the hope that this might be of interest to some people on this
> list, I am posting this announcement on hugin-ptx. Have a look, and
> let me know what you think. If you are interested in Photoropter's
> development, you are welcome to join the project mailing list at
>
> https://lists.berlios.de/mailman/listinfo/photoropter-users
Hi Robert,
How can a non-developer with good knowledge about optics and sensors
contribute?
Regards,
Daniel Reetz
Robert
> Hi Robert,
> How can a non-developer with good knowledge about optics and sensors
> contribute?
Well, for one I could use some reference material (i.e., a distorted
image with corresponding correction parameters), if possible for
different distortion models (there exist more models than just PTLens,
and I will implement what I can find; however I currently do not know
which ones are actually used 'in the wild'). Also vignetting and
especially some test material for chromatic aberrations.
Other points are: possible concepts of how to store the camera/lens
information in a meaningful and flexible way (including corresponding
identification heuristics) so that the user still can easily add
custom data (and ideally share it), how to deal with e.g. centre
shifts on different cameras, how could/should the user interface look
like (though Photoropter is only the backend, this quite directly
influences the design) etc.; I have been thinking about these points
for quite some time, but there's still plenty of room for discussion.
Also detailed information on all sorts of colour transformations would
be nice (a topic where my technical knowledge still has a few painful
gaps), possibly doing some testing, reviewing parts of the technical
background documentation for Photoropter as/when it is written etc.
But perhaps we should really shift the discussion to photoropter-
users, then.
Regards,
Robert