Firstly, so far as the Adobe LCP’s are concerned, it is my understanding that the camera/lens manufacturers do not tell Adobe anything. Rather, Adobe gets a copy of the lens, mounts it to a camera, takes a series of test shots, and then uses these test shots to create a calibration profile. (This assessment is based off of my reading of the XML profiles where there are remarks around the body lenses were mounted to when the profile was created.) This is exactly the same procedure the lensfun community follows to create profiles.
Secondly, the lensfun community has also built out the online update mechanism you speak of. It is called lensfun-update-data. Run it as your local user and it will go and fetch the latest profiles and store them locally for your user. It works quite nicely.
Right now, in lens.cc, you have one big process() function. What I mean is, rename that function process_lensfun(), and include the process() of the current PR in there too, renamed as a process_builtin(). Then, replace the lens.cc process() with:
[…]
That way, we can merge the feature in the same module, while still having different code pathes. Add the parameters you need in the parameters structure, and split other functions like distort_transform() or process_cl() with the same logic as process().
Well, i truely have come around a vast number of crappy dng files generated by drones or alike. Sure.
But also DNG is the standard output raw format for cameras writing correct output and the manufacturer of that camera might know better than lensfun or adobe. So - as the dng standard describes the parameters and the can be read by exiv2, why oppose?
If this gets merged into dt i will certainly work on that if @fdw isn’t doing it.
Of course, camera-generated .dng files are as good as (or better than) “traditional” raw files.
But those are completely different beasts from dng files obtained through conversion of another raw format. I’d consider those like any other derived file format, and keep the original raw on the side (the dng spec and converters have changed since the first versions came out…)
Can your lens correction module work with compact cameras and bridge cameras? If it can what are the chances that it will be adapted to do so? I have a Panasonic FZ330 and it does some weird tricks at wide angle to hide vignetting. Only Lightroom and Silkypix can reproduce from RAW what the camera outputs in jpeg.
Here is a RAW and camera jpeg plus a jpeg I made from the RAW in RawTherapee (I’ve used the FZ200 lens corrections from Lensfun to correct distortion but there is no vignetting correction available).
Notice how much wider angle the RawTherapee jpeg is compared the camera jpeg. The RT jpeg is 4008x3008 pixels and the camera jpeg is 4000x3000 pixels. Perhaps the camera is cropping the images then upscaling back to 4000x3000.
The camera manufacturers normally crop more at the borders than darktable and RawTherapee. In RawTherapee and its demosaicing menu you can change if you want to crop more.
It must be up scaling. I’ve noticed quite a few cameras do that with wide angle lenses. Presumably the corrections eat up pixels but they know people would be confused when some images come out a fair bit smaller. So they just hide the crop by upscaling.
In addition RT does use more of the sensor in the first place which accounts for those couple of extra pixels.
Yes, but if you look at the framing way more pixels are missing from the sooc image that can be accounted for by the 8 extra px RT use. Check the post mid lower edge or the trees at either horizon. There are a lot of pixels missing. So to crop like that and still have 4000x3000 pixels you have to scale it back up.
This is for Canon:
I took some pictures to check vignetting. I took from widest aperture to f/11 in two sets. One with Peripheral correction off and one with Peripheral correction on.
No lens correction data about 85/1,4L IS for my 6D, so just one set. I will need to download lens correction for that lens to that camera later.
For Canon EOS M5 the tags 0x0014 to 0x0018 are changing with the aperture.
For Canon EOS 6D the tags 0x000d to 0x0012 are changing with the aperture.
For M5 + 50/1.2L at f/1.2 I got: 6898 4939 2757 2041 1481
or if I also include values that aren’t changing or not changing much: 8191 6898 4939 2757 2041 1481 0
For M5 + 50/1.2L at f/11 I got: 8093 7811 7246 6954 6653
or 8190 8093 7811 7246 6954 6653 0
For 6D + 50/1.2L at f/1.2 I got: 6898 4939 2757 2041 1481
or if I also include values that aren’t changing or not changing much: 8191 6898 4939 2757 2041 1481 0
For 6D + 50/1.2L at f/11 I got: 8093 7811 7246 6954 6653
or 8190 8093 7811 7246 6954 6653 0
Panasonic Lumix S
lenses are not supported by lensfun at the moment, so they are not supported in darktable either, which is a pity.
Every RW2 Raw file from a Lumix camera does contain lens correction format in a proprietary format. With the exiftool one can extract 7 distortion parameters, see https://exiftool.org/TagNames/PanasonicRaw.html#DistortionInfo
$ exiftool P1000275.RW2 | grep -i Distortion
Distortion Param 02 : 0.002044677734375
Distortion Param 04 : 0.032867431640625
Distortion Scale : 1.00030526894194
Distortion Correction : On
Distortion Param 08 : 0.132843017578125
Distortion Param 09 : 0.01715087890625
Distortion Param 11 : -0.0714111328125
What I have to find out is what they mean. My guess is that they are parameters according to the Adobe camera model , which would need 5 parameters. See the work of: https://syscall.eu/#pana
I’m very exited about your module for darktable. If we understand for which model these parameters work, there is a chance to support every Lumix S lens out there out of the box including those to be released in the future.
Help!
I forked exiv2 and coded the first time in my life in C++:
This is how far I got:
$:~/dev/exiv2/build/bin> ./exiv2 -g “Exif.PanasonicRaw.DistortionInfo” p.rw2
Exif.PanasonicRaw.DistortionInfo Undefined 32 216
I can search the Panasonic RAW file for Distortion Information in the Makernotes, Tag 0x119, it is found and 32 bytes long.
My 1 day knowledge of C++ is not sufficient I’m afraid to get these integers out in the right way.
Could any show me how to get out for example a signed integer (corrected) from bytes 4 and 5 (=DistortionParameter02) ?
This has to be divided by 32768.0 afterwards to get the correction parameter.
Well, according to the information you provide, DistortionParameter02 is a (signed) 16-bit integer, not a rational or a floating point number. You’d need a second number to define a rational.
But, given that you showed Exiftool can read that info, isn’t it much easier to check first if those parameters vary between images? If they don’t for a given lens, and the model is supported by lensfun, it would be much easier to extract the parameters once with exiftool, and then add the data to lensfun.
Alternatively, check how Exiftool calculates the distortion parameters as floats?
Yes, you are right. They are 16-bit signed Integers. For correction to work they are divided by 32768 afterwards, according to the Research of: https://syscall.eu/#pana
We are speaking of zoom lenses here, and the correction data varies from image to image. What lensfun does is interpolate between the focal lengths given. To be exact you need lots of them and will never beas accurate as the data from the manufacturer.
AND: this quest for lensfun correction data begins a new with every new lens. If we could read out the lens correction data out of the raw we would have support from day 1 on.
