rilevamento contorno occupa la maggior parte del mio tempo nella mia visione del computer, e ha bisogno di essere più veloce. Ho così ottimizzato tutto il resto tramite le istruzioni NEON e vettorizzazione che in realtà, il rilevamento dei contorni domina il profilo. Sfortunatamente, non è ovvio per me come ottimizzare questo.Alternative più veloce per cvFindContour()
che sto facendo il classico processo di rilevamento rettangolo per trovare marker fiduciali, ovvero cvFindContours(), seguita da approssimando piazze dal contorni. Nei casi con molti, molti indicatori visibili (o catastroficamente, quando è visibile una griglia densa di rettangoli che non sono marcatori), la chiamata a cvFindContours() da sola può richiedere> 30ms su un iPhone.
ho già sostituito il incredibilmente costoso C++ cv :: FindContours() con cvFindContours(). Soprattutto se ha passato un vettore>, la versione C++ ha speso più a lungo l'allocazione e il popolamento dei vettori rispetto al suo interno cvFindContours()!
Ora, io sono legato completamente per il tempo in cvFindContours, o più specificamente in cvFindNextContour(). Il codice all'interno di cvFindNextContour è branch-heavy e non è ovviamente facile da vettorializzare. Implementa anche un algoritmo complesso che non mi fido di non sbagliare nel tentativo di ottimizzare.
Ho già visto cvBlobLib (per disambiguazione, intendo questo: http://code.google.com/p/cvblob/) per vedere se forniva algoritmi alternativi che potessero fare la stessa cosa più velocemente. Un download di base dell'origine è incredibilmente lento perché registra i contorni in uno std :: list() e trascorre quasi tutto il tempo nell'assegnazione della memoria. Sostituire quella lista con un vettore std :: vector da 256 elementi per eliminare le copie iniziali su push_back() ti lascia ancora con una funzione che richiede 3 volte più tempo di cvFindContours(), il 66% di quella direttamente in cvb :: cvLabel (). Quindi non sembra fattibile andare in questo modo.
Qualcuno ha qualche idea per come posso ottimizzare il rilevamento di molti rettangoli. La mia vaga handwaving comprende:
Esistono implementazioni veloci equivalente a cvFindContour(), idealmente come codice sorgente come sono multipiattaforma, là fuori?
La maggior parte dei contorni non sono tenuti, solo i rettangoli "successo" sono utili. In particolare, i loro contorni interni non sono quindi utili. In teoria, potrei non chiamare affatto cvFindContours e chiamare invece cvStartFindContours/cvFindNextContour, testare ogni contorno come trovato, e non ricorrere se trovo un rettangolo che sto cercando, poiché i subrectangle sono quindi garantiti come inutili?
Esiste un algoritmo di rilevamento rettangolo completamente diverso che posso utilizzare dal classico approccio FindContours()/ApproxPoly()?
c'è un modo per cvFindContours "prime" con le regioni utili di interesse? Per esempio. un rilevamento angolo FAST restituisce quasi sempre i miei angoli del fiducial marker anche con una soglia molto aggressiva. C'è un modo per usare quel punto impostato per limitare il rilevamento? (Sfortunatamente, non sono sicuro di quanto questo aiuti, anche nel caso di molti marcatori o griglie fitte non correlate ai marcatori, cosa che accade spesso nella mia app.)
Nella stessa vena di sopra, dal Il blob detection può (se ho capito bene) essere implementato come flood-filling ricorsivo, ci sono implementazioni vettoriali veloci di questo che possono essere usate per estrarre in qualche modo interessanti rettangoli di Blob e la rilevazione del contorno di semi da lì?
Tutte le idee sarebbero benvenute!
Solo un commento sul punto 5. Flood-riempimento non è normalmente il metodo più efficiente per la rilevazione blob. Piuttosto, si desidera utilizzare alghe a due passaggi o a un passaggio, alcuni dei quali sono parallelizzabili. La pagina di Wikipedia su "Connected components labeling" è un buon punto di partenza. –
Eventuali aggiornamenti qui? Nuove intuizioni? Ho un problema simile. – Antonvh