deleteIdentity

[Tobias Leupold]

Hi list!

With the addition of the deleteIdentity function to libkface's API, I think we
also have to bump the library version, so that one can check if it's there or
not.

I'm not sure about which string to update ... cmake looks for the version
defined by KFACE_LIB_*_VERSION, so can we just change
       
        SET(KFACE_LIB_PATCH_VERSION "0")

to

        SET(KFACE_LIB_PATCH_VERSION "1")

(and add the respective comment about what changed above)?

Yours, Tobias
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

You has right. but :

MINOR VERSION must be patched instead PATCH VERSION. API introduce a new method.

Also bin lib fingerprint will be different. Please patch too SO REV.

Gilles

2014-07-08 11:46 GMT+02:00 Tobias Leupold <[hidden email]>:

> Hi list!
>
> With the addition of the deleteIdentity function to libkface's API, I think we
> also have to bump the library version, so that one can check if it's there or
> not.
>
> I'm not sure about which string to update ... cmake looks for the version
> defined by KFACE_LIB_*_VERSION, so can we just change
>
>         SET(KFACE_LIB_PATCH_VERSION "0")
>
> to
>
>         SET(KFACE_LIB_PATCH_VERSION "1")
>
> (and add the respective comment about what changed above)?
>
> Yours, Tobias
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Tobias Leupold]

> MINOR VERSION must be patched instead PATCH VERSION.
> Please patch too SO REV.
Okay! Is this all right:
        https://github.com/l3u/libkface/compare/version_bump
? If so, I can push it if you want.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

perfect. Let's go

Gilles

2014-07-08 13:21 GMT+02:00 Tobias Leupold <[hidden email]>:
>> MINOR VERSION must be patched instead PATCH VERSION.
>> Please patch too SO REV.
> Okay! Is this all right:
>         https://github.com/l3u/libkface/compare/version_bump
> ? If so, I can push it if you want.
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

I identified a huge memory leak into Qt Sqlite plugin when face
database is used to train face. I not 100% sure that it's fully
relevant of Qt implementation (or libsqlite).

But in case of you view this type of dysfonction with KPhotoAlbum, the
file from bugzilla is here :

https://bugs.kde.org/show_bug.cgi?id=323888

I will write a small test program into libkface to reproduce easily
the problem in goal to hack with Qt team...

Note : under digiKam memory leak is really huge. In fact for each
query in DB, memory leaked is cumulated until end. Of course this
depend of image collection size, but in my case with more than 250.000
files to parse, digiKam mangle around 4Gb of ram (free at end of
digiKam instance)

Gilles

2014-07-08 13:41 GMT+02:00 Gilles Caulier <[hidden email]>:

> perfect. Let's go
>
> Gilles
>
> 2014-07-08 13:21 GMT+02:00 Tobias Leupold <[hidden email]>:
>>> MINOR VERSION must be patched instead PATCH VERSION.
>>> Please patch too SO REV.
>> Okay! Is this all right:
>>         https://github.com/l3u/libkface/compare/version_bump
>> ? If so, I can push it if you want.
>> _______________________________________________
>> Digikam-devel mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> You has right. but :
>
> MINOR VERSION must be patched instead PATCH VERSION. API introduce a new
> method.
>
> Also bin lib fingerprint will be different. Please patch too SO REV.

Adding a non-virtual member function will not break BC if I am not mistaken?

https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++

So SO REV can be kept at 2.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Tobias Leupold]

> So SO REV can be kept at 2.

I just reverted SO REV to 2.0.0.

Tobias
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Marcel,

About this memory leak problem due to sqlite, I have a doubt about a
dysfunction into Qtsqlite plugin or libsqlite, as i explained before.

I written 2 small test CLI programs. One to check libkface DB, one to
check digiKam DB :

https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/tests/traindb.cpp

This one create a local training DB, record 100 dumy items, verify
items registration, and call recognition. By this way, i'm able to
quickly check with valgrind if memory is lost in libkface database
management code. And good news, excepted a little memory in Qt, all is
fine here :

$ valgrind --tool=memcheck --leak-check=full --error-limit=no ./traindb
...
==26782== 476 (96 direct, 380 indirect) bytes in 1 blocks are
definitely lost in loss record 329 of 352
==26782==    at 0x4C26BF5: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26782==    by 0x56F6FA2: ??? (in /usr/lib64/libQtCore.so.4.8.6)
==26782==    by 0x56F1567: QFactoryLoader::updateDir(QString const&,
QSettings&) (in /usr/lib64/libQtCore.so.4.8.6)
==26782==    by 0x56F34C6: QFactoryLoader::update() (in
/usr/lib64/libQtCore.so.4.8.6)
==26782==    by 0x56F36E9: QFactoryLoader::QFactoryLoader(char const*,
QString const&, Qt::CaseSensitivity) (in
/usr/lib64/libQtCore.so.4.8.6)
==26782==    by 0x8044844: ??? (in /usr/lib64/libQtSql.so.4.8.6)
==26782==    by 0x804551F: QSqlDatabase::drivers() (in
/usr/lib64/libQtSql.so.4.8.6)
==26782==    by 0x4E812B8:
KFaceIface::DatabaseAccess::checkReadyForUse(KFaceIface::DatabaseAccessData*,
KFaceIface::InitializationObserver*) (databaseaccess.cpp:201)
==26782==    by 0x4E583C0:
KFaceIface::RecognitionDatabase::Private::Private(QString const&)
(recognitiondatabase.cpp:215)
==26782==    by 0x4E5814F:
KFaceIface::RecognitionDatabaseStaticPriv::database(QString const&)
(recognitiondatabase.cpp:192)
==26782==    by 0x4E588DE:
KFaceIface::RecognitionDatabase::addDatabase(QString const&)
(recognitiondatabase.cpp:276)
==26782==    by 0x4022D7: main (traindb.cpp:80)
==26782==
==26782== LEAK SUMMARY:
==26782==    definitely lost: 288 bytes in 3 blocks
==26782==    indirectly lost: 664 bytes in 9 blocks
==26782==      possibly lost: 4,676 bytes in 83 blocks
==26782==    still reachable: 66,677 bytes in 502 blocks
==26782==         suppressed: 0 bytes in 0 blocks
==26782== Reachable blocks (those to which a pointer was found) are not shown.
==26782== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==26782==
==26782== For counts of detected and suppressed errors, rerun with: -v
==26782== ERROR SUMMARY: 86 errors from 86 contexts (suppressed: 2 from 2)


https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/tests/testdatabase.cpp

With this one, it's different. It initialize digiKam database and
start ScanController, and... that all. Here memory leak is really huge
as you can see :

$ valgrind --tool=memcheck --leak-check=full --error-limit=no ./testdatabase
...
==26925==
==26925== 2,560 bytes in 2 blocks are possibly lost in loss record
2,031 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE5DCA: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE6021: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE08E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B50C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0D701: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0D779: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0F76A: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 2,560 bytes in 2 blocks are possibly lost in loss record
2,032 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE5DCA: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE6021: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE08E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B50C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE16DE7: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE391A8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE3F55E: sqlite3_step (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 2,600 bytes in 159 blocks are possibly lost in loss record
2,034 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3450: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3968: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE39B0: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE3021A: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34459: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34A81: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34D64: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34DF4: sqlite3_prepare (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 3,160 bytes in 159 blocks are possibly lost in loss record
2,042 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3450: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3968: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE39B0: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE3028B: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34459: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34A81: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34D64: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34DF4: sqlite3_prepare (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 3,488 bytes in 4 blocks are possibly lost in loss record
2,043 of 2,078
==26925==    at 0x4C2863A: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF938: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE41C3: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDF4899: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE31C06: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34459: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34A81: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34D64: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34DF4: sqlite3_prepare (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34EAE: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE35258: sqlite3_exec (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE433DF: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 3,968 bytes in 31 blocks are possibly lost in loss record
2,049 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3450: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE34CC: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE437EC: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE30433: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34459: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34A81: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34D64: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34DF4: sqlite3_prepare (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 4,112 bytes in 2 blocks are possibly lost in loss record
2,052 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE333C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE60FE: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE08E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B50C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE16DE7: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE43226: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE43580: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 4,112 bytes in 2 blocks are possibly lost in loss record
2,053 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE333C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE60FE: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE08E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B50C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE16DE7: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE391A8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE3F55E: sqlite3_step (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 4,309 bytes in 1 blocks are possibly lost in loss record
2,055 of 2,078
==26925==    at 0x4C2863A: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x163E577E: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163E5865: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163E59AA: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163D8A86: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163E097F: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163E0AB2: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163E13ED: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163E1A85: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163E085E: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163CAE03: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==    by 0x163CB893: ??? (in /usr/lib64/libdbus-1.so.3.7.6)
==26925==
==26925== 4,888 bytes in 24 blocks are possibly lost in loss record
2,057 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3450: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDF06DB: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE2EEA3: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34459: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34A81: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34D64: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34DF4: sqlite3_prepare (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34EAE: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 5,120 bytes in 4 blocks are possibly lost in loss record
2,058 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE5DCA: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE6021: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE08E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B50C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0D701: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0D9EE: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0F0E4: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 8,624 bytes in 22 blocks are possibly lost in loss record
2,068 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3450: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE31C06: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34459: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34A81: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34D64: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34DF4: sqlite3_prepare (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE34EAE: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE35258: sqlite3_exec (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 9,564 (1,920 direct, 7,644 indirect) bytes in 20 blocks are
definitely lost in loss record 2,071 of 2,078
==26925==    at 0x4C26BF5: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x5C39FA2: ??? (in /usr/lib64/libQtCore.so.4.8.6)
==26925==    by 0x5C34567: QFactoryLoader::updateDir(QString const&,
QSettings&) (in /usr/lib64/libQtCore.so.4.8.6)
==26925==    by 0x5C364C6: QFactoryLoader::update() (in
/usr/lib64/libQtCore.so.4.8.6)
==26925==    by 0x5C366E9: QFactoryLoader::QFactoryLoader(char const*,
QString const&, Qt::CaseSensitivity) (in
/usr/lib64/libQtCore.so.4.8.6)
==26925==    by 0x6456754: ??? (in /usr/lib64/libQtGui.so.4.8.6)
==26925==    by 0x6456BBF: ??? (in /usr/lib64/libQtGui.so.4.8.6)
==26925==    by 0x6458891: ??? (in /usr/lib64/libQtGui.so.4.8.6)
==26925==    by 0x6459DE7: QImageReader::read(QImage*) (in
/usr/lib64/libQtGui.so.4.8.6)
==26925==    by 0x6459FB3: QImageReader::read() (in
/usr/lib64/libQtGui.so.4.8.6)
==26925==    by 0x644E5D8: operator>>(QDataStream&, QImage&) (in
/usr/lib64/libQtGui.so.4.8.6)
==26925==    by 0x64676D8: operator>>(QDataStream&, QPixmap&) (in
/usr/lib64/libQtGui.so.4.8.6)
==26925==
==26925== 20,480 bytes in 16 blocks are possibly lost in loss record
2,073 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE5DCA: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE6021: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE08E8: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B255: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0B50C: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0D701: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0D779: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE0D867: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==
==26925== 64,008 bytes in 1 blocks are possibly lost in loss record
2,076 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE9AE1: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE5D2A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x2BA5A81E: ??? (in
/usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so)
==26925==    by 0x6E8CD60: QSqlDatabase::open() (in
/usr/lib64/libQtSql.so.4.8.6)
==26925==    by 0x5173AE6:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&)
(databasecorebackend.cpp:214)
==26925==    by 0x51733D0:
Digikam::DatabaseCoreBackendPrivate::databaseForThread()
(databasecorebackend.cpp:120)
==26925==    by 0x51768B3:
Digikam::DatabaseCoreBackend::open(Digikam::DatabaseParameters const&)
(databasecorebackend.cpp:769)
==26925==    by 0x572FBD1:
Digikam::DatabaseAccess::checkReadyForUse(Digikam::InitializationObserver*)
(databaseaccess.cpp:286)
==26925==
==26925== 64,008 bytes in 1 blocks are possibly lost in loss record
2,077 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE9AE1: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE5D2A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x2BA5A81E: ??? (in
/usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so)
==26925==    by 0x6E8CD60: QSqlDatabase::open() (in
/usr/lib64/libQtSql.so.4.8.6)
==26925==    by 0x5173AE6:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&)
(databasecorebackend.cpp:214)
==26925==    by 0x51733D0:
Digikam::DatabaseCoreBackendPrivate::databaseForThread()
(databasecorebackend.cpp:120)
==26925==    by 0x51793ED: Digikam::DatabaseCoreBackend::getQuery()
(databasecorebackend.cpp:1512)
==26925==    by 0x5179022:
Digikam::DatabaseCoreBackend::prepareQuery(QString const&)
(databasecorebackend.cpp:1467)
==26925==
==26925== 64,008 bytes in 1 blocks are possibly lost in loss record
2,078 of 2,078
==26925==    at 0x4C266ED: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26925==    by 0x1DDFF9A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDDB189: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE3317: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DDE9AE1: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x1DE5D2A6: ??? (in /usr/lib64/libsqlite3.so.0.8.6)
==26925==    by 0x2BA5A81E: ??? (in
/usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so)
==26925==    by 0x6E8CD60: QSqlDatabase::open() (in
/usr/lib64/libQtSql.so.4.8.6)
==26925==    by 0x5173AE6:
Digikam::DatabaseCoreBackendPrivate::open(QSqlDatabase&)
(databasecorebackend.cpp:214)
==26925==    by 0x51733D0:
Digikam::DatabaseCoreBackendPrivate::databaseForThread()
(databasecorebackend.cpp:120)
==26925==    by 0x51768B3:
Digikam::DatabaseCoreBackend::open(Digikam::DatabaseParameters const&)
(databasecorebackend.cpp:769)
==26925==    by 0x5181768:
Digikam::ThumbnailDatabaseAccess::checkReadyForUse(Digikam::InitializationObserver*)
(thumbnaildatabaseaccess.cpp:216)
==26925==
==26925== LEAK SUMMARY:
==26925==    definitely lost: 8,000 bytes in 690 blocks
==26925==    indirectly lost: 9,358 bytes in 81 blocks
==26925==      possibly lost: 322,123 bytes in 1,055 blocks
==26925==    still reachable: 337,337 bytes in 4,706 blocks
==26925==         suppressed: 0 bytes in 0 blocks
==26925== Reachable blocks (those to which a pointer was found) are not shown.
==26925== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==26925==
==26925== For counts of detected and suppressed errors, rerun with: -v
==26925== ERROR SUMMARY: 954 errors from 954 contexts (suppressed: 2 from 2)

...And i cut the Valgrind trace here...

I suspect something wrong in Digikam::DatabaseAccess that we don't
have with KFace::DatabaseAccess. Code is similar but no exactly the
same (i drop from here the DB schema about this problem).

What do you think about ?

Gilles

2014-07-08 13:47 GMT+02:00 Gilles Caulier <[hidden email]>:

> I identified a huge memory leak into Qt Sqlite plugin when face
> database is used to train face. I not 100% sure that it's fully
> relevant of Qt implementation (or libsqlite).
>
> But in case of you view this type of dysfonction with KPhotoAlbum, the
> file from bugzilla is here :
>
> https://bugs.kde.org/show_bug.cgi?id=323888
>
> I will write a small test program into libkface to reproduce easily
> the problem in goal to hack with Qt team...
>
> Note : under digiKam memory leak is really huge. In fact for each
> query in DB, memory leaked is cumulated until end. Of course this
> depend of image collection size, but in my case with more than 250.000
> files to parse, digiKam mangle around 4Gb of ram (free at end of
> digiKam instance)
>
> Gilles
>
> 2014-07-08 13:41 GMT+02:00 Gilles Caulier <[hidden email]>:
>> perfect. Let's go
>>
>> Gilles
>>
>> 2014-07-08 13:21 GMT+02:00 Tobias Leupold <[hidden email]>:
>>>> MINOR VERSION must be patched instead PATCH VERSION.
>>>> Please patch too SO REV.
>>> Okay! Is this all right:
>>>         https://github.com/l3u/libkface/compare/version_bump
>>> ? If so, I can push it if you want.
>>> _______________________________________________
>>> Digikam-devel mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

> I suspect something wrong in Digikam::DatabaseAccess that we don't
> have with KFace::DatabaseAccess. Code is similar but no exactly the
> same (i drop from here the DB schema about this problem).

Marcel,

I want mean in databasecorebackend.cpp instead databaseaccess.cpp

For ex, why we have this kind of difference here :

https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/database/databasecorebackend.cpp#L238

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/database/core/databasecorebackend.cpp#L216

In digiKam, we don't have this line

db.exec("PRAGMA synchronous=1;");

Why ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Marcel,

About bugzilla file https://bugs.kde.org/show_bug.cgi?id=323888, i
concluded to an upstream dysfunction from libsqlite.

Tobias,

I moved DESIGN file content to libkface Doxygen API documentation.
Don't hesitate to review/fix/improve it :

https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/show/libkface/Mainpage.dox

Gilles

2014-07-10 20:16 GMT+02:00 Marcel Wiesweg <[hidden email]>:

>
>> > I suspect something wrong in Digikam::DatabaseAccess that we don't
>> > have with KFace::DatabaseAccess. Code is similar but no exactly the
>> > same (i drop from here the DB schema about this problem).
>>
>> Marcel,
>>
>> I want mean in databasecorebackend.cpp instead databaseaccess.cpp
>>
>> For ex, why we have this kind of difference here :
>
>
> libkface's database code was taken from digikam, and then modified to get rid
> of the "one global database lock per application" which did not apply for
> libkface. (in the long run, I would like to get rid of this in digikam as
> well, but there are some assumption made that depend on this global lock)
>
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Marcel,

I just analyzed recognition.db file with sqlitebrowser and add small
tables description in libkface Mainpage.dox :

https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/Mainpage.dox

Please review. there are 2 tables where i don't know exactly the role
: OpenCVLBPHRecognizer and OpenTLDData

Can you give me somme comments about please ?

Gilles

2014-07-11 14:58 GMT+02:00 Gilles Caulier <[hidden email]>:

> Marcel,
>
> About bugzilla file https://bugs.kde.org/show_bug.cgi?id=323888, i
> concluded to an upstream dysfunction from libsqlite.
>
> Tobias,
>
> I moved DESIGN file content to libkface Doxygen API documentation.
> Don't hesitate to review/fix/improve it :
>
> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/show/libkface/Mainpage.dox
>
> Gilles
>
> 2014-07-10 20:16 GMT+02:00 Marcel Wiesweg <[hidden email]>:
>>
>>> > I suspect something wrong in Digikam::DatabaseAccess that we don't
>>> > have with KFace::DatabaseAccess. Code is similar but no exactly the
>>> > same (i drop from here the DB schema about this problem).
>>>
>>> Marcel,
>>>
>>> I want mean in databasecorebackend.cpp instead databaseaccess.cpp
>>>
>>> For ex, why we have this kind of difference here :
>>
>>
>> libkface's database code was taken from digikam, and then modified to get rid
>> of the "one global database lock per application" which did not apply for
>> libkface. (in the long run, I would like to get rid of this in digikam as
>> well, but there are some assumption made that depend on this global lock)
>>
>>
>> _______________________________________________
>> Digikam-devel mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Tobias Leupold]

> I moved DESIGN file content to libkface Doxygen API documentation.
> Don't hesitate to review/fix/improve it :

I'll have a look at that. One problem I noticed is that, no matter which
browser I use when I point to
https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/Mainpage.dox 
the file is downloaded instead of shown in a parsed way. Is it somehow
possible to make people see the parsed HTML? As this URL would then be nice to
be provided as a "home page" for the library.

Tobias
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

yes, it's already only on KDE server as HTML. contains in updated each
days, 0h00 UTC time :

http://api.kde.org/extragear-api/libs-apidocs/libkface/libkface/html/index.html

Gilles

2014-07-12 12:40 GMT+02:00 Tobias Leupold <[hidden email]>:

>> I moved DESIGN file content to libkface Doxygen API documentation.
>> Don't hesitate to review/fix/improve it :
>
> I'll have a look at that. One problem I noticed is that, no matter which
> browser I use when I point to
> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/Mainpage.dox
> the file is downloaded instead of shown in a parsed way. Is it somehow
> possible to make people see the parsed HTML? As this URL would then be nice to
> be provided as a "home page" for the library.
>
> Tobias
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Tobias Leupold]

> yes, it's already only on KDE server as HTML. contains in updated each
> days, 0h00 UTC time :
>
> http://api.kde.org/extragear-api/libs-apidocs/libkface/libkface/html/index.h
> tml

That's what we need. Fine :-) I just pushed some refinements and changes to
the file. I'm not a native English speaker either, but I think I could fix
some typos and other minor errors.

Anyway, that file is very fine. Quite some information to read at the start
when having a look at the library :-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2014-07-12 13:05 GMT+02:00 Tobias Leupold <[hidden email]>:
>> yes, it's already only on KDE server as HTML. contains in updated each
>> days, 0h00 UTC time :
>>
>> http://api.kde.org/extragear-api/libs-apidocs/libkface/libkface/html/index.h
>> tml
>
> That's what we need. Fine :-) I just pushed some refinements and changes to
> the file. I'm not a native English speaker either, but I think I could fix
> some typos and other minor errors.

me, too, i'm French... Thanks to patch contents.


>
> Anyway, that file is very fine. Quite some information to read at the start
> when having a look at the library :-)

Perhaps you can add KPhotoAlbum from list of Client Applications in
this document, if your implementation is accepted...

Gilles

> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

Am Samstag, 12. Juli 2014, 12:25:05 schrieb Gilles Caulier:

> Marcel,
>
> I just analyzed recognition.db file with sqlitebrowser and add small
> tables description in libkface Mainpage.dox :
>
> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisio
> ns/master/entry/libkface/Mainpage.dox
>
> Please review. there are 2 tables where i don't know exactly the role
>
> : OpenCVLBPHRecognizer and

This table currently will have only one entry, there is only one recognizer.
But the db in theory supports to have multiple recognizers, possibly with
different settings. Or with training data from different sources, or different
subsets of training data.

> OpenTLDData

-> was used by the TLD algorithm which was removed, because it never worked
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2014-07-13 14:21 GMT+02:00 Marcel Wiesweg <[hidden email]>:

> Am Samstag, 12. Juli 2014, 12:25:05 schrieb Gilles Caulier:
>> Marcel,
>>
>> I just analyzed recognition.db file with sqlitebrowser and add small
>> tables description in libkface Mainpage.dox :
>>
>> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisio
>> ns/master/entry/libkface/Mainpage.dox
>>
>> Please review. there are 2 tables where i don't know exactly the role
>>
>> : OpenCVLBPHRecognizer and
>
> This table currently will have only one entry, there is only one recognizer.
> But the db in theory supports to have multiple recognizers, possibly with
> different settings. Or with training data from different sources, or different
> subsets of training data.
>
>> OpenTLDData
>
> -> was used by the TLD algorithm which was removed, because it never worked

I work with traindb test program, which create a fresh recognition.db
file, where i can see this table.

As this entry is obsolete, why it's still created yet ? Can remove it ?

Gilles

> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Marcel,

look in source code. OpenTLDData creation queries still present :

https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/database/schemaupdater.cpp#L240

https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/database/schemaupdater.cpp#L247

https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/database/schemaupdater.cpp#L253

https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/database/dbconfig.xml#L67

Does these code can be removed with schema ID updated ?

Gilles

2014-07-13 22:18 GMT+02:00 Gilles Caulier <[hidden email]>:

> 2014-07-13 14:21 GMT+02:00 Marcel Wiesweg <[hidden email]>:
>> Am Samstag, 12. Juli 2014, 12:25:05 schrieb Gilles Caulier:
>>> Marcel,
>>>
>>> I just analyzed recognition.db file with sqlitebrowser and add small
>>> tables description in libkface Mainpage.dox :
>>>
>>> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisio
>>> ns/master/entry/libkface/Mainpage.dox
>>>
>>> Please review. there are 2 tables where i don't know exactly the role
>>>
>>> : OpenCVLBPHRecognizer and
>>
>> This table currently will have only one entry, there is only one recognizer.
>> But the db in theory supports to have multiple recognizers, possibly with
>> different settings. Or with training data from different sources, or different
>> subsets of training data.
>>
>>> OpenTLDData
>>
>> -> was used by the TLD algorithm which was removed, because it never worked
>
> I work with traindb test program, which create a fresh recognition.db
> file, where i can see this table.
>
> As this entry is obsolete, why it's still created yet ? Can remove it ?
>
> Gilles
>
>> _______________________________________________
>> Digikam-devel mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Marcel,

A patch attached below remove TLD data table from recognition
database. I incremented DB revision in XML config file...

It's fine for you ?

Gilles



2014-07-14 10:02 GMT+02:00 Gilles Caulier <[hidden email]>:

> Marcel,
>
> look in source code. OpenTLDData creation queries still present :
>
> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/database/schemaupdater.cpp#L240
>
> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/database/schemaupdater.cpp#L247
>
> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/database/schemaupdater.cpp#L253
>
> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/master/entry/libkface/database/dbconfig.xml#L67
>
> Does these code can be removed with schema ID updated ?
>
> Gilles
>
> 2014-07-13 22:18 GMT+02:00 Gilles Caulier <[hidden email]>:
>> 2014-07-13 14:21 GMT+02:00 Marcel Wiesweg <[hidden email]>:
>>> Am Samstag, 12. Juli 2014, 12:25:05 schrieb Gilles Caulier:
>>>> Marcel,
>>>>
>>>> I just analyzed recognition.db file with sqlitebrowser and add small
>>>> tables description in libkface Mainpage.dox :
>>>>
>>>> https://projects.kde.org/projects/extragear/libs/libkface/repository/revisio
>>>> ns/master/entry/libkface/Mainpage.dox
>>>>
>>>> Please review. there are 2 tables where i don't know exactly the role
>>>>
>>>> : OpenCVLBPHRecognizer and
>>>
>>> This table currently will have only one entry, there is only one recognizer.
>>> But the db in theory supports to have multiple recognizers, possibly with
>>> different settings. Or with training data from different sources, or different
>>> subsets of training data.
>>>
>>>> OpenTLDData
>>>
>>> -> was used by the TLD algorithm which was removed, because it never worked
>>
>> I work with traindb test program, which create a fresh recognition.db
>> file, where i can see this table.
>>
>> As this entry is obsolete, why it's still created yet ? Can remove it ?
>>
>> Gilles
>>
>>> _______________________________________________
>>> Digikam-devel mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Marcel,
>
> A patch attached below remove TLD data table from recognition
> database. I incremented DB revision in XML config file...
>
> It's fine for you ?

Please also increment the number returned by SchemaUpdater::schemaVersion() to
2. The currentRequiredVersion can remain at 1.
Then, I think it's fine. For some reason, the necessary dummy updater methods
(updateV1ToV2) are already present.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel