Bug 267789 - Make face detection and geo tagging optional features
Summary: Make face detection and geo tagging optional features
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Portability-Cmake (show other bugs)
Version: 4.4.0
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-06 13:45 UTC by Christoph Feck
Modified: 2019-08-18 08:59 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.7.0
Sentry Crash Report:


Attachments
Patch to remove any Face-Detection and Face-Tagging from digikam (8.54 KB, patch)
2012-01-21 11:39 UTC, kgw
Details
Patch making libkface fully and properly optional. (10.02 KB, patch)
2012-01-21 22:32 UTC, kgw
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Feck 2011-03-06 13:45:08 UTC
Version:           unspecified (using Devel) 
OS:                Linux

digiKam/master now requires the kface and kmap libraries together with its dependencies (notably the OpenCV library and Marble) to be installed. The dependencies are rather heavy compared to other optional dependencies (the OpenCV package has 29 MB here). Those dependencies have been optional in kipi-plugins.

If possible, I would like to continue to be able to reduce the weight of the digiKam suite by reducing its feature set, so it would be nice if the kface and kmap dependencies were optional.

Reproducible: Didn't try
Comment 1 Marcel Wiesweg 2011-03-06 14:19:52 UTC
Both libraries were developed to implemented important features wished for a long time, and are integrated closely into digikam.
I dont see the value to cut newly developed features and ship a disabled version for the sake of what?
Marble is in my understanding a pillar of KDE.
We could talk about making face detection, thus libkface optional, but dont expect any work from me in that direction.
Comment 2 caulier.gilles 2011-03-06 14:52:31 UTC
My viewpoint : set these dependencies optional will be complex (but not impossible)

I let's Marcel choose for libkface.
I let's Micheal choose for libkmap.

Gilles Caulier
Comment 3 Christoph Feck 2011-03-06 15:04:47 UTC
If it is too much of a hassle, please close as wontfix. I was mainly thinking of Live CDs and users who don't collect images of persons they know ;)
Comment 4 Marcel Wiesweg 2011-03-06 15:10:14 UTC
For libface, we need the haarcascades at 19MB. If these files are not present, face detection will fail silently, but digikam will not crash.
Regarding Marble, we mainly need the library. I dont know what happens if the basic map data is not present - marble should be able to cope with running without offline data. Loading maps from OSM or Google Maps gives much better results anyway, requires network of course.
Comment 5 Christoph Feck 2011-03-06 15:23:11 UTC
You are right, the Haar data is indeed optional, so 66% of the "OpenCV problem" is already solved. I guess the other third is not worth the hassle. Thanks. Feel free to reopen if someone wants to take the challenge.
Comment 6 caulier.gilles 2011-03-06 15:41:04 UTC
Marcel,

Note that with current stable libface 0.2.0, libkface do not compile...

Current libkface include libface 0.1.0 source code...

Gilles Caulier
Comment 7 caulier.gilles 2011-03-06 18:12:28 UTC
Alex, Can you comment my previous post please ?

Gilles Caulier
Comment 8 Alex 2011-03-06 18:20:10 UTC
Hi Giles,

Sorry I haven't commented before. I have slightly changed the interface, all in the effort of bug fixing and plugging memory leaks. So the change is actually not that big, e.g. instead of vectors pointers to the vectors are returned. I was waiting for the move to git to be done and finalised because I didn't really know where best  to submit change to libkface.


On 6 Mar 2011, at 17:12, Gilles Caulier wrote:

> https://bugs.kde.org/show_bug.cgi?id=267789
> 
> 
> Gilles Caulier <caulier.gilles@gmail.com> changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |alexjironkin@gmail.com
> 
> 
> 
> 
> --- Comment #7 from Gilles Caulier <caulier gilles gmail com>  2011-03-06 18:12:28 ---
> Alex, Can you comment my previous post please ?
> 
> Gilles Caulier
> 
> -- 
> 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
Comment 9 caulier.gilles 2011-03-06 18:25:57 UTC
Alex,

Thanks for your response. Libkface code is here in KDE Git repository:

https://projects.kde.org/projects/kdereview/libkface

Gilles Caulier
Comment 10 caulier.gilles 2011-03-06 18:28:30 UTC
Micheal,

Your comment about optional libkmap dependency ?

Gilles Caulier
Comment 11 Michael G. Hansen 2011-03-07 20:08:12 UTC
Hi,

- one option is making Marble an optional compile-time or even run-time dependency, however this is not easy because we use some geodata-classes from Marble in the core of libkmap. But in principle, it could be done. Without Marble, libkmap can still run using Google Maps.

- compiling digikam without libkmap: Should be doable using ifdef and CMake, and simply make the map search, gps properties tab and central map view unavailable.

However, I share Marcel's feeling about removing these features: For 2.0, they were heavily advertised. Now if some user fears compiling digikam, and instead try out a live cd, they might be disappointed to find a digikam without the features they anticipated.

Michael
Comment 12 Gert Kello 2011-03-08 06:52:45 UTC
Hi,

The digikam memory usage is a bit too high for my taste, so ability to disable some parts I'm not using would be quit nice feature
Comment 13 Marcel Wiesweg 2011-03-08 21:03:11 UTC
Face detection does not use memory if you dont need it.
There have been memory issues with marble, did not benchmark with 4.6 yet.
Comment 14 Michael G. Hansen 2011-03-08 21:27:13 UTC
KMap instances also only create MarbleWidget or KHTML instances when they are activated, like when a tab containing them is opened. When inactive, their only footprint should be some UI elements and the code size of libmarble. I plan to investigate how much progress has been made in Marble to reuse parts of the memory between MarbleWidget instances. We can also still optimize when KMap instances are seen to be 'active' in digikam, like only when you actually open a tab.

Off-topic: Marcel, I think we currently pre-created the editor and the lighttable - maybe we can add an option to not pre-create them?

Michael
Comment 15 Marcel Wiesweg 2011-03-08 22:03:19 UTC
> Off-topic: Marcel, I think we currently pre-created the editor and the
> lighttable - maybe we can add an option to not pre-create them?

Yes we precreate lighttable, batch queue manager and image editor. I didnt do any memory benchmarks about that as well.
Comment 16 Alex 2011-03-09 10:05:34 UTC
In the 0.1 version of libface there is a memory leak in detection, I think it will get more noticeable once you have you start going through a lot of faces. There is also a trick one can/has to do when dealing with the vector of faces from detection. Although the actual objects are stored in that array, they need to be accessed using pointers. Otherwise there when the Face/KFace class retrieved and destroyed in the local scope the Pointer to the actual data in the class will be released and later down the line it will segfault. I haven't figured if I should change from vector of Face's to vector of pointers to faces.


Alex
 
On 8 Mar 2011, at 20:03, Marcel Wiesweg wrote:

> https://bugs.kde.org/show_bug.cgi?id=267789
> 
> 
> 
> 
> 
> --- Comment #13 from Marcel Wiesweg <marcel wiesweg gmx de>  2011-03-08 21:03:11 ---
> Face detection does not use memory if you dont need it.
> There have been memory issues with marble, did not benchmark with 4.6 yet.
> 
> -- 
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

If we knew what we were doing, it wouldn't be called research, would it?
-- Albert Einstein
Comment 17 caulier.gilles 2011-03-09 10:35:17 UTC
Alex,

Did you manage all changes in libkface to compile fine against libface 0.2.0 ?

Gilles Caulier
Comment 18 Alex 2011-03-09 10:41:50 UTC
Not yet sorry, I am going to do it this afternoon.


Alex

On 9 Mar 2011, at 09:35, Gilles Caulier wrote:

> https://bugs.kde.org/show_bug.cgi?id=267789
> 
> 
> 
> 
> 
> --- Comment #17 from Gilles Caulier <caulier gilles gmail com>  2011-03-09 10:35:17 ---
> Alex,
> 
> Did you manage all changes in libkface to compile fine against libface 0.2.0 ?
> 
> Gilles Caulier
> 
> -- 
> 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
Comment 19 caulier.gilles 2011-03-11 09:40:52 UTC
*** Bug 268191 has been marked as a duplicate of this bug. ***
Comment 20 caulier.gilles 2011-03-11 10:07:23 UTC
Alex,

if you cannot commit anyway, attach patch on this bugzilla file.

Gilles Caulier
Comment 21 kgw 2011-03-11 10:22:48 UTC
IMHO the face detection also clutters the interface unduly (never used sidebar,
never used context menu entries) - I don't care about face detection one iota.
I take about 20000-30000 photos in a year and not a single of those has any
people in them that would warrant face detection unless I was careless... 
I just finished ripping out the face interface completely from my local copy - now how do I get git to not overwrite my local changes but to merge the changes in the current git branch gracefully (like svn update did previously, I already once lost my changes by doing a git pull)?
Comment 22 Alex 2011-03-11 11:14:27 UTC
I figured out why I couldn't commit before. and have just committed the changes. Or at least I think I have committed. I can't see them online. The only thing I have noticed there is that there is a local copy of libface. Perhaps I should update that with a new copy from SVN as the build will break using the local copy now.


Alex


 
On 11 Mar 2011, at 09:22, <kgw@mineralien-verkauf.de> wrote:

> https://bugs.kde.org/show_bug.cgi?id=267789
> 
> 
> 
> 
> 
> --- Comment #21 from  <kgw mineralien-verkauf de>  2011-03-11 10:22:48 ---
> IMHO the face detection also clutters the interface unduly (never used sidebar,
> never used context menu entries) - I don't care about face detection one iota.
> I take about 20000-30000 photos in a year and not a single of those has any
> people in them that would warrant face detection unless I was careless... 
> I just finished ripping out the face interface completely from my local copy -
> now how do I get git to not overwrite my local changes but to merge the changes
> in the current git branch gracefully (like svn update did previously, I already
> once lost my changes by doing a git pull)?
> 
> -- 
> 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
Comment 23 caulier.gilles 2011-03-11 11:17:23 UTC
Alex,

Yes, the libkface local copy of libface is 0.1 version. Please update code with 0.2 as well.

Thanks in advance...

Gilles Caulier
Comment 24 Alex 2011-03-11 11:18:38 UTC
On the subject of optional things, you are right there should be an option to turn automatic face detection off, when in your case you predominantly have pictures without people in them. But I don;t think it should be then hidden away completely as a vast majority of people will have majority of their photos with other people in them. 


Alex

P.S. the commit is there, but the comments are not displayed, perhaps I setup my commit environment wrong in some way. Hmmm

On 11 Mar 2011, at 09:22, <kgw@mineralien-verkauf.de> wrote:

> https://bugs.kde.org/show_bug.cgi?id=267789
> 
> 
> 
> 
> 
> --- Comment #21 from  <kgw mineralien-verkauf de>  2011-03-11 10:22:48 ---
> IMHO the face detection also clutters the interface unduly (never used sidebar,
> never used context menu entries) - I don't care about face detection one iota.
> I take about 20000-30000 photos in a year and not a single of those has any
> people in them that would warrant face detection unless I was careless... 
> I just finished ripping out the face interface completely from my local copy -
> now how do I get git to not overwrite my local changes but to merge the changes
> in the current git branch gracefully (like svn update did previously, I already
> once lost my changes by doing a git pull)?
> 
> -- 
> 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
Comment 26 caulier.gilles 2011-03-11 12:47:13 UTC
Alex,

Here, i don't have installed libface 0.2.0 on my computer. So libkface compile with internal version :

Scanning dependencies of target kface
[  5%] Building CXX object extra/libkface/libkface/CMakeFiles/kface.dir/database.cpp.o                                        
/mnt/data/Devel/GIT/2.x/extra/libkface/libkface/database.cpp: In member function 'QList<KFaceIface::Face> KFaceIface::Database::detectFaces(const KFaceIface::Image&)':
/mnt/data/Devel/GIT/2.x/extra/libkface/libkface/database.cpp:184: error: no matching function for call to 'libface::LibFace::detectFaces(const IplImage*&)'
/mnt/data/Devel/GIT/2.x/extra/libkface/libface/LibFace.h:85: note: candidates are: std::vector<libface::Face, std::allocator<libface::Face> > libface::LibFace::detectFaces(const IplImage*, const CvSize&)
/mnt/data/Devel/GIT/2.x/extra/libkface/libface/LibFace.h:100: note:                 std::vector<libface::Face, std::allocator<libface::Face> > libface::LibFace::detectFaces(const std::string&, int)
/mnt/data/Devel/GIT/2.x/extra/libkface/libface/LibFace.h:101: note:                 std::vector<libface::Face, std::allocator<libface::Face> > libface::LibFace::detectFaces(const char*, int, int, int, int, int, int)
/mnt/data/Devel/GIT/2.x/extra/libkface/libkface/database.cpp: In member function 'QList<double> KFaceIface::Database::recognizeFaces(QList<KFaceIface::Face>&)':
/mnt/data/Devel/GIT/2.x/extra/libkface/libkface/database.cpp:272: error: no match for 'operator=' in 'result = libface::LibFace::recognise(std::vector<libface::Face, std::allocator<libface::Face> >*, int)((& faceVec), 1)'
/usr/lib/gcc/i586-manbo-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/vector.tcc:156: note: candidates are: std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = std::pair<int, float>, _Alloc = std::allocator<std::pair<int, float> >]
make[2]: *** [extra/libkface/libkface/CMakeFiles/kface.dir/database.cpp.o] Error 1
make[1]: *** [extra/libkface/libkface/CMakeFiles/kface.dir/all] Error 2
make: *** [all] Error 2

Gilles Caulier
Comment 27 Alex 2011-03-11 13:14:11 UTC
Yeah I just noticed that I didnlt update the internal version of libface. I will pull out the best SVN version shortly and add it to the libkface
On 11 Mar 2011, at 11:47, Gilles Caulier wrote:

> https://bugs.kde.org/show_bug.cgi?id=267789
> 
> 
> 
> 
> 
> --- Comment #26 from Gilles Caulier <caulier gilles gmail com>  2011-03-11 12:47:13 ---
> Alex,
> 
> Here, i don't have installed libface 0.2.0 on my computer. So libkface compile
> with internal version :
> 
> Scanning dependencies of target kface
> [  5%] Building CXX object
> extra/libkface/libkface/CMakeFiles/kface.dir/database.cpp.o                     
> /mnt/data/Devel/GIT/2.x/extra/libkface/libkface/database.cpp: In member
> function 'QList<KFaceIface::Face> KFaceIface::Database::detectFaces(const
> KFaceIface::Image&)':
> /mnt/data/Devel/GIT/2.x/extra/libkface/libkface/database.cpp:184: error: no
> matching function for call to 'libface::LibFace::detectFaces(const IplImage*&)'
> /mnt/data/Devel/GIT/2.x/extra/libkface/libface/LibFace.h:85: note: candidates
> are: std::vector<libface::Face, std::allocator<libface::Face> >
> libface::LibFace::detectFaces(const IplImage*, const CvSize&)
> /mnt/data/Devel/GIT/2.x/extra/libkface/libface/LibFace.h:100: note:            
>    std::vector<libface::Face, std::allocator<libface::Face> >
> libface::LibFace::detectFaces(const std::string&, int)
> /mnt/data/Devel/GIT/2.x/extra/libkface/libface/LibFace.h:101: note:            
>    std::vector<libface::Face, std::allocator<libface::Face> >
> libface::LibFace::detectFaces(const char*, int, int, int, int, int, int)
> /mnt/data/Devel/GIT/2.x/extra/libkface/libkface/database.cpp: In member
> function 'QList<double>
> KFaceIface::Database::recognizeFaces(QList<KFaceIface::Face>&)':
> /mnt/data/Devel/GIT/2.x/extra/libkface/libkface/database.cpp:272: error: no
> match for 'operator=' in 'result =
> libface::LibFace::recognise(std::vector<libface::Face,
> std::allocator<libface::Face> >*, int)((& faceVec), 1)'
> /usr/lib/gcc/i586-manbo-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/vector.tcc:156:
> note: candidates are: std::vector<_Tp, _Alloc>& std::vector<_Tp,
> _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = std::pair<int,
> float>, _Alloc = std::allocator<std::pair<int, float> >]
> make[2]: *** [extra/libkface/libkface/CMakeFiles/kface.dir/database.cpp.o]
> Error 1
> make[1]: *** [extra/libkface/libkface/CMakeFiles/kface.dir/all] Error 2
> make: *** [all] Error 2
> 
> Gilles Caulier
> 
> -- 
> 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
Comment 28 caulier.gilles 2011-03-11 13:28:53 UTC
Alex,

I installed current code from trunk of libface. libkface compile fine, but digiKam not. 

This method have been removed now ?

[ 85%] Building CXX object core/digikam/CMakeFiles/digikam.dir/__/utilities/facedetection/facepipeline.cpp.o                  
/mnt/data/Devel/GIT/2.x/core/utilities/facedetection/facepipeline.cpp: In member function 'void Digikam::DetectionWorker::setSpecificity(double)':
/mnt/data/Devel/GIT/2.x/core/utilities/facedetection/facepipeline.cpp:485: error: 'class KFaceIface::FaceDetector' has no member named 'setSpecificity'
make[2]: *** [core/digikam/CMakeFiles/digikam.dir/__/utilities/facedetection/facepipeline.cpp.o] Error 1
make[1]: *** [core/digikam/CMakeFiles/digikam.dir/all] Error 2
make: *** [all] Error 2

Gilles Caulier
Comment 29 Alex 2011-03-11 15:46:42 UTC
Yeah thats why I increased the ABI version.


Alex

On 11 Mar 2011, at 12:28, Gilles Caulier wrote:

> https://bugs.kde.org/show_bug.cgi?id=267789
> 
> 
> 
> 
> 
> --- Comment #28 from Gilles Caulier <caulier gilles gmail com>  2011-03-11 13:28:53 ---
> Alex,
> 
> I installed current code from trunk of libface. libkface compile fine, but
> digiKam not. 
> 
> This method have been removed now ?
> 
> [ 85%] Building CXX object
> core/digikam/CMakeFiles/digikam.dir/__/utilities/facedetection/facepipeline.cpp.o 
> /mnt/data/Devel/GIT/2.x/core/utilities/facedetection/facepipeline.cpp: In
> member function 'void Digikam::DetectionWorker::setSpecificity(double)':
> /mnt/data/Devel/GIT/2.x/core/utilities/facedetection/facepipeline.cpp:485:
> error: 'class KFaceIface::FaceDetector' has no member named 'setSpecificity'
> make[2]: ***
> [core/digikam/CMakeFiles/digikam.dir/__/utilities/facedetection/facepipeline.cpp.o]
> Error 1
> make[1]: *** [core/digikam/CMakeFiles/digikam.dir/all] Error 2
> make: *** [all] Error 2
> 
> Gilles Caulier
> 
> -- 
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

If we knew what we were doing, it wouldn't be called research, would it?
-- Albert Einstein
Comment 30 caulier.gilles 2011-03-11 15:49:33 UTC
Alex, this settings must be removed into digiKam face detection gui. Right ?

It's replaced by another one ?

Gilles Caulier
Comment 31 Alex 2011-03-11 15:52:26 UTC
Yeah it should be removed. Went down a different path in order to improve the detection mechanism.


Alex

On 11 Mar 2011, at 14:49, Gilles Caulier wrote:

> https://bugs.kde.org/show_bug.cgi?id=267789
> 
> 
> 
> 
> 
> --- Comment #30 from Gilles Caulier <caulier gilles gmail com>  2011-03-11 15:49:33 ---
> Alex, this settings must be removed into digiKam face detection gui. Right ?
> 
> It's replaced by another one ?
> 
> Gilles Caulier
> 
> -- 
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

If we knew what we were doing, it wouldn't be called research, would it?
-- Albert Einstein
Comment 32 caulier.gilles 2011-03-11 17:19:48 UTC
Alex,

I removed Specificity settings from digiKam, and try again with libface 0.2.0.

digiKam crash like this :

digikam(15561)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation =>  8
- 16:56:13.499 libfaceINFO: Cascade directory located in : /usr/share/opencv/haarcascades
- 16:56:13.680 libfaceWARNING: Bad accuracy value
digikam(15561)/digikam (core) Digikam::DMetadata::getIccProfile: Exif color-space tag is AdobeRGB. Using default AdobeRGB ICC profile.
digikam(15561)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation =>  8
- 16:56:15.451 libfaceINFO: Cascade directory located in : /usr/share/opencv/haarcascades
- 16:56:15.628 libfaceWARNING: Bad accuracy value
digikam(15561)/digikam (core) Digikam::DMetadata::getIccProfile: Exif color-space tag is AdobeRGB. Using default AdobeRGB ICC profile.
digikam(15561)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation =>  8
digikam(15561)/digikam (core) Digikam::DetectionWorker::process: Found 1 faces in "_DSC0912.ARW" QSize(1080, 1616) QSize(3072, 4608)
- 16:56:17.585 libfaceINFO: Cascade directory located in : /usr/share/opencv/haarcascades
- 16:56:17.585 libfaceINFO: Config location: /home/gilles/.kde4/share/apps/libkface/database//libface-config.xml
- 16:56:17.585 libfaceINFO: libface config file exists. Will create new config.
OpenCV Error: Null pointer (The image has NULL data pointer) in cvGetMat, file /home/mandrake/rpm/BUILD/OpenCV-2.1.0/src/cxcore/cxarray.cpp, line 2391
KCrash: Application 'digikam' crashing...
sock_file=/home/gilles/.kde4/socket-localhost/kdeinit4__0
digikam: Fatal IO error: client killed
digikam(15561)/digikam (core) Digikam::DetectionWorker::process: Found 1 faces in "_DSC0913.ARW" QSize(1080, 1616) QSize(3072, 4608)

[1]+  Stopped                 digikam

Gilles Caulier
Comment 33 caulier.gilles 2011-03-11 17:21:20 UTC
Alex, 

I forget to said that Accuracy value is default 0.8. So it's fine normally for libface.

Note : i use libface from trunk. It certainly more recent than official 0.2 release...

Gilles Caulier
Comment 34 Alex 2011-03-11 17:26:54 UTC
Yeah I saw that there log there. It looks like for some reason it has found the config, and then went on to create a new one. Will check it out later on this evening.


Alex

On 11 Mar 2011, at 16:21, Gilles Caulier wrote:

> https://bugs.kde.org/show_bug.cgi?id=267789
> 
> 
> 
> 
> 
> --- Comment #33 from Gilles Caulier <caulier gilles gmail com>  2011-03-11 17:21:20 ---
> Alex, 
> 
> I forget to said that Accuracy value is default 0.8. So it's fine normally for
> libface.
> 
> Note : i use libface from trunk. It certainly more recent than official 0.2
> release...
> 
> Gilles Caulier
> 
> -- 
> 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
Comment 35 Matthias Welwarsky 2011-03-12 10:11:18 UTC
Digikam still doesn't compile?

/home/matze/Sources/digikam-software-compilation/extra/libkface/libkface/database.cpp: In member function ‘QList<KFaceIface::Face> KFaceIface::Database::detectFaces(const KFaceIface::Image&)’:
/home/matze/Sources/digikam-software-compilation/extra/libkface/libkface/database.cpp:184: error: no matching function for call to ‘libface::LibFace::detectFaces(const IplImage*&)’
/home/matze/Sources/digikam-software-compilation/extra/libkface/libface/LibFace.h:85: note: candidates are: std::vector<libface::Face, std::allocator<libface::Face> > libface::LibFace::detectFaces(const IplImage*, const CvSize&)
/home/matze/Sources/digikam-software-compilation/extra/libkface/libface/LibFace.h:100: note:                 std::vector<libface::Face, std::allocator<libface::Face> > libface::LibFace::detectFaces(const std::string&, int)
/home/matze/Sources/digikam-software-compilation/extra/libkface/libface/LibFace.h:101: note:                 std::vector<libface::Face, std::allocator<libface::Face> > libface::LibFace::detectFaces(const char*, int, int, int, int, int, int)
/home/matze/Sources/digikam-software-compilation/extra/libkface/libkface/database.cpp: In member function ‘QList<double> KFaceIface::Database::recognizeFaces(QList<KFaceIface::Face>&)’:
/home/matze/Sources/digikam-software-compilation/extra/libkface/libkface/database.cpp:272: error: no match for ‘operator=’ in ‘result = libface::LibFace::recognise(std::vector<libface::Face, std::allocator<libface::Face> >*, int)((& faceVec), 1)’
/usr/include/c++/4.4/bits/vector.tcc:156: note: candidates are: std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = std::pair<int, float>, _Alloc = std::allocator<std::pair<int, float> >]
Comment 36 Michael G. Hansen 2011-03-12 21:07:17 UTC
Git commit db7a9b586de971f756daf3addb494f2e6020f964 by Michael Georg Hansen.
Committed on 12/03/2011 at 21:06.
Pushed by mghansen into branch 'master'.

Fix building against newer libface version.

CCBUG: 267789

M  +7    -6    libkface/database.cpp     

http://commits.kde.org/libkface/db7a9b586de971f756daf3addb494f2e6020f964
Comment 37 kgw 2011-07-17 13:51:43 UTC
I'm still waiting for the face detection to become an optional component, it doesn't make sense for me or anybody I know so it has no place cluttering the interface!
Comment 38 caulier.gilles 2011-07-19 09:56:59 UTC
libkface and libkmap cannot be optional for 2.0.0.

My viewpoint is to not make it as optional for the future...

Marcel, Michael ? Fine for you ? 

Gilles Caulier
Comment 39 kgw 2011-07-19 10:12:02 UTC
(In reply to comment #38)
> libkface and libkmap cannot be optional for 2.0.0.
But a "cannot" is simply not true. 
I have made it optional (by removing it completely) in about 2 hours of my time on sunday. If you want the diff you can have it later this evening - simply add a config option to switch these things off and it's gone (like it should). 
As for the reason I did this: For one I can't get the face detection framework running (I tried for weeks but it will not compile in my environment on Linux) and for the other I don't care one iota for the excessive clutter it produces in the UI for something I have no use whatsoever for - have you ever clicked on the wrong button and the wretched thing starts scanning 100.000+ images for faces that don't exist - everything grinds to a halt...
Comment 40 caulier.gilles 2011-07-19 12:16:50 UTC
i will be more precise :
1- there is no plan to make' these depencies as optional. this will make  big puzzle i source code, and will take a while.
2- if you cannot build under your linux, check your system and ask to your distro team (or change for a better distro). 2.0.0 compilie fine here under mandriva. mageia, macosx, and win7. just check properlies depencies listed on README files.
3- 2.0.0 will be released in a few day. you can wait for a packaging solution.
4- we have work indeep on these features which are ask as top of whishes from users through kde bugzilla. this is ot to remove it as well because one user don't care or don't need.
5- if you start by error a face detection (which work perfectly here), just press cancel button it just too simple to understand...
6- and finally, if you want to ask something to an open source team, you must ask it properly, whitout to be nervous. ther is some respect against team to have
gilles caulier
Comment 41 kgw 2011-07-19 13:39:25 UTC
(In reply to comment #40)
> 1- there is no plan to make' these depencies as optional. this will make  big
> puzzle i source code, and will take a while.
It just changes about 10 files - if that's a big puzzle for you... You'd only need to make the interface conditional and take the face detection specific files out of the CMakeFile.txt, that's 3-4 includes and about as many interface .cpp - not a big deal as I said you could have the patch tonight, it barely took two hours to completely remove the dependency on the face detection framework altogether and that was without knowing which components needed to be touched - just letting the compiler complain about missing dependencies after removing the kface dependencies from the build system - so it's quite easy and not very time consuming making this component a compile time option - if the necessary dependencies are there compile it, if not then don't bother...
> 2- if you cannot build under your linux, check your system 
My systems are perfectly fine, they just need libraries that are in conflict with OpenCV (or one of it's dependencies) thus OpenCV can't be built and thus in the end digikam can't because of the dependency on this...
> 3- 2.0.0 will be released in a few day. you can wait for a packaging solution.
Even then the library dependency still won't get away, I'm on a gentoo source distribution and even if that were to work the interface still will be cluttered.
> 6- and finally, if you want to ask something to an open source team, you must
> ask it properly, whitout to be nervous.
I asked about it months ago - I just restated the question because nothing was happening but discussion about build issues which were basically off topic. Back then I told you that I managed to rip it out and thus I could have provided a patch and even today I could do a patch (which is only half as invasive as you make it sound)...
Comment 42 caulier.gilles 2011-07-19 17:12:11 UTC
marcel use gentoo too and he has no problem to compile digikam & co. so ask to him...
gilles caulier
Comment 43 Andreas K. Huettel 2011-07-19 18:21:13 UTC
(In reply to comment #41)
> > 2- if you cannot build under your linux, check your system 
> My systems are perfectly fine, they just need libraries that are in conflict
> with OpenCV (or one of it's dependencies) thus OpenCV can't be built and thus
> in the end digikam can't because of the dependency on this...

Could you please tell me what exactly the problem is? Even better, file a Gentoo bug (because Gentoo library interactions are not really on-topic here...)
Comment 44 kgw 2011-07-19 22:36:41 UTC
> Could you please tell me what exactly the problem is? Even better, file a
> Gentoo bug (because Gentoo library interactions are not really on-topic
> here...)
I can't compile some of the required libraries because of use flags I have set for other libraries to be able to get certain non-gentoo libraries to be usable that I need for my daily work! Since I don't care about face detection (in fact I despise the function and the implications it has regarding identity theft and web stalking with face detection creeping up all over the place) I'll simply continue to rip it out of digikam, it's only a few minutes once you know what to look for... 
It would have been nice to have the option out of the box to run digikam without face detection, especially as the change is well localized (15 cpp and include files in total plus small changes to the CMakeFile.txt) and not at all invasive.
Comment 45 Michael G. Hansen 2011-07-21 03:36:22 UTC
As for geolocation, I agree with Gilles' viewpoint about not making it optional. It was optional some time ago, but it was the hell to work with to make sure that after every change it would still compile with and without Marble. Also, the geotagging UI elements are only two tabs, which have always been there, and a new toolbar button, which you can easily hide. Separating the Marble dependency out of libkgeomap will again lead to lots of code duplication, which is to be avoided.

Michael
Comment 46 Christoph Feck 2011-07-23 11:31:40 UTC
Interestingly, this bug is mentioned (presumably as fixed) in the NEWS file (No 222). While you are at it, remove the trailing "r" from No 223.
Comment 47 kgw 2012-01-21 11:39:26 UTC
Created attachment 68068 [details]
Patch to remove any Face-Detection and Face-Tagging from digikam

I still despise this abhorrent function - and I can't understand why this still isn't optional for those that have no interest in feeding the big brother sites like Facebook or similar with even more tags to reduce our freedom. 
So I took an hour today to rip that junk from digikam in hope that it will help people that don't want to have this feature! If interested I could make all these changes dependent on a define to be evaluated during cmake but for the moment complete and utter removal (which was quite easy contrary to some developers claiming it was impossible) has to do.
Comment 48 caulier.gilles 2012-01-21 13:00:22 UTC
It's possible to make 2 patches : one for face detection, one for geolocation.

Thanks in advance

Gilles Caulier
Comment 49 kgw 2012-01-21 13:37:53 UTC
@#48 Should I take the change in status as signal to proceed in reworking my patch to make face detection a compile time optional component?
Comment 50 caulier.gilles 2012-01-21 13:55:56 UTC
i take a look in your patch.

Only libkface is managed. In fact not managed really, because you drop library check and code relevant.

This is not optional. You drop feature. It's not acceptable. Please revise your patch...

Gilles Caulier
Comment 51 kgw 2012-01-21 14:04:58 UTC
@#50, it was was a proof of concept patch as a developer once told me that making face detection was impossible to remove. Of course I will resubmit in due time if the patch has any chance of making it into the mainstream version, that's why I am asking if it makes sense to put in the work...
Comment 52 caulier.gilles 2012-01-21 14:08:43 UTC
yes. If patch make libkface purely optional, it will be accepted...

Thanks in advance

Gilles Caulier
Comment 53 kgw 2012-01-21 22:32:04 UTC
Created attachment 68077 [details]
Patch making libkface fully and properly optional.

Here is my revised patch. It builds properly without libkface, it's use now not only is a build time detected option, it can be disabled via a CMake option even if libkface should be available.
libkgeomap unfortunately is another matter as it encompasses a rather massive GUI adaptation (it embeds the location view) which I personally don't feel competent enough to remove.
Comment 54 caulier.gilles 2013-10-30 15:25:39 UTC
kgw,

Your patch cannot be applied against git/master :

[gilles@localhost core]$ patch -p1 < digikam-no-faces-proper.diff 
patching file CMakeLists.txt
Hunk #1 FAILED at 9.
Hunk #2 FAILED at 149.
Hunk #3 succeeded at 369 (offset 102 lines).
Hunk #4 succeeded at 432 with fuzz 2 (offset 134 lines).
Hunk #5 FAILED at 359.
Hunk #6 succeeded at 548 with fuzz 2 (offset 140 lines).
Hunk #7 succeeded at 619 with fuzz 2 (offset 155 lines).
Hunk #8 FAILED at 1158.
Hunk #9 FAILED at 1200.
Hunk #10 FAILED at 1398.
6 out of 10 hunks FAILED -- saving rejects to file CMakeLists.txt.rej
patching file digikam/album/albummanager.cpp
Hunk #3 succeeded at 198 (offset -1 lines).
Hunk #7 succeeded at 2331 (offset 32 lines).
Hunk #8 succeeded at 2505 (offset 38 lines).
Hunk #9 succeeded at 2827 (offset 39 lines).
Hunk #10 succeeded at 3000 (offset 43 lines).
Hunk #11 succeeded at 3040 (offset 43 lines).
patching file digikam/album/albummanager.h
Hunk #1 succeeded at 587 (offset -6 lines).
Hunk #2 succeeded at 595 (offset -6 lines).
Hunk #3 succeeded at 638 (offset -6 lines).
Hunk #4 succeeded at 653 (offset -6 lines).
patching file digikam/items/digikamimageview.cpp
Hunk #1 FAILED at 62.
Hunk #2 FAILED at 87.
Hunk #3 succeeded at 120 (offset 4 lines).
Hunk #4 succeeded at 132 (offset 4 lines).
Hunk #5 FAILED at 189.
Hunk #6 FAILED at 197.
Hunk #7 succeeded at 198 (offset -11 lines).
Hunk #8 succeeded at 228 (offset -8 lines).
Hunk #9 succeeded at 242 (offset -8 lines).
Hunk #10 succeeded at 306 (offset -6 lines).
4 out of 10 hunks FAILED -- saving rejects to file digikam/items/digikamimageview.cpp.rej
patching file digikam/items/digikamimageview.h
Hunk #1 succeeded at 79 (offset -8 lines).
patching file digikam/items/digikamimageview_p.cpp
patching file digikam/items/digikamimageview_p.h
patching file digikam/main/digikamapp.cpp
Hunk #1 FAILED at 95.
Hunk #2 FAILED at 120.
Hunk #3 FAILED at 144.
Hunk #4 FAILED at 3047.
Hunk #5 succeeded at 3055 with fuzz 2 (offset -1 lines).
Hunk #6 FAILED at 3067.
Hunk #7 FAILED at 3074.
6 out of 7 hunks FAILED -- saving rejects to file digikam/main/digikamapp.cpp.rej
patching file digikam/main/digikamapp.h
Hunk #1 succeeded at 59 (offset 2 lines).
Hunk #2 FAILED at 163.
Hunk #3 FAILED at 230.
2 out of 3 hunks FAILED -- saving rejects to file digikam/main/digikamapp.h.rej
patching file digikam/utils/componentsinfo.h
Hunk #1 FAILED at 38.
Hunk #2 FAILED at 74.
2 out of 2 hunks FAILED -- saving rejects to file digikam/utils/componentsinfo.h.rej
patching file digikam/views/imagepreviewview.cpp
Hunk #1 succeeded at 57 (offset -4 lines).
Hunk #2 FAILED at 74.
Hunk #3 FAILED at 84.
Hunk #4 succeeded at 102 (offset -5 lines).
Hunk #5 succeeded at 129 (offset -5 lines).
Hunk #6 FAILED at 159.
Hunk #7 succeeded at 176 with fuzz 1 (offset -3 lines).
Hunk #8 succeeded at 195 (offset -3 lines).
Hunk #9 succeeded at 224 (offset -3 lines).
Hunk #10 succeeded at 242 (offset -3 lines).
Hunk #11 succeeded at 262 (offset -3 lines).
Hunk #12 succeeded at 271 (offset -3 lines).
Hunk #13 FAILED at 313.
Hunk #14 succeeded at 323 (offset 2 lines).
Hunk #15 succeeded at 365 (offset 2 lines).
Hunk #16 succeeded at 430 with fuzz 1 (offset 14 lines).
4 out of 16 hunks FAILED -- saving rejects to file digikam/views/imagepreviewview.cpp.rej
patching file libs/database/imagescanner.cpp
Hunk #1 succeeded at 43 (offset 1 line).
Hunk #2 FAILED at 260.
Hunk #3 succeeded at 459 with fuzz 1 (offset 181 lines).
Hunk #4 succeeded at 856 with fuzz 1 (offset 272 lines).
Hunk #5 succeeded at 906 with fuzz 1 (offset 284 lines).
1 out of 5 hunks FAILED -- saving rejects to file libs/database/imagescanner.cpp.rej
patching file libs/database/imagescanner.h
Hunk #1 FAILED at 226.
1 out of 1 hunk FAILED -- saving rejects to file libs/database/imagescanner.h.rej
patching file libs/imageproperties/imagedescedittab.cpp
Hunk #1 FAILED at 442.
1 out of 1 hunk FAILED -- saving rejects to file libs/imageproperties/imagedescedittab.cpp.rej
patching file libs/models/albummodel.cpp
patching file libs/models/imagealbummodel.cpp
Hunk #1 succeeded at 37 with fuzz 2.
Hunk #2 succeeded at 374 (offset 30 lines).

Please update it if you want to see Face management become optional for next 4.0.0 release.

Best

Gilles Caulier
Comment 55 caulier.gilles 2013-11-27 13:09:48 UTC
kgw,

Do you see my previous message ?

Gilles Caulier
Comment 56 caulier.gilles 2014-07-11 08:09:31 UTC
we wait a revised patch again current git/master, please

Gilles Caulier
Comment 57 caulier.gilles 2014-10-30 13:20:45 UTC
Git commit fc482423786988f05ef28243a400a1097f8f3536 by Gilles Caulier.
Committed on 30/10/2014 at 13:19.
Pushed by cgilles into branch 'master'.

Make as libkface optional dependency for digiKam

M  +56   -24   CMakeLists.txt
M  +12   -2    app/CMakeLists.txt
M  +1    -1    app/items/digikamimagefacedelegate.cpp
M  +31   -3    app/items/digikamimageview.cpp
M  +8    -1    app/items/digikamimageview_p.h
M  +8    -1    app/utils/componentsinfo.h
M  +11   -0    app/views/digikamview.cpp
M  +58   -8    app/views/imagepreviewview.cpp
M  +23   -1    app/views/imagepreviewviewitem.cpp
M  +5    -0    app/views/imagepreviewviewitem.h
M  +4    -0    app/views/leftsidebarwidgets.cpp
M  +5    -0    app/views/leftsidebarwidgets.h
M  +35   -4    utilities/maintenance/maintenancedlg.cpp
M  +19   -3    utilities/maintenance/maintenancemngr.cpp

http://commits.kde.org/digikam/fc482423786988f05ef28243a400a1097f8f3536
Comment 58 caulier.gilles 2014-10-31 11:33:56 UTC
Git commit 2e283f2a96e6a48cd70fd2f9dde7e9bf33e2a071 by Gilles Caulier.
Committed on 31/10/2014 at 11:32.
Pushed by cgilles into branch 'master'.

make libkgeomap as optional dependency to support Geolocation Maps
FIXED-IN: 4.5.0

M  +52   -22   CMakeLists.txt
M  +3    -1    NEWS
M  +18   -6    app/CMakeLists.txt
M  +5    -0    app/main/digikamapp.cpp
M  +4    -0    app/main/digikamapp_p.h
M  +4    -1    app/utils/config-digikam.h.cmake.in
M  +31   -4    app/views/digikamview.cpp
M  +4    -0    app/views/leftsidebarwidgets.cpp
M  +8    -1    app/views/leftsidebarwidgets.h
M  +1    -1    app/views/mapwidgetview.h
M  +40   -21   app/views/stackedview.cpp
M  +15   -9    app/views/stackedview.h
M  +0    -1    app/views/tableview/tableview.cpp
M  +15   -11   app/views/tableview/tableview_treeview_delegate.cpp
M  +9    -3    libs/dialogs/libsinfodlg.cpp
M  +20   -4    libs/imageproperties/imagepropertiessidebar.cpp
M  +9    -2    libs/imageproperties/imagepropertiessidebar.h
M  +29   -9    libs/imageproperties/imagepropertiessidebarcamgui.cpp
M  +25   -5    libs/imageproperties/imagepropertiessidebardb.cpp
M  +4    -1    libs/kgeomaphelper/digikam2kgeomap_database.h
M  +4    -0    showfoto/CMakeLists.txt
M  +4    -0    utilities/importui/main/importui.cpp
M  +5    -0    utilities/importui/main/importui_p.h
M  +19   -3    utilities/importui/views/importstackedview.cpp
M  +8    -1    utilities/importui/views/importstackedview.h
M  +17   -0    utilities/importui/views/importview.cpp

http://commits.kde.org/digikam/2e283f2a96e6a48cd70fd2f9dde7e9bf33e2a071
Comment 59 caulier.gilles 2017-07-25 19:44:50 UTC
Both libkgeomap and libkface support have been dropped with digiKam 5.x. This problem will never appear...