Hoe kan ik mijn Android-openCV-applicatie versnellen?

Question

Hoe kan ik mijn Android-openCV-applicatie versnellen?

Ik heb een openCV-applicatie geïmplementeerdWaarin ik de SURF-descriptor gebruik. Het werkt prima, de code ziet er zo uit:

Ik verklein de video-ingang voor de ingangsvideo om deze te versnellen

            capture.set(Highgui.CV_CAP_PROP_FRAME_WIDTH, display.getWidth());
            capture.set(Highgui.CV_CAP_PROP_FRAME_HEIGHT, display.getHeight());

            capture.retrieve(mRgba, Highgui.CV_CAP_ANDROID_COLOR_FRAME_RGBA);

            try{

          //-- Step 1: Detect the keypoints using SURF Detector

            surfDetector.detect( mRgba, vector1 );

            for (KeyPoint t : vector1)
                Core.circle(mRgba, t.pt, 10, new Scalar(100, 100,100));    

          //-- Step 2: Calculate descriptors (feature vectors)
            //extractor.compute(mRgba, vector1, descriptor1);

          //-- Draw matches
            //Mat img_matches;
            //drawMatches( mRgba, vector1, mRgba, vector1, matches, img_matches );


            }catch(Exception e){
                Log.e( "ERROR", e.toString());

            }

Maar de berekening is nog steeds veel te traag, dus ik moet een andere methode vinden om de quallantie van de inputvideostream te verminderen. Of als je een andere methode kent om het te versnellen, voel je vrij om het met mij te delen;)

Thanks for your time & answers

17

toegevoegd 27 oktober 2011 op 01:32 de auteur Csabi

Bekeken: 62

de bron

@Csabi En wat voor beperkingen heb je het?

toegevoegd 21 augustus 2013 op 04:20, de auteur Shubhadeep Chaudhuri, de bron

@Csabi Kon je het versnellen? Ik heb hetzelfde probleem.

toegevoegd 20 augustus 2013 op 03:26, de auteur Shubhadeep Chaudhuri, de bron

@Csabi Oké, hoe zit het met de nauwkeurigheid. Is het vergelijkbaar met SURF? En over hoeveel frame rate krijg je?

toegevoegd 20 augustus 2013 op 03:34, de auteur Shubhadeep Chaudhuri, de bron

Heb je geprofileerd met profileren? Ik denk dat native calls van davlik behoorlijk duur zijn. Het is ook erg duur om toegang te krijgen tot het mmvormige geheugen dat is toegewezen aan de camera-applicatie

toegevoegd 03 november 2011 op 02:07, de auteur Konstantin Pribluda, de bron

Ik stel niet dat het deffault is, maar ik kan niet weten hoe ik het moet instellen, of wat een optimale waarde is voor preformance/visie

toegevoegd 27 oktober 2011 op 02:12, de auteur Csabi, de bron

@TimeManx de beperkingen zijn bijvoorbeeld het schaalbewustzijn en de aanspraak op, ik krijg bijna 10 keer zoveel frames als bij surfen. Maar je moet het proberen in je project

toegevoegd 21 augustus 2013 op 11:08, de auteur Csabi, de bron

@TimeManx Ik gebruik orb, met een grotere database van voorbeeldafbeeldingen, het is veel sneller, maar het heeft zijn eigen beperking, ik kon Surf niet versnellen

toegevoegd 20 augustus 2013 op 01:53, de auteur Csabi, de bron

Ik begrijp je vraag niet echt, maar het antwoord is dat liever niet.

toegevoegd 03 november 2011 op 03:02, de auteur Csabi, de bron

Maar als je output video FPS wilt is het 1 frame per 4-5 seconden dus het is vreselijk

toegevoegd 27 oktober 2011 op 02:32, de auteur Csabi, de bron

welk apparaat gebruik je voor de tests?

toegevoegd 04 november 2011 op 04:13, de auteur MobileCushion, de bron

ja, maar wat is het?

toegevoegd 27 oktober 2011 op 02:21, de auteur MobileCushion, de bron

wat is je framerate?

toegevoegd 27 oktober 2011 op 02:06, de auteur MobileCushion, de bron

2 antwoord

Maar de berekening is nog steeds veel te langzaam, dus ik moet een andere vinden methode om de quallantie van de inputvideostream te verminderen.

Het echte antwoord op deze vraag ligt veel dichter bij "er is niet veel dat je kunt doen!" dan naar iets anders. We moeten erkennen dat mobiele telefoons nog geen krachtige verwerkingscapaciteiten hebben zoals elke desktop. De meeste Android-telefoons ter wereld gebruiken nog steeds eerdere versies van het systeem en het allerbelangrijkste: het zijn single-core apparaten, ze worden geklokt met snelheden lager dan 1 GHz, ze hebben een beperkt geheugen, bla bla ...

Toch is er altijd iets dat u kunt doen om de snelheid te verbeteren met kleine veranderingen in de prestaties.

Nu ben ik ook bezig met het berekenen van OpenCV SURF op de GalaxyS en ik heb een framesnelheid van 1,5 fps voor 200 functies met een hessische drempelwaarde van 1500 in een 320x240-afbeelding. Ik geef toe dat het waardeloze prestaties zijn, maar in mijn geval hoef ik alleen maar af en toe functies te berekenen, omdat ik de optische flow meet voor trackingdoeleinden. Het is echter heel raar dat je maar om de 4-5 seconden maar 1 frame kunt krijgen.

1) Ten eerste lijkt het mij dat u VideoCapture gebruikt om de cameraframes te verkrijgen. Nou, dat ben ik niet. Ik gebruik de Android-camera-implementatie. Ik heb niet gecontroleerd hoe VideoCapture is geïmplementeerd in de Java-poort van OpenCV, maar het lijkt trager te zijn dan de implementatie in sommige handleidingen te gebruiken. Ik kan hier echter niet 100% zeker van zijn, omdat ik het niet heb getest. Heb jij?

2) Verlaag native calls naar het minimaal mogelijke. Java OpenCV native calls zijn tijdrovend. Volg ook alle richtlijnen op de Android-OpenCV best practices-pagina . Als u meerdere native calls hebt, voegt u ze allemaal bij elkaar in één JNI-aanroep.

3) U moet ook de afbeeldingsgrootte verkleinen en de drempelwaarde voor SURF Hessiaan verhogen. Dit zal echter het aantal gedetecteerde functies verminderen, maar ze zullen sterker en robuuster zijn met het oog op herkenning en matching. Je hebt gelijk als je zegt dat de SURF de robuustere detector is (hij is ook de langzaamste, en hij is gepatenteerd). Maar als dit geen doodslot voor u is, zou ik aanraden om de nieuwe ORB-detector te gebruiken, een variant van KORTE die beter presteert op het gebied van rotatie. ORB heeft echter nadelen, zoals het beperkte aantal gedetecteerde keypoints en slechte schaalinvariantie. Dit is een zeer interessant vergelijkingsrapport voor functiedetectoralgoritmen. Het suggereert ook dat de SURF-detector trager is in de nieuwe OpenCV 2.3.1-versie, waarschijnlijk als gevolg van enkele wijzigingen in het algoritme, voor meer robuustheid.

4) Now the fun bits. The ARM processor architecture (in which most of the Android phones are based) has been widely reported for its slowness handling floating point calculations, in which feature detector algorithms rely heavily. There have been very interesting discussions about this issue, and many say you should use fixed-point calculations whenever possible. The new armv7-neon architecture provides faster floating point calculations, but not all devices support it. To check if your device does support it, run adb shell cat proc/cpuinfo. You can also compile your native code with NEON directives (LOCAL_ARM_NEON := true) but I doubt this will do any good, since apparently few OpenCV routines are NEON optimized. So, the only way to increase speed with this, is to rebuild the code with NEON intrinsics (this is completely unexplored ground for me, but you might find it worth looking). In the android.opencv group it was suggested that future OpenCV releases will have more NEON-optimized libraries. This could be interesting, however I am not sure if it is worth working on it or wait for faster CPUs and optimized systems using GPU computing. Note that Android systems < 3.0 do not use built-in hardware acceleration.

5) Als je dit voor academische doeleinden doet, overtuig dan je universiteit om een beter apparaat voor je te kopen ^^. Dit zou uiteindelijk de beste optie kunnen zijn voor snellere detectie van SURF-functies. Een andere optie is om de algoritmen te herschrijven. Ik ben me ervan bewust dat sommige jongens in de Intel-labs het hebben gedaan, met enig succes, maar ze zullen het duidelijk niet delen. Eerlijk gezegd, nadat ik dit probleem enkele weken had onderzocht, besefte ik dat voor mijn specifieke behoeften (en aangezien ik geen computerwetenschappelijk ingenieur ben, noch een algoritmen-expert) er meer waarde is om een paar maanden te wachten op betere apparaten dan met mijn hoofd te bonzen op de muur die de algoritmes ontleedt en bijna-assemblagecode ontwikkelt.

Met vriendelijke groeten en veel geluk!

36

toegevoegd 05 november 2011 op 03:41 de auteur MobileCushion

de bron

Welkom bij 2015, waar we apparaten hebben met maximaal 8 kernen

toegevoegd 17 april 2015 op 09:17, de auteur Dmitry Zaytsev, de bron

@DmitryZaitsev En toch, WarpPerspective van OpenCV kost ~ 250ms voor het kromtrekken van een afbeelding op een bestemmingsgrootte van 920x720 voor mij, op een Snapdragon 800 quad core 2,3 GHz met 2 GB RAM. Zie: stackoverflow.com/questions/32880842/&ellicle;

toegevoegd 08 oktober 2015 op 07:32, de auteur bad_keypoints, de bron

Meer interessant inzicht over deze onderwerpen door Ievgen Khvedchenia: computer-vision-talks .com/2012/04/reader-vragen-1

toegevoegd 11 mei 2012 op 12:05, de auteur MobileCushion, de bron

Ik ervaar ook een zeer trage framerate met een aantal van de OpenCV-functies die hoeken op leeuwenbek detecteren. Ik ben van plan een poging te wagen voor FastCV . Heeft iemand hier wat opmerkingen over FastCV?

toegevoegd 05 oktober 2016 op 12:34, de auteur jairobjunior, de bron

@jairobjunior Ja. Ik heb geprobeerd het te gebruiken en het is eerlijk gezegd een zeer moeilijk hulpmiddel om te gebruiken - de documentatie is uiterst beperkt. Bovendien wordt vanaf versie 1.7.1 slechts één ML api verstrekt; de SVM-classificatie.

toegevoegd 09 januari 2017 op 12:06, de auteur Rishabh Bhardwaj, de bron

de auteur Chris · Answer 1 · 2011-11-02T08:27Z

Moet u de SURF-functie/descriptor voor uw toepassing gebruiken? SURF is aantrekkelijk omdat het erg mooi aansluit, maar zoals je hebt gemerkt, is het enigszins traag. Als u alleen maar punten bijhoudt via een video, kunt u ervan uitgaan dat de punten niet veel frame-to-frame zullen verschillen en dat u dus Harris/FAST-hoeken kunt detecteren en matchen en dan kunt filteren om alleen geldig te zijn als ze binnen zijn een x-pixelradius van het oorspronkelijke punt?

OpenCV heeft een (hoewel enigszins beperkte) selectie van functiedetectors en descriptor extractors en descriptor matchers , het zou de moeite waard zijn om de opties te onderzoeken als je dat nog niet gedaan hebt.