Pourquoi les circonvolutions utilisent toujours des nombres impairs comme filter_size

Si l'on regarde 90 à 99% des articles publiés à l'aide d'un CNN (ConvNet). La grande majorité d'entre eux utilise une taille de filtre de nombres impairs : {1, 3, 5, 7} pour les plus utilisés.

Cette situation peut entraîner un problème: avec ces tailles de filtre, généralement l'opération de convolution n'est pas parfaite avec un remplissage de 2 (remplissage commun) et certains bords du champ input_field se perdent dans le processus ...

Question 1: Pourquoi utiliser uniquement des nombres impairs pour les tailles de filtre à convolutions?

Question2: Est-ce réellement un problème d'omettre une petite partie du champ input_field pendant la convolution? Pourquoi oui / non?

L'opération de convolution, en termes simples, est une combinaison du produit élément par élément de deux matrices. Tant que ces deux matrices sont d'accord dans les dimensions, il ne devrait pas y avoir de problème, et je peux donc comprendre la motivation derrière votre requête.

A.1. Cependant, l'intention de la convolution est de coder la matrice de données source (image entière) en termes de filtre ou de noyau. Plus précisément, nous essayons de coder les pixels au voisinage des pixels d'ancrage / source. Jetez un œil à la figure ci-dessous: En règle générale, nous considérons chaque pixel de l'image source comme un point d'ancrage / pixel source, mais nous ne sommes pas obligés de le faire. En fait, il n'est pas rare d'inclure une foulée, dans laquelle les pixels d'ancrage / source sont séparés par un nombre spécifique de pixels.

D'accord, alors quel est le pixel source? C'est le point d'ancrage sur lequel le noyau est centré et nous encodons tous les pixels voisins, y compris le pixel d'ancrage / source. Puisque le noyau a une forme symétrique (pas symétrique dans les valeurs du noyau), il y a un nombre égal (n) de pixels de tous les côtés (4-connectivité) du pixel d'ancrage. Par conséquent, quel que soit ce nombre de pixels, la longueur de chaque côté de notre noyau de forme symétrique est de 2 * n + 1 (chaque côté de l'ancre + le pixel d'ancrage), et donc les filtres / noyaux sont toujours de taille impaire.

Et si nous décidions de rompre avec la «tradition» et d'utiliser des noyaux asymétriques? Vous subiriez des erreurs d'alias, et donc nous ne le faisons pas. Nous considérons que le pixel est la plus petite entité, c'est-à-dire qu'il n'y a pas de concept de sous-pixel ici.

A.2 Le problème des limites est traité en utilisant différentes approches: certains l'ignorent, certains le remplissent à zéro, certains le reflètent. Si vous n'allez pas calculer une opération inverse, c'est-à-dire la déconvolution, et que vous n'êtes pas intéressé par une reconstruction parfaite de l'image originale, alors vous ne vous souciez ni de la perte d'informations ni de l'injection de bruit en raison du problème de frontière. En règle générale, l'opération de regroupement (regroupement moyen ou regroupement maximal) supprimera de toute façon vos artefacts de limite. Alors, n'hésitez pas à ignorer une partie de votre «champ de saisie», votre opération de mise en commun le fera pour vous.

-

Zen de convolution:

Dans le domaine du traitement du signal à l'ancienne, lorsqu'un signal d'entrée était convolué ou traversait un filtre, il n'y avait aucun moyen de juger a-prioritaire quels composants de la réponse convoluée / filtrée étaient pertinents / informatifs et lesquels ne l'étaient pas. Par conséquent, l'objectif était de préserver les composantes du signal (toutes) dans ces transformations.

Ces composants de signal sont des informations. Certains composants sont plus informatifs que d'autres. La seule raison à cela est que nous souhaitons extraire des informations de niveau supérieur; Informations pertinentes pour certaines classes sémantiques. En conséquence, les composants de signal qui ne fournissent pas les informations qui nous intéressent spécifiquement peuvent être élagués. Par conséquent, contrairement aux dogmes de la vieille école sur la convolution / filtrage, nous sommes libres de regrouper / élaguer la réponse de convolution comme nous le souhaitons. La façon dont nous avons envie de le faire est de supprimer rigoureusement tous les composants de données qui ne contribuent pas à l'amélioration de notre modèle statistique.

1) Supposons que input_fieldtout est nul sauf une entrée à l'index idx. Une taille de filtre impaire renverra des données avec un pic centré autour idx, une taille de filtre uniforme ne le fera pas - considérons le cas d'un filtre uniforme de taille 2. La plupart des gens veulent conserver l'emplacement des pics lorsqu'ils filtrent.

2) Tout input_fieldest pertinent pour la convolution, mais les bords de output_fieldne peuvent pas être calculés avec précision car les données nécessaires ne sont pas contenues dans input_field. Si je veux calculer une réponse pour le premier élément de output_field, le filtre doit être centré sur le premier élément de input_field. Mais il y a ensuite des éléments de filtre qui ne correspondent à aucun élément disponible de input_field. Il existe différentes astuces pour deviner les bords de output_field.

Pour un filtre de taille impaire, tous les pixels du calque précédent seraient symétriquement autour du pixel de sortie. Sans cette symétrie, nous devrons tenir compte des distorsions entre les couches qui se produisent lors de l'utilisation d'un noyau de taille égale. Par conséquent, les filtres de noyau de taille égale sont généralement ignorés pour favoriser la simplicité de mise en œuvre. Si vous considérez la convolution comme une interpolation des pixels donnés vers un pixel central, nous ne pouvons pas interpoler vers un pixel central en utilisant un filtre de taille égale.

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