Alexander Pacha's profile - activity

The problem is explained here. Since Android 5.0 service intents must be explicit intents and the OpenCV library uses implicit intents in the AsyncServiceHelper.java (new Intent("org.opencv.engine.BIND")), so it doesn't work.

Changing the targetSDK is just a workaround for now, but eventually the source-code has to be changed in the future (Alex might know more). The solution would be to change the Method initOpenCV to something like this:

public static boolean initOpenCV(String Version, final Context AppContext,
        final LoaderCallbackInterface Callback)
{
    AsyncServiceHelper helper = new AsyncServiceHelper(Version, AppContext, Callback);
    Intent explicitIntent = new Intent(AppContext, org.opencv.engine.???.class);
    if (AppContext.bindService(explicitIntent,
            helper.mServiceConnection, Context.BIND_AUTO_CREATE))
    {
        return true;
    }
    else
    {
        AppContext.unbindService(helper.mServiceConnection);
        InstallService(AppContext, Callback);
        return false;
    }
}

but since parts of OpenCV are built with the JNI, I don't know what to put there instead of the ??? because 'BIND' is just a placeholder it seems to me.

When reading the tutorials or answers about using OpenCV with Android, I get the impression that I must add over 100MB of data into my GIT-repository which I obviously don't want, but did so far. Is there a better way to include OpenCV into my Android application without polluting my repo?

When using OpenCV, I aim for the OpenCV Manager on Android Devices anyway, so I just want to add a minimal jar-file to my project that I can use, like the one, which is actually built when following the procedure from above.

Ideally it would be possible to add OpenCV just like any other dependency into my Gradle Buildscript and the respective jar is automatically pulled from a repository like jcenter.

dependencies {
     compile 'org.opencv:android:2.4.10'
}

Then all I had to do was to include something like this into my build-script and could start using OpenCV almost straight away. Would that be hard to realise?

If that is not possible, what do you think of building the library only once and just adding the 200k jar file to my repository and application? (If that works, it could be added to the documentation as a "lightweight"-way of using OpenCV with Android).

Thanks for the infos, still I don't know how to change my verification here from Google to plain mail/password.

Hi, I logged in to answers.opencv.org today with my Google-Account and got the message, that only OpenID-Accounts will be valid in the future and I should migrate to OpenID.

However, I can't find a way to do this. Should this be performed inside Google, or inside this website? I want to avoid that I can't log into this site in May 2015 anymore. Any ideas or official resources?

Make sure to use the correct format for imdecode(). The assertion fails, if the provided data did not match the image-format that was expected (= specified).

Here is the helper-method that I wrote to actually perform this task:

private static Mat readInputStreamIntoMat(InputStream inputStream) throws IOException {
    // Read into byte-array
    byte[] temporaryImageInMemory = readStream(inputStream);

    // Decode into mat. Use any IMREAD_ option that describes your image appropriately
    Mat outputImage = Highgui.imdecode(new MatOfByte(temporaryImageInMemory), Highgui.IMREAD_GRAYSCALE);

    return outputImage;
}

private static byte[] readStream(InputStream stream) throws IOException {
    // Copy content of the image to byte-array
    ByteArrayOutputStream buffer = new ByteArrayOutputStream();
    int nRead;
    byte[] data = new byte[16384];

    while ((nRead = stream.read(data, 0, data.length)) != -1) {
        buffer.write(data, 0, nRead);
    }

    buffer.flush();
    byte[] temporaryImageInMemory = buffer.toByteArray();
    buffer.close();
    stream.close();
    return temporaryImageInMemory;
}

This would not work, because the keypoints returned by the FAST detector are not sorted, so you would end up taking 500 (more or less) random points instead of the 500 best points.

You are right, the documentation (http://docs.opencv.org/modules/ml/doc/k_nearest_neighbors.html) is missing the first three parameters.

Just two small hints: If opening takes some time, it's not useful to put the sleep() after the if-clause, because it already passed the relevant point. Second, make sure you have properly initialised opencv ( OpenCVLoader.initAsync(OpenCVLoader.OPENCV_VERSION_2_4_5, ...))

One way to reduce the number of keypoints detected is to increase the threshold. To do this, take a look at this post. You can replace the writeLine()-call with

writeToFile(outputFile, "%YAML:1.0\nthreshold: 30 \nnonmaxSupression: true\n");

to set the parameter for the FAST feature detector.

The other way is to get the best Keypoints is by sorting them according to their response and then pick only the n best ones:

// Detect the features with you Feature Detector
FeatureDetector fastDetector = FeatureDetector.create(FeatureDetector.FAST);
MatOfKeyPoint matrixOfKeypoints;
fastDetector.detect(imageMat, matrixOfKeypoints);

// Sort and select 500 best keypoints
List<KeyPoint> listOfKeypoints = matrixOfKeypoints.toList();
Collections.sort(listOfKeypoints, new Comparator<KeyPoint>() {
    @Override
    public int compare(KeyPoint kp1, KeyPoint kp2) {
        // Sort them in descending order, so the best response KPs will come first
        return (int) (kp2.response - kp1.response);
    }
});

List<KeyPoint> listOfBestKeypoints = listOfKeypoints.subList(0, 500);

One final remark: Gauglitz et al. 2011 showed that it is important for visual tracking, that keypoints are spatially well distributed, so keep in mind, that you might also want to select the best keypoints according to a grid, so make sure your points are spatially well distributed.

If you don't have the OpenCVTestRunner, this does the job (Exception-Handling omitted):

private void init() {

    [...]

    FeatureDetector orbDetector = FeatureDetector.create(FeatureDetector.ORB);

    File outputDir = getCacheDir(); // If in an Activity (otherwise getActivity.getCacheDir();
    File outputFile = File.createTempFile("orbDetectorParams", ".YAML", outputDir);
    writeToFile(outputFile, "%YAML:1.0\nscaleFactor: 1.2\nnLevels: 8\nfirstLevel: 0 \nedgeThreshold: 31\npatchSize: 31\nWTA_K: 2\nscoreType: 1\nnFeatures: 500\n");
    orbDetector.read(outputFile.getPath());

    [... use detector ... ]
}

private void writeToFile(File file, String data) {
    FileOutputStream stream = new FileOutputStream(file);
    OutputStreamWriter outputStreamWriter = new OutputStreamWriter(stream);
    outputStreamWriter.write(data);
    outputStreamWriter.close();
    stream.close();
}

Seems like you already accepted an answer for this question on stackoverflow. What was wrong with it?

Maybe you wanna check your archiving program and give 7-Zip a try.

Created a bug-report: http://code.opencv.org/issues/3166

I want to track interesting points in the video view. Due to performance reasons, I picked ORB as feature detector and feature descriptor that gives me 500 points each frame.

Now when it comes to the matching part, I only need a few correspondences (>7 for homography), so an approximate nearest neighbor search is fine.

My first question is: Should I use FLANN matcher with LSH Indexing like this (considering that I have a binary feature descriptor, this sounds reasonable):

FlannBasedMatcher matcher (new flann::LshIndexParams(20,10,2));
std::vector< DMatch > matches;
matcher.match( descriptors_object, descriptors_scene, matches );

or should I rather go for a Brute-Force matcher (if I have only 500 points), since I am not reusing the index that the FLANN matcher built a second time, but each frame a new one. Or simply rely on the AutotunedIndexParams? Is the building of the FLANN-Index computational expensive?

The second question is, how to find the optimal parameters for the LshIndexParams? The original documentation (p.8) of FLANN uses 12, 20 and 2. What is the correct key-size of ORB-features?

Third and final question: Are the improvements, described in this paper(download) already implemented, or do I have to directly use the authors code?

Is the STAR feature detector the implementation of the CenSurE Feature detector (download), published by Agrawal, Konolige and Blas?

All I found was this homepage that indicates my believe, but why is it called STAR? The source code is completely undocumented and the official reference only mentions the name Konolige but not the paper.