Come testare il codice di elaborazione delle immagini?

Sto lavorando all'elaborazione delle immagini (principalmente OCR) e mi chiedo come dovrei integrare i test unitari nel mio sviluppo.

Sto già utilizzando i test unitari per un tipo di codice più "comune", ma quando ho a che fare con il codice di elaborazione delle immagini non sono sicuro di come gestirlo. Questo tipo di codice necessita sempre di input / output di dati immagine e deridere ciò non è ovvio. Per ora sto facendo principalmente test di integrazione, ma impiegano un po 'di tempo per funzionare e vorrei alcune idee su come suddividere questo tipo di codice in test unitari in modo da poterli eseguire più rapidamente.

Modifica: L'analisi di un personaggio può passare attraverso molti passaggi che coinvolgono più operazioni di rotazione, ridimensionamento e morfologia. Questi passaggi cambiano spesso quando viene sviluppato l'algoritmo. Pertanto, l'input e l'output previsto possono evolvere molto durante i test. Ogni carattere può essere di 100x100 pixel, quindi è difficile codificarli nel codice o lavorare con i dati generati.

— rold2007
fonte

Puoi fare un esempio di una funzione in cui hai problemi a creare un test unitario?

— Doc Brown,

Troppo breve per una risposta reale e non un vero e proprio test unitario: stiamo elaborando i dati a mano (come in: passo attraverso un numero elevato di campioni - di solito vado oltre 1000 per tali compiti di classificazione, ma dipende dalla dimensione complessiva del campione ) e confrontando automaticamente i risultati finali con i dati elaborati a mano. Ho creato un piccolo framework per farlo, andrà open source tra poche settimane, ma questa è la descrizione - potresti clonare il processo: birgitplays.wordpress.com/2012/09/15/…

— Birgit P.

Per il tuo esempio, potresti facilmente testare la rotazione, il ridimensionamento ecc. Come piccole unità di test. La rotazione di una data immagine di 45 gradi non dovrebbe cambiare molto. Questo vale anche per le operazioni di ridimensionamento e morfologiche. È tuttavia difficile testare qualcosa in cui l'output previsto si evolve durante l'implementazione. Potresti provare a fare una misura della qualità e dire qualità> = some_quality. Per assicurarti che la tua qualità non sia degradante, ma potrebbe anche essere difficile. A parte questo, tutto ciò che puoi fare è avere dei test che dimostrano che le parti sottostanti non sono rotte. Come scala / ruota / ecc.

— martiert,

@martiert: non sto testando la rotazione, il ridimensionamento, ecc. mentre li chiamo da una terza libreria che credo sia ben testata. L'algoritmo OCR è composto da molte di queste operazioni. Ma come dici tu, testare qualcosa in cui un output si evolve è difficile. Forse è un buon avvertimento che non abbiamo

— altra

@Birgit P .: Soluzione interessante. Come dici tu, è ancora test di integrazione. Avere un framework come il tuo aiuterebbe a configurare questi test più velocemente ma non funzioneranno più velocemente ...

— rold2007

Lavoro con il software di registrazione video / analisi / streaming e abbiamo riscontrato un problema molto simile. Di seguito c'era la nostra soluzione, non sono sicuro di come funzionerà a lungo termine, ma per ora sembra funzionare.

Salvare le immagini di input / output come risorse nel progetto di unit test. Quindi fare in modo che il test unitario verifichi che quando viene fornito un input specifico, viene prodotto quell'output specifico.

9/10 volte quando si refactoring il codice e si aggiungono altre funzionalità, ci si aspetterebbe che il comportamento delle routine di gestione delle immagini non cambi, quindi se tutti i test di unità improvvisi iniziano a fallire, è probabilmente a causa di un errore.

D'altra parte, se si apportano modifiche all'algoritmo effettivo, ciò comporterà anche il fallimento del test unitario. In questo caso, è necessario verificare manualmente / visivamente che i risultati siano corretti e, se sembrano buoni, quindi aggiornare le risorse dell'immagine per ripetere il test unitario.

Nel nostro progetto, abbiamo finito per sviluppare fonti video "false" (o finte se vuoi), che possono fornirci dati sia per input che per output. Ma i dati in sé non sono falsi, in realtà sono stati acquisiti utilizzando classi di registrazione dei dati di supporto da un sistema in esecuzione quando abbiamo eseguito test manuali e verificato che tutto funzionasse.

— DXM
fonte

D'accordo, è OK fare affidamento su alcuni file concreti nei test quando si testano routine che funzionano con i file (lo si vede più spesso con i test di integrazione).

— Kemoda,

Se si esegue un input attraverso l'intera catena di elaborazione e quindi si controlla l'output, non si tratta di unit test ma di test di integrazione.

— tdammers,

@tdammers: non ho mai detto di eseguirlo attraverso l'intera catena. Esegui un input attraverso una "unità", non l'intera catena. E certo se l'output di questo è qualcosa di diverso dalle immagini, allora devi solo salvare l'input come risorse di immagine.

— DXM,

@DXM: capisco la tua soluzione ma penso che potremmo non avere gli stessi vincoli. I miei dati di input / output cambiano molto mentre viene sviluppato l'algoritmo. Come gestite questi cambiamenti regolari? In OCR posso avere oltre il 99% di precisione in modo da testare solo su un paio di immagini mi può dare una falsa sensazione di successo, mentre i test di integrazione mi potrebbero dire più tardi che ho effettivamente peggiorato l'algoritmo di ...

— rold2007