Creating a library

[Jailander]

Hi,

We want to integrate this into ROS and @marc-hanheide suggested that the best way to do so is to turn your software into a library to which we provide the images and we get some kind of output out of it, whatever is more convenient for you. Do you think this is feasible?

[marc-hanheide]

let's tag @lschilli so he sees this 😀

[marc-hanheide]

if by any means possible I'd like to remove the QT requirement from the library. This is because we run this in a headless distributed system.

[marc-hanheide]

the benefit for you @lschilli will be that we automatically build Ubuntu packages for this.

[marc-hanheide]

that said, I suggest to not catkinise the core library and also leave it ROS-free. Rather we suggest to have an independent ROS wrapper that uses the library. So proposed changes:

• refactor code to build a core library without GUI (and without ROS)
• base the main app on the library
• introduce a CMake flag to enable GUI (and use QT) and stand alone application (ON by default to have same behaviour as now)
• develop a separate ROS wrapper that uses the library (in a separate repo called ros_gazetool)

[lschilli]

Removing the QT dependency is not so hard, since it is already more or less separated due to multithreading requirements.

[marc-hanheide]

and generally... good plan? any anticipated issues?

[lschilli]

In general good plan. At the moment I have a little bit limited time to think about it but a library makes sense. I don't see any big issues. It might be necessary to develop a proper interface to configure the library at runtime. The code for that is quite simple at the moment.

[lschilli]

If you want you can start doing this in a branch in this repository (if you do not want to wait).

[Jailander]

sounds good, I will start working on it then and ask you if I have any doubts if you don't mind.

[lschilli]

Sure, I can have a look at it. By the way did you already test the current version? Does it compile / sufficiently works for your application?

[Jailander]

it compiles and runs quite well i must say, I only see a problem with the dlib dependency, we might have to release a version of it too @marc-hanheide

[lschilli]

The dlib dependency is compile time only (except the model download). The dlib author does not really support building a shared library although it is partially possible (dlib makes heavy use of templates). Still one might want to deploy dlib as a dev package.

[marc-hanheide]

If the license permits, I'd suggest to just include the source code of that lib directly in a 3rd_party subdir.

[Jailander]

dlib is under the "Boost Software License" so it should be possible.

[lschilli]

In general fine with me. For the version here I would prefer a download wrapper script solution, so it is not necessary to carry around the dlib code.

[marc-hanheide]

I personally hate it when a build script download unsolicited software (where I don't know if anyone has "injected" potentially malicious code released under the same URL). I'd rather have this as a git subtree in our repo, so we can still pull changes in from the remote repo to update to a new version. Or... we indeed release it as a package, but then we'd have to make it proper (add install targets etc).

[lschilli]

I know it is a pain but dlib's unpacked distribution size is 75M. The dlib core folder is 18M. Since it seems to live here https://github.com/davisking/dlib the subtree solution might be viable. Of course a download wrapper is a hack (which could also easily verify the checksum of the download to somewhat avoid code injection). The proper solution would be to model the external dependencies as packages, etc. I don't like including and maintaining huge chunks of external code in a repository. With the subtree solution the face alignment model dependency hosted on sourceforge is not caught. The subtree option remains an idea for the dlib dependency. However, I do not know how github handles subtrees when someone tries to download archive zip/tarballs.

[ttoenige]

@marc-hanheide @Jailander : Are there any updates related the transformation into a library? BTW: Since the last dlib release (18.18) it is possible to build a dlib library and to link against it.

[Jailander]

hi I've left this a bit on the said but now that you mention this I'll take a look and see if I can finish it thank you.

[ttoenige]

Can you estimate how much time you will need? I could have a look at it as well...

[Jailander]

I am swamped this week, so if you want to have a go at it that would be great for me.