Bug 267789

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.

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

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 ;)

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.

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.

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

Alex, Can you comment my previous post please ?

Gilles Caulier

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

Alex,

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

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

Gilles Caulier

Micheal,

Your comment about optional libkmap dependency ?

Gilles Caulier

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

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

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.

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

> 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.

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

Alex,

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

Gilles Caulier

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

*** Bug 268191 has been marked as a duplicate of this bug. ***

Alex,

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

Gilles Caulier

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)?

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

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

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

Your commit appear now :

https://projects.kde.org/projects/kdereview/libkface/repository/revisions/9556c39885eb1d0a594f200b04ed7dbc8e81bf35

Gilles Caulier

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

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

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

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

Alex, this settings must be removed into digiKam face detection gui. Right ?

It's replaced by another one ?

Gilles Caulier

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

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

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

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

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> >]

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

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!

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

(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...

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

(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)...

marcel use gentoo too and he has no problem to compile digikam & co. so ask to him...
gilles caulier

(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...)

> 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.

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

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.

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.

It's possible to make 2 patches : one for face detection, one for geolocation.

Thanks in advance

Gilles Caulier

@#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?

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

@#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...

yes. If patch make libkface purely optional, it will be accepted...

Thanks in advance

Gilles Caulier

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.

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

kgw,

Do you see my previous message ?

Gilles Caulier

we wait a revised patch again current git/master, please

Gilles Caulier

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

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

Both libkgeomap and libkface support have been dropped with digiKam 5.x. This problem will never appear...