All your assumptions are correct. Note that Ru is measured in the
original image (taken by the camera), whereas Rd is measured in the
destination picture (which is supposed to be undistorted).
--
Put Bad Developers to
My camera gives also a wrong focal distance ... I think it is also 0.
Maybe it is darktable bahaviour or that of the EXIF library.
Unfortunately, only a few cameras return the focal distance. And even
for them, only a few lenses do.
If vignetting has been already corrected in the camera, the remaining
vignette cannot be reliably corrected. Vignetting correction *must*
work on *linear* sensor data.
That said, unless vignetting is not over-corrected, everything is
fine. The human eye cannot see slightly under-corrected
GoPro hero in connection with LensFun means that somebody takes test
pictures and makes the calibration. The result of the calibration is
then incorporated into LensFun's database. See
http://wilson.bronger.org/calibration for futher information.
Thanks for the explanations.
At http://neothemachine.github.io/lensfunx/plots/dist.svg I now
plot r_d - r_u and at
http://neothemachine.github.io/lensfunx/plots/dist_rel.svg (r_d -
r_u) / r_u. Can you confirm if these look right? I am a bit worried
about the second graph as it doesn't match the
The 1.8 is approx. sqrt(1.5**2 + 1**2), i.e. half-diagonal in
normalised coordinates. And half-height is 12mm, and this is the
factor between normalised coordinates and real-world coordinates since
half-height is 1 in normalised coordinates by definition. Thus, the
half-diagonal of the sensor is
Hello,
I have been trying to get my RAW pictures taken with a Panasonic GF1
and the 20mm f1.7 lens corrected in darktable 1.05. But I can get no
correction made on the picture, and the list of lenses available do
not seem to be displaying the actual 20mm lens.
Any idea why the lens would not
http://lensfun.berlios.de/lens-calibration/lens-calibration.html
The manual doesn't say how you can actually test the results and add them to
lensfun's database.
--
Put Bad Developers to Shame
Dominate Development with
I've profiled one of my lens and would like to contribute the profile
to the lensfun database. I tried to send an email to Andrew but the
email bounced.
Where can I send the my profile?
BFC
--
Put Bad Developers to
There are a few lens definitions in the Patch section of the project.
It would be great if they were integrated eventually.
Thanks a lot.
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous
Hi, I wonder how to obtain version 0.2.5 directly from the code repository.
I see the tags/0.2.3 and tags/0.2.4, and there is the trunk.
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous
So here it is...
Quick hack for of the OpenCV calibration example. Check the README
for further instructions.
http://www.gmx.de/mc/QsL8tDXHTPE2GB1tndQIfNZLsammLn
This link is 14 days valid.
Johannes
--
Put Bad
It makes sense, if you have seen PTLens, DXOptics or any other program
that lets do lens correction (also adobe digital camera), they all
allow this. These parameters are more or less straightforward to
understand, especially if UFRaw will do realtime preview with lens
correction taken into
Ok I will try with other pictures with bigger overlapping aeras.
Thanks.
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test Deployment
Start a new
I followed with interest your discussion about converting Adobe
profile to lensfun. Trying to calibrate my lens with hugin, I searched
a more convenient way do get the distortion parameters. I almost wrote
some code, to get those parameters out of a checkerboard picture,
until i realised someone
Hi,
I'm pretty new to lensfun but have poked around a bit with it thru
Darktable, i had a D90 and made a tokina 11-16mm profile using the
documentation i found online...
The calibration was fairly good but didnt cut any high quality, and now when i
got myself a D700 i want to make some high
So far there's data only for Lumix LX3.
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test Deployment
Start a new project now. Try Jenkins in the
The code I pasted above is from ModifyCoord_UnDist_Poly5
It's not solving the inverse equation using Newton iteration.
Right, Newton integration is used in ModifyCoord_Dist_Poly5 which distorts the
image (e.g. solves the reverse equation Rd=f(Ru)).
Compare this from ModifyCoord_UnDist_Poly5
You can send the lens description to me, I'll submit it to SVN and it
will be automatically included in the next release.
10 measurements means that there's distortion correction data at
approximatively every 10 millimeters of focal length. I suspect this
is quite enough, if this particular lens
Oh, thank you, I haven't noted them - I don't get mail notifications
when a patch is added for some reason.
I will look into them right now.
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous
That's the code that was in release. I removed the push/pop in latest
svn commit, I wasn't aware gcc on x86 is so picky about ebx, and
haven't tested the x86/shared combination after last change.
If you have problems with SSE, you can always configure with
--vectorization= and leave SSE code
Well, Rd stands for radius distorted and Ru, respectively, for
undistorted. What I mean here is that Rd is the distance from
picture center to the distorted pixel (e.g. in the original camera
shot, which is distorted (and we want to rectify it)).
And right, I also noted the similarity between
You're supposed to compile the library separately, and then link your
project with it. You can build either a static or dynamic library, but
please use the provided makefiles. You have to run configure first
(you'll need Python for that), and use GNU Make.
1) I used two in tutorial to make things simpler and easier to
understand. With three photos you are more likely to get decent
results (e.g. more statistical data for hugin to chew)
2) For TCA its best to use shots of uniformely-colored things with
high-contrast edges, besides, all three R,G,B
Hey, you already know more than me ;-)
BTW if you haven't used Hugin before, you definitely must try it :-)
It's an extremely powerful tool as soon as you know what you're doing.
Lens calibration is just a small side taks for Hugin, it's main
destination is to make panoramas.
Woopsies...
cd $SRCDEST/$pkgname svn up
should be
cd $SRCDEST/$pkgname svn up; cd $SRCDEST
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test
I finally took a look at the ALPC licence and the licensing of the
community-contributed lens profiles.
I didn't see anything in the ALPC licence that suggested Adobe wants
to restrict you from doing things with the lens profiles you create
yourself.
As for the community-contributed lens
Not sure if the d parameter is necessary. The linked wiki entry says,
that d is calculated implicitly by pano12 (used by PTOptimizer,
PTStitcher and the GUIs) in order to keep the same image size. So I
assume this is redundant to the scaling parameter that can be set in a
different way in lensfun
Sorry that this is such a frustrating way to discuss this but I think
we're talking past each other.
The code I pasted above is from ModifyCoord_UnDist_Poly5
It's not solving the inverse equation using Newton iteration.
Compare this from ModifyCoord_UnDist_Poly5 again:
const float r2 = x *
Hi Andrew.
During the past months all my mails to you have bounched with
'delivery failure'. Have you changed your mail address?
I have several patches for lensfun.
Regards,
Niels Kristian Bech Jensen
--
Put Bad
So far I haven't found any lenses that needed more either, I was just
curious.
Good to know about duplicated entries in the database. Means I'll
have to remember to clean up my local database occasionally.
--
Put Bad
Thanks for the hints and your help getting this to compile. I need
your package for digikam. FWIW the source ArchLinux PKGBUILD is here,
and also the the 32bit and 64bit packages.
http://code.google.com/p/eth-os/source/browse/trunk/dev/lensfun/PKGBUILD
Isn't it the other way round?
When you calibrate a lens with a crop 1.0 camera you have information about the
distortion inside and outside of the crop 1.5 region of the same lens. So
fitting of the parameters should be more accurate.
When calibration is done with a crop 1.5 image you don't
OK. Like I wrote in the private email I'm working on improvements of
the correction parameters.
Meanwhile I got hugin producing usable parameters, but only when
hugin uses a, b and c correction parameters.
I currently have the interesting situation that for the focal length
5.1 mm I have 2
34 matches
Mail list logo
