Signal filtré vs paradoxe de compression de fichiers

9

1. Situation d'origine

J'ai un signal original sous forme de colonne de données matricielles données ncanaux x:mxn (single), avec m=120019le nombre d'échantillons et n=15le nombre de canaux.

De plus, j'ai le signal filtré comme matrice de données de colonne filtrée x:mxn (single).

Les données d'origine sont principalement aléatoires, centrées sur zéro, provenant de capteurs de capteur.

Sous MATLAB, j'utilise savesans options, buttercomme filtre passe-haut, et singlepour le casting après filtrage.

saveappliquer essentiellement une compression GZIP de niveau 3 sur un format binaire HDF5, nous pourrions donc supposer que la taille du fichier est un bon estimateur du contenu de l'information , c'est-à-dire maximum pour un signal aléatoire, et proche de zéro pour un signal constant.

  • L'enregistrement du signal d'origine crée un fichier de 2 Mo ,

  • L'enregistrement du signal filtré crée un fichier de 5 Mo (?!).

2. Question

Comment est-il possible que le signal filtré ait une plus grande taille, étant donné que le signal filtré a moins d' informations, supprimé par le filtre?

3. Exemple simple

Un exemple simple:

n=120019; m=15;t=(0:n-1)'; 
x=single(randn(n,m));
[b,a]=butter(2,10/200,'high'); 
 xf=filter(b,a,x);
save('x','x'); save('xf','xf');

crée des fichiers de 6 Mo , à la fois pour le signal original et filtré, qui est plus grand que les valeurs précédentes en raison de l'utilisation de données aléatoires pures.

Dans un sens, cela indique que le signal filtré est plus aléatoire que le signal filtré (?!).

4. Exemple d'évaluation

Considérer ce qui suit:

  • Un filtre créé à partir d'un signal aléatoire partir du bruit gaussien , et d'un signal constant égal à .xrN(0,1)xc1
  • Ne tenez pas compte du type de données, c'est-à-dire utilisons uniquement double,
  • Ne tenez pas compte de la taille des données, c'est-à-dire utilisons un vecteur de données de colonne de 1 Mo, , .n=125000m=1
  • Permet de considérer l' paramètre que l' indice aléatoire pour tester: , ce qui signifie est totalement aléatoire et entièrement constant.ax=αxr+(1α)xcα=1α=0
  • Considérons un filtre Butterworth passe-haut avec .wn=0.5

Le code suivant:

%% Data
n=125000;m=1;
t=(0:n-1)';
[hb,ha]=butter(2,0.5,'high');
d=100;
a=logspace(-6,0,d);
xr=randn(n,m);xc=ones(n,m);
b=zeros(d,2);
for i=1:d
    x=a(i)*xr+(1-a(i))*xc;
    xf=filter(hb,ha,x);
    save('x1.mat','x'); save('x2.mat','xf');
    b1=dir('x1.mat'); b2=dir('x2.mat');
    b(i,1)=b1.bytes/1024;
    b(i,2)=b2.bytes/1024;
    i
end
%% Plot
semilogx(a,b);
title('Data Size for Filtered Signals');
legend({'original','filtered'},'location','southeast');
xlabel('Random Index \alpha');
ylabel('FIle Size [kB]');
grid on;

Avec comme résultat le graphique suivant: entrez la description de l'image ici

Cette simulation reproduit l'état du signal filtré ayant toujours une taille notoirement plus grande que le signal d'origine, ce qui contredit le fait qu'un signal filtré contient moins d' informations, supprimées par le filtre.

Brethlosze
la source
6
Je pense que votre question concerne plus l'algorithme de compression qu'autre chose. Enregistrez les deux fichiers avec l'option -nocompression puis allez vérifier les modèles de bits que vous générez sans le savoir. Je suppose que votre signal aléatoire contient en fait des répétitions importantes qui se compressent bien, contrairement à la version filtrée. Intéressant néanmoins :)
zeFrenchy
1
Sans compression, tous les signaux ont la même taille, 1 Mo, car la longueur et les types de données sont tous les mêmes. Je vais vérifier cependant. Je suppose aveuglément que la compression fonctionne comme information, donc je vais mettre un exemple d'évaluation supplémentaire pour vérifier cet aspect "information" ...
Brethlosze

Réponses:

5

+1 sur une expérience très intéressante et perspicace.

Quelques idées:

  1. Ce n'est pas vrai que le signal filtré a moins d'informations. Cela dépend de votre signal d'entrée, du type de filtre et de la fréquence de coupure.
    Lorsque vous laissez passer le signal bruyant, vous supprimez les composants qui changent lentement. Cela rend votre signal composé de «nombres aléatoires changeant plus fréquemment», donc plus aléatoire. Bien sûr, cela dépend si votre signal d'entrée contient des hautes fréquences ou non. Votre entrée est du bruit, contient donc toutes les hautes fréquences. Mais si votre entrée est un signal plus ordonné, elle perdra une grande partie de son énergie après une certaine fréquence de coupure HP, la sortie devient proche de zéro, moins aléatoire, moins de taille. Je pense que si vous augmentez la fréquence de coupure de votre filtre HP assez haut, après un certain point, la taille du fichier diminuera.
    Une autre expérience serait de faire passer le signal à travers un filtre LP avec une fréquence de coupure basse et de voir la différence.

  2. Sur la base de la même théorie en 1., vous passez votre signal passe-haut, supprimant essentiellement la partie DC xcet le laissant avec du bruit xr.

doubleE
la source
2
En théorie, votre 1. est au moins à moitié faux. Le signal filtré doit contenir moins (ou tout au plus, les mêmes) informations que le signal non filtré.
Marcus Müller
2
@ MarcusMüller Je suis définitivement d'accord avec vous sur cette (déclaration évidente) mais j'ai la préoccupation suivante: si vous aviez échangé les rôles de la réponse impulsionnelle du filtre et du signal aléatoire d'entrée (c'est-à-dire que la réponse impulsionnelle (déterministe) devient l'entrée du filtre avec une réponse impulsionnelle aléatoire maintenant) pourrait-on encore dire que les informations en sortie sont inférieures aux informations en entrée?
Fat32
1
@ Fat32 qui est un angle intéressant! Vrai point. Dans ce cas particulier, je dirais que si nous considérons le LPF comme le signal porteur d'informations, nous trouverions qu'il contient très peu d'informations (étant très corrélé, par conception, et plutôt court).
Marcus Müller
1
@ Fat32 c'est une bonne suggestion. Si je compresse le FT du signal, pour un cas sans perte, je dois quand même avoir la même taille! (sans tenir compte du fait que certaines parties du spectre pourraient conduire à des informations moins précieuses et faciles à éliminer). Sinon, nous aurions découvert un meilleur algorithme de compression, dont je doute sincèrement :). Je vais donc préparer un deuxième exemple d'évaluation avec cette approche.
Brethlosze
1
@ MarcusMüller Il ne peut pas être généralisé aussi simplement. Vous devez définir des choses pour rendre cette déclaration vraie. Supposons que vous ayez un système qui randomise son entrée. Lorsque l'entrée est CC, cela la rend aléatoire, donc votre sortie a plus d'entropie (ce n'est pas difficile d'imaginer que, juste un canal de communication qui ajoute du bruit à l'entrée le ferait.) Pour les systèmes LTI, nous savons comment ils traitent le bruit , c'est donc un sujet différent. La théorie de l'information ne base pas ses résultats sur la question de savoir si un système est LTI. Bien sûr, je ne suis pas un expert, mais je pense que ce n'est pas vrai.
doubleE
3

Je vérifierais 2 choses:

  1. Si le filtre appliqué est un filtre passe-bas ou un autre filtre. S'il s'agit d'un filtre qui amplifie le bruit, le résultat est raisonnable.
    Il semble que vous l'utilisiez butter()sous une forme qui génère un filtre passe-haut. Puisque le signal d'entrée est composé de bruit, le filtre passe-haut l'amplifie et provoque un fichier moins compressible. Par exemple, essayez [hb, ha] = butter(2, 0.5, 'low');où il devrait prendre en charge une meilleure compression des données (suppression du bruit). Si vous voulez aller encore plus loin [hb, ha] = butter(2, 0.1, 'low');.
  2. Vérifiez que la sortie de la commande de filtrage l'est singleégalement. Je pense que puisque votre filtre est doublela sortie est doubledonc la taille du signal est multipliée. Dans votre code, remplacez xf = filter(hb, ha, x);par xf = single(filter(hb, ha, x));. Quels résultats maintenant?
Royi
la source
1
@hyprfrcb, essayez la même chose avec butter(2, 0.5, 'low');. Que se passe-t-il alors?
Royi
1
Le problème est donc résolu. Vous utilisez un filtre passe-haut qui amplifie le bruit, d'où un fichier plus volumineux car le bruit est moins compressible. Profitez ...
Royi
1
Vous pouvez essayer [hb, ha] = butter(2, 0.1, 'low');de voir la taille du fichier devenir encore plus petite.
Royi
1
Le passe-haut appliqué sur le bruit détériore généralement le rapport signal / bruit dans un signal. C'est ce que vous avez fait ci-dessus. Le filtre passe-haut a amplifié l'énergie du bruit, ce qui signifie que les données sont moins compressibles.
Royi
1
Le signal aléatoire qui est filtré par un filtre LPF crée une corrélation entre ses échantillons, il est donc compressible à un niveau supérieur. Cela ne fonctionne pas avec HPF qui fonctionne sur un signal aléatoire.
Royi