Activity for Lensfun
-
Peter Stephens posted a comment on ticket #156
My telephoto kit lens is not marked as VR. The 18-55 mm lens is marked as VR capable. On Sun, Apr 14, 2019, 11:22 PM Peter Stephens hzqmrk2@users.sourceforge.net wrote: [features:#156] Nikon D3500 and Kit lens* Status: open Labels: Nikon Created: Mon Apr 15, 2019 03:22 AM UTC by Peter Stephens Last Updated: Mon Apr 15, 2019 03:22 AM UTC Owner: Torsten Bronger Attachments: 0001-Added-D3500-to-slr-nikkor.xml-.-Note-that-I-assumed-.patch https://sourceforge.net/p/lensfun/features/156/attachment/0001-Added-D3500-to-slr-nikkor.xml-.-Note-that-I-assumed-.patch...
-
Torsten Bronger modified ticket #108
Vignetting with Canon PowerShot G1X Mark II at 12.5mm focal length
-
Or, you collect the upload ID where you observed this in a GitHub issue.
-
junkyardsparkle posted a comment on ticket #108
Not from me, unless it's worth keeping open a little longer as a reminder to actually add the crop tags to the profiles that need them... otherwise, I could add FIXME comments to the profiles, for the ones I can remember having this "feature"...
-
That's interesting, I've seen several cases similar to this one where maximal_radius would be useful. I did try the <crop> element, but it didn't seem to have any effect in darktable, at least. Implementing it as you describe sounds good to me, but I guess should be discussed somewhere. It might be best if there was still a way to get the current "all-the-pixels" behavior if it's desired.
-
Richard Hutchings posted a comment on ticket #153
I found the profile in the list after I posted this. No further action needed . On Sun, Apr 21, 2019, 10:27 AM Torsten Bronger bronger@users.sourceforge.net wrote: status: open --> wont-fix assigned_to: Torsten Bronger Comment: We need calibration images for fulfilling such a request. Please see https://wilson.bronger.org/calibration. [features:#153] https://sourceforge.net/p/lensfun/features/153/ Canon SX30is* Status: wont-fix Created: Wed Mar 13, 2019 11:28 AM UTC by Richard Hutchings Last Updated:...
-
Nikon Z6, Z7 and Lens 24-70 f/4.0 S
-
I included your data. If possible, still tell me the camera used. Thank you for the contribution!
-
Which camera was used for the calibration? Z6 or Z7?
-
Nikon D3500 and Kit lens
-
I clode this ticket – the data is in Lensfun thanks to another contributor. However, I’m still curious about the “VR” thing.
-
Why do you remove the “VR”?
-
Have you also submitted the data that came from freddie@w…?
-
RX100 VI lens
-
Canon SX30is
-
We need calibration images for fulfilling such a request. Please see https://wilson.bronger.org/calibration.
-
missing lens:TAMRON 100-400mm/F4.5-6.3 Di VC USD A035
-
Calibration data for this lens has been uploaded here: https://github.com/lensfun/lensfun/issues/550. Please follow progress there.
-
Canon EF 28mm f/2.8 IS ISM
-
This is explained at https://wilson.bronger.org/calibration.
-
Please add support for Canon EOS M6
-
The M6 has been included. As for the lenses, calibration images form them need to be uploaded at https://wilson.bronger.org/calibration.
-
Lens profile: Mitakon Zhongyi Speedmaster 35mm f/0.95 Mark II
-
I’m sorry to say that LCP files cannot be converted into Lensfun’s data format, and thus not included into the database distributed with it. However, you can use them with cutting-edge Lensfun versions.
-
Vignetting data for Sony SEL2470GM
-
Calibration data for Huawei P20 Pro
-
Zeiss, Fuji, Canon, and Sigma distortion correction info
-
@robert: Please provide further information so that we can include your data: Which camera was used? A 6D Mark I cannot be used for Touit or XF mount lenses. As junkyardsparkle has already pointed out, there must be only one cropfactor per calibration. Besides, cropfactor “1” for an XF lens is probably incorrect. So, which cropfactor was used for Touit 1.8/32 Touit 2.8/12 Fujifilm XF80mmF2.8 Thank you!
-
Lensfun compile instructions
-
Thinking about this again, I think I experienced the same problem but solved it by creating the symbolic links manually and didn’t bother further. I added a comment to the docs (commit 41252526).
-
Make Python scripts working on non-Unices
-
Closed because older than a year, nobody working on this I don’t know what is the exact problem, or if there is one at all anymore
-
seebk modified ticket #117
Some C API functions not exported on Windows
-
Yes, we can close this. Discussion can continue in the respective GitHub issue about the C-Wrapper: https://github.com/lensfun/lensfun/issues/502
-
Any objection to closing this?
-
As a side node, calibrate.py has the – I think undocumented – feature of having a sidecar file for each vignetting RAW which contains the line maximal_radius: 0.7. “0.7” means 70% of the image diagonal are usable. Then, farther points are not considered for the vignetting measurement, and the resulting polynomial is much better (in the useful area). Of course, it is bad that it is not documented, and that it does not create a <crop> element.
-
So, this one can be closed, and the remaining things are tracked elsewhere?
-
Ah! My bad … the RAW image viewer I used apparently showed the embedded JPEG. There is the <crop> element: http://lensfun.sourceforge.net/manual/v0.3.2/elem_calibration.html But it has never been used in the DB, and I don’t know whether the code uses it. But it is exactly for this purpose. We could make use of it in the “autoscale” function. This would be used by Darktable, too, without them needing to change the code.
-
Ah! My bad … the RAW image viewer I used apparently showed the embedded JPEG. There is the <crop> element: http://lensfun.sourceforge.net/manual/v0.3.2/elem_calibration.html But it has never been used in the DB, and I don’t know whether the code uses it. But it is exactly for this purpose.</crop> We could make use of it in the “autoscale” function. This would be used by Darktable, too, without them needing to change the code.
-
The problem isn't that the in-camera cropping affects the lensfun corrections, it's that Lensfun/darktable doesn't do the additional cropping that the camera does in order to hide the edges of the image circle in the corners. You can see this best on the second linked image (YIMG_0026.CR2)... with default correction in darktable there are still visible traces of the physical edge of the image circle, most easily noticed in the lower left. You can, of course, adjust this for each image in darktable...
-
The problem isn't that the in-camera cropping affects the lensfun corrections, it's that Lensfun/darktable doesn't do the additional cropping that the camera does in order to hide the edges of the image circle in the corners. You can see this best on the second linked image (YIMG_0026.CR2)... with default correction in darktable there are still visible traces of the physical edge of the image circle, most easily noticed in the lower left. You can, of course, adjust this for each image in darktable...
-
The problem isn't that the in-camera cropping affects the lensfun corrections, it's that Lensfun/darktable doesn't do the additional cropping that the camera does in order to hide the edges of the image circle in the corners. You can see this best on the second linked image (YIMG_0026.CR2)... with default correction in darktable there are still visible traces of the physical edge of the image circle, most easily notices in the lower left. You can, of course, adjust this for each image in darktable...
-
The declaration in the header file was slightly different to the definition in the source file. I think this is already fixed for lf_db_read_timestamp(). The implementation of lf_mount_copy() is missing. The lf_db_save and load functions have to be adapted the new lfDatabase class API. The concept of the load and save functions with its respective overloads is still a bit messy, though.
-
Can this be closed?
-
Handle two vignetting sets per lens.
-
I leave it as it is: Lensfun’s corrections always apply to the rawest possible image data to get from a certain camera.
-
How can we proceed here? We could just apply the patch (thanks for that) but Python3.5 will be out of date, as any other Python version. Can we add a note to adjust the Python version, or is there a general solution?
-
Pentax-DA 18-135mm recognition
-
Pentax-DA 18-135mm recognition
-
Lens names
-
Wrong Maker name for pentax model cameras
-
Fixed lenses RX10 and RX100M2 not autocorrected
-
I don’t really understand what we are talking about here. Frankly, I don’t see any vignetting on those shots. :-/ They are not really suitable to estimate vignetting anyway. @junkyardsparke: The cropping of the camera should not affect Lensfun’s corrections, as long as the crop factor is correctly assumed. If it is off by the same amount that at the calibration, it should not affect either.
-
Error when updating database
-
Maybe the TLS certificate at wilson.bronger.org was invalid at that point in time? Anyway, it is valid now, and should be renewed automatically. (Certbot.)
-
I did those calibrations myself back in 2012 because I own those lenses. I had a look at my old images – the correction in Darktable is perfect. Thus, there are three possible explanations: My method with the diffuser plate was suboptimal In-camera vignetting correction is on, resulting in double correction There is some lens model variance, i.e. lens samples differ from each other slightly The second point can be excluded easily: Just assure that in-camera vignetting correction is off. At least...
-
What exactly does not match (a branch in the definition of LF_EXPORT?)
