Re: [Lensfun-users] translation → slr-ussr.xml
Hallöchen! Timur Irikovich Davletshin writes: > I see that entries in slr-ussr.xml are only partially > translated. So I translated the rest. File is in the > attachment. It's not a big deal, just a bit annoying to see them > split in two groups (one Russian name and another in Latin). Thanks, I added your contribution! Tschö, Torsten. -- Torsten Bronger smime.p7s Description: S/MIME cryptographic signature ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Some missing Fujifilm cameras
Hallöchen! Guido Scholz writes: > as I found the current lensfun database does not list my Fujifilm > X-H1 and some other models as well. Does someone care to add > these: > > [...] Thank you, I added the cameras! Tschö, Torsten. -- Torsten Bronger smime.p7s Description: S/MIME cryptographic signature ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Lensfun: the past, the current state and the future
Hallöchen! Sebastian Kraft writes: > [...] > > In 2016 I started to refactor most of the library internals as it > turned out that its structure cannot be extended, e.g. with the > perspective correction now available in the alpha release, and was > really difficult to maintain. A lot of code has been modernized > and cleaned up to make Lensfun ready for the future. But > unfortunately, the time I can spent in coding for the Lensfun > project since then has decreased a lot and today the project is > more or less stalled. I think the main challenge has been that many things had to be changed at the same time -- it was not possible, or at least not obvious to me, how to separate it into smaller chunks. And this big change could not be handled given the restricted resources. I still don’t see how this can be made in smaller steps. The good news is that most of the path to the next release is behind us, at least in my estimation. The goal should be to get a working release, possibly together with patches against Darktable to use the new API. It needn’t implement all planned things. Just working. Then, we can take a deep breath and move on. In particular, then new people can join the code development sensibly. Currently, they would have a tough time to understand the code. My own agenda (until August, when I have an additional toddler around me): - Fix the cronjobs so that new uploads end up properly -- done. - Make the ownCloud directory consistent with the GitHub issues -- done. (70 new profiles in the pipe. Ye...ah!) - Create additional consistency checkers that send me mails when something wents wrong again -- done. Not done: - Crawl through all issues to filter out unusable uploads and place questions to the uploaders where necessary. - Answer the 60+ Lensfun-related emails in my inbox of the last 12 months. - Work through the tickets on Sourceforge. - Move the whole project from Sourceforge to GitHub. Except for the Mailing list. - Work through the Pull Requests of GitHub. - Open the calibration workflow so that it works completely without me. - Do the 140 calibrations. Argh! Now for the code: - Find the best internal coordinate system. The current distortion one, the current vignetting one, the Adobe system, …? - Implement that coordinate system. - Finalise the API changes. Argh! - Patch Darktable to work with the new Lensfun API. - Make a release. - Do all the other things that Sebastian mentioned. Help is welcome, especially senseful in the following areas: - Identify unusable calibration uploads. - Do the calibrations, find further calibrators. - Triage, possibly resolve, non-upload tickets and issues on GH and SF. - Patch DT for the new Lensfun API (once we know how it looks like). - Move to GitHub. Regards, Torsten. -- Torsten Bronger ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Wrong corrections applied on Alpha 6300 with E 16-50mm f/3.5-5.6 OSS PZ?
Hallöchen! Jean Bruenn via Lensfun-users writes: > [...] > > Oh right. Thanks. Then there's still the distortion / wrong > correction which can be seen in the overlay.jpg left. Any idea on > that one? Or does that have to do with the vignetting-part? I find the difference negligible. In particular, it is not wrong. Note that Lensfun’s correction bases on its own distortion measurements, and the Sony engineers have made their own measurements. It is only natural that the results are not exactly the same. Regards, Torsten Bronger. -- Torsten Bronger ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Question about radius normalization
Hallöchen! Philipp Weber writes: > I have one question concerning the radius normalization. For the > poly5 model there is a reference to > imatest.com/docs/distortion.html where it says, /"r_d / is the > distorted (measured) radius normalized to the center-to-corner > distance". Is this the case for all models? So is the radius > radius equal to 1 for the corners which would mean that the radius > can never become bigger than 1? The poly5 model of Lensfun uses the same normalised coordinate system as the poly3 and ptlens models: "1.0" is half of the image height (in landscape mode). Thus, the value is bigger than 1 on the corners. Regards, Torsten Bronger. -- Torsten Bronger ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Latest Database Files For Windows Users
Hallöchen! John J Bloomfield writes: > [...] > > I did it a couple of months ago using the folder located at > http://wilson.bronger.org/lensfun-db/version_1.tar.bz2 as > mentioned in one of the project mailing list archives > > But I am now wondering is that folder/file being updated or was it > just an idea that isn't being maintained? It is maintained. Unless my computer has serious trouble, at least. > If it is being maintained perhaps it would be a good idea to make > the link more obviously available? It is meant to be used by a program only -- lensfun-update-data -- and therefore, I don't plan to advertise it specially. Sometimes I have to point people to http://wilson.bronger.org/lensfun-db/version_0.tar.bz2 because that is for Lensfun users with versions too old to be shipped with lensfun-update-data. Regards, Torsten Bronger. -- Torsten Bronger -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Panasonic DMC-LX15 profile
Hallöchen! Thank you for your institution! Magnus Hagdorn writes: > [...] > > I think there might still be some issues with the parameters for > the widest focal length. I will update when I get around to. Do theses issues mean that we should not yet include that data? Regards, Torsten Bronger. -- Torsten Bronger -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Lens profile for the DJI Mavic
Hallöchen! Diogo Sousa writes: > I have created a profile for the DJI Mavic Pro FC220. I'm > submitting it for inclusion in the lens profile database. Thank you, I included your data! Tschö, Torsten. -- Torsten Bronger -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Adding the ILCE-7MR2?
Hallöchen! Kelvie Wong writes: > Could this be added to mil-sony.xml? > > > Sony > ILCE-7RM2 > Alpha 7R II > Sony E > 1 > Thank you, I included this entry! Tschö, Torsten. -- Torsten Bronger -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Creating a more flexible formula for vignetting correction?
Hallöchen! Roman Lebedev writes: > [...] > > I'd expect that for not-broken-by-design situations, i.e. in > 99.99% cases, the parametric formula is better in any regard. Do > you plan on including these vignetting bitmap profiles into the > lensdb.xml? If yes, how is it going to be made sure that such > bitmap is _only_ added for the terminally-broken situations? Just > curious. This is in its very early stages. I cannot give definite answers. But my motivation for flatfields is not vignetting. In fact, I only mentioned them in this thread because they may help with exotic vignetting problems, and this seemed to be such a problem. I want to have flatfields in Lensfun to fight coloured corners and sensor dust. Obviously, the profiles for sensor dust will be huge (only little downsampling possible), personal, and time-dependent. So nothing for an XML file, and not for a public DB. I'm not even sure whether Lensfun is the proper library for that in the first place. As for coloured corners, I don't know yet whether they are will be in XML form, and whether the profiles go into the public DB. After all, they are only valid for a *combination* of sensor and lens. Tschö, Torsten. -- Torsten Bronger -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Vignetting correction for wide-angle lenses.
Hallöchen! junkyardspar...@yepmail.net writes: > [...] It occurs to me that the distance between element and > diffuser is probably twice as much at the edges as at the > center. On an opaque object this would obviously result in > signifcantly reduced light at the edges, but I don't understand > optics well enough to know if this is relevant to the image > projected on the sensor through a bunch of glass... Theoretically, this is not a problem. If you have a large wall which emits light uniformly in all directions (https://en.wikipedia.org/wiki/Lambertian_reflectance), the *distance* doesn't matter. But in practice, I believe that it is very tricky to do this right, and even more so to validate it. Especially stray light is difficult to manage. Tschö, Torsten. -- Torsten Bronger -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Accuracy and testing of lens profiles
Hallöchen! Oliver Bedford writes: > [...] > > Example values: > > a; b;c; computed using 4 images: > > 0,032214; -0,105173; 0,069074 > > computed using only one of the images: > > 0,031828; -0,100712; 0,058477 > > Is this normal or an indication of bad images used for > calibration? It is probably okay. You may check the residual errors. For this, I open the preview in full-screen. If the error is smaller than 1.5px, it is okay. > Is there a simple way to test (aka see in action) the computed > values? I tried it through Gimp + GimpLensfun, but my entry > ./local/share/lensfun/test.xml doesn't get included in the lens > list. The file itself gets loaded - I get an error message, when > it contains garbage (but only if before ). What does the entry look like? Tschö, Torsten. -- Torsten Bronger -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] [BUG]insufficient undistortion
Hallöchen! Hartmut Knaack writes: > Appearance > == > > Following Torsten Brongers calibration guide, I took Raw photos of > a modern building with my Canon Powershot SX160 IS using CHDK. The > TIFF files created by calibrate.py were processed with the method > described in the vimeo tutorial. This way, I created my custom > lensfun.xml file [2]. Please try to add an aspect ratio tag to the lens. I suspect the camera produces 4:3 images, however, Lensfun assumes 3:2 by default. If this doesn't help, I dig deeper. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Lens calibration looking for help
Hallöchen! junkyardspar...@yepmail.net writes: >> Matthias Andree writes: >> >>> I also looked through the older materials on calibration and >>> have been scratching my head over the illumination of vignetting >>> test images, how do you get good ones. >> >> [...] > > I found another interesting possibility for this recently, in the > form of OLED mobile device screens. [...] I haven't had an OLED screen in my hand so far but evenness is only one thing. The other thing is independence of direction. If you tilt the screen, it must have the same brightness, with a tolerance smaller than what could be evaluated with the naked eye. Therefore FWIW, I would not accept images taken with an OLED screen. If you put a sheet of paper inbeween, it might be okay, though. > Anyway, I'll try to get to some of the calibration chores too, > pending updated hugin instructions. So I should send you access credentials? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Lens calibration looking for help
Hallöchen! Matthias Andree writes: > [...] > > Is there a list of lenses/cameras contained in those uploads? > Just to prevent someone taking more calibration images of a combo > that someone already uploaded... That's a good point, but I don't have that. On <http://wilson.bronger.org/lens-list.txt>, you can review the content of the uploads directory. The names are already changed by writing EXIF data into the filenames. But still, this list is of limited use, and I don't like to advertise it. Note that 40% of all uploads eventually turn out to be unusable. Mostly I get better ones from the original uploader, but not always. Besides, in some cases, the actual lens model is found out only during the calibration. My goal is to have so few uploads pending that a collision is very unlikely. It used to be like that. > I also looked through the older materials on calibration and have > been scratching my head over the illumination of vignetting test > images, how do you get good ones. It is less critical than it seems. A diffuser in front of the lens is always necessary, but in contrast to earlier texts of mine, I now think it can even be paper (if absolutely level of course). The actual ilumination should not cast a visible gradiant of the diffuser but unless somebody points a laser pointer to it, I think this will work in all practical cases. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Lens calibration looking for help
Hallöchen! After some 400 lens calibrations, I currently don't have the time for doing further calibrations in time. New job. 58 uploads have to be processed still, therefore, I am looking for help. Here is the plan: I set up an ownCloud server and a GitHup repo. People interested in helping get access to both. Every upload creates an issue in the repo. The details of the workflow are outlined here: https://github.com/lensfun/lensfun/blob/master/tools/calibration-webserver/workflow.rst I hope to get the calibration business on track again with that. Besides, a single point of failure never is a good idea. I will continue to calibrate myself, I just hope to do it not alone. Over the next days, I will write an HOWTO for calibrators. Moreover, I will create a new screencast showing how to use the latest Hugin for this. And of course, I will be responsive in the issues. If you are willing to help – much or little – send me an email. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Canon PowerShot SD1100/IXUS 80
Hallöchen! Jonathan Niehof writes: > In short, the attached snippet contains full (distortion + TCA + > vignetting) lens information for the Canon Powershot SD1100 IS/IXUS > 80. Thank you very much for the very thorough work! > Caveats: the distortion information is from the existing IXUS 80 > information in the database. I added TCA and vignetting data to the > IXUS 80 and copied it to the SD1100. But I think the old distortion data referred to JPEG imags, which may have seen already anti-distortion. Dos the data also work fpr DNG images? > This is the older database format since I'm still running lensfun > 0.2.8 (Ubuntu 15.10) and wanted to make sure it worked with my > current darktable. AFAICS, there is no difference between both Lensfun version in this case. > This camera doesn't have an adjustable aperture, but an ND8 > filter; when the filter is in, the camera reports the "effective" > aperture in the EXIF data, i.e. an aperture that would give the > same brightness. Do both cameras have that? > I'm assuming the ND filter doesn't affect the vignetting or TCA. If at all, it should be negligible. It may have a slight prism effect for the corners, but let's ignore that. > [...] > > I made a lenses.txt file with the distortion from the existing IXUS80 > in lensfun.xml, but with a changed first line: "Canon PowerShot SD1100 > IS: Canon, canonSD100IS, 5.9". I edited line 169 of calibrate.py to > default to "Canon PowerShot SD1100 IS" (matching the exif) instead of > "Standard". Matching the EXIF of the camera model or the lens model? Typically, the lens model field is empty for compact cameras. (I don't know for CHDK, though.) > For TCA, [...] > > I shot vignetting [...] Just to be sure: Both TCA and vignetting refer to DNGs, correct? > For the XML, I copied the IXUS 80 verbatim (both camera and lens), > then changed model tag to match Exif.Image.Model (which is the > same as Exif.Image.UniqueCameraModel), made the lang en a short > version, and named the mount similarly. I populated both the IXUS > 80 and the copied SD1100 lens calibration with the new TCA and > vignetting data. If both data is the same, I would give the SD1100 the IXUS 80 mount. This way, the first simply re-uses all calibrations for the second. > The vignetting already had two lines per focal length (near and > far distances); I added two more lines for smaller aperture, based > on the camera-reported effective aperture with the ND filter > in. Note that, as with the IXUS 80, the crop factor is 6.1 for the > camera and 5.9 for the lens (based perhaps on full area vs. JPEG > area?) Actually, bot must be the same Otherwise, your calibration data would not be applied accurately. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] [RFC PATCH 0/4] Implement XML validation via xmllint at build time.
Hallöchen! Roman Lebedev writes: > This will allow to do *some* verification of the database XML's > at the build time. Well, each time make is run. I just re-found check_database.py. Maybe the checks shoudl be incorporated into that and connected with a Git hook? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] RFC : Lumix FZ1000 Distortion correction
Hallöchen! Helmut Jarausch writes: > [...] > > I've modified the lensfun data in my installation according to > your suggestion. [...] The two images are very different. Well, I could only use gnuplot, so it was kind of "blind flying" for me. Would you mind uploading the 25mm-close-focus image pair somewhere, e.g. at http://wilson.bronger.org/calibration? Thanks! > Even if there would be some additional transformation it would too much > work: > > darktable / export / Gimp rescaling + cropping / import into > darktable. Yes, this is not senseful. > [...] > > Perhaps I can find a way to patch Rawtherapee which doesn't use > lensfun. If you prefer DT over RT, patching Lensfun allows for a simpler workflow. Possibly the following – hopefully not too tedious – background info is helpful for you to understand the implications of that polynomial. Mathematically, if scaling doesn't matter to you, the a,b,c,d set becomes under-determined, and you can set any of the parameters to a non-degenerated value without losing accuracy, which I did in the post with the transformation method. An overview of different models gives <http://wilson.bronger.org/lensfun/group__Lens.html#gaa505e04666a189274ba66316697e308e>. As you can see, only the Hugin-inherited models have d not equal to 1. Both Imatest and Adobe (Lightroom) set d=1. Note that Adobe has five parameters, but no d nevertheless. On <http://www.panotools.org/dersch/barrel/barrel.html>, Helmut Dersch, creator of PanoTools and an active researcher in this field, discusses the polynomial and explains that "d" is the scaling parameter. I scales in the sense that it changes the scale in the centre of the image, i.e. in the <https://en.wikipedia.org/wiki/Paraxial_approximation> (where the focal length is defined). Of course, one cannot just change d and the image gets bigger or smaller, the other parameters must be changed, too, which is why I removed a misleading part from the PanoTools docs: http://wiki.panotools.org/index.php?title=Lens_correction_model=14463=14358 By the way, for Lensfun, d != 1 is really unfortunate, because we need to preserve the effective focal length for certain algorithms. Thus, Lensfun jumps through some hoops for un-doing the scaling. Hope this clears up some things ... Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] RFC : Lumix FZ1000 Distortion correction
Hallöchen! Torsten Bronger writes: > [...] > >> What you are suggesting is to rescale Rd -> d*Rd which is not >> allowed. > > If you scale Rd, which is used for the look-up, this is a uniform > scaling of the original image. Here, I was wrong. If you scale Ru, it is a uniform scaling. Rd indeed must not be scaled. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] RFC : Lumix FZ1000 Distortion correction
Hallöchen! Torsten Bronger writes: > [...] > > This may happen with a bad calibration. But whether you use > a',b',c',d' or a,b,c has no effect on accuracy. In fact, both can > be transformed into another: > > a = a' / d'^4 > b = b' / d'^3 > c = c' / d'^2 Here, I was wrong. The transformation is indeed possible, but it is not that simple, see my other post. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] RFC : Lumix FZ1000 Distortion correction
Hallöchen! Helmut Jarausch writes: > On 06/16/2016 05:31:05 PM, Torsten Bronger wrote: > >> Helmut Jarausch writes: >> >>> On 06/16/2016 01:52:38 PM, Torsten Bronger wrote: >>> >>> [...] >>> >>>> [...] But can't you just use the Lensfun formula in Octave? >>> >>> Of course, I could, but it won't make sense. As one can see in >>> the table below, the sum of the coefficients is (significantly) >>> smaller than 1. >> >> But if you replace d with 1-a-b-c, and you should get different >> values for a, b, and c, namely those for which a+b+c+d = 1. > > Yes, but I don't want this. [...] Okay, fair enough, but it would work and does not affect accuracy. >>> If one compares a raw image which has been processed without lens >>> correction with the JPEG file coming from the camera, one observes >>> that the camera enlarges and then crops the image, i.e. it's >>> clearly visible that the JPEG file has a (slightly) smaller range >>> of view. Probably, Panasonic does so to cut off uncorrectable >>> distortions at the boundary of the raw image. >> >> As does Lensfun, at least in the ptlens and poly3 models >> (unfortunately; I'd love to change that). d is the scaling factor. >> In a sensible model, d = 1. > > I doubt that. The image is scaled by Lensfun by 1-a-b-c=d. But maybe we mean different things with "scaling"? I mean that the *centre* of the image is scaled, where the anti-distortion should have no effect. In other words, for r -> 0, the change in r should vanish. In Lensfun, however, (with ptlens and poly3) the change in r in the centre is d. I admit that black parts in the corners remain in case of pincushion distortion. > Before I started my own investigations I was disappointed by the > results of Darktable which uses Lensfun. This may happen with a bad calibration. But whether you use a',b',c',d' or a,b,c has no effect on accuracy. In fact, both can be transformed into another: a = a' / d'^4 b = b' / d'^3 c = c' / d'^2 (I hope I got the / or * right.) Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] RFC : Lumix FZ1000 Distortion correction
Hallöchen! Helmut Jarausch writes: > On 06/16/2016 01:52:38 PM, Torsten Bronger wrote: > > [...] > >> [...] But can't you just use the Lensfun formula in Octave? > > Of course, I could, but it won't make sense. As one can see in > the table below, the sum of the coefficients is (significantly) > smaller than 1. But if you replace d with 1-a-b-c, and you should get different values for a, b, and c, namely those for which a+b+c+d = 1. > If one compares a raw image which has been processed without lens > correction with the JPEG file coming from the camera, one observes > that the camera enlarges and then crops the image, i.e. it's > clearly visible that the JPEG file has a (slightly) smaller range > of view. Probably, Panasonic does so to cut off uncorrectable > distortions at the boundary of the raw image. As does Lensfun, at least in the ptlens and poly3 models (unfortunately; I'd love to change that). d is the scaling factor. In a sensible model, d = 1. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] [RFC PATCH 0/4] Implement XML validation via xmllint at build time.
Hallöchen! Roman Lebedev writes: > This will allow to do *some* verification of the database XML's > at the build time. Well, each time make is run. Thank your for your contribution! @seek: I merged Roman's changes to master and pushed this into the branch xmllint. It adds value and doesn't break anyting except maybe badly-written third-party tools. Moreover, I had normalized myself the database already with an own one-off tool, making Roman's changeset much smaller. So, a LGTM from me. Some questions: * Should the XSD/DTD files get the database version number in its file name? * Should the DTD get a valid URL as its name? * Should this check be enabled by default when building/installing? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] RFC : Lumix FZ1000 Distortion correction
Hallöchen! Helmut Jarausch writes: > [...] > > Result: this images are identical (except the intensities of gray > tones). This is a very nice scheme. Unfortunately, for focus at infinity, the approach with a well-defined grid is only feasible for extreme tele lenses. > This means, that the polynom computed by me produces excatly the > same lens correction as the camera (FZ1000) does it itself. > > Unfortunately the coefficient d differs from 1 which is an assumption > in lensfun. This thing has been inherited from the PanoTools (amongst other sub-optimal things). > Is there a way to use or patch lensfun to use all 4 parameters (e.g. a > general d)? We could define another model. Maybe the Adobe models, which are included soon, help you. They contain more coefficients. But can't you just use the Lensfun formula in Octave? Another problem is that Lensfun cannot process distortion parameters depending on distance. Currently, at least I don't have plans to change this because it would mean complicated modifications with small benefit. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Calibration questions
Hallöchen! Owen Mays writes: > [...] > > I have a lens (Nikon AF-S DX 16-80 mm zoom) that is not supported > by lensfun, and I thought this is the perfect opportunity to give > back to the project by contributing calibration data! [...] We have distortion data for this lens for a couple of weeks now. Feedback of its quality is greatly appreciated. > [...] > > For Vignetting correction, I read Torsten's instructions here: > http://wilson.bronger.org/lens_calibration_tutorial/ > > How even does the even illumination need to be? If I have a > suitable diffuser, could I aim at the sky for the vignetting > images? Yes. > I am concerned that if I point a standard floor lamp at the > ceiling it will have a distinct circular illumination pattern. Nevertheless, this will work, too. > For TCA correction: I haven't found a good target for TCA. Does > this calibration need a regular geometry (like the buildings used > for distortion?) The geometry is unimportant. Sharp high-contrast edges with different distance from the image centre count. > Or are trees against an overcast sky ok? No, because this is often dominated by longitudinal CA and blown-out highlights. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Add GoPro Hero3+ Black Distortion
Hallöchen! Christian Kapeller writes: > attached you'll find distortion parameters for the GoPro Hero3+ > Black Edition in 4:3 mode. A big thank you also from me! One question, though: The distortion figures are rather small. Maybe the designation as a "fisheye" lens is missing? Could you make one of your calibration images available for me? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Improved(?) OLYMPUS M.25mm F1.8 vignetting data.
Hallöchen! junkyardspar...@yepmail.net writes: > [...] The attached version seems to behave better throughout the > focus range. Thank you for your contribution! Which camera did you use? (Just for the record.) Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] calibrate.py produces no vignetting or tca in xml
Hallöchen! Jacob Nederend writes: > [...] > > python calibrate.py generates a lensfun.xml but there are only > 'ptlens' parameters in it. You mean that vignetting and/or TCA correction data is missing? > I have tried RAW (.NEF), TIFF (generated using calibrate.py by > placing all test images in /distortion) and JPEG images and none > seem to work. RAW is the way to go anyway. > If I try to calibrate using JPEGs in the vignetting and distortion folders > (tca is empty because it is not my main concern), I get the error: > > Traceback (most recent call last): > File "calibrate.py", line 429, in > vignetting_db_entries[exif_data] = result.get() > File "/usr/lib/python2.7/multiprocessing/pool.py", line 558, in get > raise self._value > NameError: global name 'FileNotFoundError' is not defined. This script needs Python 3. > If I do the same but run 'python3.4 calibrate.py' I get even more errors: > Traceback (most recent call last): > File "/usr/lib/python3.4/multiprocessing/pool.py", line 119, in worker > result = (True, func(*args, **kwds)) > File "/usr/lib/python3.4/subprocess.py", line 620, in check_output > raise CalledProcessError(retcode, process.args, output=output) > subprocess.CalledProcessError: Command '['convert', 'tiff:-', '-set'. > 'colorspace', 'RGB', '-resize', '250', 'pgm:-']' returned non-zero exit > status 1 > > The above exception was the direct cause of the following exception: > File "calibrate.py", line 429, in > vignetting_db_entries[exif_data] = result.get() > File "/usr/lib/python2.7/multiprocessing/pool.py", line 558, in get > raise self._value > subprocess.CalledProcessError: Command '['convert', 'tiff:-', '-set'. > 'colorspace', 'RGB', '-resize', '250', 'pgm:-']' returned non-zero exit > status 1 Hard to tell what is going wrong here. You max remove the stderr=open(os.devnull, "w") and see what's printed on the console. > Furthermore, I wanted to correct the vignetting test images in > DigiKam using the generated .xml but the program refuses to load > the .xml when I place it in either /usr/share/lensfun or > /usr/local.share/lensfun/update_1. What is the error message? Does DigiKam complain or Lensfun on the console? > If I edit the mil-nikon.xml (in either directory) with my lens, I > actually lose the ability to detect my camera in DigiKam. Can you post a diff with what you changed? > Instead of Nikon 1 J3, it gives me Nikon D1. The exiv2 forum told > me this is likely due to a Nikon MakerTag issue based on its > output, but I hope to get it working even if I don't have > auto-detection. But a failing autodetection should also fail before your changes. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Why does lensfun produce different results than Silkypix?
Hallöchen! Helmut Jarausch writes: > I wonder why lensfun uses a set parameters - in case of my > Panasonic DMC-FZ1000 > > c="-0.06581" /> > c="-0.03567" /> > c="-0.00043" /> > /> > /> > > /> > > > > > > > > > > > > > > Aren't the lens correction data recorded in the .rw2 raw file > suffucient for lens correction? The RAW converters that use Lensfun (e.g. Darktable) cannot read the correction data embedded into the RAW file. Neither can Lensfun itself. > Following http://syscall.eu and applying the data extracted from an image of > mine, > I get, e.g., for an image with focal="9.1" > > scale = 1.0/(1.0+(data[5]/32768.0)); 1.0 > a = data[8]/32768.0; 0.19561767578125 > b = data[4]/32768.0; 0.145965576171875 > c = data[11]/32768.0; -0.14434814453125 > > Ru = scale*(Rd + a*Rd^3 + b*Rd^5 + c*Rd^7) > > How are these releated to the parameters for focal 9.1 above? I am aware of this reverse engineering, but I haven't had time to investigate this yet. > In this case the image processed by Silkypix differs significantly > from that produced by darktable which uses lensfun. If I crop the > image produced by darktable to pixels 173 .. 5299 x 115 .. 3533 > and rescale the image to 5472 x 3648 pixels I get a very similar > result to that produced by Silkypix. So, only the scaling was different? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Upcoming work on Lensfun
Hallöchen! During the holidays, I started some work on Lensfun which turns out to become quite extensive, so I want to put in on discussion. The big picture is that we keep the current C/C++ API, and build a new one parallel to it. The new API will be easier to use and to extend. Moreover, I want to change the XML file format. The new Lensfun would not be able to read old XML files. There will be, however, a script which converts old to new. My motivation is that we now know very well which parts of Lensfun are difficult to extend, and how programs use Lensfun typically. Therefore, it makes sense to overhaul Lensfun in one big effort, so that the downstream programs can adapt at their convenience, and further changes can be made without mandatory downsteam changes. The steps are the following (in this order): 1. Add unit tests for the coordinate transformations. 2. Add unique IDs to and . 3. Put every model (e.g. ptlens, poly3, tca, vignetting, ...) into classes or at least C++ files of its own. 4. Change the internal coordinate system to "1 = half diagonal of the image sensor". 5. Change the XML file format extensively. 6. Allow internally the usage of calibrations of different crop factors in the same lfModifier. 7. Implement the new API. (Current draft is at https://sourceforge.net/p/lensfun/wiki/lfModifier%20API/) About (3): I'd like to do this because due to (4), we need an additional function for every model that transforms the coefficients so that they match the new coordinate system. Thus, there will be at least a forward callback, a reverse callback, a coefficient transformer, and possibly a postprocessor after the raw data was read from the DB -- for *every* model. And we have a lot of them. For the sake of readability, I'd like to create a file called e.g. "ptlens.cpp" which contains everything for the ptlens model. Or a singleton class instead? About (4): The current internal coordinate system is "1 = half height of the *calibration* sensor". This makes sense if you only support PT-based distortion and TCA models. More critically, you can only use one calibration sensor size for one correction. Therefore, we need a new common coordinate system anyway, and I propose the vignetting coordinate system for the *image* sensor. This moved any ugliness out of Lensfun's core into the model files. About (5): Lensfun offers an API for its DB, so the DB itself is in a way an internal format. Of course, many Lensfun users maintain local XML files, so there will be a tool for converting the current to the new format. Moreover, the current Git DB will be converted into all older versions every night. The changes that I propose are: 1. Assign unique integer IDs to cameras and lenses. All numbers < 1000 are reserved for private/local use. Anything which is not a positive integer (this includes 0) is an invalid ID. (Mount uses its name as ID.) 2. is renamed to . 3. Move the and the element out of into the element as attributes. 4. Introduce a element in which denotes the maximal image circle the lens can illuminate. This will be used like the old for filtering matching lenses. 5. Move tags as attributes into . (Already done.) 6. Collect all elements of one lens model in one entry. 7. Add optional "camera" attribute to . Any comments are welcome! Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Thoby projection
Hallöchen! I suggest to remove the Thoby projection from Lensfun. Its definition is r = 1.47 * f * sin(0.713 * theta) with r being the distance from the sensor centre and theta being the angle of the incoming light ray. The problem is that 1.47 * 0.713 is not equal to 1, which means a shrinking of the image by 5%. Frankly, such global scaling of an image is a no-go for a projection formula because it yields a wrong value of the focal length f. The Thoby projection does not occur in peer-reviewed literature. The general projection r = a * f * tan(theta/a) (or with sin instead of tan) is sometimes discussed, but "a" must be fitted per lens. There is no general value for "a". The Thoby projection was created Michel Thoby for the Nikkor 10.5mm, but this can also be -- and is in Lensfun -- described with equisolid + distortion. By the way, the 5% shrinking is due to the fact the the focal length of this Nikkor is slightly larger than 10.5mm. To summarize: * This projection is not referred to outside the PanoTools world. * It was created only for the Nikkor 10.5mm, and no research has been done whether it contains any generality. * It has never been used in Lensfun's database. * It does not add accuracy in distortion correction, not even for the 10.5mm. * It spoils all subsequent image processing that relies on an accurate focal length. Alternative: If we keep it, I propose: - We change the factor 0.713 to 0.680272108844. This un-does the shrinking, but does not distort the projection any further. - We document that "our" thoby also enlarges the image by approx. 5%. What do you think? Does anybody know of any usage of the Thoby projection? Did I overlook a discussion of it in literature? Did I overlook a usage outside the PanoTools? Has anybody reported benefit from it? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Perspective correction
Hallöchen! Torsten Bronger writes: > [...] (Plan is to add affine transformations later, to be really > complete.) I now also added affine transformation (scaling, rotation, shift) in the branch "affine-transformation". See also <http://wilson.bronger.org/lensfun-affine/structlfModifier.html#a235252cfccff59f02dcb74d3259c8ec1>. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Perspective correction
Hallöchen! I prepared a branch "perspective-correction" that contains an additional callback for perspective correction (PC) in Lensfun's modifier object. I admit that PC is not an intrinsic lens error, but it is closely related and benefits from Lensfun's framework. In particular, PC along with TCA, distortion, and projection can be rectified in one process without an intermediate image. (Plan is to add affine transformations later, to be really complete.) Moreover, PC needs focal length and crop factor, and the proper ordering relatively to projection transform and scaling, all of which is conveniently offered by Lensfun. There is a new manual section on <http://wilson.bronger.org/lensfun/perspective-correction.html>. With git clone --branch perspective-correction \ git://git.code.sf.net/p/lensfun/code lensfun you can clone the code locally. I would be grateful for any feedback, especially whether the code compiles properly with non-GCC, and whether the test suite runs through on your hardware. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] LensFun partially ignores installation prefix.
Hallöchen! Roman Lebedev writes: > (the error is on last line) > > For my debugging needs, i need to install some set of libraries into > custom prefix: > $ export PREFIX /opt/darktable > > Here is how i run cmake: > $ cmake -DCMAKE_INCLUDE_PATH:PATH=$PREFIX/include > -DCMAKE_LIBRARY_PATH:PATH=$PREFIX/lib -DCMAKE_PREFIX_PATH:PATH=$PREFIX > -DCMAKE_INSTALL_PREFIX:PATH=$PREFIX ../ && make -j9 && make install > > Your branch is up-to-date with 'origin/master'. > [...] > running install > running build > running build_py > creating build > creating build/lib > creating build/lib/lensfun > copying /home/lebedevri/src/lensfun-code/build/apps/lensfun/__init__.py > -> build/lib/lensfun > running install_lib > creating /usr/local/lib/python3.4/dist-packages/lensfun > error: could not create > '/usr/local/lib/python3.4/dist-packages/lensfun': Permission denied > <<<<<<<<<<<<<< end paste > > Exactly same cmake call seems to have worked for the rest of the > projects using cmake, so this must be showing that there is some > kind of issue in lensfun cmake files... We fixed an issue with the Python package yesterday in the branch "debian-packaging". Please test this branch for your use case. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Calibration with checkerboard
Hallöchen! Fabien Castan writes: [...] The focus has an impact on the focal length. I guess that the metadata from the camera doesn't take the focus into account. At least for Nikon, it doesn't. Probably neither for any other vendor. On the camera device, it's just a mechanical record of the focal length choose by the user on the device. The theoretical focal length value matches the real focal length of the lens/camera device when the focus is at infinity. So if you use the focal length from the metadata and the focus is not at infinity, you are using a wrong focal length. In general, yes. With the real-focal-length tag, Lensfun keeps track of nominal vs. actual focal length, e.g.: real-focal-length focal=8 real-focal=8.405 / However in most cases, it is not worth it. The benefit is largely theoretical. If we use a checkerboard for calibration, we compute both the focal length and the distortion, so the result will be correct because this relationship is independent from the focus. If I understand you correctly, you assume that a lens at 200mm nominal and close focus, which actually has only 135mm, exhibits the same distortion as the same length as 135mm nominal and focus at infinity? [...] Are you interested if we propose a pull request with a new calibration binary (with OpenCV optional at compile time)? I personally no. I do not believe in checkerboard calibrations for reasons I have stated earlier. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Calibration with checkerboard
Hallöchen! Fabien Castan writes: I cannot explain the physics in detail, but it is so. Focus changes distortion. Been there, done that: A couple of weeks ago I had to remove a database entry because it had been taken at close focus, and did not work *at* *all* for images taken at a large distance. But in that case, it is the same in the other direction, no? If you calibrate using a large distance, it doesn't work for close range pictures? Of course this doesn't work, too. :-) When you are doing the calibration do you also compute the focal value? Do you mean focal distance or focal length? Or do you use directly the metadata information and only compute the distortion? I use from the metadata the camera model (sensor size), lens model, and the focal length. For vignetting, I also use the aperture. The focal distance is set to infinity (unless the creator of the images tell differently). Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Calibration with checkerboard
Hallöchen! Fabien Castan writes: I have read some papers but it's still unclear to me why the focus at infinity is so important. I cannot explain the physics in detail, but it is so. Focus changes distortion. Been there, done that: A couple of weeks ago I had to remove a database entry because it had been taken at close focus, and did not work *at* *all* for images taken at a large distance. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Add more information in lensfun
Hallöchen! Fabien Castan writes: Currently, we are storing the diagonal (represented by the cropfactor). Since the image itself provides the aspect ratio, this also provides the sensor width. Ok, I will use that! It's not really good, because it creates some rounding error. [...] The rounding error is negligible compared to the uncertainty in the crop factor itself. But I plan to extend this information because some cameras are able to operate in different modes (resolutions, aspect ratios). Great! Yes, I have many image ratio which doesn't match the sensor ratio and there is no way to know that. So I can't use it. It could be really nice to extend the information provided by lensfun with all the raw camera characteristics. Indeed, but this will take some time. Other things are more important, I'm afraid. Maybe a collaboration with the impressive effort of http://www.digicamdb.com ? Nice site, but their figures are not more accurate than ours. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] TCA overdone for Sony SAL-16105?
Hallöchen! junkyardspar...@yepmail.net writes: [...] I don't have a good understanding of optics, but I've found the calibration data that I made myself for a zoom lens can give perfect results for some images and wrong for others. The most obvious cases are when focus distance is very small. I wonder if the complexity of the various elements in some lenses means that proper correction would have to take focus distance into account? Of course the focus distance is important: Lensfun's corrections only work for focus at infinity, which is why I urge people to take test pictures at a minimal distance. Theoretically, Lensfun coud be expanded to take focus distance into account, but this makes calibration much more complex, and I personally don't think that people will do that. But it could be done, so if there is demand, just open a feature request. Regards, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] TCA overdone for Sony SAL-16105?
Hallöchen! Jan Kasprzak writes: [...] Is it possible that the lens profile of this lens in the lensfun database is wrong? This may well be, although the data seems to have been contributed by a trustful person. Anyway ... you may provide new sample images at http://wilson.bronger.org/calibration Regards, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Calibration with checkerboard
Hallöchen! Fabien Castan writes: I don't see anything to calibrate a camera using a checkerboard, which allows a fully automatic process. The problem is that lens characteristics depend on focus distance. We need a calibration with focus at infinity, which can be reasonably achieved with distances larger than 10m. At the same time, the highest accuracy provide uninterrupted horizontal features that span the whole image width. This is why I urge people to take pictures of modern buildings. Regards, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Lens profile for Panasonic 14-140mm f/3.5-5.6
Hallöchen! First: Thank you for your contribution! John Stracke writes: [...] I had this lens for only a week (I rented it for a vacation), so if there's a problem with the profile I can't do much about it. I could provide the reference shots I took, though. Yes, please upload them at http://wilson.bronger.org/calibration Regards, Torsten Bronger. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] calibrated lens Sigma 12-24mm
Hallöchen! muellst writes: I did calibrate the vignetting of my new Sigma 12-24mm f/4.5-5.6 EX DG ASPHERICAL HSM lens and like to share my results. Thank you for the data! Which camera model was used? Regards, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Lensfun issue: The API of lfModifier is bad
Hallöchen! Sebastian Kraft writes: [...] How do you like the following? // Constructor with image/camera parameters lfModifier ( int width, int height, lfPixelFormat format, float crop, float focal, float aperture, float distance ); // Prepare corrections for a certain lens lfModifier::PrepareCorrections( const lfLens *lens, lfLensType targeom, float scale, int flags, bool reverse ); On the long run, I'm toying with the idea of adding flatfield images and perspective control in Lensfun. Whether those are really senseful and interesting ideas may be discussed when it's due, but they are good examples of further parameters that may become necessary: - Flatfields need the camera (because the sensor/lens *combination* is important) and the timestamp (sensor dust may change over time). This affects the constructor parameters. - Perspective control needs control point coordinates. This affects the Prepare...() parameters. For such developments, the API should be extensible. Of course, one may add optional parameters to the methods. But appending fields to a struct, or adding a Prepare...() method, is better in my opinion. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Lensfun issue: The API of lfModifier is bad
Hallöchen! Sebastian Kraft writes: I just had a look at the lfModifier Class. One solution would be to create a new lfModifier::Create() with a different parameter set in parallel and mark the old one as deprecated. However, putting all necessary parameters in one function would probably be too confusing. Yes, I see this problem, too. Do you have an idea how we can split this in a meaningful way? I thought about the following solution yesterday: We may introduce a new struct lfImage. It is contains no methods, but lfLens and lfCamera object, width, height (in px), the pixel format, focal length, aperture, and distance. The constructor of lfModifier gets this signature: lfModifier(lfImage, reverse) Then, lfModifier gets the methods: lfModifier::PrepareDistortionCorrection() lfModifier::PrepareTCACorrection() lfModifier::PrepareVignettingCorrection() lfModifier::PrepareProjectionTransform(target_projection) lfModifier::PrepareScaling(scale) [...] 3. Prepend the following to lensfun.h.in: #ifndef __G_TYPES_H__ typedef char gchar; typedef int gint; [...] #endif [...] (3) is the ugly part of course. And that is what should be avoided by this strange arrangement in lensfun. The glib types should not appear in the header because we do not want them to be imported into every calling application. Actually, lensfunprv.h can stay. I was wrong in trying to merge it with lensfun.h.in completely. As a very first step, @Sebastian: Please review my branch lensfunprv-refactoring and merge it if it's okay. In order to have real constructors, we need to merge the two lfExt... classes with their parents. The two GLib types here are GPtrArray and gchar. What do you think of this idea: Rename gchar - char and GPtrArray - void in the declarations moved to lensfun.h.in and some other places, and static-typecast them back to the GLib types when we call GLib functions? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Generating TCA data for existing correction profiles.
Hallöchen! junkyardspar...@yepmail.net writes: My question now is if the TCA correction really need to be at the same focal lengths as the distortion corrections. No, it needn't. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Generating TCA data for existing correction profiles.
Hallöchen! junkyardspar...@yepmail.net writes: [...] In all cases I was able to improve the results by using the tca red/blue sliders in darktable's lensfun module for fine adjustment. In this case -- which I've observed myself quite frequently -- I'd recommend to use the slider positions and generate TCA entries like tca model=poly3 focal=focallength vr=red vb=blue / Older darktable versions swapped red and blue, so check the result! Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Lensfun issue: calibration = lens
Hallöchen! I'd like to start bainstorming about some things that are sub-optimal in Lensfun currently and should be addressed in the next releases. I deliberately do not suggest how to solve them. However, you may also discuss possible implementations. I post the topics in different messages to make the discussion easier. Okay, the following is the first issue. Let's start with the toughest one: Lensfun makes no distinction between lens and calibration. This means that we may have one lens multiple times in the database. While we can certainly deal with that (it is only unelegant), Lensfun is currently unable to take calibration data from different calibration entries for one lens. This means that in a lot of cases, data is there but cannot be used! Yesterday, I added data to the database submitted by a user, which absurdly enough meant that he lost vignetting correction for his lens (which he had before). This must not happen. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Lensfun issue: calibration = lens
Hallöchen! I'd like to start bainstorming about some things that are sub-optimal in Lensfun currently and should be addressed in the next releases. I deliberately do not suggest how to solve them. However, you may also discuss possible implementations. I post the topics in different messages to make the discussion easier. Okay, the following is the first issue. Let's start with the toughest one: Lensfun makes no distinction between lens and calibration. This means that we may have one lens multiple times in the database. While we can certainly deal with that (it is only unelegant), Lensfun is currently unable to take calibration data from different calibration entries for one lens. This means that in a lot of cases, data is there but cannot be used! Yesterday, I added data to the database submitted by a user, which absurdly enough meant that he lost vignetting correction for his lens (which he had before). This must not happen. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Lensfun issue: Handling of invalid values
Hallöchen! This is about the question of how to deal with return values that are mathematically undefined. Such values occur in coordinate transformations of some fisheye projections and cannot be avoided. Currently, Lensfun returns a very big float for undefined values, which happens to be mapped in Darktable and DigiKam (and possibly also in other programms) to (int)MAX_FLT, which is undefined according to the C/C++ standard and mapped to MAXINT by the GCC. This is then clipped by the interpolation routine. Thus, this approach is fragile, albeit Lensfun is not the only to be blamed. Still, Lensfun should return something that can be safely cast to integer. Alternatively, one can force the calling programs to change their checks. In any case, Lensfun should adopt well-defined and documented behaviour for such cases. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Lensfun issue: aliases
Hallöchen! We need alias names for cameras and lenses. How could be dealt with the fact that a certain camera models have different names on different continents? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Lensfun issue: Getting rid of bogus camera mounts
Hallöchen! I'd like to have an alternative for making up all those bogus camera mount names for compact cameras with fixed lenses. There are no mounts like powershotA60 after all. Any alternative must allow for two things: - there may be more than one lens for a compact camera due to converters - two or more compact cameras may be optically equivalent, thus, they share the set of lenses Both cases are rare, so, they may be solved in a not-so-nice way. I assume that the current situation may turn out as the lesser evil. But there is always hope. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
[Lensfun-users] Lensfun issue: The API of lfModifier is bad
Hallöchen! In order to avoid a dependency of Lensfun's include file on GLib's include files, Lensfun's original author splitted the lfModifier class in lfModifier and lfExtModifier, the latter being private. This way, GLib's include files are only needed when compiling Lensfun, but not the calling program. Therefore, lfModifier doesn't have a constructor. Instead, there are Create and Initialize methods that must be called to have a functioning object. Create sets the coordinate scale, and Initialize adds the callbacks to the callback chain. In all methods of lfModifier, the object this is first typecast to an lfExtModifier object. All of this is very ugly and error-prone (even the Lensfun developers happened to tumble over this). Besides, the API is difficult to extend. Is the non-dependency on GLib's include files really so important? I'd like to see Create and Initialize being merged into a constructor proper. What's the best way in C++ to make the parameter list extensible? For example some day, I may want to have the image's timestamp in the parameter list. How can one design the API to make such changes painless? The old API must remain parallely, which should not be a problem. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Store the Exif Id inside the XML
Hallöchen! Tobias Jakobs writes: what do you thing about adding the Exif Id from the lenses and cameras to the XML files. This would have several benefits: 1. It is possible to find the right lens even if it is not supported by the Exif tool (e.g. Exiv2 or ExifTool) 2. Even with a spelling error in the name (in LensFun, Exiv2 or ExifTool) it is possible to find the right lens I feels like an ugly hack for circumventing other problems. The actual problem is that exiv2 is often not able to provide the proper lens name, either because its database is not complete, or because the EXIF data is ambiguous. Besides, it is already possible to locally add lens entries with a lens model name like (123). Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Manually set lens for LensFun
Hallöchen! Victor L writes: I use a Sony A7 with a Canon FD 50mm 1:1.4 (+ adaptator), this is an old/manual lens so I have to manually specify the lens (with exiv2) in my RAW files: [...] The lens name appears fine in darktable tag panel however the camera/lens is not found: Lensfun contains only calibration data for this lens with cropfactor 2.0, but you need 1.0. Please upload a sample image at http://wilson.bronger.org/calibration according to the instructions there. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Lens correction profiles for different aspect ratios?
Hallöchen! Jan Rathmann writes: [...] Now my question is: Would it make sense to send calibration images according to the guide at http://wilson.bronger.org/calibration which are taken at the other aspect ratios the camera supports (3:2, 16:9, 1:1), so that raw images with those ratios could also be corrected by Lensfun in the future? In such cases, we must calibrate with the smalles possible crop factor (i.e. the largest image radius). Then, we add camera entries for all possible crop factors. But still only one lens model is necessary. At least in one case (I cannot remember the model name), there were different aspect ratios but the same crop factor. Then, the same camera and lens model can be used for all aspect ratios. (This is certainly something to re-visit for the next database overhaul ...) Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] lensfun.sourceforge.net/usage isn't up to date
Hallöchen! Carl von Einem writes: [...] Thanks for pointing me to that thread. It's about 2014.0-RC4 which is Hugin's 4th release candidate prior to the release of 2014.0.0, so in a nutshell, the current release 2014.0.0 ships with Lensfun no matter what was written in that relatively old thread you mention. Maybe Vladimir was confused and actually refered to current hg hugin. [...] As I pointed out earlier: the build process documented in the panotools wiki http://wiki.panotools.org/Development_of_Open_Source_tools explicitly mentions lensfun. This may be just out-of-date. Also hugin's release notes usually mention important changes. We'll know when the release notes for Hugin 2015 are published. I volunteer to ask on hugin-ptx about the status of lensfun in hugin just to make sure. You may do so. But first I recommend that you compile Hugin's current source code and check the features you mentioned. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Recent changes
Hallöchen! Sebastian Kraft writes: in the last week I have started to implement an automatic test suite for lensfun using the GLib test framework. Very good! [...] That's it so far. Torsten, maybe if you have some time and ideas for further test cases it would be great if you could contribute some. I think you have the best knowledge about the really critical cases. I fixed test_modifier. It (rightfully) fails now, because the centre pixel (x=y=0) sometimes is passed to atan2, and atan2(0,0) is NaN. I will look for a fix and further tests later. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Calibration for OLYMPUS M.14-42mm F3.5-5.6 II R
Hallöchen! native writes: lensdatabase camera makerOLYMPUS IMAGING CORP./maker maker lang=enOlympus/maker modelE-PL5/model mount4/3 System/mount cropfactor2.0/cropfactor /camera lens makerOlympus/maker modelOLYMPUS M.14-42mm F3.5-5.6 II R/model I think this camera and lens are already in Lensfun, see http://wilson.bronger.org/lensfun_coverage.html. Or is there a difference between the ED and non-ED version? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Image artefacts as a result of vignetting correction
Hallöchen! Jan Wolter writes: [...] Does anyone has the same problem? Or can reproduce it with my raw file, which you can download here: https://www.dropbox.com/s/oa717wk8w7vkgmy/P7057624.ORF I cannot reproduce it with Darktable. Maybe a Digikam problem? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Urgent question about the database of Lensfun
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 Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Improved matching for fixed-lens cameras.
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. -- 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 cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] Improved matching for fixed-lens cameras.
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 vignetting. -- 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 cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] GoPro hero support?
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. -- 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 cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
Re: [Lensfun-users] lensfunpy
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 approx. 1.8*12mm. AT the same time, this is the maximal radius, so it is senseful to use 0..1.8*12 for the x axis. You can use the identity cos(arcsin(x)) = sqrt(1 - x**2) -- 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 cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Lensfun-users mailing list Lensfun-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lensfun-users
