2015-04-13 10 views
5

Quindi mi rendo conto che potrei chiedere molto su una versione non finita di opencv, ma sto avendo strani problemi con il metodo cvtColor che non riesco a trovare altri riferimenti a persone che hanno altrove. Per prima cosa, come ho già detto, sto scrivendo un'applicazione gui multithread che usa PyQt4, QThreads, Python 2.7 e opencv sul beaglebone black. La mia attuale fonte può essere trovata su github HERE. Inizialmente utilizzavo la versione debian di OPEN, ma risultò così obsoleto che non aveva alcune delle funzionalità che stavo cercando, ovvero la classe simpleblobdetector, ed era estremamente lento. Con questo in mente, ho compilato l'ultima opencv 3.0.0 da zero e da allora si è comportato in modo strano. Alla fine ho ridotto a un problema con cvtColor. L'ho quindi semplificato per rendere minimo il codice per assicurarmi che non si trattasse di qualcos'altro che causava il problema. Ecco cosa ho che ho usato per i test.Python 2.7 e Opencv 3.0.0 cvtColor non funzionano per conversioni BGR/RGB

import cv2 

img = cv2.imread('images/original_image.png', cv2.IMREAD_COLOR) 

rgb_img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) 
gray_img = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) 
bgr_img = cv2.cvtColor(rgb_img, cv2.COLOR_RGB2BGR) 

cv2.imwrite("images/after_convert_to_rgb.png", rgb_img) 
cv2.imwrite("images/after_convert_to_gray.png", gray_img) 
cv2.imwrite("images/after_convert_back_to_bgr.png", bgr_img) 

Le immagini risultanti da questo codice può essere trovato HERE.

Inutile dire che sono perplesso a questo punto. Trovo particolarmente strano che la conversione in grigio funzioni perfettamente mentre gli altri due non funzionano affatto. Ho avuto un paio di miei amici che lavorano con opencv per controllare sia il mio codice originale che questo codice di test e non riesco a vedere nulla di sbagliato in esso. Inoltre, anche se non come parte di questo codice di prova, ho provato a leggere in diversi formati di file e immagini da una varietà di fonti. Fa anche la stessa cosa manipolare un frame opencv ricevuto dalla classe VideoCapture poiché è lì che ho visto per la prima volta il problema e cosa sto cercando di fare.

Quindi qualcuno ha visto qualcosa di simile prima in opencv 3.0? Sto meglio solo la compilazione personalizzata su opencv 2.4 e l'utilizzo invece? Avrei fatto ciò in primo luogo, ma stavo seguendo le guide su opencv di compilazione personalizzata per il beaglebone in particolare, e tutti usavano l'ultimo 3.0, quindi ho pensato che sarebbe andato bene. Ad ogni modo, ho pensato che sarebbe valso la pena di controllare prima di fare il processo di compilazione di nuovo, visto che tendeva a prendermi un paio di giorni per farlo bene nel farlo durante la notte.

MODIFICA: Nel caso in cui qualcun altro vada a cercare e voglia sapere cosa ho scoperto. È sicuramente un bug nella release candidate di opencv 3.0 che ho scaricato. Non sono stato in grado di trovare una correzione per quella versione e alla fine ho dovuto eseguire il downgrade alla versione 2.4.10. Dal downgrade, ora tutto funziona perfettamente.

+1

Sembra come un insetto. Penso che sia meglio inviare un bug report al tracker dei problemi di OpenCV: http://code.opencv.org – jet47

+0

Questo risulta essere un bug? – ypx

+0

Sì, si è verificato un errore per il quale non sono riuscito a trovare alcuna risposta, quindi alla fine ho dovuto ricompilare 2.4.10 e utilizzarlo. –

risposta

2

Anche se non è un "OpenCV-soluzione" si può solo riordinare i canali di colore utilizzando python puro come il CV2-Interface sta utilizzando NumPy-array per la memorizzazione di dati:

rgb_img = bgr_img[:,:,::-1] #bgr --> rgb 
bgr_img = rgb_img[:,:,::-1] #bgr --> rgb