DE3788763T2

DE3788763T2 - Arithmetische Codierung zur Datenkomprimierung-Dekomprimierung mittels selektiver Anwendung von verschiedenen arithmetischen Kodierern und Dekodierern.

Info

Publication number: DE3788763T2
Application number: DE3788763T
Authority: DE
Inventors: Verne Mitchell Joan La; William B Pennebaker
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1986-09-15
Filing date: 1987-08-18
Publication date: 1994-06-23
Anticipated expiration: 2007-08-19
Also published as: BR8704622A; EP0260462A2; AU7836787A; JPS6376524A; DE3788763D1; US4891643A; CA1292070C; AU598587B2; EP0260462B1; EP0260462A3; JPH0258812B2

Description

1. Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich auf Datenkomprimierung/Dekomprimierung mittels arithmetischer Codierung. Referenzen: EP-A-0 224 753 und EP-A-0 154 860.

2. Beschreibung der Problemstellung

Ein Verfahren zur Datenkomprimierung und -dekomprimierung ist als arithmetische Codierung bekannt. Eine allgemeine Erörterung der arithmetischen Codierung gibt der Artikel von G. Langdon, "An Introduction to Arithmetic Coding", IBM J. Res. Develop., Bd. 28, Nr. 2, Seiten 135-149 (März 1984).
Wie in dem Langdon-Artikel besprochen wird, bildet die arithmetische Codierung nacheinander codierte Entscheidungen auf einen Codepunkt auf einer Zahlengeraden ab. Die arithmetische Codierung kann auf Entscheidungen angewendet werden, die zwei oder mehr mögliche Ergebnisse (als "Ereignisse" bezeichnet) haben, wobei jedem Ergebnis einer gegebenen Entscheidung eine Wahrscheinlichkeit zugeordnet ist. Jedes Ergebnis wird in den Daten als entsprechendes "Symbol" dargestellt. Die Zahlengerade stellt ein Intervall dar, das in Segmente aufgeteilt ist, wobei jedes Segment zum Eintreten eines entsprechenden Symbols als Eingabe für einen Codierer gehört. Für eine Entscheidung mit vier möglichen Ergebnissen gäbe es vier Segmente, zum Beispiel die Segmente a, b, c und d. Die relative Länge eines jeden Segments würde die Wahrscheinlichkeit für das Auftreten des entsprechenden Ereignisses widerspiegeln. Wenn die Entscheidung zu einem "d"-Ereignis gehört, wird das "d"-Segment als aktuelles Intervall gewählt, das dann wiederum in Segmente a, b, c und d aufgeteilt wird. Auf diese Weise werden der Reihe nach kleinere, weniger eingeschlossene Intervalle auf einer Zahlengeraden abgeleitet. Es ist von Bedeutung, daß jedes Intervall durch eine eindeutige Folge von Ereignissen erreicht wird. Die Erzeugung eines Codeflusses, der als Antwort auf eine gegebene Sequenz von Entscheidungsereignissen auf ein bestimmtes Intervall einer Zahlengeraden zeigt, ist bei der arithmetischen Codierung als "Codieren" bekannt.
Aus einem bestimmten Intervall und mit Information hinsichtlich der Ordnung und jeweiligen Länge der Segmente eines jeden Intervalls kann eine dazugehörige Sequenz von Entscheidungsereignissen zurückgewonnen werden. Das Verfahren, das die arithmetische Codieren rückgängig macht, wird bei der arithmetischen Codierung als "Decodieren" bezeichnet.
Die binäre arithmetische Codierung ist ein Spezialfall, bei dem jede Entscheidung zu einem von zwei einander ausschließenden Ereignissen führt. In der binären Codierungsumgebung umfaßt eines der beiden Ereignisse ein Symbol kleinerer Wahrscheinlichkeit (LPS, less probable symbol), das eine Wahrscheinlichkeit Q hat, und das zweite Ereignis umfaßt ein Symbol größerer Wahrscheinlichkeit (MPS, more probable symbol), das eine Wahrscheinlichkeit P hat. Bei der binären Codierung ist ein Intervall entlang der Zahlengeraden in zwei Segmente aufgeteilt, wobei eines zum Auftreten eines LPS-Ereignisses (oder Ergebnisses) gehört und das andere Segment zum Auftreten eines MPS-Ereignisses (oder Ergebnisses) gehört. Die Länge jedes Segments spiegelt vorzugsweise die Wahrscheinlichkeit Q bzw. P der beiden Ereignisse wider, wobei P + Q = 1.
Bei einem binären arithmetischen Codierer erstreckt sich die Zahlengerade zwischen 0 und 1, um ein Anfangsintervall zu definieren. Bei einem Hardwareschema, das in dem Langdon-Artikel beschrieben wird, gehört ein erstes Segment, das sich über die kleineren Werte des Intervalls erstreckt, zur LPS-Wahrscheinlichkeit. Ein zweites Segment, das sich über die größeren Werte des Intervalls erstreckt, gehört zur MPS-Wahrscheinlichkeit. Anfangs wird ein Codierungspunkt gesetzt, der auf das untere Ende des Intervalls zeigt (d. h. auf 0), und ein dazugehöriger Codefluß wird ebenfalls mit 000 . . . begonnen. Es ist wichtig, festzustellen, daß, obwohl die Zahlengerade sich von 0 bis 1 erstreckt, nur einer der zwei Randwerte in dem entsprechenden Intervall enthalten ist. Zum Beispiel enthält des anfängliche Hardwareintervall die 0 und alle Punkte bis, aber nicht einschließlich 1. Genauso ist bei jedem folgenden Intervall des Hardwareschemas die untere Grenze eingeschlossen, aber die obere Grenze ist es nicht.
Beim oben erörterten Hardwareschema bleibt der Codepunkt im Falle eines LPS fest, und der Codefluß bleibt im Wert gleich (obwohl sich seine Lange vergrößert). Nach einem LPS-Ereignis wird ein neues aktuelles Intervall als das LPS- (oder Q-) Segment des Vorgängerintervalls definiert. Für den Fall, daß beim oben erörterten Hardwareschema statt dessen ein MPS mit der 0 bis 1 Begrenzung auftritt, wächst der Codepunkt um den Wert Q, und das neue, aktuelle Intervall wird dasjenige, welches zum MPS-Ereignis gehört, d. h. das P-Segment des Vorgängerintervalls. Es hat sich für Hardwarecodierer gezeigt, daß die Bewegung des Codepunktes auf jedem MPS-Ereignis der Bewegung auf LPS-Ereignissen weit überlegen ist.
Bei einem neuartigen Softwareansatz zur Codierung (hier eingeschlossen) kann die obere Grenze ins Intervall eingeschlossen sein, aber dann ist es die untere Grenze nicht. Das bedeutet für die Zahlengerade, die sich von 0 bis 1 erstreckt, daß das Intervall die 1 und alle Punkte, die sich hinunter bis 0 erstrecken, aber nicht 0 selbst enthält. Gemäß diesem Softwareschema besitzt der Wert für den Codefluß einen Wert, der der oberen Grenze des aktuellen Intervalls entspricht, und wird mit jedem LPS-Ereignis verkleinert. Die Erfinder der vorliegenden Patentschrift haben herausgefunden, daß in einem Softwareschema die Bewegung des Codeflusses auf LPS-Ereignissen wirkungsvoller ist als die Bewegung auf MPS-Ereignissen.
In einigen Fällen ist es wünschenswert oder notwendig, den Wert des Codepunktes in der Hardware zu bestimmen (oder zu codieren), während der Wert des Codepunktes in anderen Fällen vorzugsweise mit Software codiert wird. Ebenso mag in einigen Fällen ein Hardwaredecodierer angemessen oder erforderlich sein, während in anderen Fällen ein Softwaredecodierer angemessen oder erforderlich sein mag, um die ursprünglichen Entscheidungsdaten aus einem gegebenen Codefluß (kennzeichnend für den entsprechenden Codepunkt in einem Intervall) zurückzugewinnen. Daher wäre es sehr wünschenswert, daß ein Hardwarecodierer und ein Softwarecodierer bei einer gegebenen Menge von Entscheidungen denselben Codefluß erzeugen oder die Codeflüsse wenigstens auf dasselbe Intervall zeigen lassen, und daß ein Hardwaredecodierer und ein Softwaredecodierer bei solchen gegebenen Codeflüssen dieselbe Menge von Entscheidungsdaten zurückgewinnen. Auf diese Weise könnten Daten mittels Hardware oder Software codiert werden, um einen Codefluß zu erzeugen, und der Codefluß könnte durch Software oder Hardware decodiert werden, um die Ausgangsdaten wiederzugewinnen.
Bis heute ist jedoch noch nicht in Betracht gezogen worden, daß Codeflüsse, die von optimierter Hardware und optimierter Software erzeugt worden sind, austauschbar sein könnten. Beim Betrachten der oben umrissenen, jeweiligen Übereinkünfte für die erörterten Hardware- und Softwareschemata ist festzustellen, daß der Hardwarecodefluß und der Softwarecodefluß nicht auf denselben Codepunkt auf der Zahlgeraden zeigen (Zum Beispiel zeigt der Hardwarecodefluß bei den Anfangsbedingungen auf 0, während der Softwarecodefluß auf 1 zeigt.). Indem die Codeflüsse auf verschiedene Codepunkte zeigen, sind sie nicht identisch. Des weiteren zeigen die beiden Codeflüsse, wie sie oben vorgeschlagen werden, nicht auf dasselbe Intervall auf der Zahlengeraden. Indem die Codeflüsse auf verschiedene Intervalle zeigen, sind sie nicht einmal kompatibel, d. h. durch denselben Decodierer decodierbar. In dieser Hinsicht ist festgestellt worden, daß ein Decodierer dieselbe Menge von Entscheidungsereignissen von verschiedenen Codepunkten in einem gegebenen Intervall zurückgewinnen kann. Somit werden zwei Codierer, die zwei verschiedene Codepunkte in demselben Endintervall codieren, so decodiert, daß dieselben Ausgangsentscheidungsdaten erzeugt werden. Zwei Codierer, die Codeflüsse erzeugen, die nicht auf dasselbe Endintervall zeigen, sind nicht kompatibel.
Das oben beschriebene Kompatibilitätsproblem ist zusammengesetzt, da die Codierung mit "endlicher Genauigkeit" ausgeführt wird. Bei endlicher Genauigkeit nimmt der Codefluß ohne vorgeschriebene Grenze an Länge zu, wenn jedes Entscheidungsereignis codiert wird; jedoch wird nur ein endlicher Teil des Codeflusses im Speicher bewahrt. Das heißt, der Codefluß wird in einem Schieberegister oder einem anderen Speicher mit fester Länge gespeichert. Wenn ein Ereignis codiert ist, gehen neue Inhalte in den Codeflußspeicher ein. Zu gewissen Zeiten werden früher gespeicherte Speicherinhalte aus dem Speicher mit fester Länge "ausgelagert". Ausgelagerte Inhalte können nicht mehr verändert werden.
Die Tatsache, daß ausgelagerte Inhalte nicht mehr verändert werden können, kann zu Schwierigkeiten führen. Die erste Schwierigkeit wird "Übertragsfortpflanzung" genannt. In einem Codierungsschema, in dem der Codefluß entweder konstant bleibt oder vergrößert wird, wie in dem zuvor erwähnten Hardwareschema, gibt es eine Möglichkeit, daß der aktuelle Codefluß C von der Form 011111111111 ist. Wenn der Speicher mit fester Länge nur die acht niederwertigsten Bits speichert und der Wert von C zum Beispiel um 000000000001 erhöht wird, sollte der neue Wert für C 1000(00000000) sein. Wenn die vier linken Bits bereits ausgelagert sind und nicht mehr verändert werden können, gibt es eine Diskrepanz; die ausgelagerten Bits wären 0111, während der aktuelle Wert nach der Übertragsfortpflanzung 1000 sein sollte. Wenn nur die 8 niederwertigsten Bits behalten werden, kann der Übertrag sein Ziel nicht erreichen. Die Schwierigkeit mit der Übertragsfortpflanzung ist auf dem Stand der Technik erkannt worden. In dem zuvor zitierten Artikel im IBM Journal of Research and Development, 28, 135, (1984), beschreibt G. G. Langdon jr. das allgemeine Konzept des Bitstopfens, um die Übertragsfortpflanzung zu verhindern, wobei dieses Bitstopfen nicht an Datenbytes gekoppelt ist.
Eine zweite Schwierigkeit, die die endliche Genauigkeit berührt, umfaßt solche arithmetischen Codierer, bei denen die obere Grenze im Intervall enthalten ist, und bei denen die Codepunktbewegung dadurch erreicht wird, indem ein Wert vom aktuellen Codefluß abgezogen wird. Ein solches Schema wird vom zuvor erwähnten Softwarecodierer vorgeschlagen. Darin zeigt der Codefluß auf die obere Grenze eines Intervalls. Als Antwort auf ein LPS-Ereignis wird das P-Intervall von abgezogen, um einen neuen Wert für den Codefluß zu liefern (siehe Fig. 4). Wenn der Codefluß nach einer 1 eine Folge von 0-Bits enthält (z. B. 1000000000000) und eine endliche Genauigkeit vorliegt, können die führenden Bits, die das 1-Bit enthalten, bereits ausgelagert sein, so daß ihnen zukünftig nichts mehr abgezogen werden kann. Im obigen Beispiel wären die führenden Bits 10000 bei einem 8- Bit-Register bereits ausgelagert und unterlägen keinen Änderungen mehr. Eine Subtraktion von 00000001 von den acht im Schieberegister oder einem anderen Speicher gespeicherten Nullen führt zu einer Abzugsfortpflanzung, die nicht in der rage ist, ein 1- Bit zu erreichen, bei dem sich ein Abzug niederschlagen würde. Somit stellt die Abzugsfortpflanzung eine beachtliche Schwierigkeit dar, die sich aus der Verarbeitung mit endlicher Genauigkeit ergibt.
Zusätzlich dazu, daß sie in einem gegebenen Codierer Schwierigkeiten erzeugen, haben die sich aus der Verarbeitung mit endlicher Genauigkeit ergebenden Diskrepanzen die Kompatibilität zwischen Codierern behindert. Das heißt, die Diskrepanzen haben es schwierig gemacht, denselben oder einen kompatiblen Codefluß für (a) einen Codierer zu erhalten, der eine Vergrößerung des Codeflußwertes als Antwort auf ein vorgegebenes Ereignis einschließt, und (b) einen Codierer, der eine Verringerung des Codeflußwertes aufgrund eines vorgegebenen Ereignisses einschließt.
Das Problem, einen identischen oder wenigstens kompatiblen Codefluß mit einem erhöhenden und einem vermindernden Codierer zu erzeugen, tritt deutlich hervor, wenn man die einem Hardwarecodierer und einem Softwarecodierer zugeschriebenen optimalen Vorschriften betrachtet.
Für die optimale Verarbeitung bewegt der Hardwarecodierer den Codepunkt auf einem MPS-Ereignis, was in einem geeigneten Ausführungsbeispiel zu einer Erhöhung des Codeflußwertes führt. Die optimale Verarbeitung bei einem Softwareschema schließt die Bewegung des Codepunktes auf einem LPS-Ereignis ein und führt in einem geeigneten Ausführungsbeispiel zu einer Verkleinerung des Codeflußwertes. Um die beiden Codeflüsse durch einen einzigen Decodierer decodierbar zu machen, müssen die Schwierigkeiten der endlichen Genauigkeit wie auch die Ungleichheit beim Zeigen des jeweiligen Codeflusses gelöst werden.
An dieser Stelle soll bemerkt werden, daß die Erfinder der vorliegenden Patentschrift alternativ vorgeschlagen haben, daß die Wahrscheinlichkeitssegmente eines Intervalls "invertiert" werden können. Anstatt zum Beispiel das P-Segment ans obere Ende (der Werte) eines Intervalls zu legen, könnte das P-Intervall das untere Ende des Intervalls besetzen. Eine Kurznotation für die frühere Vorschrift ist "P/Q", während die letztere Vorschrift "Q/P" ist. Ein Beispiel eines invertierten Q/P-Codierers würde den aktuellen Codefluß auf die untere Grenze eines Intervalls (dieser Punkt ist im Intervall enthalten) zeigen lassen. Das Q- Segment liegt am oberen Ende des aktuellen Intervalls, und das P-Segment besetzt das untere Ende des Intervalls. Bei einem invertierten Softwarecodierer bleibt der Codepunkt im Fall eines MPS unverändert. Auf jedem LPS-Ereignis erhöht der invertierte Q/P-Softwarecodierer den Wert von C um den Wert des P-Segments, beginnend bei der unteren Grenze des aktuellen Intervalls. Der invertierte Softwarecodierer arbeitet als Spiegelbild des oben beschriebenen P/Q-Softwarecodierers. Es ist festzustellen, daß der Wert des Q/P-invertierten Softwarecodierers für den Codefluß Ci zum Wert Cs des P/Q-Softwarecodierers in folgender Beziehung steht: Ci = 1 - Cs. Da die Länge von Cs nicht fest ist, ist der Wert von Ci in der Länge nicht festgelegt. Doch können sich bei dem Versuch, den Codierer mit invertiertem Code einzusetzen, um einen Codefluß zu erzeugen, der mit dem Codefluß kompatibel oder identisch ist, den ein optimaler P/Q-Hardware- oder optimaler P/Q-Softwarecodierer erzeugt, wieder Schwierigkeiten aus der Abzugsfortpflanzung ergeben.
Ein Reihe von Problemen hindern einen optimalen Hardwarecodierer und einen optimalen Softwarecodierer daran (ob sie nun einer P/Q-oder Q/P-Ordnung der Symbole folgen), austauschbar zu sein, denselben oder wenigstens kompatiblen Codefluß zu erzeugen. Genauso gibt es eine Reihe von Problemen, die den austauschbaren Gebrauch eines optimalen Softwaredecodierers und eines optimalen Hardwaredecodierers verhindern, um eine ursprüngliche Menge von Entscheidungsereignissen aus einem Codefluß zurückzugewinnen, der von einem optimalen Hardwarecodierer oder einem optimalen Softwarecodierer erzeugt wurde. Die vorliegende Erfindung umfaßt die Konfiguration der verschiedenen Software- und Hardwarecodierer, damit sie austauschbar sind, und die Konfiguration entweder eines Hardwaredecodierers oder eines Softwaredecodierers, damit er die Codeflüsse jedes der austauschbaren Codierer gleichartig decodiert.
Gemäß der vorliegenden Erfindung, wie sie in den Ansprüchen niedergelegt ist, werden ein optimaler Softwarecodierer und ein optimaler Hardwarecodierer konfiguriert, um jeweils solche Codeflüsse zu erzeugen, die von einem einzigen Decodierer in Zusammenhang mit endlicher Genauigkeit decodiert werden können.
Es ist ebenfalls eine Aufgabe der Erfindung, wie sie in den Ansprüchen niedergelegt ist, einen optimalen Hardwaredecodierer und einen optimalen Softwaredecodierer zu, liefern, von denen jeder so konfiguriert ist, daß er dieselbe Menge von Entscheidungsdaten zurückgewinnt, nachdem die jeweiligen Codeflüsse verarbeitet worden sind, die ein optimaler Hardwarecodierer oder ein optimaler Softwarecodierer erzeugt hat.
Zusätzlich besteht eine Aufgabe der Erfindung darin, eine Codierung durch binäre, arithmetische Codierung zu liefern, bei der die Anordnung von Segmenten entlang einer Zahlengeraden umgekehrt werden kann und bei der der vom invertierten Codierer erzeugte Codefluß entweder von einem optimalen Hardwaredecodierer oder einem optimalen Softwaredecodierer für die Decodierung einfach verarbeitet werden kann.
Entsprechend ist es eine Aufgabe der vorliegenden Erfindung, einen optimalen Hardwarecodierer mit entweder einer P/Q- oder einer Q/P-Anordnung von Intervallsegmenten und einen optimalen Softwarecodierer mit entweder einer P/Q- oder einer Q/P-Anordnung von Intervallsegmenten zu liefern, wobei eine Menge von Ereignisentscheidungen, die als Codefluß von einem der vier Codierer codiert worden ist, durch entweder einem optimalen Hardwaredecodierer oder einem optimalen Softwaredecodierer zurückgewonnen werden kann.
Darüber hinaus betrachtet die vorliegende Erfindung einem optimalen Hardwarecodierer endlicher Genauigkeit und einem optimalen Softwarecodierer endlicher Genauigkeit, wobei die jeweils dazugehörigen Codepunkte mit der Verarbeitung aufeinanderfolgender Entscheidungen konvergieren.
Auch trägt die vorliegende Erfindung der Differenz zwischen Codepunktwerten verschiedener Codierer Rechnung, indem wenigstens ein Codepunktwert angeglichen wird, um einen Faktor für den "Endbereich" anzugeben, so daß zwei verschiedene Codepunkte in Übereinstimmung gebracht werden können.
Des weiteren setzt die vorliegende Erfindung eine Methodik ein, bei der die Probleme der Übertragsfortpflanzung und Abzugsfortpflanzung überwunden werden. Insbesondere wird die Übertragsfortpflanzung durch Bitstopfen bewerkstelligt, und die Abzugsfortpflanzung wird mit geeigneten Vorabzügen ausgeführt. Vorabzüge werden angewendet, wenn (a) ein Codefluß aus der Invertierung eines anderen Codeflusses abgeleitet wird und wenn (b) ein Codefluß, der mit einem Byte aus Nullen endet, einen Minuenden darstellt, der auf vorgeschriebene Weise verkleinert werden soll.
Der letztere Fall des Vorabzugs vermeidet die Abzugsfortpflanzung und ermöglicht es, daß der vermindernde Codefluß gemäß entsprechenden Regelsätzen mit einem erhöhenden Codefluß identisch oder wenigstens kompatibel ist. Gemäß einem ersten Regelsatz wird ein Vorabzug durchgeführt, sobald ein auszulagerndes Byte codierter Daten nur aus Nullen besteht, wobei die hexadezimale '00' (für ein Byte aus acht Bits) in ein hexadezimales 'FF' plus einem Übertragsbit umgeformt wird. Es sei vermerkt, daß im folgenden Hexadezimalwerte durch Werte dargestellt werden, die in einfache Anführungszeichen eingeschlossen sind (z. B. 'A1'), oder durch Werte, denen ein X vorangestellt ist und die in einfache Anführungszeichen eingeschlossen sind (z. B. X'A1', das in der Binärschreibweise 10100001 darstellt). Die Anwendung des ersten Regelsatzes führt bei einem erhöhenden Codeflußschema und einem vermindernden Codeflußschema zu Codeflüssen, die kompatibel sind. Das heißt, daß der erste Regelsatz für die verschiedenen Codierer Codeflüsse liefert, die auf dasselbe Intervall zeigen und deshalb von einem einzigen Decodierer decodiert werden können.
Bei einem zweiten Regelsatz wird der Teil der codierten Daten, der für einen aktuellen Codefluß eingesetzt werden soll, mit dem aktuellen Intervallwert A(i) verglichen. Wenn der aktuelle Intervallwert größer ist, wird ein Vorabzug durchgeführt; andernfalls wird kein Vorabzug durchgeführt. Die Bedingung für den Vorabzug gemäß dem zweiten Regelsatz wird, verwendet, um identische Codeflüsse für ein erhöhendes (Hardware-) Schema und ein verminderndes (Hardware-) Schema zu bilden. Der Vergleich zeigt an, ob der Wert des Hardwarecodeflusses im 00-Intervall, auf das die Software zeigt, oder im kleineren FF-Intervall liegt. Im ersten Fall gibt es kein Abzugsfortpflanzungsproblem, und ein Vorabzug ist nicht erforderlich, wohingegen im letzten Fall ein Vorabzug durchgeführt wird. Das heißt, wenn der optimale Softwarecodefluß ein '00'-Byte enthält und der entsprechende optimale Hardwarecodefluß 'FF' sein muß, wandelt das Vorabzugsverfahren die Sofware-'00' in 'FF' um, und für beide Konfigurationen werden identische Codeflüsse erzeugt.
Auch werden gemäß der Erfindung codierte Daten als Bytes mit ÜBERTRAGen und ABZÜGen ausgegeben, was aber auf das ganz zuletzt auszulagernde Byte beschränkt ist. Die Beschränkung von ÜBERTRAGen und ABZÜGen auf Bytegrenzen betrifft die Aufgabe des Ausschlusses von Übertrags- und Abzugsfortpflanzung. Wenn des weiteren die Erlaubnis für ÜBERTRÄGe und ABZÜGe dort, wo das auszulagernde Byte und das zuvor ausgelagerte Byte in einem Puffer gespeichert werden, nur für das auszulagernde Byte besteht, wird dem Pufferzeiger ein sequentielles Durchlaufen des Puffers ohne Sicherung ermöglicht.
Darüber hinaus vermeidet die vorliegende Erfindung unendliche Genauigkeit in einer invertierten Version eines Decodierers, wobei der Codefluß Ci beim Codierschritt mit 1 - Cs gleichgesetzt wird, indem von 1 immer ein Vorabzug &epsi; gemacht wird, so daß der invertierte Codefluß in das durch Cs definierte Intervall gelenkt wird.
Die vorhergehenden und andere Aufgaben, Eigenschaften und Vorteile der Erfindung werden durch die ausführlichere Beschreibung der bevorzugten, erfindungsgemäßen Ausführungsbeispiele, wie sie die anliegenden Abbildungen zeigen, offenbar werden.

Kurzbeschreibung der Abbildungen

Fig. 1 ist ein allgemeines Blockdiagramm eines Systems zur Datenkomprimierung/Dekomprimierung.
Fig. 2 ist eine Abbildung einer Zahlengeraden, auf der arithmetische Codierungsoperationen für einen ersten Codierer/Decodierer-Typ gezeigt werden.
Fig. 3 ist eine Abbildung einer Zahlengeraden, auf der arithmetische Codierungsoperationen für einen zweiten Codierer/Decodierer-Typ gezeigt werden.
Fig. 3 ist eine Abbildung einer Zahlengeraden, auf der arithmetische Codierungsoperationen für einen dritten Codierer/Decodierer-Typ gezeigt werden.
Fig. 5 ist ein Diagramm, das eine Vielzahl verschiedener arithmetischer Codierer zeigt, von denen jeder zusammen mit jedem Decodierer aus einer Vielzahl von Decodierern benutzt werden kann.
Fig. 6 ist ein Diagramm, das zeigt, wie die einzelnen Codierer aus Fig. 5 in Abhängigkeit von Entscheidungsereignissen arbeiten.
Fig. 7 ist ein Diagramm, das die Konvergenz zweier Codeflüsse zeigt, die von zwei verschiedenen Codierern erzeugt worden sind, die beide dadurch gekennzeichnet sind, daß die Ereignisse nach derselben Vorschrift geordnet sind.
Fig. 8 ist ein Diagramm, das die Konvergenz zweier Codeflüsse zeigt, die von zwei verschiedenen Codierern erzeugt worden sind, die beide dadurch gekennzeichnet sind, daß die Ereignisse nach derselben Vorschrift geordnet sind, wobei die Vorschrift umgekehrt zu der aus Fig. 7 ist.
Fig. 9 ist eine Abbildung, die die Bitanordnung in einem Schieberegister eines Codierers gemäß der vorliegenden Erfindung zeigt.
Fig. 10 ist eine Abbildung, die die Bitanordnung in einem Schieberegister eines Decodierers gemäß der vorliegenden Erfindung zeigt.
Fig. 11 ist ein Flußdiagramm, das die allgemeinen Verarbeitungsschritte zeigt, die von einem System zur Datenkomprimierung/Dekomprimierung gemäß der vorliegenden Erfindung ausgeführt werden.
Fig. 12, Fig. 13 und Fig. 14 sind Flußdiagramme, die das Initialisierungsverfahren für jeden von drei verschiedenen Decodierer- Typen zeigen.
Fig. 15, Fig. 16 und Fig. 17 sind jeweils Darstellungen von Codierungsverfahren von drei verschiedenen Codierer-Typen.
Fig. 18 ist ein Flußdiagramm, das zeigt, wie die Werte für das aktuelle Intervall und den aktuellen Codefluß gleichermaßen renormiert werden, um die Intervallgröße für jede Entscheidung über einem Minimalwert AMIN zu halten.
Fig. 19, Fig. 20 und Fig. 21 sind jeweils Flußdiagramme einer BYTEOUT-Operation, bei der die Zahl der mit jedem Datenbyte auszulagernden Datenbits anhand der möglichen ÜBERTRAGs- und ABZUGs-Erwägungen bestimmt wird.
Fig. 22 bis Fig. 29 sind jeweils Flußdiagramme, die zeigen, wie Bytes mit 6 Datenbits oder 8 Datenbits pro Byte auszulagern sind. Die verschiedenen Figuren spiegeln die unterschiedlichen Typen von Codierern wider.
Fig. 30 ist ein Flußdiagramm, das eine Prozedur zeigt, nach der verfahren werden muß, wenn eine spezielle Art von ABZUGs-Situation auftritt.
Fig. 31 ist ein Flußdiagramm, das zeigt, wie Bytes in den Pufferspeicher eingegeben werden, wobei der Pufferzeiger sich beim Speichern eines neuen Bytes bewegt.
Fig. 32, Fig. 33 und Fig. 34 sind jeweils Flußdiagramme, die zeigen, wie das X-Register, das Daten enthält, die noch nicht in den Pufferspeicher ausgelagert sind, "geräumt" wird, nachdem das letzte Symbol codiert ist.
Fig. 35, Fig. 36 und Fig. 37 sind jeweils FINALBYTE-Flußdiagramme, die den letzten Teil des Ausräumens der Bits aus dem X- Register zeigen.
Fig. 38, Fig. 39, Fig. 40 und Fig. 41 sind jeweils Flußdiagramme, die weitere Räumungsschritte zeigen, die bei der FINALBYTE-Operation durchgeführt werden.
Fig. 42, Fig. 43 und Fig. 44 sind Flußdiagramme, die das Initialisierungsverfahren für jeden der drei verschiedenen Typen von Decodierern zeigen.
Fig. 45, Fig. 46 Fig. 47 und Fig. 48 sind jeweils Darstellungen von Decodierungsverfahren.
Fig. 49 und Fig. 50 sind jeweils Flußdiagramme, die die Renormierung im Decodierer zeigen.
Fig. 51 und Fig. 52 sind jeweils Flußdiagramme, die zeigen, wie die jeweiligen Typen von Decodierern codierte Bytes als Eingabe empfangen.
Fig. 53 ist ein Flußdiagramm, das die Bewegung des Pufferzeigers zeigt, wenn Bytes in den Puffer gelangen.
Fig. 54 bis Fig. 57 sind jeweils Blockdiagramme, die einen Hardwarecodierer bzw. Teile davon zeigen.
Fig. 58 bis Fig. 60 sind jeweils Blockdiagramme, die einen Hardwaredecodierer bzw. Teile davon zeigen.
Bevorzugtes Ausführungsbeispiel gemäß der Erfindung

I. ERZEUGUNG IDENTISCHER UND KOMPATIBLER CODEFLÜSSE MIT CODIERERN MIT UNTERSCHIEDLICHEN CODIERUNGSVORSCHRIFTEN

Bezugnehmend auf Fig. 1, wird eine allgemeine Vorrichtung 100 zur Komprimierung und Dekomprimierung von Daten gezeigt, die einen arithmetischen Codierer 102 und einen arithmetischen Decodierer 104 umfaßt. Beim Komprimieren von Daten nimmt die Vorrichtung 100 eingehende Daten (DATAIN) auf, die als Reihe von binären (ja/nein) Entscheidungen (YN, yes/no) ausgedrückt werden können, wobei jedes Ergebnis oder Ereignis eine entsprechende Wahrscheinlichkeit hat, und stellt die Reihe durch eine codierte Folge von Bits dar. Durch das Codieren der Entscheidungsreihe mit darin eingebetteter Wahrscheinlichkeitsinformation kann die komprimierte Folge von Bits schneller übertragen werden als die ursprünglichen Eingangsdaten. Darüber hinaus können die komprimierten Daten auf weniger Platz gespeichert werden als die ursprünglich übertragene Information.
Bei Anwendungen, bei denen große Datenmengen durch irgendwelche Übertragungsvorrichtungen oder -medien (z. B. Element 105) mit hohen Baudraten übertragen werden müssen oder bei denen große Datenmengen in begrenztem Speichern gespeichert werden müssen (oder bei denen große Datenmengen gespeichert werden müssen und anschließend mit kleinen Baudraten übertragen werden müssen), ist die Anwendung komprimierter Daten von enormem Wert. Ein besonderes Ausführungsbeispiel, bei dem eine solche Kompression von beachtlichem Wert ist, betrifft den Bereich der Videodatenverarbeitung, insbesondere den der Videokonferenzen. Bei Videokonferenzen müssen riesige Informationsmengen von einem Ort zum anderen übertragen werden, um Bildinformation und andere Information zu übermitteln.
Nachdem die codierten Daten zum gewünschten Ziel übertragen worden sind, werden sie dekomprimiert. Das heißt, die ursprünglichen Daten oder eine entsprechende Darstellung davon werden mittels des Decodierers 104 zurückgewonnen. Der Decodierer 104 macht letztlich das Verfahren des Codierers 102 rückgängig.
In Fig. 1 werden die eingehenden Daten DATAIN von einem Modell- und Wahrscheinlichkeitsgenerator 106 verarbeitet. Der Modell- und Wahrscheinlichkeitsgenerator 106 verleiht den Daten einen Zusammenhang. Bei der Bildübertragung zum Beispiel können Teile der eingehenden Daten der Information entsprechen, ob ein gegebener Bildpunkt schwarz oder nicht-schwarz ist. Eine Bedingung oder ein Ereignis ist im allgemeinen wahrscheinlicher. Für einen speziellen Bildpunkt wird bestimmt, ob er der wahrscheinlicheren oder der weniger wahrscheinlichen Bedingung entspricht. Wenn aufeinanderfolgende Datenteile verarbeitet werden, können die relativen Wahrscheinlichkeiten zwischen den wahrscheinlicheren Bedingungen (als "MPS" bezeichnet) und den weniger wahrscheinlichen Bedingungen (als "LPS" bezeichnet) im Wert verändern oder sogar vertauscht werden. Das heißt, wenn die wahrscheinlichere Bedingung schwarz ist und zahlreiche Fälle von nicht-schwarz auftreten, kann die Bedingung für nicht-schwarz wahrscheinlicher werden. Die MPS würden dann von der Bedingung schwarz zu der Bedingung nicht-schwarz wechseln. Das Modell, das bestimmt, wie die eingehenden Daten DATAIN auszuwerten sind, und der Wahrscheinlichkeitsgenerator, der die relativen Wahrscheinlichkeitswerte aktualisiert, sind im Element 106 enthalten. Verschiedene Modelle werden auf dem Stand der Technik diskutiert. Ein spezieller Ansatz zur Wahrscheinlichkeitsanpassung ist in der gleichzeitig anhängigen Patentanmeldung mit der Überschrift "Probability Adaptation for Arithmetic Coders", Erfinder J.L. Mitchell und W.B. Pennebaker, EP-A-0 224 753 vom 7. November 1986, enthalten. Ein weiterer Zugang zur Wahrscheinlichkeitsabschätzung wird in der gleichzeitig anhängigen Anmeldung EP-A-0 260 460, Erfinder J.L. Mitchell und W.B. Pennebaker, die dasselbe Datum wie diese Patentanmeldung trägt und mit "Probability Estimation based on decision history" überschrieben ist, vorgestellt. Ein geeigneter Wahrscheinlichkeitsgenerator wird ebenfalls in der Patentanmeldung mit der Überschrift "Symmetrical Adaptive Data Compression/Decompression System", Erfinder G. Goertzel und J.L. Mitchell, US-Seriennummer 06/598 981, vom 15. März 1984 (jetzt US-Patentschrift 4 633 490), entsprechend EP-A-0 154 860 vom 22. Febr. 1985, offenbart.
Weitere Information hinsichtlich der Wahrscheinlichkeitsanpassung und der arithmetischen Codierung wird in einer weiteren gleichzeitig anhängigen Patentanmeldung, die dasselbe Datum wie diese Patentanmeldung trägt, mit der Überschrift "Arithmetic Coding Encoder and Decoder System", Erfinder G.G. Langdon jr., J.L. Mitchell, W. Pennebaker und J.J. Rissane, alles Mitarbeiter der IBM Corporation, gegeben (EP-A-0 260 461).
Der Modell- und Wahrscheinlichkeitsgenerator 106 liefert drei Datensätze an den Codierer 102. Erstens wird die Bedingung bezeichnet, der das wahrscheinlichere Ereignis zugeordnet ist (d. h. welche Bedingung ein MPS-Ereignis ist). Zweitens wird ein Wert Q geliefert, der der Wahrscheinlichkeit des weniger wahrscheinlichen Ereignisses (des LPS-Ereignisses) entspricht. Drittens bezeichnet ein YN-Wert das eingehende Entscheidungsereignis.
Der Codierer 102 wandelt die drei Informationssätze vom Modell- und Wahrscheinlichkeitsgenerator 1006 mittels arithmetischer Codierung in komprimierte Datensätze um. Fig. 2, Fig. 3 und Fig. 4 stellen jeweils ein Codierungsschema dar. Fig. 2 stellt einen optimalen Hardwarecodierer dar. Fig. 4 stellt einen optimalen Softwarecodierer dar. Fig. 3 zeigt ein optimales Codierungsschema, das als Softwarecodierer mit invertiertem Code bezeichnet wird.
In Fig. 2 ist der Codepunkt anfangs auf die "untere" (den Wert betreffend) Grenze eines gegebenen Intervalls gesetzt. Das mit dem Auftreten eines LPS-Ereignisses verbundene Q-Segment befindet sich ebenfalls am unteren Ende des Intervalls. Das mit einem MPS-Ereignis verbundene MPS-Ereignis befindet sich am oberen Ende des Intervalls. C(n) gehört zu einem Codeflußwert zu einer Zeit n. Bei jeder Entscheidung folgt ein optimaler Hardwarecodierer folgenden Vorschriften:
Wenn das Entscheidungsereignis (in den Abbildungen als YN dargestellt) ein MPS-Ereignis ist:
(a) C(n) ← C(n - 1) + A(n - 1) · Q
(b) A(b) ← A(n - 1) · (1 - Q)
Wenn das Ereignis ein LPS-Ereignis ist:
(a) C(n) ← C(n - 1)
(b) A(b) ← A(n - 1) · Q
Sowohl beim MPS-Ereignis als auch beim LPS-Ereignis benötigt die Hardware einen Verarbeitungszyklus, der den Wert für A, das Intervall (oder den Bereich), neu festsetzt. Darüber hinaus wird der Codepunkt bei einem MPS um den Wert A(n - 1) · Q erhöht (d. h. bewegt). Da die Hardware die Aktualisierung von A und C parallel durchführen kann, benötigt die Hardware für jede Entscheidung nur einen Verarbeitungszyklus. Wäre die Hardware auf der anderen Seite so konfiguriert, daß der Codepunkt auf jedem LPS-Ereignis zu bewegen wäre, wären jedesmal, wenn der Codepunkt zu bewegen wäre, zwei Verarbeitungszyklen erforderlich, um C ← C - (A · Q) zu bestimmen. Da die Begrenzung der Zahl der Verarbeitungszyklen beim Hardwarebetrieb entscheidend ist und da die Bewegung des Codepunktes auf LPS-Ereignissen zum Verbrauch von mehr Zykluszeit führt, hat sich bei Hardware die Bewegung des Codepunktes auf MPS-Ereignissen als optimal herausgestellt.
Mit Bezug auf Fig. 3 wird nun eine zweite Implementierung vorgestellt. Diese Implementierung ist von den Erfindern der vorliegenden Patentschrift in einem experimentellen Codierer am IBM Corp. Thomas J. Watson Research Center vorgeschlagen worden. Der Codepunkt Z wird direkt ans "untere" Ende des Intervalls gesetzt. Das P-Segment liegt ebenfalls am unteren Ende des Intervalls, während sich das Q-Segment sich auf dem oberen Endes des Intervalls erstreckt. Bei dieser Implementierung gelten die folgenden Regeln:
Wenn das Ereignis ein MPS-Ereignis ist:
(a) Z (n) ← Z(n - 1)
(b) A(n) ← A(n - 1) · (1 - Q)
Wenn das Ereignis ein LPS-Ereignis ist:
(a) Z(n) ← Z(n - 1) + A(n - 1) · (1 - Q)
(b) A(n) ← A(n - 1) · Q
Es hat sich herausgestellt, daß obige, zu Fig. 3 gehörigen Vorschriften für Software optimal sind. Software verarbeitet nicht parallel. Würde die Software die Aktualisierung von Z und A gemäß den Regeln für Fig. 2 durchführen, müßten sowohl Z als auch A seriell geändert werden, und da die Aktualisierung auf den als wahrscheinlicher angenommenen MPS-Ereignissen durchgeführt wird, wäre diese serielle Aktualisierung häufig erforderlich. Dies würde beträchtliche Verarbeitungszeit erfordern. In Fig. 3 dagegen sollte Z selten aktualisiert werden (besonders wenn Q«P).
Der Codierungsprozeß aus Fig. 4 ist ein Spiegelbild des in Fig. 3 gezeigten Prozesses des invertierten Softwareschemas, im Vergleich zu dem die Anordnung des P- und Q-Segments vertauscht sind. Ebenfalls mit Fig. 3 verglichen, bewegt sich der Codepunkt in Fig. 4 auf ein LPS-Ereignis hin in entgegengesetzte Richtung. Gemäß dem invertierten Schema aus Fig. 3 heißt das, daß der Codefluß mit jedem LPS-Ereignis vergrößert wird; dagegen wird der Codefluß mit dem entgegengesetzten Codierer aus Fig. 4 mit jedem LPS-Ereignis verkleinert. Der Vergleich von Fig. 4 mit Fig. 2 zeigt, daß, wie nun gezeigt werden wird, für jedes Ereignis = C + A.
In einem einfachen Beispiel sei angenommen, daß A(n-1) binär gleich 0,100 ist und Q gleich 0,001 ist. Auch sei angenommen, daß der aktuelle Wert für C(n-1) in Fig. 2 gleich 0,100 und für (n-1) in Fig. 4 gleich 1,000 ist. Im Falle eines LPS bleibt der Codepunkt im Hardwareausführungsbeispiel aus Fig. 2 unverändert; C(n) ← C(n-1). Der Wert von A(n) in Fig. 2 ist dann gleich A(n-1) * Q, was im vorliegenden Beispiel (0,100) * (0,001) = 0,0001 ist. Der Wert von C(n) (wie oben angegeben) bleibt bei 0,100, und der Wert von A(n) ist 0,0001. Die Summe von C(n) und A(n) ist daher 0,1001. Beim Softwareausführungsbeispiel aus Fig. 4 wird (n) jedoch bestimmt, indem (n-1) um den Wert A(n-1) * (1- Q), d. h. um (0,100) * (1-0,001) = 0,0111, verkleinert wird. Der - Wert ist dann (1,000-0,0111) oder 0,1001. Somit ist C(n) + A(n) dasselbe wie (n). Ein einziger Decodierer kann C(n) + A(n) oder (n) decodieren, um denselben Satz von Eingangsentscheidungsereignissen zurückzugewinnen. Das heißt, erhält der Decodierer (siehe Decodierer 104 in Fig. 1) eine erste Eingabe, die anzeigt, welche Bedingung einem MPS-Ereignis entspricht, und eine zweite Eingabe, die den aktuellen Wert für Q für das zu decodierende Stück des Codeflusses anzeigt, kann der Decodierer entweder C(n) plus das letzte Intervall A(n) oder (n) verarbeiten, um eine Folge von YN-Ausgaben zu erzeugen, die der Folge von YN-Eingaben an den Codierer 102 entspricht. Die YN-Entscheidungen gehen in den Modell- und Wahrscheinlichkeitsgenerator 110 ein, der dem Modell- und Wahrscheinlichkeitsgenerator 106 entspricht, und der die Originaldaten oder eine Kopie davon als Ausgabe DATAOUT liefert.
Da die Schemata aus Fig. 3 und Fig. 4 für die Bewegung des Codepunktes auf einem LPS-Ereignis sorgen, wird die für die Softwareverarbeitung erforderliche Zahl von Zyklen klein gehalten. Diese beiden Schemata werden für das Softwareausführungsbeispiel als optimal angesehen (Hier sollte der Vollständigkeit halber festgestellt werden, daß ein invertierter Codierer, der die Hardware durch Invertierung der P/Q-Anordnung aus Fig. 2 optimiert, gemäß der Erfindung auch ins Auge gefaßt wird.).
Mit Bezug auf Fig. 5 wird eine Hauptaufgabe der Erfindung gezeigt. Es werden vier Codierer 200 bis 206 gezeigt. Die Codierer 200 und 204 codieren entsprechend der optimalen Hardwareregel, daß der Codepunkt sich auf jedem MPS-Ereignis bewegt, wobei ersterer mit einer P/Q-Symbolanordnung implementiert ist und letzterer mit einer Q/P-Symbolanordnung (invertiert) implementiert ist. Die Codierer 202 und 206 codieren entsprechend der optimalen Softwareregel, daß der Codepunkt sich auf jedem LPS- Ereignis bewegt, wobei der erste mit einer P/Q-Symbolanordnung implementiert ist und der zweite mit einer Q/P-Symbolanordnung (invertiert) implementiert ist.
Gemäß der Erfindung können die von den Codierern 200 und 202 erzeugten Codeflüsse gleich (oder zumindest kompatibel) gemacht werden und werden mit C dargestellt. Gemäß der Erfindung können die von den Codierern 204 und 206 erzeugten Codeflüsse gleich (oder zumindest kompatibel) gemacht werden und werden mit Z dargestellt. Z und C können gemäß dem Ausdruck C = 1-Z ineinander überführt werden, wobei ein Inverter 208 diese Rechnung ausführt. Der Codefluß C kann direkt vom Decodierer 210 decodiert werden, der auf optimalen Hardwarebetrachtungen basiert (z. B. Parallelverarbeitung). Der Codefluß Z kann direkt vom Decodierer 216 decodiert werden, der auf optimalen Softwarebetrachtungen basiert. Es ist festgestellt worden, daß entweder der Decodierer 210 oder 216 benutzt werden kann, um einen Codefluß zu decodieren, der von einem der vier Codierer 200 bis 206 erzeugt worden ist, wobei einige Codeflüsse auf dem Weg zum Decodierer durch den Inverter 208 bearbeitet werden.
Der Vollständigkeit halber sei bemerkt, daß zwei weitere Decodierer, ein Q/P-Hardwaredecodierer 214 und ein P/Q-Softwaredecodierer 212, ebenfalls erfindungsgemäß implementiert werden können. Ein P/Q-Softwaredecodierer wird sogar weiter unten in Abschnitt II(B) kurz beschrieben.
Die wechselseitige Beziehung zwischen den vier Codierern 200 bis 206 in Fig. 5 wird in Fig. 6 gezeigt. Im linken Teil von Fig. 6 werden ein Hardwarecodierer (z. B. Codierer 200) und ein Softwarecodierer (z. B. Codierer 202) mit P/Q-Symbolanordnung gezeigt, die auf ein MPS- bzw. ein LPS-Ereignis antworten. Bei einem MPS-Ereignis erhöht der P/Q-Hardwarecodierer (mit H bezeichnet) den Codeflußwert um den Betrag A(n-1) · Q, wobei die Intervallgröße A(n) gleich A(n-1) · (1-Q)9 gesetzt wird. Der P/Q-Softwarecodierer (mit S bezeichnet) behält die Position des Codepunktes bei einem MPS-Ereignis bei, wobei die Intervallgröße auf A(n-1) · (1-Q) gesetzt wird. Bei einem LPS-Ereignis behält der P/Q-Hardwarecodierer die Position des Codepunktes bei, während der P/Q-Softwarecodierer den Wert des Codepunktes um A(n-1) · (1- Q) vermindert. Bei einem LPS-Ereignis setzen beide P/Q-Codierer die neue Intervallgröße gleich A(n-1) · Q.
Im rechten Teil von Fig. 6 wird ein Q/P-Hardwarecodierer gezeigt, der seinen Codepunkt infolge eines MPS-Ereignisses herabsetzt, und die Intervallgröße wird an den Wert A(n-1) · (1-Q) angeglichen. Bei einem MPS-Ereignis behält der Q/P-Softwarecodierer die Position des Codepunktes bei und setzt die Intervallgröße auf A(n-1) · (1-Q). Bei einem LPS-Ereignis behält der Q/P- Hardwarecodierer die Position des Codepunktes bei, während der Q/P-Softwarecodierer seine Codepunktposition Z um A(n-1) · (1-Q) erhöht. Bei einem LPS-Ereignis setzen beide Q/P-Codierer die neue Intervallgröße gleich A(n-1) · Q.
Basierend auf den in Fig. 6 dargestellten Vorschriften, wird für in Fig. 7 für jeden Codierer die Codierung eines Satzes von Entscheidungsereignissen gezeigt. Insbesondere wird die nachstehende Ereignisfolge codiert: MPS, MPS, MPS, LPS, MPS, MPS, MPS, MPS, LPS, MPS, LPS, MPS. Fig. 7 zeigt die Codepunktbewegungen der P/Q-Hardware (H) und P/Q-Software (S). Fig. 8 zeigt die Codepunktbewegungen der Q/P-Hardware (H) und Q/P-Software (S) für dieselbe Ereignisfolge wie Fig. 7. Aus Fig. 7 und Fig. 8 kann entnommen werden, daß sich der Codepunkt der Hardware und der Codepunkt der Software für eine spezielle Symbolanordnung um den Wert des aktuellen (letzten) Intervalls A(n) unterscheiden. Es wird auch festgestellt, daß die beiden Codepunkte mit der Folge der Entscheidungsereignisse konvergieren.
Der Vergleich von Fig. 7 mit Fig. 8 zeigt, daß zwei Codepunkte, die mit invertierter Symbolanordnung erzeugt worden sind, leicht durch folgenden Ausdruck zueinander in Beziehung gesetzt werden können:
Z = (1 - &epsi;) - C - (A · δ - &epsi;),
wobei &epsi; einen möglichen Vorabzug darstellt, und das δ eine Entscheidung darüber darstellt, ob das letzte Intervall eingesetzt werden muß. Wenn kein Vorabzug erforderlich ist und das letzte Intervall nicht eingesetzt werden muß, vereinfacht sich der Ausdruck zu Z = 1-C, was ein alternativer Ausdruck für die Verarbeitung durch den Inverter 208 (aus Fig. 5) ist. Bei der allgemeinen Verarbeitung verwendet der Inverter 208 den aus führlicheren Ansatz, der möglichen Endintervall- und Vorabzugsfaktoren Rechnung trägt.

II. CODIERUNG UND DECODIERUNG AUFEINANDERFOLGENDER EREIGNISSE MIT ENDLICHER GENAUIGKEIT

Um die Beschreibung in diesem Abschnitt zu erleichtern, werden die folgenden Definitionen gegeben. Variablennamen haben in den meisten Fällen dieselbe Bedeutung.

Definitionen

C = Codefluß; der Zeiger (d. h. der Codepunkt) auf das aktuelle Intervall.
Cd = Codefluß des Decodierers mit angepaßter Grundlinie.
X = Teil des Codeflusses im Register und nicht ausgelagert.
Q(i) = geschätzte Wahrscheinlichkeit für ein LPS-Ereignis für das i-te codierte Symbol.
P(i) = geschätzte Wahrscheinlichkeit für ein MPS-Ereignis für das i-te codierte Symbol.
A(i) = Erstsummand (oder Intervall) für das i-te Symbol.
Si = i-tes Symbol.
n(i) = kumulative Renormierungszählung bis zur Codierung des Symbols Si.
R(i) = Renormierungsfaktor für das i-te Symbol.
δ(Bedingung) = entspricht dem Kronecker-Symbol (1 wenn die Bedingung wahr, 0 wenn falsch).
&epsi; = kleinste Änderung, die beim aktuellen Wert C möglich ist.
Mit obigen Definitionen gelten die folgenden Beziehungen:
A(i) · P(i) = A(i) - (A(i) · Q(i))
R(i) = 1/2 n(i)
&epsi; = R(i)2&supmin;¹² für eine 12-Bit-Genauigkeit.

A. P/O-Hardwarecodierer und -decodierer

Bei einer P/Q-Symbolanordnung zeigt ein optimaler Hardwarecodierer ans untere Ende des aktuellen Intervalls, und der Codefluß wird durch folgende Gleichung dargestellt:
C = i R(i)A(i)Q(i)δ(Si = M)
In Worten, der Wert von C wird bestimmt, indem jedes folgende Entscheidungsereignis Si (bzw. Symbol) untersucht wird. Wenn ein aktuelles Symbol einem MPS-Ereignis entspricht, wird der A · Q- Wert zur Zeit des aktuellen Symbols mit einem Renormierungsfaktor multipliziert. Der Renormierungsfaktor bezieht sich auf die Tatsache, daß die Intervallgröße zwischen vorgegebenen Grenzen gehalten wird, z. B. 0,5 und 1,0. Das heißt, die Intervallgröße wird durch einen "Erstsummanden" (als "A" bezeichnet) dargestellt, dessen Wert so angepaßt wird, daß er innerhalb der vorgegebenen Grenzen bleibt. Wenn der Wert des Erstsummanden bei einem i-ten Symbol, d. h. A(i), unter 0,5 fällt, wird er so oft verdoppelt wie notwendig ist, um ihn in die vorgegebenen Grenzen zurückzuführen. Der Bezug auf ein Intervall A oder A(i) berücksichtigt den Renormierungsfaktor.
Jedesmal, wenn ein Symbol codiert wird, ist eine Renormierung möglich. Um sicher zu sein, wird der Wert von A(i) jedesmal renormiert (wenigstens mit 2 multipliziert), wenn die neue Intervallgröße gleich A · Q gesetzt wird (was nach Definition kleiner oder gleich A · P ist und somit kleiner oder gleich A · 0,5 ist), um ihn innerhalb der Grenzen bringen.
Auf ein MPS-Ereignis hin wird die Größe des aktuellen Intervalls A(i) anfangs gleich A(i-1) · (1-Q) gesetzt, was kleiner oder auch nicht kleiner als 0,5 sein kann; so kann Renormierung im MPS- Fall erforderlich sein oder auch nicht. Die Gesamtzahl der Male, die das aktuelle Intervall durch Verdopplung renormiert worden ist, wird ermittelt und durch n(i) oder, wie oben beschrieben, durch R(i) = 1/2n(i) dargestellt. Der Renormierungsfaktor R(i) stellt sicher, daß der Codepunkt C seinen Wert ändert (z. B. daß er ebenso häufig verdoppelt wird), wenn das Intervall seinen ändert. Ist das Symbol Si codiert, wird der Wert von C für die P/Q-Hardware somit im Fall eines MPS-Ereignisses vergrößert, und die Vergrößerung wird durch Q-Werte und die Renormierungsfaktoren aller vorhergehenden Symbole bestimmt.
Der P/Q-Hardwaredecodierer macht obige Prozesse gemäß folgender Gleichung rückgängig:
Cd = C - i R(i)A(i)Q(i)δ(Si = M)
Cd ist der Wert des Codeflusses, nachdem die Wirkung eines Ereignisses entfernt ist. Der P/Q-Hardwaredecodierer decodiert ein LPS, wenn Cd < A(i)Q(i).

B. P/O-Softwarecodierer und -decodierer

Der P/Q-Softwarecodierer zeigt auf das obere Ende jedes aktuellen Intervalls. Der Softwarecodefluß wird durch folgende Gleichung bestimmt:
= A(0) - i R(i)A(i)P(i)δ(Si = L).
Die Auswertung von beginnt mit einem Wert A(0), von dem die Summe abgezogen wird. Jeder Summand der Summe entspricht dem Produkt A mal dem aktuellen Wert P mal einem Renormierungsfaktor bei einem LPS-Ereignis. Die Subtraktion des letzten Intervallwertes A(l) von führt zum Wert C, der als P/Q-Hardwarecodefluß abgeleitet wird.
Ein P/Q-Softwaredecodierer würde dieser Gleichung folgen:
d = + i R(i)A(i)P(i)δ(Si = L).
Jedoch ist der für die Decodierung des LPS-Symbols notwendige Vergleich unhandlich (der Bequemlichkeit wegen ist das Tilde ( )-Zeichen weggelassen):
Cd < A(0) - A(i) + A(i) · Q(i)
Oder, indem auf beiden Seiten der Beziehung A(0) subtrahiert wird:
Cd - A(0) < - A(i) + A(i) · Q(i)
Sei C'd = Cd - A(0), so ergibt sich, daß
C'd < - A(i) · (1 - Q(i))
Sowohl C'd als auch - A(i) · (1 - Q(i)) sind negativ, liegen aber immer innerhalb eines Abstands A(i) von 0. Daher ist die Arithmetik für den Decodierer eine Arithmetik mit fester Genauigkeit. Der Softwaredecodierer ist dann:
T ← A · Q
A← A - T
If C'd < A
(LPS decodiert)
C'd ← C'd + A
A ← T
renormalisiere A und C'd
else
(MPS decodiert)
renormalisiere A und C'd, falls nötig.
endif

C. O/P-Softwaredecodierer

Ein bevorzugter Aufbau zur Decodierung des Codeflusses, der von P/Q-Software erzeugt wird, wird hier unten als Alternative zum Decodierer 212 aus Fig. 5 vorgestellt. Ein Codefluß wird vom Codierer 202 verarbeitet, um einen Codefluß C zu bilden. Der Codefluß C wird vom Inverter 208 invertiert, um gemäß dem folgenden Ausdruck Z zu bilden, der, wie zu bemerken ist, analog zu dem zuvor gegebenen Ausdruck für die Codeinvertierung ist:
Z = A(0) - C - &epsi;
Der Codefluß für den Decodierer 216 ist dann:
Zd = Z - i R(i)A(i)P(i)δ(Si = L)
Zd stellt den Codefluß vor der Decodierung des i-ten Symbols dar. Das heißt, der Decodierer subtrahiert einen Wert von einem aktuellen Codefluß Z, um zu bestimmen, was das i-te Symbol war und was der Wert des Codeflusses Zd war, bevor das i-te Symbol codiert wurde.
Der Decodierer decodiert ein MPS, wenn Zd < A(i) - A(i) · Q(i), andernfalls decodiert er das i-te Symbol als ein LPS.
Anders dargestellt, folgt die Decodierung folgendem Ablauf:
T ← A · Q
A← A - T
if
Z < A
(LPS decodiert)
Z ← Z - A
A ← T
renormalisiere A und Z
else
(MPS decodiert)
renormalisiere A und Z, wenn nötig.
endif
Es sei bemerkt, daß A(0) mit 1,00000 . . . initialisiert wird.
Wenn von 1 subtrahiert wird, wird unendliche Genauigkeit vermieden, indem die 0-Bits durch 1-Bits ersetzt werden und ein Summand addiert wird:
binäre 1,000000 . . . = 0,111111 + &epsi;
Letztlich wird ein Vorabzug durchgeführt. Die Bedeutung dieses Vorabzugs wird in folgendem Beispiel deutlich. Angenommen, der A(0)-Wert sei 1,00000 . . . (binär). Bei der Durchführung der Subtraktion A(0)-C wird festgestellt, daß die Länge von C nicht fest ist. Wenn die Länge von C die feste Länge von A(0) übersteigt, erfordert es die Subtraktion, daß C von einem Register aus 0-Bits subtrahiert wird, und es würde sich ein Abzug ausbreiten, der kein 1-Bit erreichen würde. Die Umwandlung von 1,000 . . . nach 0,111 . . . + &epsi; schließt dieses Problem aus.
Zusätzlich bewegt der Vorabzug den Codefluß der P/Q-Software um &epsi; in das aktuelle Intervall für einen P/Q-Hardwarecodierer. Das &epsi; trägt letztlich der Tatsache Rechnung, daß sich Intervalle in P/Q-Hardwarecodierern von der unteren Grenze des Intervalls bis hoch zur, aber nicht einschließlich, der oberen Grenze des Intervalls erstrecken, wohingegen das Intervall bei P/Q-Softwarecodierern definitionsgemäß die obere Grenze, nicht jedoch die untere Grenze enthält. Bei einem Intervall von 0 bis 1 würde sich das Intervall eines P/Q-Hardwarecodierers von 0 bis 1&supmin; erstrecken, wogegen das Intervall eines Softwarecodierers zwischen 0+ und 1 läge. Der P/Q-Hardwarecodierer zeigt auf 1, und der P/Q-Softwarecodierer zeigt auf 1. Um die beiden Punkte in dasselbe Intervall zu bringen, muß ein beliebiger Wert vom Softwarecodefluß subtrahiert werden oder zum Hardwarecodefluß addiert werden (oder beides). In diesem Fall wird &epsi; von den Softwareergebnissen subtrahiert.
Es ist festzustellen, daß die Codeinvertierung entweder als Teil des Codierungsprozesses oder als Teil des Decodierungsprozesses oder als getrennter Zwischenschritt angesehen werden kann. Wie Fig. 7 zeigt, kann die Softwarecodierung entlang eines absteigenden Pfades fort schreiten, wobei der letzte Wert des Codeflusses invertiert und dann vom Q/P-(Software-)Decodierer decodiert wird. Oder die Codierung durch die Software kann, was gleichwertig ist, entlang eines ansteigenden Pfades in Fig. 8 fortschreiten und anschließend von einem Q/P-Softwaredecodierer decodiert werden. Diese alternativen Pfade werden in Fig. 5 vorgeschlagen.
Die Beziehung zwischen dem Codefluß Calt, der von einem der P/Q- Codierer wie in Fig. 7 dargestellt erzeugt wird, und dem Codefluß Zalt von einem der Q/P-Codierer, wie in Fig. 8 dargestellt, ist:
Zalt = (1 - &epsi;) - Calt - (A(1) ξ δ - &epsi;),
wobei &epsi; zu einem Vorabzug gehört, der 1,000 . . . in 0,1111 . . . + &epsi; umwandelt, und δ anzeigt, ob der Endbereich eingesetzt werden muß oder nicht.

III. CODIERER- UND DECODIERERREGISTER

Fig. 9 zeigt ein bevorzugtes Codierer-Speicherregister 300, um Codeflußinformation zu speichern. Das Register 300 umfaßt 32 Bits mit folgenden Zuordnungen. Die Bits 31-24 stellen 8 Flag- Bits dar, das 31-te Bit stellt ein "Vorzeichen"-Bit dar. Den Bits 23 und 22 ist keine Aufgabe zugeschrieben. Bit 21 ist ein Empfänger für einen Übertrag, der sich fortpflanzen kann. Die Bits 20 bis 13 (als bbbbbbbb bezeichnet) stellen das letzte vorhergehende 8-Bit Byte der Codeflußdaten dar. Jeweils nach 8 Verschiebungen stellen die Bits 20 bis 13 ein Byte dar, das in den Pufferspeicher auszulagern ist. In Bitposition 12 ist ein Abstandsbit, das zur Übertragsfortpflanzung dient. Die Bits 11 bis 0 stellen den jüngsten Teil der Codeflußdaten dar. Die Bits 11 bis 0 werden als der "Bruchteil" des Codeflusses bezeichnet, und die Bits 20 bis 12 gehören zum "ganzzahligen Teil" des Codeflusses. Das Register 300 wird als X-Register bezeichnet und enthält den zuletzt codierten Teil des Codeflusses CS. Bevor die Bits im X-Register codiert werden, können Tausende von Bits zuvor codiert worden sein. Diese früheren Bits wandern durch den Bruchteil des X-Registers in den ganzzahligen Teil des Registers und von dort in den Pufferspeicher, der eine endliche Zahl von Vorgängerbits speichert. Wenn gewünscht, können Bytes vom Pufferspeicher in den Speicher übertragen werden oder zu einer anderen Stelle übertragen werden, wo die Decodierung durchgeführt wird.
Gemäß der Erfindung werden Daten in Bytes strukturiert und als Bytes ausgelagert. Dies wird durch die Flag-Bits erreicht. Durch Initialisierung der 8 Flag-Bits mit 00000001 wird kenntlich gemacht, daß das 1-Bit sich nach links verschiebt, wenn nachfolgende b-Bits in den ganzzahligen Teil des, Registers 300 geschoben werden. Wenn das am weitesten links stehende Flag-Bit 1 wird, werden die Inhalte des X-Registers als "negativ" betrachtet. Bei der nächsten Verschiebung wird der Integerteil des X- Registers 300 in den Pufferspeicher eingegeben.
Vorzugsweise ist der Pufferspeicher (nicht gezeigt) ein Speicher, der zum Beispiel 256 Bytes speichert. Ein Pufferzeiger BP kennzeichnet das Byte B, das zuletzt in den Pufferspeicher eingegangen ist.
Zusätzlich zum X-Register gibt es ein A-Register (nicht gezeigt), um den Wert des aktuellen Intervalls zu speichern. Wie oben ausgeführt, wird das aktuelle Intervall zwischen vorgeschriebenen Grenzen gehalten, zum Beispiel zwischen 0,5 und 1. Das A-Register umfaßt einen "Bruch"-Teil aus 12 Bits, der mit dem Bruchteil des X-Registers ausgerichtet ist, und auch einen ganzzahligen Teil enthält.
Die Ausrichtung der Bruchteile des X-Registers und des A-Registers erleichtert die verschiedenen Rechnungen, die zur Aktualisierung des Codeflusses durchgeführt werden. Es sei nochmals festgestellt, daß jedesmal, wenn das Intervall renormiert wird, um es in die Grenzen zurückzuführen, der Codefluß gleichermaßen renormiert wird, um seine relativen Werte beizubehalten. Es sei daran erinnert, daß die Renormierung lediglich einige Linksverschiebungen umfaßt (d. h. Multiplikation mit 2), wenn die Begrenzungen der Intervallgröße auf 0,5 und 1 gesetzt werden.
Nachdem ein Codebyte im Pufferspeicher abgelegt ist (und kein ÜBERTRAG vorliegt), werden die Inhalte des X-Registers 300 mit '1FFF' (in Hexadezimalschreibweise) logisch UND-verknüpft, um die Codebyte-Bits 20 bis 13 zu entfernen, während die Bits 12 bis 0 bewahrt werden. Anschließend wird das X-Register auf X ODER '1 00 00 00' (Hexadezimalschreibweise) gesetzt, wobei sichergestellt wird, daß das Bit 24 (der Flag-Bits) auf 1 gesetzt wird.
In Fig. 10 wird ein bevorzugtes 32-Bit Decodiererregister 400 gezeigt, das bei einer P/Q-Hardwareimplementierung benutzt wird. Die Bit-Zuweisungen umfassen: vier führende Null-Bits, denen 12 "Bruch"-Bits folgen, denen wiederum 8 Bits für neue Daten folgen. Die 8 niederwertigsten Bits entsprechen Flag-Bits. Das Register 400 kann auf unterschiedliche Art und Weise als ganzes Wort, halbe Wörter oder Bytes eingeteilt werden. Die 12 Bits des Bruchteils sind mit den Bruchbits des Erstsummanden ausgerichtet, die in einem A-Register des Decodierers gespeichert sind.
Nachdem ein vorhergehendes Datenbyte nach XC (Bits 31 bis 16) geschoben ist, wird ein neues Datenbyte in die höheren Bits von XNEW (Bit 15 bis Bit 0) invertiert, und XFLAG (Bit 7 bis Bit 0) wird auf 1 rückgesetzt, es sei denn, ein Übertrag ist aufgetreten. Das heißt,
XNEW = hex'FF00' - SLL B 8 (SLL ("shift left single") bezeichnet den Befehl "Schiebe um ein Bit nach links) XFLAG = 1.
Die obige Angaben für XNEW führen zu einer Subtraktion des neuen Byte B von 'FF'-Bits.
Wenn XFLAG, das unten angeordnete Byte, Null wird, wird ein neues komprimiertes Datenbyte gebraucht.

D. ÜBERTRAGE und ABZÜGE

Der obigen Überblick über Codierer und Decodierer zeigt, daß die einzige Stelle, an der die Codeflüsse sich gegebenenfalls unterscheiden, die ist, wo bei einer gegebenen P,Q-Vorschrift ein ÜBERTRAG oder ABZUG auftreten.
An dieser Stelle sei festgestellt, daß ÜBERTRAGe und ABZÜGe an Bytegrenzen vorgesehen sind. Die Auswirkung jedes ÜBERTRAGs oder ABZUGs pflanzt sich somit nicht über das letzte ausgelagerte Byte hinaus fort. Daher braucht der Pufferzeiger niemals frühere Bytes zu sichern, sondern kann statt dessen fortschreiten, um auf nachfolgende Bytes zu zeigen, sobald eines in den Pufferspeicher eingeht.
Das Problem der ÜBERTRAGs-Fortpflanzung tritt auf, wenn der Codefluß aktualisiert wird, indem sein Wert erhöht wird, und wenn ein oder mehrere aufeinanderfolgende Bytes von codierten Daten jeweils eine Folge von 1-Bits enthalten. In diesem Fall führt eine Summation zu einer Übertragsfortpflanzung. Um diese Situation zu vermeiden, sieht die vorliegende Erfindung vor, daß ein Bit in ein Byte gestopft wird, um einen ÜBERTRAG zu empfangen, der erzeugt werden könnte. Es sei zum Beispiel eine Folge von Bytes Bn-1, Bn, Bn+1 gegeben, von denen sich Bn-1 im Pufferspeicher befindet, wobei der Pufferzeiger das Byte Bn-1 identifiziert. Byte Bn befindet sich im ganzzahligen Teil des X- Registers, und Bn+1 befindet sich im Bruch-Teil des X-Registers.
Wenn der Wert des Byte Bn gleich 'FF' ist (in Hexadezimalschreibweise), bekommt das nächste Byte Bn+1 ein gestopftes Bit an seiner führenden (höchstwertigen Bit-) Position. Wenn Bn und Bn+1 11111111 ('FF') bzw. 11111111 ('FF') ergäben, würde die vorliegende Erfindung ein Bit an den Anfang von Bn+1 stopfen, so daß die neue Folge codierter Daten 11111111, 01111111, 1 . . . wäre, wobei das 0-Bit ein gestopftes Bit ist, um gegebenenfalls einen Übertrag aufzunehmen. Wenn der Decodierer ein Byte aus lauter 1-Bits feststellt, interpretiert er das nächste niederwertige Bit als ein gestopftes Bit und verarbeitet es entsprechend, um den richtigen Codeflußwert zu erzeugen. Beim vorliegenden Ausführungsbeispiel werden zwei Bits gestopft. Damit wäre die neue Folge 11111111, 00 111111, 11 . . .
Das Problem der ABZUGs-Fortpflanzung tritt auf, wenn der Codefluß, der verringert werden kann, ein Byte aus lauter 0-Bits umfaßt. Angenommen, es treten drei aufeinanderfolgende Bytes Bn-1, Bn, Bn+1 auf, von denen das mittlere Byte aus lauter Nullen besteht.
Gemäß einem ersten Regelsatz würde am Byte Bn-1 ein Vorabzug vorgenommen werden, indem es um eins reduziert wird. Bn wird in acht 1-Bits umgewandelt. Der Rest wird eingeschlossen, indem an der 2-ten führenden Bitposition von Byte Bn+1 ein gestopftes Bit eingefügt wird, so daß die acht auf Bn folgenden Bits eine Null (zu Steuerwort-Zwecken) und ein gestopftes Bit plus 6 Bits codierter Daten enthalten. Der vom Codierer übertragene Datenfluß ist dann:
(Bn-1-1), 11111111, 0b (führende sechs Bits von Bn+1)
Die zwei unteren Bits, die vom Bn+1-Bytesegment abgeschnitten sind, werden im nächsten Bytesegment der Daten aufgegriffen. Der ABZUG ist praktisch in einen ÜBERTRAG umgewandelt worden. Der Decodierer interpretiert die gestopften Bits in jedem Fall als solche und verarbeitet die gestopften Bits als einen ÜBERTRAG.
Da es das Ziel ist, einen P/Q-Softwarecodefluß zu erzeugen, der mit einem P/Q-Hardwarecodefluß, der Bitstopfen einschließt, kompatibel ist, muß der Codefluß unter zwei Einschränkungen erzeugt werden. Erstens muß jedem hexadezimalen 'FF' ein gestopftes Bit folgen. Andernfalls würden für den Hardwarecodierer unzulässige Bitmuster erzeugt. Zweitens muß der Codefluß so aufgebaut sein, daß, sobald ein Abzug vom vorliegenden Byte erforderlich ist, dieser definitionsgemäß möglich ist (Das vorliegende Byte ist das Byte, das während des vorhergehenden Code-Bytezyklusses vom Coderegister zum Codepuffer übertragen worden ist.). Da nur eine Einheit abgezogen wird, ist der einzige Bytewert, von dem nichts abgezogen werden kann, die Null.
Im allgemeinen wird die Notwendigkeit des, Abzugs vom vorliegenden Byte angezeigt, indem im Coderegister ein "Vorabzugs"-Bit hoher Ordnung an den Anfang eines neuen Byte eingesetzt wird. Der Bequemlichkeit halber wird es an eine Bitposition, P, gesetzt, die das Vorzeichenbit wird, wenn das nächste Byte zum Schreiben bereit ist. Es sei zum Beispiel angenommen, daß mit einem 32-Bit Code-(X-)Register folgende Registereinträge vorlägen:
X-Register:
00000000,P0000000, xxxxxxxx,xxxxxxxx
A-Register:
000aaaaa, aaaaaaaa
Wenn das nächste Byte abgeschlossen ist, ergeben sich folgende Inhalte:
X-Register:
P0000000,nnnnnnnn, xxxxxxxx, xxxxxxxx
A-Register:
000aaaaa, aaaaaaaa
Wenn das Coderegister positiv ist (P = 0), ist der Vorabzug verwendet worden, und es wird ein Abzug vom vorliegenden Byte benötigt. Der Abzug wird daher vom vorliegenden Byte genommen, bevor das neue Byte, nnnnnnnn, vom Coderegister zum Puffer übertragen wird. Wenn der Vorabzug verwendet wird, ist der Wert im Coderegister immer größer als im A-Register, und künftige Abzüge können aus den Coderegistereinträgen genommen werden. Wenn das Coderegister negativ (P = 1) ist, wird kein Abzug vom aktuellen Byte benötigt, und der ungenutzte Vorabzug, P, wird entfernt.
Das Code-(X-)Register wird mit dem A-Register verglichen. Wenn das Coderegister kleiner ist, werden zwei Dinge angezeigt. Erstens ist das nächste auszulagernde Byte (nnnnnnnn) Null. Zweitens könnte ein Abzug vom aktuellen Byte benötigt werden. Daher wird ein Abzug vom aktuellen Byte genommen und im Register durch das Null-Byte geschoben. Dies wandelt das Null-Byte in 'FF' um. Nachdem dieses 'FF' in den Codepuffer ausgelagert ist und der Inhalt des Coderegisters weitergeschoben ist, werden zwei Vorabzüge gesetzt, einer in die Position, die zum Vorzeichenbit werden wird, und der andere in die Position des stbertrag'-Bits für das nsächste Byte. Also, wenn das Coderegister kleiner ist als das A-Register,
X-Register:
00000000,P0000000, 00Px,xxxx,xxxxxxxx
A-Register:
000aaaaa, aaaaaaaa
und wenn das nächste Byte vollständig ist,
X-Register:
P0000000, Pnnnnnnn, xxxxxxxx, xxxxxxxx
A-Register:
000aaaaa, aaaaaaaa
Das hexadezimale 'FF' im Puffer leitet das Bitstopfen ein, so daß das Vorabzugsbit in die Stopfbit-(Übertragsempfänger-)Position geschrieben wird. Ein ungenutzter Vorabzug ist somit einem Übertrag des Hardwarecodeflusses gleichwertig. Wenn das Coderegister nicht kleiner ist als das A-Register, sind die aktuellen Einträge des Coderegisters groß genug, um jede Abzugsanforderung erfüllen zu können. Das aktuelle Byte wird überprüft, und wenn es 'FF' ist, wird Bitstopfen eingeleitet. In diesem Fall, da kein Vorabzug erforderlich war, ist das gestopfte Übertragsbit immer gelöscht.
Obige Abfolge erfüllt alle Anforderungen; sie erzeugt einen Codefluß, der die Abzugsfortpflanzung blockiert und der mit der Hardware kompatibel ist. Wenn alle Null-Bytes einfach in 'FF' umgewandelt würden, könnte ein Hardwaredecodierer den sich ergebenden Codefluß decodieren. Jedoch wird der sich ergebende Codefluß durch das Voraus schauen, um festzustellen, ob ein Abzug gebraucht werden könnte, wenn das auszulagernde Byte Null ist, zu einem mit dem Hardwarecodefluß identischen Codefluß gemacht. Praktisch zeigt dieses Vorausschauen das Auftreten von 'FF' im Hardwarecodefluß an.
Wenn es gewünscht wird, kann ein vollständig äquivalentes, auf Null-Bytes folgendes inverses Bitstopfen eingerichtet werden, wobei die Hardware das Vorausschauen nach dem 'FF'-Muster ausführt, um festzustellen, ob ein Überlauf nach '00' möglich sein könnte. Ein solches Verfahren würde das Blockieren des Abzugs in einer Weise analog dem oben beschriebenen Blockieren des Übertrags vorsehen.

IV. BESCHREIBUNG DER FLUSSDIAGRAMME

In den folgenden Flußdiagrammen wird Q der Bequemlichkeit halber als Festkommabruch mit 12 signifikanten Bits definiert. Andere auf die Flußdiagramme anwendbare Definitionen werden unten geliefert.
"A" ist eine 16-Bit-Ganzzahl, kann aber als binärer Bruch angenommen werden, bei dem das binäre Komma so gesetzt ist, daß 12 Bruch-Bits und 4 Ganzzahl-Bits zur Verfügung stehen. Die drei führenden Ganzzahl-Bits sind immer Null. Das niederwertigste Ganzzahl-Bit ist bei diesem Ausführungsbeispiel nur bei der Initialisierung von Null verschieden.
A · Q stellt den neuen LPS-Bereich dar. Bei einem Schrägcodierer, wie er in dem zuvor erwähnten Langdon-Artikel beschrieben ist, wäre dies 2**-k. Andere Charakterisierungen können in Übereinstimmung mit der vorliegenden Erfindung ebenfalls benutzt werden. In den Flußdiagrammen wird angenommen, daß A · Q eine Multiplikation mit einer Genauigkeit von 32-Bit ist. Das Ergebnis wird 12 Bits nach rechts verschoben, und die 16 niederwertigsten Bits werden dann für den neuen LPS-Bereich genommen.
LEN ist die Länge des Puffers für den Codefluß. Sie wird auf 256 Bytes gesetzt (eine willkürliche, aber geeignete Wahl). LEN könnte auf 1 gesetzt werden.
BPST zeigt auf den Anfang des Puffers mit komprimierten Daten.
BE zeigt auf das erste Byte außerhalb des Puffers mit komprimierten Daten.
BP ist der Zeiger auf das aktuelle Byte aus komprimierten Daten.
B ist das Byte aus komprimierten Daten, auf das BP zeigt.
AMIN ist ein Referenzwert um festzulegen, wann Renormierung notwendig ist. Für dieses Ausführungsbeispiel ist AMIN auf X'0800' gesetzt (was gleich 0,5 ist). Wenn A unter 0,5 fällt, tritt Renormierung ein.
BRW ist die Abzugs-Flag in der invertierten Softwareversion.
T ist eine temporäre Variable, um den neu berechneten LPS-Bereich zu speichern.
Die Variablen X, XC, XNEW und XFLAG entsprechen den hier oben gegebenen Definitionen (mit Bezug auf Fig. 9 und 10).
Mit Bezug auf Fig. 11 wird ein grundlegendes Flußdiagramm 500 gemäß der vorliegenden Erfindung zur Datenkomprimierung-Dekomprimierung gezeigt. Nach dem START wird der Codierer gemäß den Schritten von INITENC initialisiert. In INITENC werden Variablen aus obiger Auflistung Anfangswerte zugeordnet. Von einem Modell- und Wahrscheinlichkeitsgenerator (wie 106 in Fig. 1) werden MPS-, Q- und YN-Daten erhalten, um gemäß der Prozedur ENCODE codiert zu werden. Die Codierungsoperation wird so lange fortgesetzt, wie Eingangsdaten empfangen werden. Wenn die Codierung beendet ist, wird das Programm FLUSH aufgerufen. Die codierten Daten werden übertragen (oder übermittelt). Einige Zeit nach der Übertragung werden die codierten Daten normalerweise decodiert. Der Decodierer wird durch INITDEC initialisiert und, wenn MPS- und Q-Eingabedaten von einem Modell- und Wahrscheinlichkeitsgenerator (siehe Element 110 in Fig. 1) gegeben sind, werden YN- Ereignisse mit einer DECODE-Prozedur decodiert. Das Decodieren hält an, bis alle YN-Ereignisse zurückgewonnen sind.
Die Teilprozeduren eines allgemeinen Flußdiagramms sind in codierungsbezogene und decodierungsbezogene Prozeduren eingeteilt und werden unten getrennt erörtert.

A. Codiererbezogene Prozeduren

INITENC (Fig. 12, Fig. 13 und Fig. 14) führt die Initialisierung des Codierers durch. Drei Versionen von INITENC sind implementiert worden, abhängig davon, ob die in Fig. 2 gezeigte Hardwareversion (-H), die in Fig. 3 gezeigte invertierte Version (- I) oder die in Fig. 4 gezeigte Softwareversion (-S) implementiert ist. Alle Versionen initialisieren LEN mit 256 Bytes, setzen BE auf das Ende des Puffers mit den komprimierten Daten und setzen BP ein Byte vor BPST, den tatsächliche Anfang des zu sendenden Puffers. Der Zeiger wird aktualisiert, bevor ein Byte geschrieben wird; folglich ist ein Offset von 1 erforderlich. Das Byte B (durch BP adressiert) wird mit '80' initialisiert, um sicherzustellen, daß die Spezialfälle B=0 oder B='FF' nicht als erstes Byte in den komprimierten Datenfluß eingeführt werden. Der Bereich A wird mit '1000' initialisiert, und AMIN wird mit der Hälfte dieses Wertes ('0800') initialisiert. Die Unterschiede zwischen den Versionen treten bei der Initialisierung von X auf. Bei allen Versionen wird das 8-te MSB (most significant bit) auf 1 gesetzt um zu signalisieren, wenn 8 komprimierte Bits fertig sind. Die invertierte Version hat im 20- ten werthöchsten Bit einen Vorabzug (Bit s in Fig. 9), während die Softwareversion ihn gleich hinter der Flag einfügt und X auch an das obere Ende des Bereichs A setzt. Bei der invertierten Version wird die Abzugsflag BRW zu Null gesetzt.
ENCODE (Fig. 15, Fig. 16 und Fig. 17) codiert eine ja/nein-Entscheidung für gegebene MPS- und Q-Eingaben. Jedesmal wird der neue LPS-Bereich berechnet und temporär in T gespeichert. Bei diesen Ausführungsbeispiel sind A und Q Zahlen fester Genauigkeit mit zwölf Bits hinter dem binären Komma. Nach der Multiplikation wird das Ergebnis durch zwölf Verschiebungen nach rechts auf eine Genauigkeit von 12 Bits abgeschnitten.
Auf dem MPS-Pfad erhöht die Hardwareversion X um T und vermindert A um T. Die anderen beiden Versionen brauchen A vor der MPS-Prüfung nur um T zu vermindern, da der neue MPS-Bereich sowohl auf dem MPS- als auch auf dem LPS-Pfad gebraucht wird. Eine Renormierung von A und X, die in RENORME (Fig. 18) durchgeführt wird, ist auf dem MPS-Pfad nur erforderlich, wenn A kleiner als AMIN ist. Die I- und S- Versionen müssen X auf dem LPS-Pfad um den Betrag des MPS-Bereichs bewegen, wenn auch in unterschiedliche Richtungen. Alles Versionen setzen A vor der Renormierung auf den neuen LPS-Bereich zurück. Da A · Q immer kleiner als AMIN ist, wird RENORME auf dem LPS-Pfad immer gebraucht.
RENORME (Fig. 18) normiert die A- und X-Werte bitweise. A wird zuerst verschoben, und dann wird X geprüft, um festzustellen, ob das werthöchste Bit gesetzt ist. Wenn dies der Fall ist, entfernt die folgende Verschiebung von X dieses Flagbit, und durch BYTEOUT (siehe Fig. 19, Fig. 20 und Fig. 21) wird ein Byte ausgegeben. Andernfalls wird X gerade um ein Bit verschoben. Dieser Vorgang wird so lange wiederholt, wie A kleiner als AMIN ist.
BYTEOUT (Fig. 19, Fig. 20 und Fig. 21): Der Decodierer erwartet, daß auf jedes 'FF' im nächsten Byte unmittelbar zwei führende, gestopfte Bits folgen. Das führende Bit ist für komprimierte Daten immer Null. Das zweite werthöchste Bit ist das Übertragsbit. Ein Schlüsselteil dieser Erfindung für alle drei Codiererversionen besteht darin, identisch komprimierte Datenflüsse zu erzeugen und der Hardware- und Softwareimplementierung zu erlauben, dazu unterschiedliche Versionen mit minimaler Berechnung zu wählen.
In Fig. 19 betrachtet die Hardwareversion zuerst das letzte Byte B und gibt sofort nur 6 Datenbits in SHIP6-H (Fig. 22) aus, wenn B gleich 'FF' ist. Jeder Übertrag erscheint im zweiten werthöchsten Bit des neuen Bytes. Wenn B kleiner als 'FF' ist, wird X auf einen Übertrag hin geprüft. Das heißt mit Bezug auf Fig. 9, ob das Übertragsbit in Position 21 gesetzt ist. Wenn dort kein Übertrag vorliegt, können 8 Bits in SHIP8-H (Fig. 25) ausgegeben werden. Wenn ein Übertrag vorliegt, muß das letzte Byte um 1 erhöht und das Ergebnis daraufhin geprüft werden, ob es jetzt 'FF' ist. Wenn dies der Fall ist, muß der Übertrag in X, der bereits zu B addiert ist, gelöscht werden, bevor die nächsten 6 Bits ausgegeben werden. Andernfalls können 8 Bits in das neue Byte ausgegeben werden.
In Fig. 20 prüft die Version von BYTEOUT für den invertierten Codierer zunächst, ob X groß genug ist, um einen Abzug von B zu verlangen. Ist dies der Fall, wird er von BIGX (Fig. 30) durchgeführt. Andernfalls wird die Summe aus X und A mit dem Schwellenwert für mögliche zukünftige Abzüge verglichen, um festzustellen, ob SHIP8FF-I (Fig. 28) der geeignete Weg ist. Wenn nicht, bestimmt das aktuelle B, ob 6 oder 8 Bits ausgegeben werden.
Die Softwareversion BYTEQUT-S (Fig. 21) prüft, ob X positiv ist. Wenn X positiv ist, ist das Abzugsbit verwendet worden, und B muß um 1 verkleinert werden, bevor 8 Bits ausgegeben werden. Wenn das Abzugsbit noch gesetzt ist, wird es aus X gelöscht, bevor A mit X verglichen wird. Wenn X kleiner als A ist, könnte in Zukunft ein Abzug benötigt werden, der nicht zur Verfügung stünde, wenn das neue Byte als Null ausgegeben würde (A ist meistens '0FFF', so daß X nur Nullen in den 8 Ausgabebits stehen hat.). SHIP8FF-S (Fig. 29) führt den Vorabzug aus, wandelt das neue Byte in 'FF' um und speichert das abgezogene Bit in X. Wenn B gleich 'FF' ist, werden statt der 8 Bits durch SHIP8-S (Fig. 27) nur 6 Bits durch SHIP6-S (Fig. 24) ausgelagert.
SHIP6-H (Fig. 22) erhöht den Ausgabebytezeiger in NEXTBYTE (Fig. 31) und speichert im neuen B die Bits 22 bis 15 von X. Es ist sichergestellt, daß das führende Bit Null ist. Das zweite Bit enthält irgendeinen Übertrag. Nur die letzten 15 Bits werden in X belassen, bevor die Flag beim 6-ten werthöchsten Bit eingesetzt wird. Dies bewirkt, daß das neue Byte ausgegeben wird, wenn 6 neue Bits fertig sind, da 2 in X belassen worden sind. SHIP6-S (Fig. 24) ist mit SHIP6-H identisch, nur daß das Abzugsbit gleich nach dem Flagbit gesetzt wird.
Der invertierte Codierer beinhaltet einen komplizierteren Prozeß wie er in SHIP6-I (Fig. 23) dargestellt ist, um 6 Bits auszugeben, da die Bits in X invertiert werden müssen. Der Ausgabezeiger wird durch NEXTBYTE erhöht. Wenn BRW gesetzt ist, hat ein Abzug das vorhergehende 'FF' erzeugt. Die 6 Bits plus einem möglichen Übertrag werden dann von 7 '1'-Bits abgezogen und der BRW wird rückgesetzt. Wenn nicht, dann werden nur 6 '1'-Bits verwendet, um die 6 Bits zu invertieren, da in X kein Übertrag vorhanden sein kann, wenn das vorangehende Byte 'FF' ist. Das werthöchste Bit in B wird gelöscht, und alle bis auf die 15 niederwertigsten Bits in X werden gelöscht. Das Flagbit wird dann in die 6-te Position der werthöchsten Bits eingesetzt.
SHIP8 (wie in Fig. 25, Fig. 26 und Fig. 27 gezeigt) ist für alle Versionen ähnlich. Nachdem der Zeiger zum nächsten Byte B erhöht worden ist, werden die 8 Bits aus X an den Positionen 20-13 in B gespeichert. Die invertierte Version invertiert diese Bits zunächst, indem sie von 'FF' abgezogen werden. Alle bis auf die 13 niederwertigsten Bits werden in X gelöscht, und das Flagbit wird beim 8-ten werthöchsten Bit eingesetzt. Die Softwareversion setzt nach dem Flagbit auch ein Abzugsbit ein.
Die invertierte Codiererversion und die Softwarecodiererversion müssen sicherstellen, daß B verkleinert werden kann, falls es notwendig sein sollte. So müssen in SHIP8FF-I (Fig. 28) 6 Bits ausgelagert werden, wenn das Abzugsflag gesetzt ist (d. h. wenn B gleich 'FF' ist). Wenn BRW Null ist, wird B verkleinert, bevor der Ausgabezeiger erhöht wird, das nächste Byte wird auf 'FF' gesetzt, und das BRW-Bit wird gesetzt, um für das nächste Byte verwendet zu werden.
Die Softwareversion SHIP8FF-S (Fig. 29) verkleinert B immer, bevor 'FF' im nächsten Byte gespeichert wird. Der zusätzliche Abzug wird in X eingesetzt, von wo er als Übertrag ans nächste Byte übergeben wird, wenn er nicht gebraucht wird.
BIGX (Fig. 30) wird nur für die invertierte Version gebraucht. Wenn das Abzugsbit gesetzt ist, werden 6 Bits ausgelagert. Andernfalls kann es B verkleinern und 8 Bits auslagern.
NEXTBYTE (Fig. 31) bewegt BP, um das nächste Byte im Puffer mit komprimierten Daten anzusprechen. Wenn BP nach der Erhöhung nicht kleiner als das Ende des Puffers ist, muß der Puffer übertragen werden und an den Anfang des Puffers zurückgesetzt werden. Es ist vorausgesetzt, daß BPST und BE nötigenfalls geeignet verändert werden.
Nachdem das letzte Symbol codiert ist, müssen die noch in X befindlichen 21 komprimierten Datenbits ausgestoßen werden. In FLUSH-H (Fig. 32) wird CT mit 21 initialisiert und bei jeder Verschiebung in X vermindert, bis das Flagbit das werthöchste Bit ist (wodurch das Vorzeichen von X negativ wird). Eine weitere Verschiebung setzt die Ausgabebits auf eine Bytegrenze. Dann kann FINALBYTES-H (Fig. 35) diese letzten Bytes ausgeben.
FLUSH-I (Fig. 33) muß zunächst die Größe des letzten Erstsummanden A minus 1 zu X addieren. Die abgezogene 1 entspricht der oben beschriebenen u-Subtraktion. Die Bits sind dann zu Bytes zusammengefügt, so daß FINALBYTES-I (Fig. 36) die verbliebenen Bytes ausstoßen kann.
FLUSH-S (Fig. 34) bewegt X zum unteren Teil des Intervalls, wo es dann genau bei dem Wert positioniert wird, der von der Hardwareversion erzeugt wird. Nachdem die Bits zu Bytes zusammengefaßt sind, muß das letzte Byte verkleinert werden, wenn der Abzug gebraucht worden ist, bevor die letzten Bytes in FINALBYTES- S (Fig. 37) ausgegeben werden.
FINALBYTES-H (Fig. 35) durchläuft in einer Schleife dieselbe Art von Operationen wie BYTEOUT-H (Fig. 19), bis alle Bits ausgestoßen sind. Die Blöcke FLUSH6-H und FLUSH8-H schließen geeignete Verringerungen von CT um 6 oder 8 Bits ein. Ist dies abgeschlossen, wird BP erhöht, nachdem das letzte Byte gespeichert ist, und der letzte Puffer kann ausgegeben werden.
FINALBYTES-I (Fig. 36) ähnelt BYTEOUT-I, außer daß X + A > '200000' nicht auftreten kann, da A von X abgezogen worden ist, das kleiner als '200000' war. Das letzte Byte kann wegen des Invertierungsprozesses zusätzlich angehängte '1'sen haben. Diese müssen entfernt werden, wenn ein identischer Codefluß gewünscht wird.
Die Softwareversion von FINALBYTES-S (Fig. 37) umfaßt das Auslagern von 6 oder 8 Bits, je nachdem, ob das vorhergehende Byte 'FF' ist. Der Vorabzug ist bereits in FLUSH-S bearbeitet worden. Da X zum unteren Teil des Intervalls bewegt worden ist, ist die Prüfung mit A in BYTEOUT-S überflüssig.
In FLUSH6-H,S (Fig. 38) werden sowohl bei der Hardware- als auch bei der Softwareversion 6 Bits ausgegeben, indem auf das neue Byte gezeigt wird, die Bits 22-15 gespeichert werden, nur die 15 niederwertigsten Bits von X gesichert werden, X um 6 Stellen verschoben und CT um 6 vermindert wird. In FLUSH6-I (Fig. 39) muß die invertierte Version jene Bits in X auch invertieren, während der Abzug geeignet durchgeführt wird.
In FLUSH8-H,S (Fig. 40) werden sowohl bei der Hardware- als auch bei der Softwareversion 8 Bits ausgegeben, indem auf das neue Byte gezeigt wird, die Bits 20-13 gespeichert werden, nur die 13 niederwertigsten Bits von X gesichert werden, X um 8 Stellen verschoben und CT um 8 vermindert wird. In FLUSH8-I (Fig. 41) muß die invertierte Version auch jene 8 Bits invertieren.

B. Decodiererbezogene Prozeduren

INITDEC (Fig. 42, Fig. 43, Fig. 44) führt die Initialisierung für den Decodierer durch. Von INITDEC sind drei Versionen implementiert worden, abhängig davon, ob der Decodierer sich auf die optimale Hardware (H) oder die optimale Software (S) bezieht oder invertierte Symbolordnung (I) einschließt (siehe die Decodierer 210 bis 216 in Fig. 5). Alle Decodiererversionen beginnen damit, daß sie einen neuen Puffer komprimierter Daten erhalten. Dies wird für die Initialisierung von BPST und LEN vorausgesetzt. BE wird auf das Byte hinter dem Ende des komprimierten Puffers gesetzt, und BP wird beim Initialisieren an den Anfang des Puffers gesetzt. Der Bereich A wird mit '1000' initialisiert; für S-'1000'. AMIN wird für die Hardware- (H-)Version und die invertierte (I-)Version mit '0800' initialisiert. Bei der Software (S-)Version wird AMIN anfangs auf -'0800' gesetzt.
Unterschiede zwischen den Versionen treten auch bei der Initialisierung von X auf. Bei INITDEC-H werden die ersten beiden Bytes in den Bits 28-13 im Decodierer-X-Register 400 in Fig. 10 plaziert. Das führende Bit des komprimierten Datenflusses ist 0, also wird es ins Bit 28 geschoben. Das erste Byte wird in die Positionen 28-21 geschoben, der Zeiger BP wird in GETBYTE (Fig. 50) erhöht, und dann wird das zweite Byte in die Bits 20-13 hinzugefügt. Es ist sichergestellt, daß das führende Byte nicht 'FF' ist, so daß keine Prüfung erforderlich ist. Der Decodierungsprozeß sieht nur auf die Bits in XC, die zwei oberen Bytes von X (Bits 31-36). Das Flag, das anzeigt, daß ein neues Byte gebraucht wird, wird wegen der führenden 0 im Codefluß bei Bit 5 plaziert. In INITDEC-I (Fig. 43) wird X mit 15 '1'-Bits in den Positionen 27-13 initialisiert, und Bit 5 wird gesetzt (welches die "neues-Byte-benötigt"-Flag ist). Dann können die ersten zwei Bytes von den Bits 28-13 abgezogen werden. In Fig. 44 arbeitet der Softwaredecodierer INITDEC-S im Intervall von -1 bis 0. A wird mit -1 initialisiert, d. h. mit (-X'1000'). Der Renormierungspunkt ist -0,5, dargestellt als -X'0800'. Das anfängliche A wird von 0 abgezogen, um XC auf 'F000' zu setzen. Das Flagbit wird als 5-tes Bit gesetzt, und das erste Byte wird in die Bits 28 bis 21 hinzugefügt. Nachdem der Zeiger in GETBYTE auf das nächste Byte erhöht worden ist, wird das zweite Byte in die Bits 20 bis 13 in X hinzugefügt.
DECODE (Fig. 45, Fig. 46, Fig. 47 und Fig. 48) zeigt vier Implementierungen. Fig. 45 und Fig. 46 sind alternative Ansätze für die Hardwareversion (als -H1 und -H2 bezeichnet), während Fig. 47 die invertierte Version (-I) darstellt. In allen Fällen wird YN zunächst auf das MPS-Symbol gesetzt, und der neue LPS-Bereich wird berechnet und vorübergehend in T gespeichert. Wenn X wenigstens so groß ist wie T, folgt die Hardwareversion in DECODE-H1 (Fig. 45) dem MPS-Pfad und verkleinert sowohl XC als auch A um T. Die invertierte Version in DECODE-I (Fig. 47) verkleinert vor der Prüfung A um T, da dieser neue MPS-Bereich auch auf dem LPS- Pfad gebraucht wird. Ähnlich verkleinert die zweite Hardwareversion DECODE-H2 (Fig. 46) sowohl A als auch MPS im voraus, so als wäre das MPS aufgetreten. Bei vielen Prozessoren setzt die Subtraktion Zustandscodes, so daß die folgende Prüfung von XC gegen 0 einem Vergleich mit T vorgezogen wird. Jedoch muß der LPS-Pfad bei DECODE-H2 XC umspeichern, bevor YN invertiert wird, A auf den LPS-Bereich (T) gesetzt wird und die Renormierung in RENORMD (Fig. 49) durchgeführt wird. Ein Renormierung ist auf dem MPS- Pfad nur erforderlich, wenn A kleiner ist als AMIN. Die invertierte Version muß ebenfalls XC um den neuen MPS-Bereich A verkleinern, wenn XC wenigstens so groß ist wie A, ein Zeichen dafür, daß ein LPS aufgetreten ist. In Fig. 48 setzt die Decodierungsprozedur für die Software, DECODE-S, YN auf den MPS- Wert. Dann wird das negative A mit Q multipliziert und arithmetisch 12 Bits nach rechts verschoben, bevor es in T gespeichert wird. Das negative T wird vom negativen A abgezogen, um dessen Betrag zu verkleinern. Wenn XC größer oder gleich A ist (d. h. der Betrag von XC ist kleiner als der Betrag von A), ist ein MPS decodiert worden. Für den Fall, daß das negative A größer oder gleich dem negativen AMIN ist (d. h. der Betrag von A ist kleiner als der Betrag von AMIN), wird von RENORMD (Fig. 50) eine Renormierung durchgeführt. Wenn ein LPS decodiert worden ist, wird XC gegen Null bewegt, indem das negative A abgezogen wird. Der YN-Wert wird in den LPS-Wert umgewandelt, und A wird auf die LPS-Intervallgröße gesetzt. Eine Renormierung ist immer erforderlich.
RENORMD (Fig. 49 und Fig. 50) normiert den A- und X-Wert bitweise. In Fig. 49 werden sowohl A als auch X verschoben, und dann wird XFLAG, das niederwertigste Byte von X, geprüft, um festzustellen, ob irgendwelche Bits gesetzt sind. Wenn nicht, ist es an der Zeit, ein neues Byte zu holen. Dieser Prozeß wird so lange fortgeführt, wie A kleiner als AMIN ist. In Fig. 50 ist der Renormierungsprozeß des Decodierers für die Softwareversion RENORMD-S derselbe wie für die Hardwareversion und die invertierte Version, außer daß die Prüfung von A im Vergleich zu AMIN umgekehrt wird.
Während des Prozesses des Einbringens eines neuen Bytes in X, wie ihn BYTEIN (Fig. 51 und Fig. 52) zeigt, müssen beide Versionen das letzte Byte B prüfen, um zu sehen, ob es ein 'FF'-Byte war, bevor GETBYTE (Fig. 53) das nächste Byte einbringt. In jedes Byte, das einem 'FF' folgt, sind die 2 führenden Bits während der Codierung eingesetzt worden, und ihnen muß bei der Decodierung richtig Rechnung getragen werden. BYTEIN ist für die Hardware- und Softwaredecodierung gleich. In BYTEIN-H,S (Fig. 51) wird, wenn ein 'FF' vorgelegen hat, XNEW, die zwei niederwertigsten Bytes von X, auf den Wert 4 gesetzt, um das Flag in XFLAG mit einer 2-Bit-Verschiebung zu setzen. Auf diese Weise stellt das Flag fest, daß nur 6 Bits im Datenfluß sind und 2 für ÜBERTAGszwecke eingegliedert sind. Das nächste Byte, das normalerweise in das zweite niederwertige Byte gesetzt würde, wird um zusätzlich zwei Bits verschoben und X hinzugefügt. Wenn kein 'FF' aufgetreten ist, wird XNEW gesetzt, wie es der rechte Pfad zeigt. Die invertierte Version BYTEIN-I (Fig. 52) muß bei den führenden Bits von XNEW sechs oder acht '1'-Bits voreinstellen, um die komprimierten Daten richtig zu invertieren. Zur selben Zeit wird im niederwertigen Byte das Flagbit gesetzt. Die richtig verschobenen neuen Daten werden dann von X oder XNEW abgezogen.
GETBYTE (Fig. 53) bewegt BP, um das nächste Byte im Datenpuffer anzusprechen. Wenn BP, nachdem es erhöht worden ist, nicht kleiner als das Ende des Puffers ist, muß ein neuer Puffer erhalten werden, und BP muß auf den Anfang des Puffers rückgesetzt werden. Es wird vorausgesetzt, daß BPST und BE geeignet verändert werden, falls dies notwendig sein sollte.
Die oben beschriebenen Prozeduren für den Softwarecodierer können auf einem gewöhnlichen Großrechner implementiert werden, zum Beispiel einer IBM 3370, oder auf einem Personal-Computer wie dem IBM PC-XT oder PC-AT. Die Prozeduren können in Hochsprachen wie der Programm Development System Language (die nach vorn wirkende polnische Notation benutzt) so wie oben ausgeführt implementiert werden.

V. BESCHREIBUNG DES HARDWAREAUSFÜHRUNGSBEISPIELS

Mit Bezug auf Fig. 54 wird ein Hardwarecodierer 501 vorgestellt, der eine Codiereinheit 502 einen c/over-Ausgabepuffer (carryover- bzw. Übertragsausgabepuffer) 504 hat. Die Codiereinheit 502 erhält als Eingabe einen Q-Wert, ein MPS-Tastbit und ein YN- Entscheidungsereignis. Daraus erzeugt die Codiereinheit eine SHIFTAMT-Ausgabe, die anzeigt, um wieviel der Codefluß geschoben werden soll, eine C/OUT-Ausgabe, die einen binären Übertragsausgabewert darstellt und eine C/UNNORM-Ausgabe, die zu einem nicht normierten Codefluß aus 13 Bit gehört. Die Ausgaben der Codiereinheit 502 gehen in den c/over-Ausgabepuffer 504 ein, der als eine Ausgabe einen komprimierten CODESTRING liefert und als andere Ausgabe eine AUSGABESTEUERUNG, die anzeigt, ob null, ein oder zwei Bytes aus komprimierten Daten bereit sind.
Die Codiereinheit 502 wird in Fig. 55 im einzelnen gezeigt. Die MPS- und YN-Eingaben durchlaufen Gatter 510, dessen Ausgabe in A-LOGIK 512 eingeht, die einen geeigneten A-Wert für das aktuelle Intervall und die SHIFTAMT-Ausgabe erzeugt. Der A-Wert wird im Multiplizierer 514 mit Q multipliziert, um einen Wert A*Q zu erzeugen, der als vorübergehender Wert T gespeichert wird (A*Q wird bei der Bestimmung des nächsten Wertes für A benutzt.). Die Ausgabe des Gatters geht auch in C-LOGIK 516 ein, die C/OUT und C/UNNORM erzeugt.
Die A-Logik 514 wird in Fig. 56 im einzelnen gezeigt. Gemäß Fig. 56 geht T (oder A*Q) als Subtrahend in den Subtrahierer 520 ein, und der aktuelle A-Wert geht als Minuend ein. Wenn gemäß einem MPSOP-Eingang ein MPS codiert wird, wird der neue Wert für A(neu) von A(alt)-A*Q abgeleitet. Wenn ein LPS vorliegt, verläßt A*Q den Multiplexer 522. Die Ausgabe des Multiplexers geht in einen Prioritätscodierer 524 ein. Der Prioritätscodierer 524 zählt die Zahl der führenden Nullen auf dem A-Bus und erzeugt die Größe der Verschiebung, die gebraucht wird, um eine 1 auf das werthöchste Bit auf dem A-Bus umzuspeichern. Wenn der A-Bus keine Renormierung anfordert, ist die SHIFTAMT-Ausgabe Null. Die SHIFTAMT-Ausgabe wird an einen A-Schieber 526 übertragen, der die Verschiebung durchführt. Die Schieberausgabe wird dann in das A-Register 528 eingegeben, das einen Wert enthält, der als nächster Wert des Minuenden für den Subtrahierer 520 dient.
Eine detaillierte Abbildung der C-Logik befindet sich in Fig. 57. Der Wert T (oder A*Q) ist eine Eingabe und der vorhergehende Wert für den Codefluß eine zweite Eingabe für den Addierer 540. Wenn ein MPS-Ereignis vorliegt, ergibt die Summe C/UNNORM. Wenn ein LPS-Ereignis vorliegt, bleibt der Codeflußwert unverändert (siehe Multiplexer 542). Die Ausgabe des Multiplexers geht zusammen mit dem SHIFTAMT-Wert in einen C-Schieber 544 ein. Die aktualisierten Werte von A und C werden somit richtigerweise um denselben Betrag verschoben. Die Ausgabe des C-Schiebers 544 geht ins C-Register 546 ein, das den aktuellsten Teil des Codeflusses speichert. Je nach Bedarf werden beim Schiebevorgang Nullen in die niederwertigen Bits eingetragen. Es sei festgestellt, daß der Addierer 540 eine C/OUT-Ausgabe liefert, die für einen Übertrag kennzeichnend ist, wenn einer erzeugt worden ist.
Fig. 58 zeigt ein allgemeines Diagramm des Decodiererteils 600 eines optimalen P/Q-Hardwareausführungsbeispiels. Q und MPS gehen in eine Decodiereinheit 601 ein, und der CODESTRING geht in den Eingangspuffer 602 ein. Der C/IN-Eingangspuffer 602 nimmt ein oder zwei Bytes komprimierter Daten entgegen und bringt diese Daten in serielle Form, so daß dann 12 Bits als INSTRING für die Decodiereinheit 601 zur Verfügung stehen. Das zusätzliche Übertragsbit C/IN ist eine weitere Eingabe für die Decodiereinheit 601 und ist normalerweise 0, außer wenn es manchmal einem 'FF'-Byte folgt (wie oben erörtert).
Die Ausgaben der Decodiereinheit 601 sind ein YNOUT und ein SHIFTAMT, die in den Eingangspuffer 602 zurückgegeben werden. Die Arbeitsweise der Decodiereinheit 601 wird in Fig. 59 detailliert dargestellt. Insbesondere gehen C/IN, INSTRING und MPS in die CD-Logik 604 ein, die eine erste Ausgabe liefert, die anzeigt, ob ein MPS- oder ein LPS-Ereignis decodiert wird. Diese MPSOP-Ausgabe geht zusammen mit einem T-Wert (oder aktuellen A*Q-Wert) vom Multiplizierer 608 in die A-Logik 606 ein. Wie oben beschrieben, wird der richtige neue A-Wert für ein MPS- bzw. ein LPS-Ereignis erzeugt und als Eingabe für den Multiplizierer 608 zur Verfügung gestellt. Zusätzlich wird von der A-Logik 606 eine SHIFTAMT-Ausgabe als Eingabe für die CD-Logik 604 erzeugt. Der aktuelle T-Wert geht auch in die CD-Logik 604 ein. Die CD-Logik 604 erzeugt das YNOUT als Eingabe für verschiedene Eingänge.
Fig. 60 zeigt die Operationen der CD-Logik 604 im einzelnen. Zuerst, abhängig davon, ob ein C/IN-Wert vorliegt oder nicht, wird ein T- oder (T-1)-Wert als Subtrahend zum Subtrahierer 620 gemultiplext (siehe Element 618). Der Inhalt des CD-Registers 622 stellt den Minuenden dar. Der Subtrahierer 620 liefert eine Differenzwertausgabe und eine Abzugsausgabe, falls angebracht. Der Abzug setzt eine LPS-Operation (MPSOP) voraus. C/IN ist auch ein Summand am Addierer 624, wobei der Inhalt des CD-Registers der andere Summand ist. Die Summe vom Addierer 624 wird mit der Differenzausgabe vom Subtrahierer 620 gemultiplext, wobei erstere die Ausgabe eines Multiplexers 626 ist, wenn ein Abzug vorliegt, und letztere ausgegeben wird, wenn kein Abzug vorliegt. Die gemultiplexte Ausgabe wird auf einem CD-Bus 628 weitergeleitet und geht in den CD-Schieber 630 ein. Die Verschiebungsgröße SHIFTAMT legt fest, um wieviel der CD-Bus-Wert verschoben werden muß, bevor er für die Speicherung im CD-REGISTER bereit ist. Die niederwertigen Bit werden während der Verschiebung mit den werthöchsten Bits von INSTRING belegt.
Die Decodiereinheit verwendet bis zu zwölf Bits von INSTRING plus das C/IN-Übertragseingabesignal, um die Daten zu dekomprimieren und die ursprünglichen YN-Daten zurückzugewinnen. Insbesondere sind die Abzugsausgabe und der MPS-Tastwert Eingaben für ein Gatter 634, dessen Ausgabe anzeigt, ob eine JA- oder NEIN- Entscheidung decodiert ist.
Die in Fig. 54 bis Fig. 60 gezeigte Hardware arbeitet zusammengenommen gemäß den Anforderungen, die in obigen Flußdiagrammen und obiger Beschreibung ausgeführt sind. Weitere Einzelheiten zum Hardwarecodierer 501 und -decodierer 600 werden in der Patentanmeldung mit der Überschrift "Arithmetic Coding Encoder and Decoder System", Erfinder G.G. Langdon jr., J.L. Mitchell, W. Pennebaker und J. Rissanen, bekanntgemacht, die zusammen mit dieser Patentschrift eingereicht ist.
Obwohl die Erfindung mit Bezug auf bevorzugte Ausführungsbeispiele beschrieben worden ist, ist für den Fachmann klar, daß verschiedene Änderungen an Form und Details durchgeführt werden können, ohne den Bereich der Erfindung zu verlassen. Obwohl das beschriebene Ausführungsbeispiel sich zum Beispiel auf eine binäre arithmetische Codierungsumgebung bezieht, liegt es innerhalb des Bereichs der Erfindung, arithmetische Codierung und Decodierung in Hardware und Software in einer Multisymbolumgebung zur Verfügung zu stellen, in der Entscheidungen mehr als zwei mögliche Ausgaben haben. Das heißt, daß gemäß der vorliegenden Erfindung Intervalle betrachtet würden, die in mehr als zwei Segmente eingeteilt sind, z. B. in ein a-, b-, c- und d-Segment, wobei ein erster Codierer den Codepunkt ans untere Ende des aktuellen Intervalls setzen und nur Erhöhungen (aber keiner Verkleinerung im Wert) unterliegen würde, während ein zweiter Codierer den Codepunkt ans obere Ende des aktuellen Intervalls setzten und nur Verkleinerungen (aber keiner Erhöhung im Wert) unterliegen würde.
In einer solchen Umgebung wäre die Bestimmung des Wertes des ersten Summanden A und des Codepunktwertes C (oder Z) analog zur Vorgehensweise in einer binären Codierungsumgebung. Angenommen, die Ereignisse a/b/c/d befänden sich in absteigender Anordnung entlang eines Intervalls auf der Wahrscheinlichkeitsgeraden, wobei die entsprechende Wahrscheinlichkeiten 0,5, 0,125, 0,25 und 0,125 sind.
Die Entscheidungsereignisse sind in einer Rangfolge angeordnet, wie das P/Q bei binären Symbolen, so daß sie entlang der Zahlengeraden Abschnitte Pa/Pb/Pc/Pd bilden, wobei Pa≥Pb≥Pc≥Pd ist. Der Codierer vom Q/P-Typ würde vom unteren Ende codieren, was viele Additionen erfordern würde, um einen neuen Codeflußwert zu erzeugen. Insbesondere wird der Codefluß für einen "Hardware"- Codierer vom Q/P-Typ dargestellt durch:
Ch = iR(i)A(i) iQe(j),
wobei N(i) das ausgewählte Ereignis ist, wenn der i-te Satz aus M Ereignissen codiert wird.
Bei einem "Software"-Codierer, der eine umgekehrte Rangfolge hat, d. h. Pa≤Pb≤Pc≤Pd, folgt die Codierung folgender Formel:
Cs = A(0) - iR(i)A(i) j=N(i)+1 Qe(j).
Bei der letzteren Art der Anordnung umfaßt die Berechnung von Cs im Schnitt weniger Additionen als die Berechnung von Ch. Wenn die Summe Qe jedoch schon bekannt ist, werden beide Schemata einander beim Berechnungsvorgang sehr ähnlich.

Anhang I. Testfolge für eine kleine Datenmenge

Mit einem Zufallszahlengenerator wurde eine Testdatei so erzeugt, daß die Wahrscheinlichkeit für eine 0 in der binären Folge 0,1875 war. Die tatsächliche Zahl von Nullen in der Datei war wie erwartet 48. Der Q-Wert lag fest bei '0300' (0,1875 entsprechend einer 12-Bit-Genauigkeit). Der MPS-Wert lag fest bei 1. Daher wurde ein MPS codiert, wenn das Symbol eine 1 war.
Bei den folgenden Codierertests folgt dem Ereigniszähler (event counter ec) ein YN-Symbol. Die A- und X-Werte werden nach jedem Zyklus ausgegeben. Die Gesamtzahl der Renormierungen ist unter 'Bits' angegeben. Die "Codebytes" werden aufgelistet, sobald sie ausgegeben werden. Zwei Bytes in der Spaltenliste, ein geändertes vorangehendes Byte zusammen mit dem neuen Byte.
Testdaten (64 Symbole in hexadezimaler Form): EBB7FAFEBFEFD6C7F7FFFDFE7FFBDFF3FDFFFF97F6F5F7FEB97BDF76EDD7E7FF
Für diese Datei ergibt die Zählung codierter Bits 192, einschließlich des Zusatzes, um die letzten Daten auszustoßen. Der wirkliche codierte Datenfluß für alle drei Codierer ist (in hexadezimaler Form):
3EBE5A084D54CDAD9D6D187C8C022272CB2C72F0E5693D88

Hardwarecodierer

ec sym a x Bits Codebytes Invertierter Codierer Softwarecodierer Hardwaredecodierer Invertierter Decodierer

Claims

1. Datencodierungssystem für arithmetische Codierung mit endlicher Genauigkeit, bei dem ein Datenfluß eingegeben wird und Entscheidungsereignisse als Reaktion auf eine Codierungsvorschrift erzeugt werden, die einen Codefluß mit Werten erzeugt, die als Codepunkte auf einer Wahrscheinlichkeitsgeraden identifizierbar sind, mit:

ersten Codierungsmitteln zur arithmetischen Codierung (200 oder 202 oder 204 oder 206), um als Reaktion auf als Eingabe eingehende Entscheidungsereignisse einen ersten Codefluß gemäß einer ersten Codierungsvorschrift zu erzeugen;

zweiten Codierungsmitteln zur arithmetischen Codierung (200 oder 202 oder 204 oder 206), um als Reaktion auf als Eingabe eingehende Entscheidungsereignisse einen zweiten Codefluß gemäß einer zweiten Codierungsvorschrift zu erzeugen;

Zeigermitteln (516, 540, 542; Fig. 16, 17), die auf einen gegebenen Satz von Entscheidungsereignissen reagieren, die als Eingabe in die ersten und zweiten Codierungsmittel (200, 202, 204, 206) eingehen, um entsprechende Codeflußwerte (C, Z) zu identifizieren, die von jedem Codierungsmittel als unterschiedliche Codepunkte entlang einer Wahrscheinlichkeitsgeraden ausgegeben werden, wobei der identifizierte Punkt jedes Codierungsmittels sich gemäß der jeweiligen Codierungsvorschrift in einem entsprechenden Intervall auf der Wahrscheinlichkeitsgeraden befindet; und

Mitteln (208), um die Werte des ersten Codeflusses zu ändern, so daß sich der identifizierte Punkt des ersten Codeflusses und der des zweiten Codeflusses als Reaktion auf den gegebenen Satz von Entscheidungsereignissen, die als Eingabe in jedes Codierungsmittel eingehen, in demselben Intervall auf der Wahrscheinlichkeitsgeraden befinden.

2. System gemäß Anspruch 1, wobei die Änderungsmittel Mittel (208) einschließen, um für jeden gegebenen Satz von Entscheidungsereignissen die Codeflußwerte (C; Z) des ersten Codierungsmittels in einer solchen Weise zu ändern, daß das Zeigermittel in die Lage zu versetzt wird, dieselben Punkte auf der Wahrscheinlichkeitsgeraden zu identifizieren, die durch die entsprechenden Werte (Z; C) des zweiten Codierungsmittels identifiziert werden.

3. System gemäß einem der Ansprüche 1 oder 2:

der erste Codierer identifiziert aufeinanderfolgende, kleinere Intervalle auf einer Zahlengeraden, wobei jedes folgende Intervall ein Segment ist, das aus einem größeren Intervall aus einander ausschließenden Segmenten ausgewählt wird, wobei jedes Segment zu einem der möglichen Ereignisse einer Entscheidung gehört.

4. System gemäß einem der Ansprüche 1 bis 3, wobei das wertändernde Mittel einschließt:

Mittel zur selektiven Modifizierung des Wertes des ersten Codeflusses C, um ihn dem Wert des zweiten Codeflusses Z gemäß folgender Beziehung anzupassen:

Z = (A(0) - &epsi;) - C - (Aδ - &epsi;)

wobei A(0) ein Wert des Intervalls ist, das vor den Entscheidungsereignissen liegt, die codiert werden;

wobei &epsi; einen Vorabzug darstellt, der an einem Minuenden zur Abzugsfortpflanzung vorgenommen wird, und

wobei δ eine Entscheidung darstellt, daß ein letztes Intervall A(1) eingefügt werden muß, sobald die beiden Codierer ihre jeweiligen Codepunkte auf verschiedene binäre Ereignisse bewegen.

5. System gemäß Anspruch 4, wobei sich die beiden Codierer (200, 204; 206, 202) als Reaktion auf denselben Ereignistyp um gleiche Beträge in entgegengesetzte Richtungen bewegen:

das selektiv modifizierende Mittel modifiziert C zur Anpassung an Z gemäß dem folgenden Ausdruck:

Z = (A(0) - &epsi;) - C,

wobei C und Z zueinander invertierte Codeflüsse sind.

6. System gemäß einem der Ansprüche 1 bis 5, wobei das Zeigermittel Mittel zur Spezifizierung eines Punktes in einem Intervall einschließt; und

wobei jeder Codierer ein binärer, arithmetisch codierender Codierer ist; und

wobei der zweite Codierer (202 oder 206) einen Punkt spezifiziert, der nur bewegt wird, wenn das weniger wahrscheinliche der zwei möglichen binären Ereignisse einer Entscheidung codiert wird (Fig. 16 oder 17); und

wobei der erste Codierer (200 oder 204) Mittel (516, 540, 542) umfaßt, um den darin spezifizierten Punkt nur dann zu bewegen, wenn das wahrscheinlichere der zwei möglichen binären Ereignisse einer Entscheidung codiert wird.

7. System gemäß Anspruch 6, wobei der erste Codierer ein Hardwarecodierer ist und der zweite Codierer einen Softwarecodierer einschließt;

wobei der Softwarecodierer (202) folgendes umfaßt:

(a) Mittel zur Positionierung des spezifizierten Punktes an der oberen Grenze eines aktuellen Intervalls (Fig. 14, 17); und

(b) Mittel zur Verkleinerung des Codeflußwertes mit der Codierung jedes Ereignisses, das den Punkt bewegt (Fig. 17).

8. System gemäß einem der Ansprüche 1 bis 7 mit einem Mittel, das für eine gegebene Folge von Entscheidungsereignissen einen Codefluß mit einem aktuellen Wert erzeugt, der einen Punkt anzeigt, der an der werthöheren Grenze eines aktuellen Intervalls A(i) auf der Zahlengeraden liegt, und wobei das aktuelle Intervall in einem ersten Segment positioniert wird, das zu einem ersten Typ von binärem Ereignis gehört, das anschließend codiert wird, und in einem zweiten Segment, das zu dem anderen Typ von binärem Ereignis gehört, das anschließend codiert wird;

Mittel zur Verkleinerung des aktuellen Wertes des Codeflusses um den Wert des ersten Segments, wenn das nächste Ereignis vom zweiten Ereignistyp ist; und

Mittel zur Aktualisierung des Wertes für das Intervall, so daß es entweder den Wert des ersten Intervalls annimmt, wenn als nächstes ein Ereignis des ersten Typs codiert wird, oder den Wert des zweiten Segments annimmt, wenn als nächstes ein Ereignis des anderen Typs codiert wird.

9. System gemäß Anspruch 8, wobei der Codierer folgendes umfaßt:

Mittel zur Berechnung des Codeflußwertes beim i-ten Entscheidungsereignis gemäß

C = A(0) - Σi R(i)A(i)P(i)δ(Si = L)

wobei A(i) der Wert des aktuellen Intervalls ist, R(i) einem Renormierungsfaktor entspricht, der angewandt wird, wenn A(i) kleiner als ein vorgeschriebener Minimalwert ist, P(i) ein Wert ist, der bei der i-ten Entscheidung mit dem ersten Ereignistyp verbunden ist, und δ eine Funktion ist, die 0 ist, wenn das i-te Symbol vom ersten Ereignistyp ist, und die 1 ist, wenn das i-te Symbol vom zweiten Ereignistyp ist, und wobei Si das i-te Ereignis darstellt und L den zweiten Ereignistyp darstellt; und wobei das System weiter einen Decodierer umfaßt, der folgendes einschließt:

Mittel zur Berechnung eines Wertes:

Cd = - A(0) + [C + Σi R(i)A(i)P(i)δ(Si = L)],

wobei C der Teil des codierten Codeflusses ist, der dieselbe Genauigkeit hat wie A(i), und wobei A(0) der Anfangswert für den Codierer ist; und

Vergleichsmittel um festzustellen, ob C'd < A(i); und

Mittel, um aus dem Ergebnis des Vergleichs festzustellen, ob das i-te Ereignis ein Ereignis des ersten Typs oder ein Ereignis des zweiten Typs ist.

10. System gemäß den Ansprüchen 7-9, wobei wenigstens eines der Hardware- und Softwarecodierermittel folgendes umfaßt:

Mittel (300, 504), um ihren Codefluß als Folge von Bytes aus n Bits zu bilden; und

Bitstopfmittel (300, 504), um an einer Bytegrenze wenigstens ein, aber weniger als n 0-Bits zu plazieren, an der sich ein Übertrag über eine vorgeschriebene Anzahl von Bytes hinaus fortpflanzen würde.

11. System gemäß den Ansprüchen 7-9, wobei wenigstens eines der Hardware- und Softwarecodierermittel folgendes umfaßt:

Mittel, um ihren Codefluß als Folge von Bytes aus n Bits zu bilden; und

Bitstopfmittel (300), um an einer Bytegrenze wenigstens ein, aber weniger als n 1-Bits zu plazieren, an der sich ein Abzug über eine vorgeschriebene Anzahl von Bytes hinaus fortpflanzen würde.

12. System gemäß Anspruch 10, das weiter einschließt: Decodierermittel (500, 600), um aus einem Codefluß einen Eingabesatz von Entscheidungsereignissen zurückzugewinnen, wobei das Decodierermittel einen entsprechenden Satz von Entscheidungsereignissen für ein gegebenes Intervall decodiert;

wobei das Decodierermittel Mittel (602 oder Fig. 51, 52) zur Erkennung gestopfter Bits einschließt.

13. System gemäß Anspruch 11, wobei wenigstens eines der Hardware- und Softwarecodierermittel, die den jeweiligen Codefluß als eine Folge von Bytes ausformen, folgendes enthält:

Mittel zum Vorabzug von dem Byte, das einem vorliegenden Byte vorausgeht, wenn das vorliegende Byte nur 0-Bits enthält und ein Minuend sein kann, der einer Verkleinerung unterzogen wird, bei der sich ein Abzug über eine vorgeschriebene Anzahl von Bytes hinaus fortpflanzen könnte.

14. System gemäß Anspruch 11, wobei wenigstens eines der Hardware- und Softwarecodierermittel, die den jeweiligen Codefluß als eine Folge von Bytes bilden, folgendes enthält:

Mittel zur Vorübertragung, wenn ein Byte, das nur 1-Bits enthält, ein Summand sein kann, der einer Vergrößerung unterzogen wird, bei der sich ein Übertrag über eine vorgeschriebene Anzahl von Bytes hinaus fortpflanzen könnte.

15. System gemäß Anspruch 13, wobei die Vorabzugsmittel folgendes einschließen:

Mittel zur Umwandlung eines Bytes, das nur 0-Bits enthält, in ein Byte, das nur 1-Bits enthält und dem ein gesetztes Summandenbit folgt, wobei die Umwandlung bei Bytes aus 0- Bits durchgeführt wird, wenn jedes dieser Bytes erzeugt wird, um dem Codefluß als Reaktion auf die Eingabe von Entscheidungsereignissen hinzugefügt zu werden.

16. System gemäß Anspruch 13, das weiter folgendes umfaßt:

ein Codeflußregister mit einem ersten Teil, in dem ein auszulagerndes Byte enthalten ist, und einem zweiten Teil, der Bits des Codeflusses enthält, die der Berechnung unterliegen; und

einen Pufferspeicher, um eine endliche Zahl von Bytes zu speichern, die zuvor aus dem Codeflußregister ausgelagert worden sind;

wobei die Vorabzugsmittel Umwandlungsmittel umfassen, um (a) den Wert des ganz zuletzt in den Pufferspeicher ausgelagerten Bytes um eins zu verkleinern, (b) die 0-Bits im genannten ersten Teil in 1-Bits umzuwandeln und (c) um ein gesetztes Summandenbit in das Codeflußregister zu stopfen, das dem ersten Teil folgt.

17. System gemäß Anspruch 16, wobei die Vorabzugsmittel weiter einschließen:

Mittel um festzustellen, wann (a) der aktuelle Wert des Teils aus dem zweiten Teil des Codeflußregisters kleiner als der Wert des aktuellen Intervalls ist und (b) wann der Codefluß verkleinert wird, und wobei das Umwandlungsmittel auf die genannten feststellenden Mittel reagierend arbeitet.

18. Verfahren zur Datenkomprimierung in einem Datencodierungssystem gemäß einem der Ansprüche 1-11 oder 13-17

und/oder zur Datendekomprimierung in einem Datencodierungssystem gemäß Anspruch 12, bei dem aufeinanderfolgende, kleinere verschachtelte Intervalle auf einer Zahlengeraden gemäß dem Eingang aufeinanderfolgender Entscheidungsereignisse ausgewählt werden, gekennzeichnet durch folgende Schritte:

Speichern eines aktuellen Intervalls A(i) in einem Register mit einem Wert A größer als A(i);

Erzeugung eines ersten Codeflusses mit einem Wert C1 für eine gegebene Folge von Entscheidungsereignissen, der einen Punkt bei der wertmäßig kleineren Grenze des aktuellen Intervalls A(i) anzeigt;

Erzeugung eines zweiten Codeflusses für dieselbe gegebene Folge von Entscheidungsereignissen, der einen Wert Z hat, der einen Punkt anzeigt, der bei der oberen Grenze des aktuellen Intervalls A(i) minus dem Wert des niederwertigsten Bits des A-Registers liegt;

Einteilung des aktuellen Intervalls A(i) in einander nicht überlappende Segmente mit einer ersten Segmentgröße, die der geschätzten Wahrscheinlichkeit eines ersten Entscheidungstyps entspricht, und einer zweiten Segmentgröße, die der geschätzten Wahrscheinlichkeit einer zweiten Art von Eingaben von Entscheidungsereignissen entspricht;

Vergrößerung des aktuellen Wertes des ersten Codeflusses C um den Wert des zweiten Segments, wenn die nächste Ereigniseingabe ein Entscheidungsereignis erster Art ist;

Verkleinerung des aktuellen Wertes des zweiten Codeflusses Z um den Wert des ersten Segments, wenn die nächste Ereigniseingabe ein Entscheidungsereignis zweiter Art ist; und

Berechnung eines neuen aktuellen Intervalls A(i+1) als:

das erste Segment in Reaktion auf die Eingabe eines Entscheidungsereignisses erster Art; und

das zweite Segment in Reaktion auf die Eingabe eines Entscheidungsereignisses zweiter Art;

Renormierung, um den Wert von A nach jeder Ereigniseingabe innerhalb fester Grenzen zu halten; und

Renormierung des Codeflußwertes durch denselben Faktor wie bei der Renormierung des A-Wertes, um das Verhältnis zu erhalten.

19. Verfahren gemäß Anspruch 18, das folgenden weiteren Schritt umfaßt:

Decodierung eines Codeflußwertes für einen beliebigen Codierer nach dem Änderungsschritt zur Wiedergewinnung der gegebenen Folge von Entscheidungsereignissen.

20. Verfahren zur Handhabung von Daten in einem Datencodierungssystem gemäß einem der Ansprüche 1-17, bei dem ein arithmetischer Codierer einen codierten Code erzeugt, der einen dazugehörigen Wert C hat, der in Reaktion auf hintereinander decodierte Entscheidungen auf aufeinanderfolgende, kleinere verschachtelte Intervalle auf einer Wahrscheinlichkeitsgeraden zeigt, beginnend mit einem positiven Intervall A(0), gekennzeichnet durch folgende Schritte:

Initialisierung des Decodiererintervalls auf der Wahrscheinlichkeitsgeraden mit A(0); Initialisierung mit einem Wert -A(0) sowie den xc-Teil eines Codeflußregisters, wobei der xc-Teil die werthöchsten Bits des Registers enthält und zu ausgerichtet ist und von derselben Genauigkeit wie das Decodiererintervall auf der Wahrscheinlichkeitsgeraden ist;

Hinzufügen von wenigstens einem Byte des codierten Codeflusses zum Codeflußregister;

Speichern eines negativen Wertes entsprechend einem der Entscheidungsereignisintervalle in einem zweiten Register in einer Reihe mit dem xc-Teil des Codeflußregisters;

Vergleich des Inhaltes des xc-Teils mit dem gespeicherten negativen Wert für das eine, genannte Entscheidungsereignisintervall; und

Decodieren des nächsten Entscheidungsereignisses auf der Grundlage des Vergleichsergebnisses als die eine oder andere Art von binärem Entscheidungsereignis.

21. Verfahren gemäß Anspruch 20, das folgenden weiteren Schritt einschließt:

wenn ein Entscheidungsereignis der ersten Art decodiert ist, werden A(i) und der Inhalt des Codeflußregisters des Decodierers nur dann renormiert, wenn A(i) größer oder gleich einem vorgeschriebenen Wert AMIN ist, wobei AMIN eine negative Konstante ist, die festlegt, wann eine Renormierung erforderlich ist; und wenn ein Entscheidungsereignis der ersten Art decodiert ist, (a) Angleichen des Wertes von xc an einen positiveren Wert, (b) Angleichen des Intervallwertes an einen positiveren Wert und (c) Renormierung von A(i) und des Inhaltes des Codeflußregisters des Decodierers nur dann, wenn A(i) größer oder gleich dem negativen, vorgeschriebenen Wert AMIN ist.