As the title suggests, there seems to be vignetting showing up on Canon PowerShot G1X Mark II photos taken at 12.5 mm. Here are some sample photos to test on:
https://www.imaging-resource.com/PRODS/canon-g1x-ii/YIMG_0023.CR2.HTM
https://www.imaging-resource.com/PRODS/canon-g1x-ii/YIMG_0026.CR2.HTM
more:
https://www.imaging-resource.com/PRODS/canon-g1x-ii/canon-g1x-iiGALLERY.HTM
I checked a couple others (31mm & 63mm) and those seemed to be okay.
This lens profile is in data/db/compact-canon.xml at around line 2531.
This is not uncommon at the wide end of fixed zooms. The in-camera processing simply crops it away as part of correction (and this particular camera apparently always crops a little anyway, in order to maintain same angle of view at different aspect ratios). There actually exists a "crop" parameter as part of LensFun's calibraton data format, but I don't know if any software actually does anything with it. At least, darktable doesn't seem to, and generally likes to offer the user all available pixels as a rule. If RawTherapee uses it, it might be worth adding to the profile, I suppose?
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.
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 with the "scale" slider in the lens correction module, or just by using normal cropping, but there doesn't seem to be a way to "hint" within the profile itself that extra scaling is needed to emulate camera processing in this way (and darktable seems philosophically opposed to this kind of thing anyway).
So, while it's nice that the user has the option of how to make use of the full capture area (perhaps with a more square-like crop to make use of additional vertical area), there will probably be some who will wish for an easy way to "just do what the camera does" in this regard.
Last edit: junkyardsparkle 2019-04-20
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.
Last edit: Torsten Bronger 2019-04-21
As a side node,
calibrate.pyhas the – I think undocumented – feature of having a sidecar file for each vignetting RAW which contains the linemaximal_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.That's interesting, I've seen several cases similar to this one where
maximal_radiuswould 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.Any objection to closing this?
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"...
Or, you collect the upload ID where you observed this in a GitHub issue.