Perché le convoluzioni usano sempre i numeri dispari come filter_size

Se diamo uno sguardo al 90-99% dei lavori pubblicati utilizzando una CNN (ConvNet). La stragrande maggioranza di essi utilizza le dimensioni del filtro per i numeri dispari : {1, 3, 5, 7} per i più utilizzati.

Questa situazione può comportare alcuni problemi: con queste dimensioni di filtro, di solito l'operazione di convoluzione non è perfetta con un'imbottitura di 2 (imbottitura comune) e alcuni bordi del campo di input si perdono nel processo ...

Domanda 1: Perché usare solo odd_numbers per le dimensioni del filtro di convoluzioni?

Domanda2: In realtà è un problema omettere una piccola parte di input_field durante la convoluzione? Perché così / no?

L'operazione di convoluzione, per dirla in parole povere, è una combinazione del prodotto saggio di due matrici. Finché queste due matrici concordano nelle dimensioni, non dovrebbe esserci un problema e quindi posso capire la motivazione alla base della tua domanda.

A.1. Tuttavia, l'intento della convoluzione è codificare la matrice di dati di origine (intera immagine) in termini di filtro o kernel. Più specificamente, stiamo cercando di codificare i pixel nelle vicinanze dei pixel di ancoraggio / sorgente. Dai un'occhiata alla figura seguente: In genere, consideriamo ogni pixel dell'immagine sorgente come pixel di ancoraggio / sorgente, ma non siamo obbligati a farlo. In effetti, non è raro includere un passo, dove in noi i pixel di ancoraggio / sorgente sono separati da un numero specifico di pixel.

Okay, quindi qual è il pixel sorgente? È il punto di ancoraggio in cui è centrato il kernel e stiamo codificando tutti i pixel adiacenti, incluso il pixel di ancoraggio / sorgente. Poiché il kernel ha una forma simmetrica (non simmetrica nei valori del kernel), esiste un numero uguale (n) di pixel su tutti i lati (4- connettività) del pixel di ancoraggio. Pertanto, qualunque sia questo numero di pixel, la lunghezza di ciascun lato del nostro kernel di forma simmetrica è 2 * n + 1 (ogni lato dell'ancora + il pixel di ancoraggio), e quindi i filtri / kernel hanno sempre dimensioni dispari.

E se decidessimo di rompere con la "tradizione" e di usare kernel asimmetrici? Subiresti errori di aliasing e quindi non lo facciamo. Consideriamo il pixel come l'entità più piccola, ovvero qui non esiste un concetto di sub-pixel.

A.2 Il problema al contorno viene affrontato usando approcci diversi: alcuni lo ignorano, altri zero lo bloccano, altri lo rispecchiano. Se non hai intenzione di calcolare un'operazione inversa, vale a dire la deconvoluzione, e non sei interessato alla ricostruzione perfetta dell'immagine originale, allora non ti interessa né la perdita di informazioni né l'iniezione di rumore a causa del problema di confine. In genere, l'operazione di pooling (pool medio o pool massimo) rimuoverà comunque i tuoi artefatti di confine. Quindi, sentiti libero di ignorare parte del tuo "campo di input", l'operazione di pooling lo farà per te.

-

Zen di convoluzione:

Nel dominio di elaborazione del segnale della vecchia scuola, quando un segnale di ingresso era contorto o passato attraverso un filtro, non c'era modo di giudicare in precedenza quali componenti della risposta convoluta / filtrata fossero rilevanti / informativi e quali no. Di conseguenza, l'obiettivo era preservare i componenti del segnale (tutti) in queste trasformazioni.

Questi componenti del segnale sono informazioni. Alcuni componenti sono più informativi di altri. L'unica ragione di ciò è che siamo interessati ad estrarre informazioni di livello superiore; Informazioni pertinenti ad alcune classi semantiche. Di conseguenza, i componenti del segnale che non forniscono le informazioni a cui siamo specificamente interessati possono essere eliminati. Pertanto, a differenza dei dogmi della vecchia scuola sulla convoluzione / filtro, siamo liberi di raggruppare / potare la risposta di convoluzione come ci sentiamo. Il modo in cui abbiamo voglia di farlo è quello di rimuovere rigorosamente tutti i componenti di dati che non stanno contribuendo a migliorare il nostro modello statistico.

1) Supponiamo che input_fieldsia tutto zero tranne una voce all'indice idx. Una dimensione del filtro dispari restituirà i dati con un picco centrato intorno idx, una dimensione del filtro uniforme no - considera il caso di un filtro uniforme con dimensione 2. La maggior parte delle persone desidera preservare le posizioni dei picchi quando filtrano.

2) Tutto ciò input_fieldè rilevante per la convoluzione, ma i bordi di output_fieldnon possono essere calcolati accuratamente poiché i dati necessari non sono contenuti in input_field. Se voglio calcolare una risposta per il primo elemento di output_field, il filtro deve essere centrato sul primo elemento di input_field. Ma poi ci sono elementi filtro che non corrispondono a nessun elemento disponibile di input_field. Esistono vari trucchi per indovinare i bordi output_field.

Per un filtro di dimensioni dispari, tutti i pixel del livello precedente sarebbero simmetricamente attorno al pixel di output. Senza questa simmetria, dovremo tenere conto delle distorsioni tra i livelli che si verificano quando si utilizza un kernel di dimensioni pari. Pertanto, i filtri del kernel di dimensioni pari vengono per lo più ignorati per promuovere la semplicità di implementazione. Se si considera la convoluzione come un'interpolazione da un dato pixel a un pixel centrale, non possiamo interpolare un pixel centrale usando un filtro di dimensioni pari.

fonte: https://towardsdatascience.com/deciding-optimal-filter-size-for-cnns-d6f7b56f9363