I should rather think about dividing my program into processing part and visualization part?
Sì.
Non ho una buona risposta esauriente (cioè non penso di aver trovato una soluzione al problema), ma ecco il mio approccio.
Ho aggiunto "debug image listener interface" alle principali classi dell'algoritmo. L'interfaccia contiene un metodo che "riceverà" alcune immagini che vengono generate durante la normale esecuzione dell'algoritmo principale. L'implementatore di quella classe ascoltatrice deciderà cosa fare con quell'immagine, ad esempio salvandola.
La separazione di "punti di estensione" (l'interfaccia, che funge da callback o hook) e le implementazioni (le implementazioni del listener di immagini di debug, che sono responsabili del loro salvataggio su disco o analizzandole al volo) è ciò che consente la separazione del codice di produzione e del codice di sviluppo.
Questo è accettabile in C ++ perché, in C ++, gli handle di matrice OpenCV ( cv::Mat ) si comportano in modo simile ai riferimenti alle matrici sottostanti. Passare un handle per lo scopo di sola lettura non richiede una copia della memoria sottostante. Ciò significa che handle-passing è efficiente in termini di memoria.
Per casi d'uso più complicati, questo è quello che ho provato:
- Passa una stringa descrittiva insieme a ciascuna immagine. La stringa può descrivere il passo che genera quell'immagine intermedia.
- Passa una stringa che può essere utilizzata come nome file (cioè i caratteri della stringa descrittiva che non sono validi come caratteri del nome file sono stati eliminati)
- Aggiungi un secondo metodo all'interfaccia, che consente di interrogare se una particolare immagine intermedia debba essere salvata o meno.
- Converti tra immagini multi-canale e alta profondità (valore intero) tramite codice Morton, in modo che le matrici che non sono compatibili con PNG possano essere codificate in PNG.
Come puoi vedere, la registrazione di immagini 2D richiede un sacco di piccoli accorgimenti e sembra essere ben lungi dall'essere un problema risolto.
Infine, lo sviluppo dell'algoritmo delle immagini a volte richiede un sacco di R & D, che viene tipicamente svolto come progetto software separato (o "artefatto software" - sottoprodotti tangibili del processo di sviluppo del software). Questi artefatti valgono la pena di manutenzione. Senza questi artefatti, la fissazione di difetti a livello di algoritmo o miglioramenti a livello di algoritmo, o persino l'ottimizzazione dei parametri (al contrario dell'implementazione o dei difetti di codifica) può diventare impossibile.