https://bugs.kde.org/show_bug.cgi?id=478848
--- Comment #4 from kdbrsts <kdeb...@rastos.org> --- Created attachment 164371 --> https://bugs.kde.org/attachment.cgi?id=164371&action=edit picture of AF points in focus The picture is a shot of EOS 850D display with smartphone, so sorry for the low quality ;-( Maik, to be honest I do not understand your statement: > However, we do not differentiate between Selected In focus and In focus, so > all focus fields would be red. The JSON produced by exiftool lists under key "AFPointsInFocus" seven AF points. When previewing the picture on the camera,it shows seven point arranged in the center of the screen like this: x x x x x x x And the value under AFPointsInFocus key indeed lists a group of 3 consecutive points (9,10,11) and then another group of 3 points (16,17,18) and then a group with single point (25). Each of those groups, IMO, corresponds to one row of adjacent AF points shown in the preview. The assignment of the AF point number to the coordinates in AFAreaXPositions and AFAreaYPositions keys is unclear to me. I did not try to explore that in detail. I expect that may vary with camera model and total number and layout of the AF points. Yes, both AFPointsSelected and AFPointsInFocus are parsed and assigned to af_selected (focuspoints_extractor_canon.cpp:187), but only AFPointsInFocus is parsed into af_infocus (focuspoints_extractor_canon.cpp:190). I assume that only points in "af_infocus" variable are shown in red in digikam when selecting "Show focus points". Am I wrong about that? I'm not saying that FocusPointsExtractor::findValue(...) should be modified to always use comma instead of space. I have no idea if that could break parsing other values. But creating a special parsing for AFPointsInFocus or adding a separator parameter with default value set to space and specifying "," only when parsing AFPointsInFocus could make this particular issue fixed. Right? -- You are receiving this mail because: You are watching all bug changes.
