Version: 2.0.0 (using KDE 4.5.3) OS: Linux Using 2.0.0 beta 1 I tried to detect some faces. I click on "scan collection for faces" after a few minutes, the progress bar is still moving but the process is finished and I can click on close. But I can not see any picture in the people/unknown tag. The view on the right is completely empty. I can not scroll (as in Gilles' report). If I go back to album view and preview a pciture, if I click on "add a face tag" nothing happens and I can not see any face tag. Reproducible: Always
I forgot to say that I tried to change sensitivity and rerun face detection without success. Julien
Do you have installed OpenCV data files ? Under mandriva it's a separate rpm for ex. Here, all work fine... Gilles Caulier
I am runing ubuntu 10.10 and i installed all libcv, libcv-dev libcvaux libcv4 packages. The files such as haarcascade_frontalface_alt2.xml ... are not installed by the packages libcv* packages but by the opencvdoc package in /usr/share/doc/opencvdoc/examples/haarcascades/haarcascades/haarcascade_frontalface_alt2.xml.gz Is this the problem ? digikam needs this ? Julien
yes, haar cascade files are mandatory Gilles Caulier
K so it seems that in a lot of places the default installs are different. Can we try to compile a list of places that packages install cascades and I can add them to the code so we can anticipate this. Otherwise I might add a parameter to specify the location of the cascades as so many people have them in different directories. Alex On 4 Jan 2011, at 15:29, Julien Narboux wrote: > https://bugs.kde.org/show_bug.cgi?id=262074 > > > > > > --- Comment #3 from Julien Narboux <Julien narboux fr> 2011-01-04 16:29:58 --- > I am runing ubuntu 10.10 and i installed all libcv, libcv-dev libcvaux libcv4 > packages. > The files such as haarcascade_frontalface_alt2.xml ... are not installed by > the packages libcv* packages but by the opencvdoc package in > /usr/share/doc/opencvdoc/examples/haarcascades/haarcascades/haarcascade_frontalface_alt2.xml.gz > > Is this the problem ? digikam needs this ? > > Julien > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug. > _______________________________________________ > Digikam-devel mailing list > Digikam-devel@kde.org > https://mail.kde.org/mailman/listinfo/digikam-devel If we knew what we were doing, it wouldn't be called research, would it? -- Albert Einstein
After searching into ubuntu packages, it seems that these files are considered as examples and hence are not shipped with opencv but are shipped with the applications using them. Maybe digikam should also include a copy of these files. Anyway there should be an error message appearing in the gui if the file can not be found, otherwise we will get many similar bug reports. Julien
Thanks for your help. Under ubuntu 10.10, copying and uncompressing the haarcascades solved the issue: sudo cp -R /usr/share/doc/opencv-doc/examples/haarcascades/haarcascades /usr/share/opencv/ cd /usr/share/opencv/haarcascades sudo gunzip *.gz Julien
Alex, How to solve this issue ? haar cascade files must be included in libface ? Gilles Caulier
No, we should not include them: It's 20 MB. That will be ten or twenty times the size of the package, all of it duplicated. And these files are not examples. They were created by researchers in a pretty involved process from large datasets, then made available publicly. You dont do that in an afternoon. It is the collection of haarcascades available freely in this world. So e.g. file a bug against Ubuntu.
Thanks Marcel, so i close this file now... Gilles Caulier
Ok Marcel, I will file a bug against ubuntu. But there is still a problem in digiKam, if the files are missing there should be an error message in the gui not in the console I think. Julien
On my system, opencv is complete with haarcascades files, located in /usr/share/opencv/haarcascades, but digikam looks for them at /haarcascades. I have had to create symbolic link /haarcascades -> /usr/share/opencv/haarcascades and now it works. How come it has detected an unexisting path for those files? is it hardcoded? I haven't found an option to change haarcascades path in digikam properities. (system is Slackware64 current)
A bug has been filed in Ubuntu bug tracking system here: https://bugs.launchpad.net/opencv/+bug/698016
face detection doesn't work in openSUSE 11.4 (factory) with KDE RC2 (K:D:F) either. after downloading & unpacking opencv-doc from ubuntu repos, i found that they were alredy included in the opencv package i'd installed. also providing a symlink in / doesn't help, as it did according to #12. i'll try to compile digikam2 from source now, let's see what happens...
I'm under kubuntu 10.10 and the face detection does not work. following this thread I tried "sudo apt-get install-dev libcv libcv libcvaux libcv4 => E: Could not find package libcv E: Could not find package libcvaux E: Could not find package libcv4 " libcv-dev was already installed Then I try "sudo apt-get install opencv-doc sudo cp-R / usr / share / doc / opencv-doc / examples / haarcascades / haarcascades / usr / share / opencv / cd / usr / share / opencv / haarcascades sudo gunzip *. gz " Despite this manipulation, the face-detection "does not work may be necessary to recompile it digikam?
Vince, how did you get digikam 2.0.0 beta 1 ? can you lis the files in /usr/share/opencv/haarcascades ? Julien
I get get digikam 2.0.0 beta 1 here : http://sourceforge.net/projects/digikam/files the files in my /usr/share/opencv/haarcascades are : haarcascade_eye_tree_eyeglasses.xml haarcascade_eye.xml haarcascade_frontalface_alt2.xml haarcascade_frontalface_alt_tree.xml haarcascade_frontalface_alt.xml haarcascade_frontalface_default.xml haarcascade_fullbody.xml haarcascade_lefteye_2splits.xml haarcascade_lowerbody.xml haarcascade_mcs_eyepair_big.xml haarcascade_mcs_eyepair_small.xml haarcascade_mcs_lefteye.xml haarcascade_mcs_mouth.xml haarcascade_mcs_nose.xml haarcascade_mcs_righteye.xml haarcascade_mcs_upperbody.xml haarcascade_profileface.xml haarcascade_righteye_2splits.xml haarcascade_upperbody.xml thanks for your work and your interest
What do you mean exactly by does not work ? what are the symptoms ? can you run digikam in a console to check if there are some error messages about haarcascades ? Julien
ok it's work launching Digikam in a terminal show me that Digikam for cascades files at /haarcascades like in comment #12 so i create a symbolic link like this : sudo ln -s /usr/share/opencv/haarcascades /haarcascades and the face-detection scanner work fine Thanks for your work, For me Digikam is the best photo-manager
This must be fixed in libface's CMake files. Obviously, an empty string is detected for location of opencv, to which "/haarcascades" is appended.
Just fyi: I am on Fedora 14, using a self prepared digikam 2.0 rpm. I had to add the link to /haarcascades as well.
For me, neither 2.0.0-beta1 nor 2.x svn branch ever detect any faces - the detection completes OK, but the People/Unknown tag always remains with zero pictures. My opencv looks correctly installed, and I tried making the /haarcascades symlink, but it didn't help. When I run digikam through strace -e file and look for file syscalls involving the haarcascades files, I don't see any. Also, the binary links against libkface, but not libface - surely that is not right? $ pmap `pgrep -f /opt/digikam2/bin/digikam` | grep face 00007f2b36341000 316K 200K 200K 0K 0K r-xp /opt/digikam2/lib64/libkface.so.1.0.0 00007f2b36390000 2048K 0K 0K 0K 0K ---p /opt/digikam2/lib64/libkface.so.1.0.0 00007f2b36590000 4K 4K 4K 4K 0K r--p /opt/digikam2/lib64/libkface.so.1.0.0 00007f2b36591000 8K 8K 8K 8K 0K rw-p /opt/digikam2/lib64/libkface.so.1.0.0 $ ldd /opt/digikam2/lib64/libkface.so.1.0.0 | grep face Any other ideas? Finally, this is marked as RESOLVED UPSTREAM but I can't see anywhere that it has been reported upstream: https://code.ros.org/trac/opencv/report/6 http://sourceforge.net/apps/trac/libface/report/6 Is it a libface issue or an opencv issue?
I did some investigation under my svn working directory and found these relevant lines: build/CMakeCache.txt:OpenCV_DIR:PATH=/usr/share/opencv extra/libkface/libface/LibFace.h: LibFace(Mode type = ALL, const std::string& configDir = ".", const std::string& cascadeDir = std::string(OPENCVDIR)+"/data/haarcascades"); extra/libkface/libface/LibFace.h: LibFace(Mode type = ALL, const std::string& configDir = ".", const std::string& cascadeDir = std::string(OPENCVDIR)+"/haarcascades"); extra/libkface/libface/LibFaceConfig.h.cmake:#define OPENCVDIR "@OpenCV_DIR@"
> Also, the binary links > against libkface, but not libface - surely that is not right? Indeed - but I dont think libkface will link without libface. It's not an optional dependency. ldd /usr/lib64/libkface.so | grep libface libface.so.0 => /usr/lib64/libface.so.0 (0x00007f6c9e26b000) ldd /usr/bin/digikam | grep libface libface.so.0 => /usr/lib64/libface.so.0 (0x00007f43d9649000) > Any other ideas? Where are your haarcascades installed then? In /usr/share/opencv/(data/)haarcascades ? ls /usr/share/opencv/haarcascades/ haarcascade_eye_tree_eyeglasses.xml haarcascade_lefteye_2splits.xml haarcascade_mcs_righteye.xml haarcascade_eye.xml haarcascade_lowerbody.xml haarcascade_mcs_upperbody.xml haarcascade_frontalface_alt2.xml haarcascade_mcs_eyepair_big.xml haarcascade_profileface.xml haarcascade_frontalface_alt_tree.xml haarcascade_mcs_eyepair_small.xml haarcascade_righteye_2splits.xml haarcascade_frontalface_alt.xml haarcascade_mcs_lefteye.xml haarcascade_upperbody.xml haarcascade_frontalface_default.xml haarcascade_mcs_mouth.xml haarcascade_fullbody.xml haarcascade_mcs_nose.xml > > Finally, this is marked as RESOLVED UPSTREAM but I can't see anywhere > that it has been reported upstream We mark as upstream if it is an issue we cannot fix by changing any digikam C++ or CMake code, here it was pretty obviously a problem of installing packages and having files in place. I will certainly not open a bug report for a distribution which I do not use.
(In reply to comment #24) > > Also, the binary links > > against libkface, but not libface - surely that is not right? > > Indeed - but I dont think libkface will link without libface. It's not an > optional dependency. So how did this happen with my build? $ ldd /opt/digikam2/bin/digikam | grep face libkface.so.1 => /opt/digikam2/lib64/libkface.so.1 (0x00007f078e09f000) $ ldd /opt/digikam2/lib64/libkface.so | grep face Here is the extract from my digikam cmake output: -- ---------------------------------------------------------------------------------- -- Starting CMake configuration for: libkface -- Found Qt-Version 4.7.1 (using /usr/bin/qmake) -- Found Qt-Version 4.7.1 (using /usr/bin/qmake) -- Found X11: /usr/lib64/libX11.so -- Found KDE 4.6 include dir: /usr/include -- Found KDE 4.6 library dir: /usr/lib64 -- Found the KDE4 kconfig_compiler preprocessor: /usr/bin/kconfig_compiler -- Found automoc4: /usr/bin/automoc4 -- Check LibFace library using pkg-config... -- WARNING: you are using the obsolete 'PKGCONFIG' macro use FindPkgConfig -- PKGCONFIG() indicates that libface is not installed (install the package which contains libface.pc if you want to support this feature) -- Cannot find LibFace library! -- First try at finding OpenCV... -- Great, found OpenCV on the first try. -- External libface was not found, use internal version instead... -- ---------------------------------------------------------------------------------- Does the last line mean that it is automatically using the internal version, or that I have to do something before it will use the internal version? If so, what? > Where are your haarcascades installed then? In > /usr/share/opencv/(data/)haarcascades ? Yep: $ ls /usr/share/opencv/haarcascades haarcascade_eye_tree_eyeglasses.xml haarcascade_mcs_eyepair_small.xml haarcascade_eye.xml haarcascade_mcs_lefteye.xml haarcascade_frontalface_alt2.xml haarcascade_mcs_mouth.xml haarcascade_frontalface_alt_tree.xml haarcascade_mcs_nose.xml haarcascade_frontalface_alt.xml haarcascade_mcs_righteye.xml haarcascade_frontalface_default.xml haarcascade_mcs_upperbody.xml haarcascade_fullbody.xml haarcascade_profileface.xml haarcascade_lefteye_2splits.xml haarcascade_righteye_2splits.xml haarcascade_lowerbody.xml haarcascade_upperbody.xml haarcascade_mcs_eyepair_big.xml > > Finally, this is marked as RESOLVED UPSTREAM but I can't see anywhere > > that it has been reported upstream > > We mark as upstream if it is an issue we cannot fix by changing any digikam C++ > or CMake code, here it was pretty obviously a problem of installing packages > and having files in place. Sure - so which project is the problem with: libkface, libface, or opencv? I checked the bug databases for all three and I couldn't see it reported in any of them, so I am wondering if anyone else is aware of the problem. > I will certainly not open a bug report for a distribution which I do > not use. Sure - distributions are downstream not upstream, anyway. I agree it's pointless submitting distro bugs for this OpenCV_DIR path issue, because it is not distro-specific (I am on openSUSE 11.3, for instance). That's why I am checking that a bug really has been filed upstream. Thanks for your continued help!
Ok, the linking is not our problem, if no system libface is found an internal version is compiled in, not linked. Wrong track. It wouldn't compile otherwise. There is a line of output from libface where it gives the directory it is using: "Cascade directory located as : " << cascadeDir probably when you begin face detection. Btw, I think we closed as upstream because of the "/haarcascades" symlink problem in libface.
(In reply to comment #26) > Ok, the linking is not our problem, if no system libface is found an internal > version is compiled in, not linked. Wrong track. It wouldn't compile otherwise. OK, that's what I suspected. > There is a line of output from libface where it gives the directory it is > using: > "Cascade directory located as : " << cascadeDir > probably when you begin face detection. Yep - I see this: Cascade directory located as : /usr/share/opencv/haarcascades but still I get zero photos with the People/Unknown tag, even if I slide the top slide bar all the way to the right towards Accurate and the bottom one all the way to the left towards Sensitive. What can I check next? In case it helps, here is the STDOUT/STDERR log: http://adamspiers.org/computing/digikam/digikam2.log > Btw, I think we closed as upstream because of the "/haarcascades" symlink > problem in libface. Well there is no issue reported here: http://sourceforge.net/apps/trac/libface/report but based on the above, maybe it's already fixed.
Dont you think the approx one thousand error messages about failed database queries look suspicious? ;-) It seems that neither the main database nor the thumbnail database have been properly upgraded to the new schema - the error messages say that tables like TagProperties, ImageTagProperties or CustomIdentifiers do not exist. The very strange point here is that the version number of the database is increased, which is usually only done in one transaction with the actual upgrade.
(In reply to comment #28) > Dont you think the approx one thousand error messages about failed database > queries look suspicious? ;-) Yes, I did wonder about those, but I also assumed that users would not be expected to carefully read STDOUT/STDERR (which normally vanishes into some hidden log file or /dev/null anyway). > It seems that neither the main database nor the thumbnail database have been > properly upgraded to the new schema - the error messages say that tables like > TagProperties, ImageTagProperties or CustomIdentifiers do not exist. > The very strange point here is that the version number of the database is > increased, which is usually only done in one transaction with the actual > upgrade. Right, I guess that explains why the UI didn't warn me about an out of date schema, although one would have hoped that the transactional nature of the upgrade would not have allowed this :( I will do a manual schema upgrade and see if it fixes the issue. Thanks again!
One more thought - if the face detection code requires certain fields to be in the database and doesn't find them, surely it should issue some kind of error in the UI rather than silently failing? Shall I submit a separate bug for this?
There may be a loophole. It's all depending on the dbconfig.xml file. It seems if the wrong file is used - from the 1.x version - the schema update action is null, but the update apparently succeeds. I will add a few safety nets to avoid such a problem. If you are a sure digikam uses the right dbconfig.xml - it's using /opt/digikam2/share/apps/digikam/database/dbconfig.xml for you atm - it should be sufficient that you only reduce the DBVersion flag in the settings table from 6 to 5, at the next restart the schema update will then be done. For the thumbnail db, from 2 to 1.
(In reply to comment #31) > There may be a loophole. It's all depending on the dbconfig.xml > file. It seems if the wrong file is used - from the 1.x version - > the schema update action is null, but the update apparently > succeeds. I will add a few safety nets to avoid such a problem. Great, thanks! > If you are a sure digikam uses the right dbconfig.xml - it's using > /opt/digikam2/share/apps/digikam/database/dbconfig.xml for you atm - > it should be sufficient that you only reduce the DBVersion flag in > the settings table from 6 to 5, at the next restart the schema > update will then be done. For the thumbnail db, from 2 to 1. Yep - that fixed it for me: sqlite3 Pictures/digikam4.db 'update settings set value = 5 where keyword = "DBVersion"' sqlite3 Pictures/thumbnails-digikam.db 'update settings set value = 1 where keyword = "DBThumbnailsVersion"' Now faces are being detected but there are other problems: (1) The photos are not being tagged with 'People/Unknown' (2) When I do a "Recognize faces" scan, it completes immediately with no prompting - to find the detected faces, I have to manually scroll through the photos (mentioned in bug 262212) (3) The "Add a Face Tag" icon and entry in the right-click context menu don't do anything (mentioned in bug 262212) Let me know if I should submit new bugs for (1) and (3).
1) They are grouped under People/Unknown from the People left sidebar? No more is supposed to be done. We dont want to fully tag with a temporary tag like the Unknown tag which will usually be removed later 2) If recognition worked, the idea is that the photos are marked with the recognized name, grouped under the name in the People's sidebar, but still have the Ok/- buttons to confirm or reject. 3) I know, there's a bug report somewhere.
(In reply to comment #33) > 1) They are grouped under People/Unknown from the People left sidebar? No, not for me. That is the problem. > 3) I know, there's a bug report somewhere. Bug 262212?
SVN commit 1218150 by mwiesweg: Ensure that digikam is using the correct version of the dbconfig.xml file. From now on, if a wrong file is found, a big error message is displayed at startup. An attempted schema update should fail. You will need to "make install" after this change. CCBUG:262074 M +4 -0 CMakeLists.txt M +4 -0 data/database/CMakeLists.txt M +6 -0 data/database/dbconfig.xml.cmake M +1 -0 digikam/CMakeLists.txt M +6 -0 libs/database/databaseaccess.cpp M +53 -15 libs/database/databaseconfigelement.cpp M +2 -0 libs/database/databaseconfigelement.h M +1 -0 libs/database/databasecorebackend.cpp M +9 -1 libs/database/schemaupdater.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1218150
> > 1) They are grouped under People/Unknown from the People left sidebar? > No, not for me. That is the problem. So the album views accessible from the left sidebar are empty for you, and you see recognized faces only framed in the preview view? Hm, did you check that the ioslaves from 2.0 are properly in use, not those from 1.x? > > 3) I know, there's a bug report somewhere. 262574
(In reply to comment #36) > > > 1) They are grouped under People/Unknown from the People left sidebar? > > No, not for me. That is the problem. > > So the album views accessible from the left sidebar are empty for you No, the album views are populated correctly. It's the People > Unknown tag which always has zero photos, whether I view it from the Albums sidebar or the People sidebar. > you see recognized faces only framed in the preview view? Right. > Hm, did you check that the ioslaves from 2.0 are properly in use, not those > from 1.x? It seems kdeinit4 munges argv[0] to things like "kdeinit4: kio_digikamtags [kdeinit] digikamtags" but based on lsof/pmap, it looks like it's using the 1.x ioslaves. I wrote a shell wrapper which always does this before launching digikam: export DIGIKAMDIR=/opt/digikam2 export PATH=$DIGIKAMDIR/bin:$PATH export LD_LIBRARY_PATH=$DIGIKAMDIR/lib64:$LD_LIBRARY_PATH export KDEDIRS=$DIGIKAMDIR:/usr kbuildsycoca4 Am I missing something?
But again it seems more defensive programming is required - if an out of date kioslave is in use and that's an issue for digikam 2.x, shouldn't digikam detect that and either refuse to run or show an error in the GUI?
Adam - because you have digikam installed in a different place to KDE itself, do: export KDE_FORK_SLAVES=1 ...before running digikam, or the IO slaves from /usr will always be loaded, rather than checking in $KDEDIRS..
Ah, thanks! Now I'm finally getting photos appearing under the People/Unknown tag in the People sidebar! I'm now experiencing other issues, but they no longer fall under the scope of this bug, so I've filed them as bug 265022 and bug 265025.