KPhotoAlbum is using libkface now

[Tobias Leupold]

Hi list :-)

Yesterday, I committed my face detection/recognition code to git master of
KPhotoAlbum. So I think we're the very first non-Digikam project to use
libkface.

Thanks again for all the help, I hope we'll continue to have a productive
cooperation :-)

Here's a screencast showing the current state of the code, in case somebody is
interested in it: https://www.youtube.com/watch?v=GDvbByjaU9U

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

[Gilles Caulier-4]

Congratulation Tobias.

I hope to continue to improve libkface in the future to share the
experience between both project.

Please read my mail of few day ago about the reunion in Berlin. You is
welcome to register you to the event.

https://sprints.kde.org/sprint/248

Best

Gilles Caulier

2014-09-16 20:42 GMT+02:00 Tobias Leupold <[hidden email]>:

> Hi list :-)
>
> Yesterday, I committed my face detection/recognition code to git master of
> KPhotoAlbum. So I think we're the very first non-Digikam project to use
> libkface.
>
> Thanks again for all the help, I hope we'll continue to have a productive
> cooperation :-)
>
> Here's a screencast showing the current state of the code, in case somebody is
> interested in it: https://www.youtube.com/watch?v=GDvbByjaU9U
>
> 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]

> I hope to continue to improve libkface in the future to share the
> experience between both project.
I hope so :-)

> Please read my mail of few day ago about the reunion in Berlin. You is
> welcome to register you to the event.
I'll have to check if can can come ... can't tell yet ...

But apart from this:

Have you ever thought about creating an own libkface package/release? (As a
libkface git repository does already exist)

Seems like not all distributors create own packages for libkface (Gentoo e. g.
does, Debian e. g. does not). Sure, one can simply install the whole Digikam
package, but I think, as a library, an own package for libkface would be nice,
particularly as libkface does not depend on Digikam.

What do you think?

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

[Gilles Caulier-4]

2014-09-17 13:30 GMT+02:00 Tobias Leupold <[hidden email]>:
>> I hope to continue to improve libkface in the future to share the
>> experience between both project.
> I hope so :-)
>
>> Please read my mail of few day ago about the reunion in Berlin. You is
>> welcome to register you to the event.
> I'll have to check if can can come ... can't tell yet ...
>

It's important to have the information soon, because i must book an
hotel and the place where people will work for 3 days.

> But apart from this:
>
> Have you ever thought about creating an own libkface package/release? (As a
> libkface git repository does already exist)
>
> Seems like not all distributors create own packages for libkface (Gentoo e. g.
> does, Debian e. g. does not). Sure, one can simply install the whole Digikam
> package, but I think, as a library, an own package for libkface would be nice,
> particularly as libkface does not depend on Digikam.
>
> What do you think?

Currently, libkface is in extragear. I don't want to manage a release
lib. It's too much of work.

Solution :

1/ move libkface into kdegraphics/libs, as libkipi, libkexiv2, and
libkdcraw. Release is done with KDE. This can be a good way since code
is in a better stage now.

2/ do as digiKam : include libkface as 3rdparty lib to kphotoalbum.
Not the best but this simplify release plan. Look how it's done in
digiKam. We have a super repository with scripts that we run to check
3rd party code at release time. It's done automatically.

I recommend to look on solution 2/ first and we can plan 1/ when we
can judge that code is ready to be more public as libkipi, libkdcraw,
or libkexiv2. This is an important topic to talk at Berlin in
November.

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

[Tobias Leupold]

> 1/ move libkface into kdegraphics/libs, as libkipi, libkexiv2, and
> libkdcraw. Release is done with KDE. This can be a good way since code
> is in a better stage now.
I think this would be the nicest solution!

> 2/ do as digiKam : include libkface as 3rdparty lib to kphotoalbum.
> Not the best but this simplify release plan. Look how it's done in
> digiKam. We have a super repository with scripts that we run to check
> 3rd party code at release time. It's done automatically.
I'll have to ask the "big" KPA developers if this would be possible to do. But
your first solution sounds a lot better to me.

I just thought of the Gentoo way. We have a single libkface ebuild, which
takes the Digikam sources and only builds and installs libkface. Digikam
itself also depends on this ebuild, so if you install it, Digikam will be
built without libkface (after building libkface itself, of course).

So what I have been thinking of, of course for Gentoo, is a USE-Flag telling
if we want or don't want libkface support (the implementation in KPA is
optional). So if you want it, KPA simply pulls libkface and when it's there,
the face detection/recognition functionality will be built.

I don't know if this would work analogously for other distributions.

But what would happen if we packaged libkface, if you install both Digikam and
KPA? Wouldn't we get collisions?

I really think a separate release for libkface would be the way better
solution ... especially, if it could be done automatically, as you write above
(sorry, I'm a very new KDE dev, so I don't know how this all works yet ;-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2014-09-17 13:54 GMT+02:00 Tobias Leupold <[hidden email]>:

>> 1/ move libkface into kdegraphics/libs, as libkipi, libkexiv2, and
>> libkdcraw. Release is done with KDE. This can be a good way since code
>> is in a better stage now.
> I think this would be the nicest solution!
>
>> 2/ do as digiKam : include libkface as 3rdparty lib to kphotoalbum.
>> Not the best but this simplify release plan. Look how it's done in
>> digiKam. We have a super repository with scripts that we run to check
>> 3rd party code at release time. It's done automatically.
> I'll have to ask the "big" KPA developers if this would be possible to do. But
> your first solution sounds a lot better to me.
>
> I just thought of the Gentoo way. We have a single libkface ebuild, which
> takes the Digikam sources and only builds and installs libkface. Digikam
> itself also depends on this ebuild, so if you install it, Digikam will be
> built without libkface (after building libkface itself, of course).
>
> So what I have been thinking of, of course for Gentoo, is a USE-Flag telling
> if we want or don't want libkface support (the implementation in KPA is
> optional). So if you want it, KPA simply pulls libkface and when it's there,
> the face detection/recognition functionality will be built.
>
> I don't know if this would work analogously for other distributions.
>
> But what would happen if we packaged libkface, if you install both Digikam and
> KPA? Wouldn't we get collisions?

Right. So point 2/ is a bad way, excepted if packager will solve the puzzle...

>
> I really think a separate release for libkface would be the way better
> solution ... especially, if it could be done automatically, as you write above
> (sorry, I'm a very new KDE dev, so I don't know how this all works yet ;-)

I vote for point 1/

This want mean to ask to kdegraphics mailing list if admin are agree
to plug this library as official kde sub-lib. The move can be operated
also by kdegraphics team _at_ the right time (i want mean when it's
the good moment accordingly with KDE release plan)

Can you manage a future kdegraphics discussion about this topic ?

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

[Tobias Leupold]

> I vote for point 1/
>
> This want mean to ask to kdegraphics mailing list if admin are agree
> to plug this library as official kde sub-lib. The move can be operated
> also by kdegraphics team _at_ the right time (i want mean when it's
> the good moment accordingly with KDE release plan)
>
> Can you manage a future kdegraphics discussion about this topic ?

I'll ask the kdegraphics mailing list :-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Thanks

Gilles

2014-09-17 14:24 GMT+02:00 Tobias Leupold <[hidden email]>:

>> I vote for point 1/
>>
>> This want mean to ask to kdegraphics mailing list if admin are agree
>> to plug this library as official kde sub-lib. The move can be operated
>> also by kdegraphics team _at_ the right time (i want mean when it's
>> the good moment accordingly with KDE release plan)
>>
>> Can you manage a future kdegraphics discussion about this topic ?
>
> I'll ask the kdegraphics mailing list :-)
> _______________________________________________
> 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