Add eye model annotations to face landmark dataset with sufficient resolution for eye models: iris (ellipse) + pupil (ellipse) + eyelid contours (16 points) + eye cream (9 points).

Will be adding simple opencv highgui tool for local eye model annotation.

Consider adding functionality to: https://github.com/menpo/landmarkerio-server

The current cvmatio design uses an overloaded class EFStream : public std::fstream approach for endian portability which forces MatlabIO to use an input filename. This prevent portable istream use, which is required for loading baked assets in Qt (and similar). The EFStream read operator performs a normal read followed by a swapEndian call.

    // overloaded fstream read method with 
    // byte swapping capacity
    std::istream& read(char *s, std::streamsize n) {
        // call the parent read
        std::istream& stream = std::fstream::read(s,n);
        // swap the endianness if necessary
        if (byte_swap_ && n%2 == 0) swapEndian(s,n);
        return stream;
    }

Moving the endian swap out of the EFStream (into MatlabIO) would allow MatlabIO to work with arbitrary istream classes.

TOOLCHAIN=vs-14-2015, CONFIG=Release

[00:13:40] EIGEN3_INCLUDE_DIR =
[00:13:40] HAVE_VALGRIND: HAVE_VALGRIND-NOTFOUND
[00:13:40] CMAKE_CXX_COMPILER_ID: MSVC
[00:13:40] =======
[00:13:40] 3: Test timeout computed to be: 9.99988e+006
[00:13:40] 3: [==========] Running 1 test from 1 test case.
[00:13:40] 3: [----------] Global test environment set-up.
[00:13:40] 3: [----------] 1 test from ACFTest
[00:13:40] 3: [ RUN      ] ACFTest.ACFDetection
[00:13:40] 3: -------------------------
[00:13:40] 3: File: C:/projects/drishti/assets/drishti_face_inner_48x48.mat
[00:13:40] 3: MATLAB 5.0 MAT-file, Platform: MACI64, Created on: Fri Oct  2 22:17:11 2015                                         Variables: detector vector<vector<MatlabIOContainer>>
[00:13:40] 3: -------------------------
[00:13:40] 3: [       OK ] ACFTest.ACFDetection (123 ms)
[00:13:40] 3: [----------] 1 test from ACFTest (123 ms total)
[00:13:40] 3:
[00:13:40] 3: [----------] Global test environment tear-down
[00:13:40] 3: [==========] 1 test from 1 test case ran. (123 ms total)
[00:13:40] 3: [  PASSED  ] 1 test.
[00:13:40] 3/3 Test #3: acf_test .........................   Passed    0.13 sec
[00:13:40] 
[00:13:40] 100% tests passed, 0 tests failed out of 3
[00:13:40] 

TOOLCHAIN=vs-14-2015, CONFIG=Debug

[00:13:53] EIGEN3_INCLUDE_DIR =
[00:13:53] HAVE_VALGRIND: HAVE_VALGRIND-NOTFOUND
[00:13:53] CMAKE_CXX_COMPILER_ID: MSVC
[00:13:53] =======
[00:13:53] Errors while running CTest
[00:13:53] 3: [----------] 1 test from ACFTest
[00:13:53] 3: [ RUN      ] ACFTest.ACFDetection
[00:13:53] 3/3 Test #3: acf_test .........................***Failed    0.06 sec
[00:13:53] 
[00:13:53] 67% tests passed, 1 tests failed out of 3
[00:13:53] 
[00:13:53] Total Test time (real) =  65.65 sec
[00:13:53] 
[00:13:53] The following tests FAILED:
[00:13:53]     3 - acf_test (Failed)
[00:13:53] Command exit with status "8": [C:\projects\drishti\_builds\vs-14-2015]> "ctest" "-C" "Debug" "-VV"

• Travis/AppVeyor build
• Qt binaries from server (we can use *-p7 version?)
• bin/build-all.sh on Linux
• bin/build-all.sh on OSX
• tests from src/tests/drishti, CTest
• data/images: use Hunter? (see also #19)
• src/3rdparty to Hunter
• local vs Hunter 3rdparty: use alias target for convenience
• "namespacing" for modules
• "namespacing" for options
• RPATH update, I think logic is redundant (describe here + fix)
• options: https://github.com/elucideye/drishti/pull/16/files/057ac42ad12a04c2e3d5fcd192d90d37a8c4ccf5..3bcbb22a5cd9405e9d40955665a4a38d15009025#r74771788

Other stuff from chat:

• size of the SDK (see #5)
  • O2 instead of O3?
  • MinSizeRel?
  • Link Time Optimization?
  • Single Compilation Unit?
• build time (Hunter binary cache enough? Try Travis directory cache (see comment)

I've currently removed JPEG support, which I believe was causing problems for cvmatio builds (see #106)

hunter_config(OpenCV VERSION 3.0.0-p6 CMAKE_ARGS "${OPENCV_CMAKE_ARGS}")

Per @ruslo:

# Look for WITH_JPEG=ON in Hunter/config.cmake
# Dependency for OpenCV and cvmatio. Usually dependent packages are
# installed automatically but current hardcoded version of OpenCV is not
# hunterized enough so it doesn't know about Jpeg, i.e. there is no
# `hunter_add_package(Jpeg)`.  But Jpeg is present in fresh version of Hunter with
# custom FindJPEG.cmake module which expect JPEGConfig.cmake installed.
# OpenCV do use `find_package(JPEG)` without `hunter_add_package(Jpeg)`, hence
# FindJPEG.cmake exits with error "JPEG::jpeg not found". As a workaround
# we manually download Jpeg before OpenCV.
# TODO: remove after OpenCV version updated
hunter_add_package(Jpeg)
find_package(JPEG CONFIG REQUIRED)

https://github.com/luoyetx/JDA

I've created a public https://github.com/elucideye/hunter-cache site to host binary packages for drishti builds. We need travis + appveyor build mode to support uploading hunter packages to this site for an indepdent/backup binary cache, per documentation here:

https://github.com/ruslo/hunter/blob/master/docs/faq/why-binaries-from-server-not-used.rst

list(APPEND HUNTER_CACHE_SERVERS "https://github.com/elucideye/hunter-cache")
HunterGate(URL ... SHA1 ...)

Effectively enable --test and debug/fix problems

For simple video processing applications, most of the boilerplate QT qmlvideofilter type code can probably be abstracted into something more reusable (and potentially replaced by alternative frameworks). It should be easy to swap in different video pipelines with an API that receives as input an OpenGL texture ID (or void * + width + height + stride + format) and outputs an OpenGL texture ID for display. Some specification for additional output images and or texture ID's could be specified by the user as needed.

int Detector::deserialize(const char *filename)
{
    MatlabIO matio;
    ParserNode<Detector> root_(filename, *this); // <=== printing
    // SNIP
}

Output:

File: /Users/dhirvonen/devel/drishti/assets/drishti_face_inner_48x48.mat
MATLAB 5.0 MAT-file, Platform: MACI64, Created on: Fri Oct  2 22:17:11 2015                                         Variables: detector vector<vector<MatlabIOContainer>>

DRISHTI_BUILD_SHARED_SDK=OFF

The install() is currently skipped on static builds, since the initial use for static builds was asan testing (workaround), that is ok.

# TODO: The install section is failing for static libraries.
#CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti" which requires target "drishti_world" that is not in the export set.
#CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti" which requires target "xgboost" that is not in the export set.
#CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti" which requires target "boost-pba" that is not in the export set.
if(NOT DRISHTI_BUILD_SHARED_SDK)
  return()
endif()

See: https://github.com/headupinclouds/drishti/blob/pr.xcode.asan.exp/src/lib/drishti/CMakeLists.txt#L352-L354
https://github.com/headupinclouds/drishti/blob/pr.xcode.asan.exp/src/lib/drishti/CMakeLists.txt#L329

Boost portable binary archive caveats:
http://www.boost.org/doc/libs/1_55_0/libs/serialization/doc/todo.html

We could always rely on xml or json archives to get things working:

1. login linux
2. deserialize foo.pba.z
3. serialize to foo.xml
4. login windows
5. deserialize foo.xml
6. serialize to foo.win64.pba.z [optional]
7. Need: src/app/pba/pbatoxml and src/app/pba/xmltopba

That should be portable and might be good enough to support Windows development, since this stuff is primarily targeting mobile platforms.

    add_definitions(-DUSE_LOCAL_OGLES_GPGPU=0)
    hunter_add_package(ogles_gpgpu)
    find_package(ogles_gpgpu CONFIG REQUIRED)
    include_directories("${OGLES_GPGPU_ROOT}/include/ogles_gpgpu")
    include_directories("${OGLES_GPGPU_ROOT}/include/ogles_gpgpu/common")
    list(APPEND DRISHTI_SDK_3RDPARTY_PKG_LIBS ogles_gpgpu::ogles_gpgpu) # Add library    

The include_directories() calls above needed after the hunter_add_package(ogles_gpgpu) call to provide paths needed by internal ogles_gpgpu header use, such as:

#include "proc/filter3x3.h"

The internal #include calls should be made to use consistent paths like this:

#include "ogles_gpgpu/common/proc/filter3x3.h"

Sample build log:
ProcessPCH++ /var/folders/03/f9zk5wl94437_7j7vcssvd5r0000gn/C/com.apple.DeveloperTools/7.2.1-7C1002/Xcode/SharedPrecompiledHeaders/drishti_world_CXX_prefix-cyjocbcbdqsnmndrtburcdrlvonp/drishti_world_CXX_prefix.hxx.pch _builds/xcode/src/lib/drishti/Release/cotire/drishti_world_CXX_prefix.hxx normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/dhirvonen/devel/drishti
export LANG=en_US.US-ASCII
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++-header -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O3 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -DCMAKE_INTDIR="Release" -D_USE_MATH_DEFINES -DON=1 -DOFF=0 -DDRISHTI_OPENGL_ES=0 -DHAS_XGBOOST=1 -DHAVE_FP16=1 -DHAVE_HALF_FLOAT=1 -DDO_SQUEEZE=1 -DDLIB_NO_GUI_SUPPORT=1 -DUSE_LOCAL_OGLES_GPGPU=0 -DXGBOOST_DO_LEAN=0 -DXGBOOST_USE_BOOST=1 -DXGBOOST_SQUEEZE=1 -DHALF_ENABLE_CPP11_CMATH=1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -mmacosx-version-min=10.10 -Wno-sign-conversion -I/Users/dhirvonen/devel/drishti/_builds/xcode/src/lib/drishti/Release/include -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/1043db2/388520a/Install/include/opencv -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/1043db2/388520a/Install/include -I/Users/dhirvonen/devel/drishti/src/lib -I/Users/dhirvonen/devel/drishti/src/lib/drishti -I/Users/dhirvonen/devel/drishti/src/3rdparty/pba -I/Users/dhirvonen/devel/drishti/src/3rdparty -I/Users/dhirvonen/devel/drishti/src/lib/drishti/acf/acf/toolbox -I/Users/dhirvonen/devel/drishti/_builds/xcode/src/lib/drishti -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/1043db2/388520a/Install/include/eigen3 -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/1043db2/388520a/Install/include/cvmatio -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/1043db2/388520a/Install/include/xgboost -I/Users/dhirvonen/devel/drishti/_builds/xcode/src/lib/drishti/drishtisdk.build/Release/drishti_world.build/DerivedSources/x86_64 -I/Users/dhirvonen/devel/drishti/_builds/xcode/src/lib/drishti/drishtisdk.build/Release/drishti_world.build/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/dhirvonen/devel/drishti/_builds/xcode/src/lib/drishti/Release -std=c++11 -stdlib=libc++ -Wno-c++11-narrowing -Wno-unused-parameter -Wno-unused-local-typedefs -Wno-unknown-attributes -ftemplate-depth=900 -DNDEBUG -MD -MT dependencies -MF /var/folders/03/f9zk5wl94437_7j7vcssvd5r0000gn/C/com.apple.DeveloperTools/7.2.1-7C1002/Xcode/SharedPrecompiledHeaders/drishti_world_CXX_prefix-cyjocbcbdqsnmndrtburcdrlvonp/drishti_world_CXX_prefix.hxx.d -c /Users/dhirvonen/devel/drishti/_builds/xcode/src/lib/drishti/Release/cotire/drishti_world_CXX_prefix.hxx -o /var/folders/03/f9zk5wl94437_7j7vcssvd5r0000gn/C/com.apple.DeveloperTools/7.2.1-7C1002/Xcode/SharedPrecompiledHeaders/drishti_world_CXX_prefix-cyjocbcbdqsnmndrtburcdrlvonp/drishti_world_CXX_prefix.hxx.pch --serialize-diagnostics /var/folders/03/f9zk5wl94437_7j7vcssvd5r0000gn/C/com.apple.DeveloperTools/7.2.1-7C1002/Xcode/SharedPrecompiledHeaders/drishti_world_CXX_prefix-cyjocbcbdqsnmndrtburcdrlvonp/drishti_world_CXX_prefix.hxx.dia
In file included from /Users/dhirvonen/devel/drishti/_builds/xcode/src/lib/drishti/Release/cotire/drishti_world_CXX_prefix.hxx:4:
In file included from /Users/dhirvonen/devel/drishti/_builds/xcode/src/lib/drishti/Release/cotire/drishti_world_CXX_prefix.cxx:66:
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/1043db2/388520a/Install/include/ogles_gpgpu/common/proc/grad.h:16:10: fatal error: 'proc/filter3x3.h' file not found

include "proc/filter3x3.h"

• Orginize this as Hunter package?
• Where to store such package: Hunter main public (ruslo/hunter) or create private (?) fork?

• acf cpu vs gpu channel computation
• acf SIMD code
• geometry : fitEllipse
• ml : xgboost regression tests (fit cosine, etc); shape_predictor covered by eye model tests
• core : arithmetic + conversions (SIMD)
• graphics: WIP, but test basic ogles_gpgpu texture manipulation
• rcpr : test end-to-end CPR for synthetic ellipse data (train + predict)
• face : test FaceDetectorAndTracker.h
• Coveralls for coverage badge? https://github.com/JoakimSoderberg/coveralls-cmake-example

• Use experimental (not yet released) CMake
• Describe location of config file
• Describe usage of GitHub tokens instead of passwords

# ~/.configs/Hunter/passwords.cmake
hunter_http_password(<packagename-1> USERNAME "MyName" PASSWORD "MyPassword")
hunter_http_password(<packagename-2> USERNAME "MyName2" PASSWORD "MyPassword2")

See, for example:
Rendering of Eyes for Eye-Shape Registration and Gaze Estimation
http://arxiv.org/pdf/1505.05916.pdf

There are an improvement ideas about CMake/Hunter/Polly that have mentioned in few bugs which may have influence on Drishti. This bug will summarize them. Though most of them can be fixed simply in Drishti itself or workarounded somehow, it may be useful to know the whole picture. Probably those pieces of the puzzle will form a new directions.

CMake

Automatic grouping in IDE (Xcode/Visual Studio)

• #44 (comment)
• https://gitlab.kitware.com/cmake/cmake/merge_requests/320

I have a bunch of Python modules in Sugar for such job. But this functionality require to have Python installed and require patching of CMakeLists.txt. If such feature will be implemented in CMake then we can simply add set(CMAKE_IDE_AUTOMATIC_LAYOUT TRUE) or even have this feature ON by default (introduce new CMake policy).

Mirror CMake option to C++ definition

• #78 (review)

This is kind of widely used pattern of transparent connectivity of CMake and C++ levels. Though I think that drishti_mirror_definition should be applied for targets (i.e. call target_compile_definitions instead of add_definitions).

Size of installed files

• #77

Introduce two features:

• New command file(SIZE ...)
• Add option for printing installed sizes using file(SIZE ...), like CMAKE_INSTALL_SIZE_INFO=K (K - kilobytes, M - megabytes, H - human readable, see man ls)

Testing of installed libraries

• #75

This feature missing in CMake itself, I did mentioned it here for example. The next errors is not covered by regular testing:

• Missing definitions. Internally package can define macro by add_definitions("-DFOO"). And if macro FOO used in public header then FOO will be defined on build step and not after the install step.
• Missing find_dependency call. Error happens quite often: after package installed and find_package(CONFIG) called, users got "target Boo::boo is not built by this project, probably find_package is missing". This error means that we have to call find_dependency(Boo) in FooConfig.cmake file.
• Private headers usage/missing headers. Layout of headers on build step may differs from layout after install. In this case if package is using some private header (header that are not planned to install) there will be no error on build step. And vice versa if we are planning to use some header but forget to install it.

CMake methods for manipulation C++ warnings

• #49 (comment)

The feature described here: https://cmake.org/pipermail/cmake-developers/2016-April/028279.html and I'm planning to implement it anyway (my priorities: CGold, Hunter docs, this feature) since it's an importand part of C++ ecosystem which provide one more benefit of using CMake :) Also it will be closely coupled with Leathers (Leathers is a C++ level of CMake funtionality). Idea based/tested on Sugar modules.

Work with JSON format for GitHub API

This one needed for Hunter for uploading binaries to GitHub using CMake instead of Python scripts. Need to introduce new command/family of commands for working with JSON format, like json(PARSE ...) or string(JSON ...) to parse responses from GitHub. I know that some JSON library already integrated into CMake for server-mode feature so just need to discuss/develop API and implement it. Alternatively kind of GitHub API commands can be introduced, like file(GITHUB_API RELEASE_ID release_id RELEASE "v0.0.1" REPO user/repo), file(GITHUB_API RELEASE_LIST release_list REPO user/repo).

I no longer think it's a good idea. It's better to create service that will handle this stuff and other "remote" things.

Single Compilation Unit

• #96
• #97

I still haven't used cotire tool however common sense and API I saw make me think that implementing SCU in CMake itself has next benefits:

• You don't have to patch CMakeLists.txt
• 3rd party library can be added to final single source file too

It means that if you have add_library(foo foo.cpp) there are next variants:

• BUILD_SHARED_LIBS=ON build shared library
• BUILD_SHARED_LIBS=OFF build static library (default)
• CMAKE_BUILD_SCU=ON: for libraries don't build anything, just save the list of files and add them to the final executable. If such library planned to be installed - install only sources and special directive in *Config.cmake file so user can still use find_package(foo CONFIG REQUIRED) + target_link_libraries(<exe> PUBLIC foo)

Hunter

Uploading binaries to GitHub without use of Python script

This feature is important for having custom/private cache servers when user upload binaries without having fork of the Hunter with upload.* branches. The main difference is about the fact that upload.* do operations step-by-step, e.g. if there are A, B, C dependent packages then first we run upload.A, then upload.B, then upload.C. When user have one job for it he should wait for all A, B, C packages built in one single step. If A+B+C takes longer then 50 minutes (or other timeout) there will be no packages uploaded at all. For this feature we need CMake support (see JSON/GitHub API).

Alternative approach will be to use custom front-end server that will handle requests from Hunter and redirect them to the back-end. Different back-ends can be implemented depending on user's settings: S3 bucket, GitHub repository, Sourceforge, custom server, etc. I see it like this: user enter the site with service, login with credentials, set back-end for the upload. Then using same credentials Hunter send request about upload. Server check credentials, determine user, determine user's back-end and redirect request. I have very poor experience with web development so can't say any implementation details for now.

Managing compilers with Hunter

• #90 (comment)

Alternative to using clang from Xcode or brew. The benefits is that we can control build options and version of compilers using CMake code and Hunter packages, store them to binary cache server, etc.
Basic issue is here: https://github.com/ruslo/hunter/issues/495

Thaw

I have an idea about creating super tool for bootstraping. This tool will include:

• functionality of Polly (something based on aliasing, some will be moved to Hunter)
• install-ci-dependencies.py: install latest CMake verion (or precise)
• Implement aliasing system: https://github.com/ruslo/CMake/issues/3 (instead of implementing it in CMake, my proposal was rejected)
• Hunter root maintenance: https://github.com/ruslo/hunter/issues/173
• Reporting human readable/understandable difference between toolchains-id so user can easily find the way how to tweak his environment to use cache server

http://clang.llvm.org/docs/AddressSanitizer.html
http://useyourloaf.com/blog/using-the-address-sanitizer/

Trying polly xcode-address-sanitizer toolchain (similar to [] Enable Address Sanitizer in Xcode scheme).

xcode-sanitizer-address.cmake

# Copyright (c) 2014-2015, Ruslan Baratov
# All rights reserved.

if(DEFINED POLLY_XCODE_SANITIZE_ADDRESS_CMAKE_)
  return()
else()
  set(POLLY_XCODE_SANITIZE_ADDRESS_CMAKE_ 1)
endif()

include("${CMAKE_CURRENT_LIST_DIR}/utilities/polly_init.cmake")

set(POLLY_XCODE_COMPILER "clang")
polly_init(
    "Xcode / ${POLLY_XCODE_COMPILER} / \
LLVM Standard C++ Library (libc++) / c++11 support / sanitize-address"
    "Xcode"
)

include("${CMAKE_CURRENT_LIST_DIR}/utilities/polly_common.cmake")

include("${CMAKE_CURRENT_LIST_DIR}/compiler/xcode.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/library/std/libcxx.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/flags/cxx11.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/flags/sanitize_address_libcxx.cmake")

sanitize_address_libcxx.cmake

# Copyright (c) 2014-2016, Ruslan Baratov
# Copyright (c) 2016, David Hirvonen
# All rights reserved.

if(DEFINED POLLY_FLAGS_SANITIZE_ADDRESS_LIBCXX_CMAKE_)
  return()
else()
  set(POLLY_FLAGS_SANITIZE_ADDRESS_LIBCXX_CMAKE_ 1)
endif()

include(polly_add_cache_flag)

polly_add_cache_flag(CMAKE_CXX_FLAGS "-fsanitize=address")
polly_add_cache_flag(CMAKE_CXX_FLAGS "-g")
polly_add_cache_flag(CMAKE_CXX_FLAGS "-D_LIBCPP_HAS_NO_ASAN")

set(
    CMAKE_CXX_FLAGS_RELEASE
    "-O1 -DNDEBUG"
    CACHE
    STRING
    "C++ compiler flags"
    FORCE
)

polly_add_cache_flag(CMAKE_C_FLAGS "-fsanitize=address")
polly_add_cache_flag(CMAKE_C_FLAGS "-g")
polly_add_cache_flag(CMAKE_C_FLAGS "-D_LIBCPP_HAS_NO_ASAN")

set(
    CMAKE_C_FLAGS_RELEASE
    "-O1 -DNDEBUG"
    CACHE
    STRING
    "C compiler flags"
    FORCE
)

Running ./bin/build-xcode.sh with the above toolchain fails with the following error:

CMake Error at /usr/local/Cellar/cmake/3.5.0/share/cmake/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler
  "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
  is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp



  Run Build Command:"/usr/bin/xcodebuild" "-project"
  "CMAKE_TRY_COMPILE.xcodeproj" "build" "-target" "cmTC_3f5d6"
  "-configuration" "Debug"

  === BUILD TARGET cmTC_3f5d6 OF PROJECT CMAKE_TRY_COMPILE WITH CONFIGURATION
  Debug ===



  Check dependencies



  Write auxiliary files

  /bin/mkdir -p
  /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/Objects-normal/x86_64


  write-file
  /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/Objects-normal/x86_64/cmTC_3f5d6.LinkFileList




  CompileC
  CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/Objects-normal/x86_64/testCCompiler.o
  testCCompiler.c normal x86_64 c com.apple.compilers.llvm.clang.1_0.compiler

      cd /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp
      export LANG=en_US.US-ASCII
      /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -DCMAKE_INTDIR=\"Debug\" -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -mmacosx-version-min=10.10 -g -Wno-sign-conversion -I/Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/Debug/include -I/Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/DerivedSources/x86_64 -I/Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/Debug -D_LIBCPP_HAS_NO_ASAN -fsanitize=address -MMD -MT dependencies -MF /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/Objects-normal/x86_64/testCCompiler.d --serialize-diagnostics /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/Objects-normal/x86_64/testCCompiler.dia -c /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/testCCompiler.c -o /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/Objects-normal/x86_64/testCCompiler.o



  Ld Debug/cmTC_3f5d6 normal x86_64

      cd /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp
      export MACOSX_DEPLOYMENT_TARGET=10.10
-- Configuring incomplete, errors occurred!
See also "/Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeOutput.log".
See also "/Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeError.log".
      /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -L/Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/Debug -F/Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/Debug -filelist /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/Objects-normal/x86_64/cmTC_3f5d6.LinkFileList -mmacosx-version-min=10.10 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Xlinker -dependency_info -Xlinker /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_3f5d6.build/Objects-normal/x86_64/cmTC_3f5d6_dependency_info.dat -o /Users/dhirvonen/devel/drishti/_builds/xcode-sanitize-address/CMakeFiles/CMakeTmp/Debug/cmTC_3f5d6

  Undefined symbols for architecture x86_64:

    "___asan_init", referenced from:
        _asan.module_ctor in testCCompiler.o
    "___asan_version_mismatch_check_v6", referenced from:
        _asan.module_ctor in testCCompiler.o

  ld: symbol(s) not found for architecture x86_64

  clang: error: linker command failed with exit code 1 (use -v to see
  invocation)



  ** BUILD FAILED **





  The following build commands failed:

    Ld Debug/cmTC_3f5d6 normal x86_64

  (1 failure)

We need to ensure that functionality in the post installation libraries (after stripping etc.) is tested, as something could go wrong during that stage.

https://github.com/patrikhuber/superviseddescent

☝️

The SDK and classifier/regressor files must be reduced:

• investigate replacing compressed boost portable binary archives with cereal
• compare above w/ flatbuffers (see dest)
• BUILD_MIN_SIZE macro to remove training and IO that isn't needed at runtime
• reduce opencv use

Some discussion: http://stackoverflow.com/questions/1061169/boost-serialization-vs-google-protocol-buffers. flatbuffers is not really intended for serialization but may provide more compact storage at the expense of less concise code. Need to compare combined lib + storage size after library stripping.

https://github.com/elucideye/drishti/blob/master/src/CMakeLists.txt#L28-L33

TODO: missing learner-inl.hpp

...my_file.cpp:27:10: fatal error: 'src/learner/learner-inl.hpp' file not found

Currently library modules are built as static libraries and CMake adds "Source Files" and "Header Files" folders like this:

module
 |-- Source Files
 |-- Header Files

It would be nice to include an addition folder for subcategories, such as the gpu modules.

module
 |-- Source Files
 |-- Header Files
 |- gpu
      |-- Source Files
      |-- Header Files

This seems to be inevitable

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

The build has been terminated

Manual restarts are almost always required for 1 toolchain. Need to investigate .

Various resource files (detectors + regressors) should be moved out of the repository and managed by Hunter. In some cases this can help clarify license issues.

Binary files in:
https://github.com/elucideye/drishti/tree/master/assets

https://aws.amazon.com/device-farm

Pay per minute for device testing on tag + release:
https://aws.amazon.com/device-farm/pricing/

Not critical, disabling for now.

CMakeFiles/test-thread-pool.dir/test-thread-pool.cpp.o:/Users/dhirvonen/devel/drishti/src/tests/thread-pool/test-thread-pool.cpp:function main: error: undefined reference to '__aeabi_read_tp'
CMakeFiles/test-thread-pool.dir/test-thread-pool.cpp.o:/Users/dhirvonen/devel/drishti/src/tests/thread-pool/test-thread-pool.cpp:function Worker<128u>::threadFunc(unsigned int, Worker<128u>*): error: undefined reference to '__aeabi_read_tp'

Build monolithic static library drishti_world by aggregating all sources collected using sugar.

If I use

target_link_libraries(drishti_c PRIVATE "${DRISHTI_SDK_LIBS}")
I'm able to install cleanly, but when I switch this to PUBLIC:

target_link_libraries(drishti_c PUBLIC "${DRISHTI_SDK_LIBS}")
I get the following errors on installation. This is a shared library, so I wouldn't expect a need to install the dependencies.

CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti_c" which requires target "drishti_eye" that is not in the export set.
CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti_c" which requires target "drishti_rcpr" that is not in the export set.
CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti_c" which requires target "drishti_ml" that is not in the export set.
CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti_c" which requires target "drishti_geometry" that is not in the export set.
CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti_c" which requires target "drishti_sensor" that is not in the export set.
CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti_c" which requires target "drishti_core" that is not in the export set.
CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti_c" which requires target "xgboost" that is not in the export set.
CMake Error: install(EXPORT "drishtiTargets" ...) includes target "drishti_c" which requires target "boost-pba" that is not in the export set.
-- Generating done

@ruslo : Continuation of PR discussion

https://github.com/luoyetx/face-alignment-at-3000fps

This is low priority.

Doxygen headers have been added for all files, but function and class documentation needs to be added (starting with drishti public API).

TODO: The standard library style namespace macros (which prevent IDE indentation) are currently confusing doxygen. This needs to be fixed.

Initial cotire testing...

The cotter builds seem to reduce to 0.66x (debug) to 0.75x (release) the standard build time. I've added an option to use these targets. This will create new _unity targets. The current installed SDK has not been updated to use drishti_world_unity target, however.

Release : 0.75x
drishti_world: 80, 79
drishti_world_unity: 63, 60

Debug: 0.66x
drishti_world: 91, 78, 77
drishti_world_unity: 48, 50, 53

This would only work for HOST == TARGET builds (of course). I believe this is as simple as just passing the --test option to the polly.py command in appveyor.yml and .travis.yml for HOST == TARGET builds.

• src/3rdparty/xgboost
• src/3rdparty/thread-pool-cpp
• src/3rdparty/ogles_gpgpu
• src/3rdparty/eos
• src/3rdparty/dest

Test both configuration on Travis/AppVeyor?

The internal library folder layout should be such that both build and install paths can use a "namespaced" include path:

#include <drishti/foo/thing.hpp>

We can adopt the layout used in opencv:

Single per module include (optional):

opencv/modules/core/include/opencv2/core.hpp

Individual module files:

opencv/modules/core/include/opencv2/core/core.hpp

Investigate in the context of GPU friendly tree evaluation. In ACF processing we compute features in shaders and pull down the textures to the CPU w/ platform optimized transfers, then evaluate regression and classification trees on the CPU. It would be nice to investigate ways to do this end-to-end on the GPU (my sense is it will be hard to beat the CPU even w/ transfer overhead).

CVMATIO ZLIB:
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)

cvmatio Configuration Summary

Building with ECTO/Catkin: OFF
Build as executable: OFF
Build with documentation: OFF

-- Configuring done
CMake Error at src/CMakeLists.txt:8 (add_library):
Target "cvmatio" links to target "JPEG::jpeg" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?

CMake Error at src/CMakeLists.txt:8 (add_library):
Target "cvmatio" links to target "JPEG::jpeg" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?

CMake Error at src/CMakeLists.txt:8 (add_library):
Target "cvmatio" links to target "JPEG::jpeg" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?

CMake Error at src/CMakeLists.txt:8 (add_library):
Target "cvmatio" links to target "JPEG::jpeg" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
-- Generating done

-- Build files have been written to: /home/travis/.hunter/_Base/defe8ce/95401fc/9de7cb3/Build/cvmatio/Build/cvmatio-Release-prefix/src/cvmatio-Release-build
CMake Warning:
Manually-specified variables were not used by the project:

CMAKE_CONFIGURATION_TYPES

make[2]: Leaving directory /home/travis/.hunter/_Base/defe8ce/95401fc/9de7cb3/Build/cvmatio/Build' make[2]: *** [cvmatio-Release-prefix/src/cvmatio-Release-stamp/cvmatio-Release-configure] Error 1 make[1]: *** [CMakeFiles/cvmatio-Release.dir/all] Error 2 make: *** [all] Error 2 make[1]: Leaving directory/home/travis/.hunter/_Base/defe8ce/95401fc/9de7cb3/Build/cvmatio/Build'

[hunter ** FATAL ERROR **] Build step failed (dir: /home/travis/.hunter/_Base/defe8ce/95401fc/9de7cb3/Build/cvmatio
[hunter ** FATAL ERROR **] [Directory:/home/travis/.hunter/_Base/Download/Hunter/0.16.2/defe8ce/Unpacked/cmake/projects/cvmatio]

------------------------------ WIKI -------------------------------

https://github.com/ruslo/hunter/wiki/error.external.build.failed

CMake Error at /home/travis/.hunter/_Base/Download/Hunter/0.16.2/defe8ce/Unpacked/cmake/modules/hunter_wiki.cmake:12 (message):
Call Stack (most recent call first):
/home/travis/.hunter/_Base/Download/Hunter/0.16.2/defe8ce/Unpacked/cmake/modules/hunter_fatal_error.cmake:20 (hunter_wiki)
/home/travis/.hunter/_Base/Download/Hunter/0.16.2/defe8ce/Unpacked/cmake/modules/hunter_download.cmake:499 (hunter_fatal_error)
/home/travis/.hunter/_Base/Download/Hunter/0.16.2/defe8ce/Unpacked/cmake/projects/cvmatio/hunter.cmake:59 (hunter_download)
/home/travis/.hunter/_Base/Download/Hunter/0.16.2/defe8ce/Unpacked/cmake/modules/hunter_add_package.cmake:87 (include)
CMakeLists.txt:314 (hunter_add_package)

-- Configuring incomplete, errors occurred!
See also "/home/travis/build/elucideye/drishti/_builds/gcc-4-8-pic-Release/CMakeFiles/CMakeOutput.log".
See also "/home/travis/build/elucideye/drishti/_builds/gcc-4-8-pic-Release/CMakeFiles/CMakeError.log".
Command exit with status "1": [/home/travis/build/elucideye/drishti]> "cmake" "-H." "-B/home/travis/build/elucideye/drishti/_builds/gcc-4-8-pic-Release" "-DCMAKE_BUILD_TYPE=Release" "-GUnix Makefiles" "-DCMAKE_TOOLCHAIN_FILE=/home/travis/build/elucideye/drishti/polly-master/gcc-4-8-pic.cmake" "-DCMAKE_VERBOSE_MAKEFILE=ON" "-DPOLLY_STATUS_DEBUG=ON" "-DHUNTER_STATUS_DEBUG=ON" "-DCMAKE_INSTALL_PREFIX=/home/travis/build/elucideye/drishti/_install/gcc-4-8-pic" "-DDRISHTI_BUILD_REGRESSION_SIMD=NO" "-DDRISHTI_BUILD_REGRESSION_FIXED_POINT=NO" "-DHUNTER_USE_CACHE_SERVERS=YES" "-DHUNTER_DISABLE_BUILDS=NO" "-DCMAKE_INSTALL_PREFIX=/home/travis/build/elucideye/drishti/_install"

Log: /home/travis/build/elucideye/drishti/_logs/polly/log.txt
*** FAILED ***

The command "build.py --toolchain ${TOOLCHAIN} --config ${CONFIG} --verbose --fwd DRISHTI_BUILD_REGRESSION_SIMD=NO DRISHTI_BUILD_REGRESSION_FIXED_POINT=NO HUNTER_USE_CACHE_SERVERS=YES HUNTER_DISABLE_BUILDS=NO CMAKE_INSTALL_PREFIX="pwd/_install" --test --jobs 8 ${STRIP}
" exited with 1.

Done. Your build exited with 1.

https://github.com/patrikhuber/4dface

Migrated from PR discussion...

Ruslo: LINK_FLAGS can be set outside of the project: in someone's toolchain or by using Drishti with add_subdirectory(drishti). It's better to not rely on such things and clean variable always.

https://github.com/golnazghiasi/hpm-detection-code

Part based models begin do better than pure regression approaches for heavily occluded face images. HPM outperforms RCPR in occlusion data sets. Need to benchmark for feasibility in mobile processing (size + speed). See:

This may not be suitable for real time processing on mobile devices. The paper reports 10 seconds per frame using this approach [reference?].

A settings file is needed to configure various device specific settings (resolution, scale parameters, etc.)

Does QT have a generic way to report the active device name (manufacturer + model)?

• https://github.com/luoyetx/deep-landmark
• https://github.com/luoyetx/mini-caffe-example
• https://github.com/ufoym/Caffe-mini

Both mini-caffe and Caffe-mini projects above seem to be candidate hunter packages for running caffe models portably "outside" the caffe environment.

• simple test to prove that we need to rebuilt libcxx (e.g. std::string usage)
• try new Xcode with builtin asan
• toolchain in Polly, some WIP stuff:
  • https://github.com/ruslo/polly/blob/master/flags/sanitize_address.cmake
  • https://github.com/ruslo/polly/blob/master/library/std/nolibs.cmake
  • https://github.com/ruslo/polly/blob/master/sanitize-address.cmake
• organize libcxx into Hunter package, related: https://github.com/ruslo/hunter/issues/495

Initial PR with dependencies added here:

https://github.com/elucideye/drishti/blob/pr.package.config.full/cmake/Config.cmake.in

This will need to work correctly for both shared and static builds, as well as "world" and individual library configurations.

This may help reduce regressor size for coarse models. Such a configuration could provide decent performance for eye localization at low resolution using a 5 point (eyes + nose + mouth corners) model.

Need to remove potentially redundant math constant definitions here:

https://github.com/elucideye/drishti/blob/master/src/lib/drishti/core/drishti_math.h

After @ruslo's CMakeLists.txt per library definitions here:

# define M_PI_2 for Visual Studio
target_compile_definitions(drishti_ml PUBLIC _USE_MATH_DEFINES) 

I don't currently have a local Windows host for testing.

Adding an issue so we don't forget.

Currently a small set of test images is maintained in the repository. This should be stored externally and can be managed by hunter.