Logcompressie

[ukster]

Een voordeel van Logaritmische schermweergave ten opzichte van lineaire schermweergave van een powerspectrum (bestaande uit zeer grote en zeer kleine vermogenswaarden) is dat dat de kleinere waarden als het ware worden uitvergroot ten opzichte van de grote waarden (scaling). Hierdoor kan een powerspectrum beter worden geïnterpreteerd.
Uiteraard is dit alles geautomatiseerd maar waar het mij nu even om gaat is het theoretisch verloop van een lineair- naar log omzetting in een geheugenregister.
voorbeeld: De decimale waarde 1686,875 [Watt] uit een powerspectrum wordt in gewogen binaire 8-4-2-1 code in een 16 bits breed register geplaatst. (hieronder in te vullen)

16 bits 5030 keer bekeken

Vervolgens wordt dit vermogen omgezet naar power[in dB] in het binaire stelsel. voor zo’n binaire logaritmische compressie zijn bijvoorbeeld 8 bits beschikbaar. De plaats van de komma moet nog nader worden bepaald.

8 bits 5030 keer bekeken

Vraag: wat is de inhoud van het 8-bits register waarbij het vermogen in [dB] wordt weergegeven.
Werkwijze

logcompressie

(122.26 KiB) 130 keer gedownload

Ik zou wel eens willen weten of dit als een 'werkzame' procedure wordt ervaren.

[Benm]

De simpelste implementatie is domweg 'bit skipping' waarbij je een 16 bits waarde reduceert naar een 8 bits waarde om en om 1 bit te behouden, en 1 bit te negeren. Je zou dan bijvoorbeeld krijgen:

0010 0011 1010 0011
naar
01 01 11 01

uiteraard verlies je daarbij de nodige informatie, maar je behoud relatief meer van de minst significantie bits dan het simpelweg te trunceren tot de 8 meest significantie. De reconstructie volgens deze methode zou zijn

01 01 11 01
naar (met zero-padding)
0010 0010 1010 0010

Dit is natuurlijk wel de botste methode om dit te doen, als het gaat om een reeks samples (bijvoorbeeld een geluidsfragment, helderheidswaarde van pixels of iets dergelijks) kun je middels dithering betere resultaten verkrijgen door de fout te 'verdelen' over opeenvolgende samples.

Een iets minder botte maar wel snelle methode zou eventueel nog iets met een carry kunnen zijn, als je bijvoorbeeld hebt:

0101 0000 0000 0000

zou domweg 'bit skippen' dit reduceren tot

00 00 00 00 - absoluut ongewenst.

Als je de eerste 0101 echter behandeld als 'kluitjes' van 2 bits dan heb je

0101 dat splitst in 01 en 01, maar van de eerste 01 neem je het missen van de eerste 1 mee naar het volgende bit en krijg je 00 10 00 00 - aanzienlijk dichter bij de werkelijkheid, en dat is hoe de eenvoudigste systemen zoiets doen.



Overigens zie je dit niet zo vaak meer in moderne systemen die het aanzienlijk slimmer kunnen aanpakken, maar het was wel hoe men bijvoorbeeld 24-bit RGB pixels van 8 bits per kanaal naar 5 bits per kanaal omzette - en dan 6 bits voor het groene kanaal omdat je die extra bit bij 16 bits toch nog over had en dat visueel het meeste impact maakte.

Praktisch gezien is het allemaal geschiedenis, maar voor bijvoorbeeld audio die van 16 naar 8 bits per kanaal moest worden omgezet door bandbreedte/opslag beperking werkte dat wel zo en was het resultaat aanzienlijk beter dan domweg 'weggooien' van de minst significante bits.

[ukster]

Is dit niet net even anders dan ‘gewoon’ logaritmisch comprimeren?
Met deze methode wordt een vermogen (in Watt) opgeslagen in een n-bits breed register binair geconverteerd naar praktisch hetzelfde vermogen (maar nu in dB) in een register met (veel) minder bits volgens de definitie:

Logcompressie 4928 keer bekeken

Overigens vind ik dit wel een mooi voorbeeld van de kracht en de efficiëntie van enkele simpele registerbewerkingen (load/schift/sum etc.), waarmee de beoogde logcompressie uit het voorbeeld wordt gerealiseerd met 50% bit reductie met slechts een afwijking van 0,77dB. Als er voor de compressie 10 bits beschikbaar zijn, is de fout ongeveer 0,4dB

[Xilvo]

@Benm

Ik begrijp niet wat het doel is van 'bit-skipping'.
Als het doel is met minder bits een waarde te benaderen, dan lijkt het me het meest logisch om alleen de meest significante bits te behouden, en niet minder significante bits behouden ten koste van meer significante.

Maar misschien begrijp ik de methode en/of het doel niet

[Benm]

Laat ik het bij een praktisch voorbeeld houden: een stuk muziek met luide en stille passages, gesampled op 16 bit.

Je kunt dat omzetten daar 8 bit door domweg de 8 minst significante bits weg te gooien. Daarmee reduceer je het dynamisch bereik van 96 naar 48 decibel. Bij een luide passage is er niets aan de hand, maar bij een passage die pakweg 40 decibel onder het maximum zit houdt je dan nog ~2 bits informatie per sample over - onvoldoende om een herkenbaar geluid uit te reproduceren.

Ga je voor bit skipping (met carry) dan houdt je 4 bits per sample over - ook niet royaal, maar genoeg om pakweg spraak (met enige moeite) te kunnen verstaan.

Als je samplerate hoog genoeg is kun je ook nog wat doen met dithering, als je daarmee de fout middelt over 16 samples win je nog 2 bits extra in het amplitudedomein (en verlies je die in het tijdsdomein) en kom je al richting 6 bruikbare bits, wat genoeg is voor een goed verstaanbaar gesprek.

En het is inderdaad 'gewoon' logaritmisch comprimeren, zij het met base-2, niet met base-e wat wellicht een beter resultaat zou opleveren maar floating point berekeningen vereist en dergelijke.

Uiteraard gebruikt men dit niet/nauwelijks meer en heb je voor audio gewoon >>10:1 compressie die vrijwel transparant is dankzij psycho-akoestische modellen die wel allemaal wel kennen van MP3 bestanden en de opvolgers daarvan.

Maar als je het echt realtime wilt doen, met alleen simpele AND/NAND/OR/XOR gates, dan is logaritmisch resampelen met een beetje slimme inrichting bruikbaar.

[Xilvo]

Bedankt voor de uitleg.
Ik zie het graag in werking maar hoe die carry precies in z'n werk gaat is me nog niet helemaal duidelijk.
Simpele bitskipping komt er op neer dat je het binaire getal in groepjes van twee bits opdeelt waarvan je steeds het eerste (of steeds het tweede, maakt voor het principe niet uit) weggooit.

Bij bitskipping met carry "doe je nog wat" met dat weggegooide bit. Maar wat is de regel precies?

[Benm]

Stel even dat je aan de andere kant terug van 8 naar 16 bits gaat door steeds 1 bit te nemen, een nul, het volgende bit etc, dus van zeg 1101 naar 10 10 00 10:

Bij de compressie behandel je steeds 2 bits tegelijk op 1 output bit te maken. Telkens 4 opties:

00 -> output 0, carry 0
01 -> output 0, carry 1
10 -> output 1, carry 0
11 -> output 1, carry 1

Bij het volgende bit neem je de carry mee - is deze 1 dan is dat bit sowieso 1, ook al was het 00 of 01. Was het 10 of 11 dan neem je bij het volgende bit weer carry 1 over tot je bij het minst significante bit bent gekomen.

Op die manier compenseer je de fout deels door 'te laag afgeronde' waardes door de schuiven naar het volgende bit waardoor ze nog voor de helft worden goedgemaakt.

[Xilvo]

Bedoel je dat dit de waarheidstabel is?

c b b u cu
0 0 0 0 0
0 0 1 0 1
0 1 0 1 0
0 1 1 1 1
1 0 0 1 0
1 0 1 1 0
1 1 0 1 1
1 1 1 1 1

Editor weigert meer dan één spatie, dus ik kon de cijfers niet verder uit elkaar plaatsen.
Achtereenvolgens zijn het carry-in, bit0, bit1 (het tweetal bits), uit, carry-uit.

[Benm]

Volgens mij klopt dat zo inderdaad!

[Xilvo]

Dit is wat ik eruit krijg (12 bit, getallen 0...4095).
Ongewijzigd, 6 LS bits weggehaald, bitskip, bitskip met carry.

[Benm]

Misschien heb ik die carry dan toch niet helemaal goed onthouden - het is een tijd geleden dat ik er iets mee gedaan heb. Ergens staat me er bij dat er 2 carry bits waren, eentje zoals beschreven en eentje om te corrigeren voor een fout de andere kant op (dat hier ontbreekt waardoor je blijkbaar 'plateaus' in de output krijgt die daar niet thuishoren.

Wat krijg je eruit als je het hele carry gebeuren weglaat, maar wel groepjes van 2 input bits behandeld, volgens:

00 -> 0
01 -> 1
10 -> 1
11 -> 1

?

[Xilvo]

Dat levert dit op:

Als je de methode nog kunt achterhalen, graag.
Niet dat ik 'm wil gebruiken, maar gewoon uit nieuwsgierigheid.

Ik heb even kort op "bit skipping" gegoogeld maar dat leverde niets op.

[Benm]

Doe je dit wel goed?

Ik zie voor inputs > 2048 een aantal outputs die 0 zijn.

Aangezien die qua MSB beginnen met 10 of 11 zou het MSB van de output ook 1 moeten zijn en die getallen dus minstens 32 in dit voorbeeld.

[Xilvo]

Doe je dit wel goed?

Nee
Dit zou 'm moeten zijn:

[CoenCo]

Doe je dit wel goed?

Nee
Dit zou 'm moeten zijn:
Bitskip2.jpg

Ga je van MSB naar LSB, of van LSB naar MSB?
En wat gebeurt er als je de andere kant op gaat?