As funções de compactação são práticas apenas porque "as cadeias de bits que ocorrem na prática estão longe de serem aleatórias"?


7

Eu teria feito um comentário, pois isso diz respeito à resposta de Andrej Bauer neste tópico ; no entanto, acredito que vale a pena fazer uma pergunta.

Andrej explica que, dado o conjunto de todas as seqüências de bits de comprimento 3 ou menos, uma função de compactação sem perdas pode apenas "compactar" algumas delas. Os outros, por exemplo, "01" precisariam ser compactados para uma sequência como "0001", com comprimento 4. A taxa de compactação é simplesmente a compactação média no conjunto de entrada.

Isso faz com que a compactação sem perdas pareça impraticável, mas a citação importante é a seguinte:

As cadeias de bits que ocorrem na prática estão longe de serem aleatórias e exibem muita regularidade.

É difícil acreditar que, por exemplo, os arquivos multimídia sejam representados por qualquer coisa que não sejam cadeias de bits aleatórias. Existe realmente um padrão que as funções de compactação utilizam para tornar o algoritmo útil na realidade?


3
Não sou especialista, mas definitivamente há muita regularidade nas coisas. Considere a figura de uma árvore; verde e marrom dominam a imagem. Como vemos muito esses valores, podemos compactá-los para valores menores. Em seguida, considere a idéia de compactação sem perdas, é bom demais para ser verdade. Algo tem que dar. É sobre isso que se fala aqui. Por fim, tente um experimento em que você gera seqüências aleatoriamente e veja qual é a média da taxa de compactação várias vezes. Se você fizer as coisas certas (o que pode ser difícil), não verá nenhuma vantagem geral real.
Jake

2
Além disso, mesmo que você tenha deliberadamente armazenado dados aleatórios como um arquivo multimídia, o próprio arquivo possui uma estrutura que é repetitiva e pode ser compactada - cabeçalhos, dados de quadros (para itens com quadros) e assim por diante.
Luke Mathieson

Respostas:


10

Antes de tudo, você está certo: os arquivos multimídia são representados (mais ou menos) como arquivos aleatórios. A razão para isso é que esses arquivos já estão compactados (com perdas). Observe que o mp3, por exemplo, não passa de um algoritmo de compressão!
Uma conseqüência é que a compactação adicional não produzirá nenhuma compactação perceptível (e, de fato, a compactação sem perdas em arquivos já compactados (multimídia) nunca foi um caminho para o sucesso).

Você também tem razão: a compactação sem perdas não pode ser comprimida em média. Para ver que, digamos, seu conjunto de dados possível consiste em elementos diferentes. Quantos bits você precisa por arquivo para poder sempre distinguir elementos do seu conjunto? Certo, . No total, todos os arquivos serão representados por nada menos que bits. Agora, se você representar alguns desses arquivos por menos de bits, alguns arquivos serão representados por mais de bits. É tudo o que há para dizer. 2nnn2nnn

Em resumo, a compactação sem perdas funciona porque os arquivos de texto estão longe de serem aleatórios (considere a distribuição das letras da minha resposta e compare o número de e 's com o número de z 's!) E comprima dados aleatórios (por exemplo, dados já compactados ou dados criptografados) não faz nenhum sentido.


Eu acho que você está misturando questões, um pouco. "Compactar arquivos multimídia nunca foi um caminho para o sucesso" - o LZ funciona em multimídia não compactada, como WAV ou TIFF? O LZ foi projetado para strings, ou seja, com certas suposições que podem ou não ser válidas para dados que não são de string.
Raphael

Certamente entendo seu ponto de vista quanto a arquivos de texto e distribuição de cartas. Coisas muito interessantes.
AlexMayle

@Raphael Você está certo, comprimir WAV ou TIFF deve produzir uma compressão perceptível. Eu incluí a palavra "compactado" na parte correspondente. Em relação ao seu outro ponto, sim, os algoritmos LZ foram definidos para seqüências de caracteres, mas, tanto quanto eu sei, o zip etc funciona para todos os dados binários.
31415 John -leo

Ok, mas mais um comentário: nem todas as compressões multimídia são com perdas. Por exemplo, FLAC e PNG são compactados significativamente sem perdas. Comparar ZIP com FLAC ou PNG (começando com WAV ou TIFF) pode ser educativo com relação ao impacto das suposições de design.
Raphael

@ Rafael, em vez disso, escolhi erradicar a referência a qualquer algoritmo de compactação real; descobri que falar de ZIP, FLAC ou O QUE NÃO é um assunto diferente.
31415 John -leo

9

Os dados multimídia estão muito longe de serem aleatórios, e é por isso que os compactam tão bem. Por exemplo, um único segundo de vídeo com resolução de 1920x1080 pixels, com cores de 24 bits e 24 quadros por segundo, representa cerca de 150 MB de dados descompactados. Os arquivos multimídia já foram compactados, por isso é difícil compactá-los ainda mais.

No entanto, mesmo dados multimídia não compactados provavelmente parecerão bem aleatórios se você considerar apenas um fluxo de zeros e uns. (Dito isso, os GIFs são compactados usando o LZW, tratando-os essencialmente como um fluxo de bits; que funciona decentemente bem.) Quando você olha para os dados de multimídia sabendo o que isso significa, há muita estrutura.

  • As imagens têm muitos gradientes de cores e blocos de cores semelhantes. O JPEG usa algo parecido com isto.
  • No vídeo, quase todos os quadros se parecem muito com o quadro imediatamente anterior, com algumas partes movendo-se um pouco. O MPEG usa isso extensivamente.
  • Muitos dos sons nos interessam são formas de onda de objetos ressonantes, não frequências aleatórias.

Mencionei JPEG e MPEG, que são, obviamente, com perdas. Mas suspeito que você possa usar essas idéias, em princípio, para produzir boas taxas de compactação sem perda desses dados não aleatórios. Duvido que alguém tente fazer isso, no entanto, já que o tempo necessário para comprimir seria provavelmente incrivelmente grande.


Alguns bons exemplos aqui.
AlexMayle

1920 * 1080 * 24 * 24 são 1,11 Gb de dados não compactados. 150Mb é suficiente para escala de cinza de 320x480. @ 1fps.
FROB

@FRob Bytes, não bits. Corrigi "Mb" para "MB".
David Richerby

11
Em relação ao último parágrafo: algo como isso é realmente feito. Existem codecs de áudio sem perdas que são baseados em um fluxo usando um algoritmo de compactação com perdas mais a diferença disso para o original compactado de maneira convencional.
Carsten S

3

Sim, a compactação sem perdas aproveita o fato de muitos arquivos não serem aleatórios. Sim, a maioria dos arquivos multimídia não é aleatória.

As imagens de fax são um bom exemplo desse efeito. Em sua forma mais simples, uma imagem de fax é uma imagem em preto-e-branco em 2-D, obtida pela digitalização de uma única página de algum documento. Se você representar esta imagem como uma sequência de bits, um bit por pixel (0 = branco, 1 = preto), descobrirá que os dados binários resultantes não são de todo aleatórios. Por exemplo, aqui estão alguns padrões não aleatórios que você encontrará:

  • Normalmente, as imagens de fax têm muito mais pixels brancos do que pixels pretos.

  • Além disso, é mais provável que cada pixel tenha a mesma cor do pixel à esquerda do que uma cor diferente.

  • Para um padrão mais sofisticado: imagine digitalizar pixels horizontalmente, da esquerda para a direita, e contando o comprimento de cada "execução" de pixels consecutivos da mesma cor. Em seguida, execuções longas são mais comuns que execuções curtas, e execuções longas de pixels brancos são mais comuns que execuções longas de pixels pretos.

Os algoritmos de compactação de fax foram projetados para aproveitar esses aspectos não aleatórios. Os algoritmos iniciais de compactação de fax são um exemplo particularmente bom, porque são esquemas simples de compactação sem perdas que exploram diretamente essas propriedades não aleatórias das imagens digitalizadas.

Por exemplo, um esquema anterior para compactar imagens de fax usava a codificação de execução combinada com a codificação Huffman . A codificação de duração da execução substitui cada execução de pixels da mesma cor por um único número inteiro contando a duração da execução. Por exemplo, 00000110001 se torna "5 2 3 1". A codificação de execução explora o fato de que os pixels tendem a ocorrer em execuções da mesma cor. A codificação Huffman explora ainda mais o fato de que algumas durações são mais comuns que outras. Veja aqui um exemplo detalhado de como um desses primeiros esquemas funcionou - o esquema é simples e elegante e explora diretamente os padrões mencionados acima.

Esses esquemas não oferecem compactação, em média, para arquivos aleatórios. No entanto, as imagens de fax digitalizadas não são aleatórias e, como resultado, esses esquemas de compactação podem oferecer economias substanciais.

Comentários semelhantes se aplicam a outros arquivos multimídia. Os padrões presentes em outros tipos de arquivos multimídia podem ser mais complexos, mas ainda existem muitos padrões que tornam os dados não aleatórios.


0

Um arquivo de áudio aleatório constitui um tipo de ruído. A maioria das pessoas armazena arquivos de áudio com música ou fala, sem ruído.


2
Obrigado pela sua contribuição. Você poderia elaborar e adicionar alguns exemplos? A ideia que você deu é boa, verdadeira, mas já foi apresentada em 3 respostas anteriores.
Evil

@EvilJS, muito provavelmente verdade. Não acho que deva levar meia página para explicar que existe uma diferença entre fala e ruído.
Carsten S

Não deve demorar meia página para explicar os fatos mais importantes, para que sua resposta explique por que a fala e a música são compactadas, mas o ruído aleatório não.
David Richerby

@DavidRicherby, esses dados aleatórios não compactam já foram aceitos na pergunta. A pergunta era "mas os dados multimídia não são aleatórios?" para a qual a resposta é que obviamente não é.
Carsten S
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.