Version: (using KDE KDE 3.5.4) Installed from: Debian testing/unstable Packages libexiv already support severel makernotes from Canon. For example, it shows (as an integer field) the AF point chosen by the camera. A (kipi-plugin?) to overlay the focuspoint squares would be very handy, like in Canon's ZoomBrowser, or EosViewer. (See attachment). It might be tricky, since the focuspoints size and location differs from camera-make to camera-make. I can provide example pics wit hthe overlay shown for EOS20D (a friend's machine) and EOS350D (mine). NOTE: this feature is important for VIEWING. That is, it is needed not just in the editor, but in the preview mode.
Created attachment 18895 [details] Screenshot of Canon's ZoomBrowserEX highlighting the AF points of an EOS350D as a picture overlay. Selected AF point(s) is/are shown in red
Note, that (at least in Caon cameras) the sensitivity of the AF points are not unidirectional (not widely known property, though). Their sensitivity are indicated by the shape of the AF-point-indication. Attachment#18895 [details] is a little bit misleading from this point of view, since it shows "squares" instead of properly oriented rectangles
The implementation shall be prepared to select different AF-sensor layout for drwaing no a per-camera-brand/make basis. I will upload an EOS 20D example soon, to see the differences between the AF-sensors of the different camereas from the same vendor
Additional practical note: the implementation shall be prepared to zoom the AF-point overlays together with the viewed picture, otherwise it may show erroneous location of AF-point
Created attachment 18900 [details] Screenshot of Canon's EosViewer highlighting the AF points of an EOS20D as a picture overlay. Selected AF point(s) is/are shown in red
I have just tested this on my Canon 400D (Digital Rebel XTi) and which has same AF layout as 20 D and it reports same results in exiv2 field: img_4191.jpg Exif.CanonPi.AFPointsUsed20D Short 1 center img_4192.jpg Exif.CanonPi.AFPointsUsed20D Short 1 top img_4193.jpg Exif.CanonPi.AFPointsUsed20D Short 1 upper-right img_4194.jpg Exif.CanonPi.AFPointsUsed20D Short 1 right img_4195.jpg Exif.CanonPi.AFPointsUsed20D Short 1 lower-right img_4196.jpg Exif.CanonPi.AFPointsUsed20D Short 1 bottom img_4197.jpg Exif.CanonPi.AFPointsUsed20D Short 1 lower-left img_4198.jpg Exif.CanonPi.AFPointsUsed20D Short 1 left img_4199.jpg Exif.CanonPi.AFPointsUsed20D Short 1 upper-left img_4200.jpg Exif.CanonPi.AFPointsUsed20D Short 1 center, lower-right As you can see, this is bitmap field and can indicate multiple points used.
Arnd, This can be another candidate for GoC Gilles
*** Bug 182912 has been marked as a duplicate of this bug. ***
Any news in this topic? It would be really useful function, specially for young photographers. Rafael
Nothing. A wrapper must be created between image metadata and digiKam to create a map of AF rectangle. This interface must be able to extract these information from other camera model (for ex., i know something similar about Minolta/Sony makernotes) Gilles Caulier
Just tell me how can I support you :-)
Rafael, Are you developper ? Gilles
I was few years ago, but not anymore :-( I can support you by testing, giving feedback, examples etc.
Some of problem with showing of focus points lies in non-standardization of this area. digiKam would have to store layouts of focus points for all cameras and all codenames for particular points. Gigantic task for small niche of users.
Contributing the information about the location and size of autofocus regions can be done by interested users, once the basic infrastructure is set up. Of course supporting *all* cameras is maybe asking too much, but still after a while a substantial collection will emerge....
Arnd you are right. I'm sure interested users could collect all necessary data within few months - I would be one of the first :-) From the programming point of view I would make it as a separate file with database that could be downloaded from the internet (or installed with RPM). You can already load ICC files and in the same way one could load the configuration file with AF points.
To have a better audience, why not to implement the metadata wrapper in Exiv2 instead digiKam or libkexiv2. Like this, informations can be available in others programs which use Exiv2. Also, user can display information with Exiv2 command line tool. Andreas ? Gilles
There is also an important point to talk: For fresh image taken with camera, parsing and displaying AF area over the image is simple. We jsut need to compute rectangle using a camera AF database. But if the image is modified, for example cropped! what we can do ? The AF area is not at the sample place, because coordinates over the image given in Database will be done using full camera sensor resolution. The only way to wrap around this problem, is to compute adjusted coordinates of AF aera by digiKam and to store it to XML in digiKam namespace. Of course, this way will faild if user crop imgae in another editor as Gimp... Gilles Caulier
Why not use an external, file-based database? The focus point rectangles (or whatever shapes) could represented as scalable SVG graphics. (IMHO, the solution should support zooming, scaling, anyway) In many cases several models share the same focusing screen. (E.g., Canon EOS 20D,30D,40D,450D). There could be a set of focusing-screen definitions + a set a vendor/model definitions that cross-references the former. Digikam shall first lookup the camera model from EXIF, then lookup focusing screen layout by model. If the focusing screen definition is an external file (e.g., XML-based SVG graphics), the users could bugfix, extend, download, etc. the database without the need for recompiling Digikam
We should be aware that the focus points are not always rectangle shaped (see, for example, some Pentax models). Therefore, I recommend to store not just the focus point coordinates, but the shape as well, per camera model. SVG overlay could solve the two task at once: coordinates plus arbitrary shape with the same coding effort, IMHO
One additional comment: the database shall store relative coordinates instead of absolutes (e.g., leftmost focus point at 33% horizontal, 50% vertical of the image, regardless of resolution): consider shots taken with the same camera model but with using different image resolution... As for what to do with AF point position after crop: there shall be some image metadata about the image: whether it is at the original size and resolution, or not. (I hope that there is such info in EXIF). If the image is not at its original resolution, then the AF point overlay shall not be rendered, but a warning dialog shall pop-up, stating that the AF-point coordinates became invalid due to cropping.
Gilles, Maybe your solution is too complicated, why not display AF area only for pictures which have the same aspect ratio as the original pictures (uncropped) given by the sensor of the camera ? >To have a better audience, why not to implement the metadata wrapper in Exiv2 >instead digiKam or libkexiv2. Like this, informations can be available in others >programs which use Exiv2. Also, user can display information with Exiv2 command >line tool. Andreas ? I think it is a good idea to do it in Exiv2. Maybe the same applies to my wish: https://bugs.kde.org/show_bug.cgi?id=180322 Exiv2 could compute the 35mm equivalent focal length of pictures using the sensor size ? Julien
Re comment #17: First, we'll definitely have to update the Canon makernotes in Exiv2. Besides, I agree that this is probably rather a niche requirement, so while having it in Exiv2 would be nice for a few users, the extra code would be bloat for all others. If at all, I'd only consider adding this after 0.19, when we have a unified metadata container and can add 'synthesized' tags with that information. -ahu.
As for the 35mm equivalent focal length mentioned in comment #22, I agree that this should be in Exiv2. It also requires a 'synthesized tag' and the architecture for these will be added in 0.19. -ahu.
*** Bug 249078 has been marked as a duplicate of this bug. ***
Andreas, This can be a future GoSC project for Exiv2/digiKam. What do you think about ? Gilles Caulier
A new LR plugin in open source have been created to display Focus point. It use Exiftool in background to extract right makernotes. https://www.dpreview.com/news/6649462113/open-source-lightroom-plugin-focus-point-viewer-highlights-active-focus-points https://github.com/musselwhizzle/Focus-Points/tree/master/focuspoints.lrdevplugin Gilles Caulier
With digiKam 7.3.0, we introduce ExifTool support. So a similar tool than one listed in comment #27 can be studied. Gilles Caulier
This feature is now implemented in 7.4.0. https://imgur.com/YsoQOLo This need to be improved again, but at least, displaying focus area over preview work for camera providing these information in metadata. Gilles Caulier