-
HINTERGRUND DER ERFINDUNG
-
Gebiet der Erfindung
-
Die
vorliegende Erfindung bezieht sich auf Datenkomprimierungssysteme.
Die vorliegende Erfindung bezieht sich insbesondere auf ein verlustfreies
Datendekomprimierungssystem und ein Verfahren und eine Vorrichtung
zur Erhöhung
der Dekomprimierungsgeschwindigkeit eines Stroms von codierten Daten
in Systemen, die ein selbsterstellendes Wörterbuch verwenden, um Stringcodes
und Zeichencodes zu speichern.
-
Beschreibung des Standes
der Technik
-
Bis
jetzt waren verlustfreie Datenkomprimierungsalgorithmen bekannt
wie die Algorithmen zum Decodieren der Komprimierungscodes, die
am Datenkomprimierer erzeugt wurden. Die bekanntesten verlustfreien
Datenkomprimierungsalgorithmen sind adaptiv und verwenden ein String-Wörterbuch
am Komprimierer und am Dekomprimierer.
-
Das
Komprimierungssystem erzeugt Strings von Zeichen und durchsucht
das Wörterbuch
nach der längsten
String-Übereinstimmung,
die im Wörterbuch
gefunden werden kann, und gibt dann einen String-Code für den längsten String
aus, der gefunden wurde. Die längste
String-Übereinstimmung
wird im Komprimierungssystem-Wörterbuch
mit dem Verlängerung-Zeichen
gespeichert, das die Fehlübereinstimmung
hervorgerufen hat. Der String, der im Wörterbuch gespeichert ist, wird
dem nächst
höheren String-Code
durch einen Code-Zähler
zugeordnet. Das Komprimierungssystem gibt auch Einzelzeichen-Codes
aus, wenn diese als der längste Übereinstimmungsstring
erscheinen.
-
Das
Dekomprimierungssystem empfängt
nur Codes für
Strings und/oder Einzelzeichen-Codes. Lemple-Ziv-Welch-(LZW)-Datenkomprimierungssysteme
geben nur Zeichencodes oder längste übereingestimmte
String-Codes an ein Dekomprimierungssystem aus, das ein Wörterbuch
besitzt, das vorzugsweise mit sämtlichen
Einzelzeichen-Codes initialisiert wird, so dass anfänglich nur
Mehrfachzeichen-String-Codes gesucht werden und Zeichencodes an
das Dekomprimierungssystem aus dem Komprimiersystem gesendet werden.
Für eine
Abhandlung über
LZW siehe A Technique for High-Performance Data Compression (Eine
Technik für
Hochleistungsdatenkomprimierung) von Terry A. Welch; IEEE Computer,
Band 17, Nummer 6, Juni 1984.
-
Der
LZW-Komprimierer speichert jede neue Eingabe in seinem Wörterbuch
als einen letzten Übereinstimmung-String-Code
plus einen Verlängerung-Zeichencode.
Der Komprimierer sendet jedoch an den Dekomprimierer den letzten Übereinstimmung-String-Code
aber nicht das Verlängerung-Zeichen.
Der Dekomprimierer muss eine Stufe hinter dem Komprimierer angeordnet
sein und muss zwei sequentielle Eingabe-Codes puffern. Der vorherige String-Code,
der empfangen wurde, wird mit dem ersten Zeichen des nächsten oder
des neuen Codes gepaart, um eine Eingabe im Dekomprimierer-String-Wörterbuch
zu bilden.
-
Das
Problem bei dieser Abfolge von Arbeitsgängen besteht darin, dass die
String-Codes, die von dem Komprimierungssystem empfangen werden, länger werden
und mehrere kleinere Teilstring-Codes umfassen,
die decodiert werden müssen.
Es ist für
einen langen String-Code nicht ungewöhnlich, über fünfzig Zeichen (Bytes) darzustellen,
die beinahe genauso viele Teilstring-Codes umfassen. Um die fünfzig Zeichen
zu decodieren, die von einem solchen langen String-Code dargestellt
werden, ist es notwendig, in das Wörterbuch zu sehen und jeden
Teilcode und dessen Verlängerung-Zeichen
abzurufen bis sämtliche
Teilstring-Codes decodiert wurden und erschöpft sind. Nur ein Verlängerung-Zeichen
wird an den Ausgabedatenstrom ausgegeben, jedes Mal, wenn ein Teilstring-Code
in einen neuen Teilstring und dessen Verlängerung-Zeichen erweitert wird, und
somit könnte
das Dekomprimierungssystem von Zeit zu Zeit mehrere Male einen Zyklus
durchlaufen, wobei es einen langen String-Code decodiert, der bereits gesehen
wurde.
-
Die
PCT-Veröffentlichung
WO9403983A (D-1) erkennt die Notwendigkeit, die Decodiergeschwindigkeit
von String-Codewerten in adaptiven oder wörterbuch-artigen Decodier-Systemen
zu erhöhen.
Das Dukument D-1 verändert
nicht den grundlegenden Algorithmus zum Decodieren von String-Codewerten,
eliminiert aber tatsächlich
jede verschwendete Zeit, die erforderlich ist, um die Strings der
Datenzeichen zu umkehren, die in einem herkömmlichen Lempel-Ziv-Welch-(LZW)-Decoder erzeugt
werden, der durch die Beschaffenheit seines Algorithmus bedingt
die Zeichen in einer umgekehrten Reihenfolge der ursprünglichen
Daten decodiert. Die Veröffentlichung
lehrt, dass eine Vielzahl von Registern oder LIFO-Stapelspeichern
oder Kreis-Warteschlangen durch ein oder zwei herkömmliche
invertierte (umgekehrte) LIFO-Stapelspeicher ersetzt werden kann,
so dass es immer einen verfügbaren
leeren Stapelspeicher gibt, um die decodierten Verlängerung-Zeichen
zu empfangen, die von dem Decoder erzeugt werden. Die Vorrichtung
wird als Stringumkehrungsmechanismus bezeichnet. Die mehrfachen
Stapelspeicher gestatten das Speichern von nachfolgenden Strings
der Zeichen, während
sie zuvor gespeicherte Strings von Zeichen in umgekehrter Reihenfolge
dessen ausgeben wie sie gespeichert waren.
-
Sowohl
das Dokument D-1 als auch der LZW laden die decodierten Strings
in das Äquivalent
der LIFO-Stapelspeicher, um die Umkehrung der Speicherreihenfolge
zu erzielen. Das Dokument D-1 muss jeden String-Codewert so decodieren
als ob er vorher nie decodiert worden wäre. Die vorliegende Erfindung
verwendet einen Hilfsspeicher, in dem decodierte String-Codewerte
in der richtigen Reihenfolge als Datenzeichen gespeichert werden,
wenn sie das erste Mal decodiert werden. Nachfolgende String-Codewerte
werden als ein Zeiger zum Hilfsspeicher verwendet und der zuvor
decodierte String wird aus dem Speicher gelesen und erfordert das
Decodieren nicht ein zweites Mal, und gestattet somit ein gleichmäßiges Decodieren
von Codewerten in Echtzeit.
-
Es
wäre begehrenswert,
die Zeit zu eliminieren, die in einem Dekomprimierungssystem verschwendet
wird, um irgendeinen Mehrfachzeichen-String mehr als einmal zu erweitern.
Anders aus gedrückt
wäre es
begehrenswert, einen Satz von individuellen Zeichen abzurufen, der
stellvertretend für
irgendeinen langen String-Code ist, der bereits gesehen wurde, ohne
den Ausweg über
sich ständig wiederholende
erweiternde SubString-Codes zu nehmen.
-
Zusammenfassung
der Erfindung
-
Es
ist eine Hauptaufgabe der vorliegenden Erfindung, ein Verfahren
und eine Vorrichtung zum Decodieren von komprimierten Daten bereitzustellen,
das schneller ist als bis jetzt möglich war.
-
Es
ist eine Hauptaufgabe der vorliegenden Erfindung, das sich ständig wiederholende
Decodieren von langen String-Codes durch die Erweiterung von Teilstring-Codes
in einem Dekomprimierungssystem zu eliminieren.
-
Es
ist eine Aufgabe der vorliegenden Erfindung, das Decodieren der
meisten Teilstrings in einem langen String-Code zu eliminieren.
-
Es
ist eine Aufgabe der vorliegenden Erfindung, überflüssige Decodier-/Erweiterungsarbeitsgänge in Datendekomprimierern
zu eliminieren.
-
Es
ist eine Aufgabe der vorliegenden Erfindung, einen Speicher mit
schnellem Zugriff bereitzustellen, in dem sämtliche Zeichen gespeichert
werden, die stellvertretend für
einen bekannten oder vorher gesehenen langen String-Code sind.
-
Es
ist eine weitere Aufgabe der vorliegenden Erfindung, ein Decodier-System
bereitzustellen, das in der Lage ist, ganze Seiten von komprimierten
Daten, die auf Webseiten gespeichert sind, so schnell zu decodieren
wie die Daten zum Dekomprimierungssystem heruntergeladen werden
können.
-
Es
ist eine weitere Aufgabe der vorliegenden Erfindung, ein Verfahren
und eine Vorrichtung zum Decodieren von Seiten eines Buches oder
von Katalogen als Blöcke
von komprimierten Datencodes bereitzustellen.
-
Es
ist eine weitere Aufgabe der vorliegenden Erfindung, einen Wörterbuch-artigen
Dekomprimierer bereitzustellen, der zu Videobild-Dekomprimierungsgeschwindigkeiten
in Echtzeit ohne übermäßige Pufferspeicher
in der Lage ist.
-
Gemäß diesen
und anderen Aufgaben der vorliegenden Erfindung wird ein Dekomprimierer
mit einem Wörterbuch
bereitgestellt, der zwei Teile umfasst. Ein String-Wörterbuch
wird verwendet, um komprimierte Daten in der Form von String-Codes und
Verlängerung-Zeichen
zu erstellen oder zu kopieren. Ein decodiertes String-Wörterbuch
oder ein Speicher werden ebenfalls bereitgestellt, um sämtliche
Zeichen, die stellvertretend von oder in einem empfangenen String-Code
enthalten sind, auf den als ein Block von Zeichen in einem einzigen
Zyklus zugegriffen werden kann, an den Adressen zu speichern, die
von den String-Codes
dargestellt werden.
-
Jeder
komprimierte Eingabe-Code in einem Eingabedaten-String wird in einen Zeiger oder eine Adresse
umgewandelt, der bzw. die verwendet wird, um auf Daten in einem
decodierten String-Wörterbuch
zuzugreifen und Blöcke
von Zeichen an eine Nutzungsvorrichtung zu übertragen. Wenn sich der Informationsblock
nicht im decodierten String-Wörterbuch
befindet, dann befähigt
eine logische Vorrichtung den Decoder, den String das erste Mal
zu decodieren und verschiedene Formen des decodierten Strings sowohl
im String-Wörterbuch
als auch/oder im decodierten String-Wörterbuch am gleichen Codezeiger
oder der Adresse zu speichern.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
eine Komprimierungstabelle, die darstellt wie ein typischer String
von Zeichen verarbeitet wird, um Ausgabecodes am Komprimierer zu erzeugen;
-
2 ist
eine Dekomprimierungstabelle, die darstellt wie die Ausgabecodes
verarbeitet werden, die in der 1 erzeugt
wurden, um ein Decoder-Wörterbuch
zu erstellen und den ursprünglichen String
von Zeichen wiederherzustellen, die am Komprimierungssystem komprimiert
wurden;
-
3 ist
ein Blockdiagramm eines Dekomprimierers aus dem Stand der Technik,
der verwendet wird, um den Vorgang der Erstellung eines Decoder-Wörterbuches
zu erklären
und zum Erklären
der Wiederherstellung von individuellen Zeichen, die die wiederhergestellten
und decodierten ursprünglichen Zeichen
eines Strings umfassen;
-
4 ist
ein schematisches Blockdiagramm eines allgemeinen Dekomprimierers
der vorliegenden Erfindung, der verwendet wird, um den Vorgang der
Erstellung eines Decoder-Wörterbuches
zu erklären
und zum Speichern der decodierten String-Codes;
-
5 ist
ein Flussdiagramm, das den Vorgang der Erstellung oder der Erzeugung
eines Strings von decodierten Zeichen aus Eingabedaten-Codes zeigt,
wobei das in der 4 gezeigte Decoder-Wörterbuch
verwendet wird;
-
6 ist
ein schematisches Blockdiagramm des Decoders oder Dekomprimierungssystems
einer bevorzugten Ausführungsform
zum Erweitern der eingehenden komprimierten Datencodes in Blöcke oder
Strings von decodierten Zeichen in einem einzigen Wiederherstellungszyklus;
-
7 ist
ein schematisches Blockdiagramm eines veränderten Decoders oder Dekomprimierungssystems,
das anfangs einen langen String-Code in einer herkömmlichen
Weise decodiert bis einer der verbleibenden Teilstring-Codes als
ein Block oder ein Strom von Zeichen decodiert wird;
-
8 ist
ein schematisches Blockdiagramm des Decoder-String-Wörterbuches einer weiteren bevorzugten
Ausführungsform
zum Decodieren von eingehenden langen Strings und zum Decodieren
eines zuerst gesehenen String-Codes, wobei dann die decodierten
Zeichen im Decoder-String-Wörterbuch gespeichert
werden;
-
9 ist
ein schematisches Blockdiagramm eines Teils des Decodersystems einer
bevorzugten Ausführungsform,
das automatisch Eingabe-Codes erkennt und decodiert, die durch einen
herkömmlichen
Vorgang im Decodersystem nicht zu decodieren sind.
-
Detaillierte
Beschreibung der bevorzugten Ausführungsformen
-
Betrachte
man nun die 1 und die Komprimierungstabelle 10,
die einen String von Zeichen 11 zeigt, die komprimiert
werden sollen. Der Strich "-" zwischen den Zeichen
ist ein Weg, um ein Leerzeichen zwischen den Zeichen anzuzeigen,
und ist nicht ein Zeichen, das als ein Strich codiert werden soll. Die
Tabelle 10 wird gezeigt, wobei sie vier vertikale Spalten besitzt,
in denen die äußerste linke
Spalte 12 eine vertikale Spalte der längsten Strings ist, die in dem
String 11 erscheinen bevor sich ein Fehlschlag ereignet,
der den Lempel-Ziv-Welch-Datenkomprimierungsalgorithmus verwendet.
Betrachtet man zum Beispiel den String 11, in dem "-WED" auf den ersten vier
Stellen erscheint, ist das "-W" der erste String
von Zeichen, der nicht im Wörterbuch
gefunden wird, das mit sämtlichen
Einzelzeichen-Strings oder
einem String-Satz initialisiert wurde, der den Lempel-Ziv-Welch-Komprimierungsalgorithmus
verwendet. An der zweiten Zeile wird das W, das die Fehlübereinstimmung
verursacht hat, zur dritten Zeile als das erste Zeichen im nächsten String
getragen, der als WE gezeigt wird. Jedes Mal, wenn sich ein neuer
Stringfehlschlag ereignet, wird der String im String-Wörterbuch
an einer neuen Code-Adresse oder Code-Nummer gespeichert. Zum Beispiel
wird das -W an der Code-Adresse 256 gespeichert und das
WE wird an der Code-Adresse 257 in der Spalte 13 gespeichert.
Die Zeichen, die in der Spalte 14 gezeigt sind, werden
im String-Wörterbuch
als Strings plus ein Verlängerung-Zeichen
gespeichert. Der Präfix-String
W am Code 257 stellt die längste Übereinstimmung dar, die im
Wörterbuch
gefunden wurde, und wird an einen Dekomprimierer oder eine Nutzungsvorrichtung
ausgegeben wie bei Spalte 15 gezeigt ist. Wenn der letzte
Satz von Zeichen oder das Zeichen erscheint, wie in der letzten
Zeile gezeigt ist, dann beinhaltet es ein T. Das T ist das Ende
des Strings von Zeichen 11 und wird im Wörterbuch
als ein Zeichen oder Code für
ein Zeichen gespeichert und wird als das letzte Zeichen T ausgegeben.
-
Nachdem
eine vereinfachte Abfolge von Arbeitsgängen erklärt wurde, die sich am Komprimierer ereignet,
wird es angemerkt, dass der Dekomprimierer, der nachstehend erklärt wird,
die Zeichen der Spalte 14 reproduzieren wird, die als Strings
plus Verlängerung-Zeichen
gespeichert sind, obwohl nur die in der Spalte 15 gezeigten
Code-Adressen empfangen werden.
-
Betrachte
man nun die 2, die eine Dekomprimierungstabelle 16 zeigt,
die vier vertikale Spalten besitzt. Die äußerste linke vertikale Spalte 17 stellt
die Abfolge oder die Reihe von individuellen Codes in der Spalte 15 dar,
die am De komprimierer vom Komprimierer empfangen wurden. Die vertikale
Spalte 18 stellt die Code-Nummer dar, die von einem Code-Zähler zum
Zeitpunkt erzeugt wurde, an dem der Code-Empfang in das Wörterbuch
geschrieben wurde. Die vertikale Spalte 19 stellt den String
und das Verlängerung-Zeichen
dar, die in das Wörterbuch
an der nummerierten Code-Zählung
geschrieben werden, gezeigt zur Linken der Spalte 19. Die äußerste rechte
Spalte 22 ist das Ausgabezeichen oder sind die Zeichen,
das/die erzeugt wird/werden, wenn der in der Spalte 19 gezeigte
String S decodiert wird. Es wird beobachtet werden, dass wenn sämtliche
Zeichen oder Strings am Dekomprimierer in der Spalte 17 empfangen
werden, das erste Zeichen in das Wörterbuch als das Verlängerung-Zeichen
eingefügt wird,
wie in der Spalte 19 gezeigt ist, und einer Code-Zählung zugeordnet
wird, wie in der Spalte 18 gezeigt ist. Der Präfix-String S in der Spalte 19 stellt
das Zeichen oder den String dar, der der zuvor empfangene war und
in der Spalte 19 gezeigt ist. Wenn die Code-Zählungen
von 256 bis 260 mit der Information verglichen werden, die im Dekomprimierungswörterbuch
gespeichert ist, wird es beobachtet werden, dass sie identisch zur
Information sind, die in der Spalte 14 des Komprimiererwörterbuches
gespeichert ist, wie in der 1 gezeigt
ist. Somit kann sie, wenn irgendwann ein Code in der Spalte 17 empfangen
wird, im Dekomprimierer-String-Wörterbuch durch
dessen empfangene Code-Zählung nachgesehen
werden und durch Benutzung der in der Spalte 19 gezeigten
Information decodiert werden. Wenn zum Beispiel der Code 256 empfangen
wird, wie in der fünften
Zeile der Spalte 17 gezeigt ist, dann ist bekannt, dass
er sich im Dekomprimierer-Wörterbuch
an der Code-Zählung 256 befindet
und dass die Information oder die Zeichen -W sind, die mit dem Komprimierungswörterbuch übereinstimmen.
Es wird auch beobachtet werden, dass die Codes oder Zeichen, die
in der Spalte 17 empfangen wurden, die Verlängerung-Zeichen
für die
gegenwärtige
Code-Zählung
enthalten und den Präfix-String-Code
bilden, der mit einem Verlängerung-Zeichen
für die
vorherige Code-Zählung
benutzt wurde. Somit ist mit einer einzigen Ausnahme, die nachstehend
erörtert wird,
das Dekomprimierungssystem in der Lage, die genauen Strings zu reproduzieren,
die in der Spalte 14 des Komprimierers in der 1 gezeigt
sind. Nach der Erstellung des String-Wörterbuches
im Dekomprimierer ist es möglich,
den Teil des Präfix-Strings
S in der Spalte 19 zu decodieren, und den Präfix-String S auszugeben,
um den identischen Eingabestring 11 in der Spalte 22 als
eine Ausgabe zu reproduzieren.
-
Betrachte
man nun die 3, die ein Blockdiagramm eines
Dekomprimierers aus dem Stand der Technik zeigt, der in der Veröffentlichung
von Terry Welch (oben) verwendet wurde, um den Vorgang der Erstellung
eines Decoder-Wörterbuches
zu erklären
und zum Erklären
der Wiederherstellung der individuellen Zeichen der empfangenen
String-Codes.
-
Der
Dekomprimierer 20 wird gezeigt, wobei er eine Eingabeleitung 22 besitzt,
die die Eingabe-Codes an den Dekomprimierer empfängt. Der Eingabe-Code wird
gezeigt, während
er im Register 23 als der nächste String Sn gespeichert
wird. Der String, der zuvor der Sn war, wird gezeigt, während er im
letzten oder vorherigen Code-Register 24 platziert wird,
der den String Sp oder den vorherigen String speichert. Im Arbeitsgang
des Dekomprimierers 20 wird der String Sn an der Leitung 22 an
einen RAM-Adressengenerator 25 angeschlossen,
der eine Zeigeradresse an der Leitung 26 in die String-Tabelle 27 erzeugt.
Die Code-Adresse
erzeugt einen decodierten ersten Zeichencode an der Leitung 28,
der verwendet wird, um das Verlängerung-Zeichen
zu erzeugen, das im äußersten
rechten Teil der String-Tabelle 27 als ein Verlängerung-Zeichen
gespeichert werden soll. Der letzte oder vorherige String Sp im
Register 24 liefert den vorherigen String-Code an der Leitung 29,
der als ein Präfix
im linken äußersten
Teil der String-Tabelle 27 an der Code-Adresse gespeichert
wird, die durch den Code-Zähler 35 erzeugt
wurde.
-
Der
Code Sp im Register 24, der nun in der String-Tabelle 27 gespeichert
ist, wird ebenfalls decodiert, um einen Ausgabestring von Zeichen
in umgekehrter Reihenfolge an der Leitung 31 zu erzeugen,
die im Ausgabe-Stapelspeicher 32 platziert sind. Wenn das
letzte Zeichen an der Leitung 33 im Block 34 erkannt
oder geprüft
wurde, beendet das die Decodierabfolge für den String Sp. Der String
Sp im Stapelspeicher 32 kann nun aus dem Stapelspeicher 32 in
dessen richtiger Reihenfolge gelesen wer den, die in der Spalte 22 gezeigt
ist.
-
Nachdem
eine Abfolge von Arbeitsgängen aus
dem Stand der Technik durch Verwendung der 3 erklärt wurde,
wird angemerkt, dass dem String-Wörterbuch 27 die Information
an der Adresse geliefert wird, die durch den Eingabe-Code an den Leitungen 22 und 26 angezeigt
wird, jedoch stellen die Zeichen, die im Stapelspeicher 32 in
umgekehrter Reihenfolge platziert sind, die letzten oder vorherigen Codes
Sp dar. Somit ist der Decodierprozess eine Stufe oder eine Code-Zählung hinter
der Wörterbuch-Code-Zählung. Wenn
der vorherige Code Sp ein String von Teilstrings und Verlängerung-Zeichen ist,
dann umfasst das Decodieren von Sp das Erweitern sämtlicher
Teilstrings und das Platzieren der Verlängerung-Zeichen in den Stapelspeicher 32 bis
das Endzeichen vom Sp (z. B. das Anfangszeichen) am Block 34 erkannt
wird.
-
Betrachte
man nun die 4, die gemäß der vorliegenden Erfindung
ein schematisches Blockdiagramm eines allgemeinen Dekomprimierers
zeigt, der verwendet wird, um den Vorgang der Erstellung eines Decoder-Wörterbuches
zu erklären
und zum Speichern der decodierten String-Codes. Der verbesserte
Decoder 20A wird gezeigt, wobei er einen Eingabestring
von Codewerten 36 besitzt, die an das Pufferregister 37 den
nächsten
Code Sn liefern. Der String-Code Sn wird, nachdem er verwendet wurde, in
das vorherige String-Register 38 übertragen. Das Anfangszeichen
des Strings Sn im Register 37 wird gezeigt, während es
vom logischen Block 39 gelesen und an den Block 41 geliefert
wird, der das Verlängerung-Zeichen
empfängt,
das in der String-Tabelle 27A als das äußerste rechte Verlängerung-Zeichen an
der Zeigeradresse gespeichert werden soll, die vom nächsten Code-Adressenzähler 35A erzeugt wird.
Es wird beobachtet werden, dass die Zeit, die benötigt wird,
um den String abzurufen und ihn im Puffer. 37 zu platzieren,
als die Zeit T1 verzeichnet wird und die Zeit, die zum Setzen der
Puffer 37 und 38 benötigt wird, als die Zeit T2
gezeigt wird und beide dieser Zeiten werden für das betrachtete System festgelegt.
Wenn der String Sp decodiert wird wie im logischen Block 42 gezeigt
ist, wird diese Zeit als T3 als eine Variable gezeigt, weil irgendein
bestimmter Code Sp ein langer String von Codes sein könnte und Teilcodes
enthalten wird, die den Bezug zum String-Wörterbuch 27A mehr
als einmal erfordern, um die Verlängerung-Zeichen zu extrahieren
und um neue Teilstrings zu erzeugen wie nachfolgend erklärt wird.
Der Decodierprozess im Block 42 ist somit eine Variable,
die im Stand der Technik jedes Mal erforderlich war, wenn der String-Code Sp oder ein
identischer String-Code decodiert wurde. In der vorliegenden Ausführungsform
wird das Decodieren des String-Codes
Sp am logischen Block 42 gezeigt. Der decodierte String
Sp wird ausgegeben und als ein String von Zeichen am Block 43 gespeichert
und kann am logischen Block 44 in einen Hilfsspeicher an der
Adresszeiger-Code-Adresse über
die Leitung 45 hinzugegeben werden. Schematisch kann der
decodierte String Sp an die String-Tabelle 27A wie die
individuellen Zeichen zurück
geleitet werden und an der Stelle des Strings Sp gespeichert werden
wie nachfolgend im Detail erklärt
wird. In einer Form der vorliegenden Erfindung wird der Mehrfachstring
von Zeichen, die im Speicher über
die Leitung 45 gespeichert werden sollen, als ein Anfangsbyte
und eine Länge
von Zeichen erkannt wie am Block 46 gezeigt ist. Diese
Information wird an den logischen Block 47 geliefert und
verwendet, um die Länge
und die Anfangsadresse in einen Finder-Speicher an einer Zeiger-Code-Adresse
zu schreiben, die durch einen Zähler 35A erzeugt
wurde, wie nachfolgend erklärt wird,
wenn ein Hilfsspeicher verwendet wird.
-
Betrachte
man nun die 5, die ein Flussdiagramm zeigt,
das verwendet wird, um den Vorgang der Erstellung oder Erzeugung
eines Stroms von decodierten Zeichen aus Eingabedaten-Codes zu erklären, wobei
ein Decoder-Wörterbuch
des in der 4 gezeigten Typs verwendet wird.
Die nächsten
Eingabedaten-Codes Sn an der Leitung 22A werden beim Eingeben
in einen logischen Code-Puffer 48 gezeigt.
Die Information im logischen Code-Puffer 48 wird verwendet,
um eine vorherige Zeigeradresse Sp zu erzeugen wie im Block 25A gezeigt
ist, das ähnlich
zum Block 25 der 3 ist. Die
Zeigeradresse Sp bewirkt, dass die Inhalte des Wörterbuches 27 an der
Zeigeradresse herausgelesen werden, die durch den String Sp erzeugt
wurde wie am Block 49 gezeigt ist. Die Ausgabe an der Leitung 28A wird
logisch für
die Bestimmung geprüft,
ob sie einen Mehrfachstring S plus ein Verlängerung-Zeichen umfasst wie am Block 51 gezeigt
ist. Wenn S ein Einzelzeichen-String ist, wird die Information am
logischen Block 52 eingegeben und das Einzelzeichen wird
an den decodierten String über
die Leitung 31B und in den Stapelspeicher 32A ausgegeben.
Wenn das das letzte Zeichen des Strings S ist, wie am Block 53 gezeigt
ist, ist der nächste
String zum Decodieren bereit. Die Information an der Leitung 54 lädt den neuen Code
Sn in den Zeigeradressblock 25A als ein neuer Sp und der
Vorgang startet wieder von vorne. Wenn jedoch der Block 51 einen
Mehrfachzeichen-String prüft,
der S plus ein Verlängerung-Zeichen
umfasst, dann wird das Verlängerung-Zeichen
dem Decodierstrom zugefügt,
wie am Block 55 gezeigt ist, über die Leitung 31A und
in den Stapelspeicher 32A. Der String S wird verwendet,
um den nächsten
Teilstring-S-Code zu erzeugen wie am logischen Block 56 gezeigt
ist. Die Inhalte des Wörterbuches 27 an
der neuen Teilstring-S-Adresse werden in den Block 51 gelesen.
-
Jedes
Verlängerung-Zeichen
wird in den Umkehr-Stapelspeicher 32A geladen bis das letzte Zeichen
von S darin enthalten ist, und dann wird die Information aus dem
Stapelspeicher 32A umgekehrt heraus und in den Ausgabedatenstrom 57 in
dessen richtiger Reihenfolge gegeben.
-
Es
wird nun verstanden, dass die 5 zeigt,
dass ein logischer Weg der Decodierung von Teilstrings darin besteht,
jeden der bekannten Verlängerung-Zeichen
aus dem String-Wörterbuch 27 zu nehmen
und sie in einen Stapelspeicher zu geben. Wenn einmal der Stapelspeicher
mit sämtlichen
Zeichen aus einem bestimmten Code Sp geladen ist, dann wird diese
Information aus dem Stapelspeicher umgekehrt heraus und in den Ausgabedatenstrom gegeben
und der nächste
Sp-Code kann decodiert werden.
-
Betrachte
man nun die 6, die ein schematisches Blockdiagramm
des Decoders einer bevorzugten Ausführungsform in einem Dekomprimierungssystem
zur unmittelbaren Erweiterung von Komprimierungsdatencodes in Strings
oder in Blöcke von
decodierten Zeichen in einem einzigen Wiederherstellungszyklus zeigt.
Die Datencodes Sp im Block 25B werden bei der Verwendung
zur Erzeugung einer Zeigeradresse gezeigt, die an eine Adressen speicherstelle
im Finder-Speicher 58 zeigt, der nachfolgend in größerem Detail
beschrieben wird. Die Information in diesem Finder-Speicher erzeugt eine
Leseanfangsadresse an der Leitung 59 und einen Länge-L-Wert
an der Leitung 61, der der Logik gestattet, eine End-Adresse
zu finden. Die Information an der Leitung 61 stellt Daten
bereit, die anzeigen, dass der Finder-Speicher 59 mit Information
geladen wurde, die die Länge
eines Blocks betrifft. Die Logik im Block 62 bestimmt,
ob die Länge
gleich Null ist, und wenn nicht, werden die Daten im zugehörigen Speicher
gefunden. Wenn die Länge
nicht gleich Null ist, wird ein Verschiebe-Befehl (Move-Befehl)
im Block 63 erzeugt, um einen Block von Speicherzeichen
zu verschieben, der an der Anfangsadresse beginnt, die an der Leitung 64 gezeigt
ist, und eine Länge
L, die an L 66 gezeigt ist, und eine End-Adresse, die an
der Leitung 67 gezeigt ist, besitzt. Der decodierte String
Sp wird aus dem String-Speicher mit variabler Länge 65 heraus gelesen.
Dieser Speicher kann jede Form annehmen, in der ein Speicher die Datenblöcke übertragen
oder verschieben kann, die eine Länge L besitzen. Die decodierten
Zeichen werden gezeigt, während
sie an der Leitung 68 unmittelbar in den Ausgabedatenzeichenstrom 69 bereitgestellt
werden. Es wird verstanden, dass die Informationsblöcke 8-Bit-Zeichen
sein können
und entsprechend als 8-Bit in einer Reihe von Strings übertragen oder
unmittelbar im entsprechenden Format für eine Sicherheitskopie ausgegeben
werden. Nachdem das Verfahren einer bevorzugten Ausführungsform
des unmittelbaren Lesens von decodierten Zeichen aus einem String-Speicher
erklärt
wurde, wird es eingesehen, dass nur ein kontinuierlicher Zyklus
notwendig war, um sämtliche
Zeichen zu erhalten, und zwar anstelle von jedes mal ein Zeichen
herausnehmen zu müssen,
wie im Decoder aus dem Stand der Technik gezeigt ist, der mit Bezug
auf die 3 erklärt wurde. Der Speicher mit
variabler Länge 65 ist
schematisch und wenn der Typ des verwendeten Computers zum Bewegen
der Information keinen Blockverschiebung-Befehl besitzt, ist es
möglich,
an der Adresse 64 zu beginnen und damit fortzufahren, die
individuellen Abfolge-Adressen herauszulesen, bis die Zahl von Adressen
in der Länge 66 mit
der End-Adresse 67 endet und die gleiche Über tragung
oder Sicherungskopie würde
ausgeführt,
obwohl sie länger
dauern würde
als ein Verschiebe-Befehl mit variabler Länge.
-
Betrachte
man nun die 7, die ein schematisches Blockdiagramm
eines veränderten
Decoders oder Dekomprimierungssystems zeigt, das anfangs einen sehr
langen String-Code in Teilstrings plus Verlängerung-Zeichen auf eine herkömmliche Art
decodiert bis einer der verbleibenden Teilstrings als ein Block
oder ein Strom von Zeichen decodiert werden kann. Der Grund zum
Bereitstellen einer Veränderung
diesen Typs besteht darin, dass sehr lange Strings manchmal auf
die Daten beschränkt
sind und nur einmal oder zweimal in einer riesigen Datendatei auftreten
würden.
Ein String diesen Typs, der in den Speicher geschrieben wurde, der
in der 6 beschrieben wird, könnte aufgenommen werden, aber manche
Speichertypen sind nicht so aufnehmend und die Länge des Strings muss auf eine
Größe verkürzt werden,
die im verwendeten System betriebsfähig ist.
-
Die
Datencodes Sp werden gezeigt während sie
in den neuen Stringeingabe-Puffer 25C eingegeben werden,
der eine Zeigeradresse zum Finder-Speicher 58C erzeugt.
Wenn die Längendaten an
der Leitung 61C an die Logik 62C ausgegeben werden,
kann die Folgerung gemacht werden, dass der vollständige String
bereits im Hauptspeicher aufgezeichnet ist. Wenn die Länge gleich
Null ist, dann befindet sich der String nicht im Speicher und der String
muss in Teilstrings erweitert werden. Der Beginn dieser Erweiterung
wird im Block 71 gezeigt, wo der eingehend String in einen
Teilstring S1 plus einem Verlängerung-Zeichen
erweitert wird. Der Teilstring S1 wird verwendet, um eine S1 Zeigereingabe am
logischen Block 72 zu erzeugen. Der neue Zeiger oder der
neue String S1 wird in den Block 25C über die Leitung 73 eingegeben,
um einen neuen Zeiger zu erzeugen, der einem Teilstring von Sp entspricht. Ein
zweiter Durchlauf wird von dem System gemacht, wenn sich der String
nicht im Speicher befindet, und startet mit der Erweiterung von
S1 in einen String S2 plus einem neuen Verlängerung-Zeichen am Block 71'. Ein neuer
Zeiger wird am Block 72' erzeugt
und wird in den Zeigeradressen-Generator 25C eingegeben.
Sowohl der Block 72 als auch der Block 72' geben ihr Verlängerung-Zeichen
in den Puffer 32C beziehungsweise 32C' aus, wo sie
bis zu dem Zeitpunkt gehalten werden, an dem ein Freigabesignal
an der Leitung 75 erzeugt wird, das anzeigt, dass es nicht länger notwendig
ist, den String zu erweitern, der nun in den Block 25C geladen
wurde. Der logische Block 76 wird dann den Informationsblock
lesen, der der Anfangsadresse an der Leitung 59C und dessen
Länge an
der Leitung 61C aus dem Speicher entspricht, der in der 6 oder
einer gleichwertigen Figur gezeigt und beschrieben wird. Der Speicheradressen-Zeigerblock 76 gibt
auch ein Signal an den logischen Block 77 aus, um die Erweiterung
der Teilstrings zu beenden und um die Zeichen auf die Ausgabeleitung 78 zu
geben, die aus einem Speicherblock gelesen wurden. Ein Freigabesignal
an den Leitungen 77E gibt die Verlängerung-Zeichen aus dem zweiten
Durchlauf und dann aus dem ersten Durchlauf der Reihe nach auf die
Ausgabeleitung 78, um den Ausgabedatenstrom zu erzeugen.
-
Zusammenfassend
wird das in der 7 gezeigte Decodersystem starten,
indem es die Verlängerung-Zeichen
aus dem langen String in umgekehrter Reihenfolge bis zu dem Zeitpunkt
herausnimmt, an dem es einen decodierten String aus einem Blockspeicher
bis zum Block 77 erzeugen kann und dann in umgekehrter
Reihenfolge die Verlängerung-Zeichen
zufügen,
die zuvor während
dem Vorgang der Verkürzung
der Länge
des ursprünglichen
String-Codes herausgenommen
wurden.
-
Betrachte
man nun die 8, die ein schematisches Blockdiagramm
einer weiteren bevorzugten Ausführungsform
des Decoder-/String-Wörterbuches
zum Erhöhen
der Decodiergeschwindigkeit von eingehenden langen String-Codes
und/oder zum Decodieren eines zuerst gesehenen String-Codes und das
Speichern des decodierten Strings in einem Wörterbuch zeigt. In dieser verbesserten
Ausführungsform
wird der neue Hilfsspeicher oder das String-Wörterbuch 27D verwendet,
um ausschließlich
Zeichen zu speichern. Anstelle des Speicherns von Sp plus einem
Verlängerung-Zeichen
an einem Adressencode, der von dem Adressenzähler erzeugt wurde, wird der
gesamte String von Zeichen, der Sp darstellt, im Speicher 27D gespeichert.
-
Die
komprimierten Codes kommen an dem Dekomprimierer 20B aus
dem Daten-Codestrom 36 an und werden in einem neuen Code- Register 37A gepuffert.
Der neue String-Code Sn wird in den vorherigen Code-Block 38A geladen,
wo er verwendet wird, um eine Lesezeigeradresse für den String-Code
Sp zu erzeugen. Wie hier zuvor erklärt wurde gibt es genügend Information
im Wörterbuch 27A,
um Sp zu decodieren und Sp plus dessen Verlängerung-Zeichen in das Wörterbuch
zu schreiben. Wenn Sp ein zuvor gesehener Code im Datenstrom ist,
dann wurde er bereits decodiert und in das Wörterbuch 27D geschrieben.
Das kann am Block 81 erkannt werden, wenn die Daten am
Zeiger Sp herausgelesen werden. Der Block 82 kann unmittelbar
die decodierten Zeichen an den Ausgabedatenstrom 84 über die
Leitung 83 herauslesen.
-
Wenn
keine Daten aus dem Speicher 27D am Zeiger Sp gelesen werden,
dann befindet sich Sp noch nicht im Wörterbuch und muss zum ersten
Mal decodiert werden. Der logische Block 42D decodiert Sp
zum ersten Mal und zeichnet auf und speichert die Ausgabe im Puffer 43D in
einer passenden Form zum Ausgeben an der Leitung 84 an
den Ausgabedatenstrom 85.
-
Das
Wörterbuch
hat Sp noch nicht decodiert, das als ein Präfix für einen Codewert gespeichert
ist. Die gleiche Information wird an der Leitung 86 geliefert
und wird in das Wörterbuch
an der nächsten
Zähler-Adresse
geschrieben wie mit Bezug auf die 4 erklärt wurde,
wobei der Schreibadressen-Zeigercode verwendet wird. Wenn Sp in
den/das Speicher/Wörterbuch 27D geschrieben
wird, ist er in der Form von decodierten Zeichen (decodierte Strings) und
wird von einem Verlängerung-Zeichen
aus dem String-Code Sn im Block 37A gefolgt. Um dieses Ende
auszuführen,
wird ein Schreibpuffer 39D bereitgestellt, um das erste
Zeichen des Strings Sn zu verlängern
und es in den Speicher zu schreiben, wenn es durch die Leitung 86 freigegeben
wird wie an der Speicher-Freigabe-Eingabe gezeigt ist.
-
Zusammenfassend
ergänzt
die 8 die 4 und beschreibt ein Verfahren
des Ersetzens von Sp im Wörterbuch
durch einen String von Zeichen. Wenn ein Sp-Lesezeiger die Inhalte
des Speichers 27D nachfolgend liest, kann er das Verlängerung-Zeichen
vernachlässigen
und Sp alleine ausgeben.
-
Als
eine Alternative zum Lesen und Decodieren von Sp zuerst und dann
einen neuen Sp als Zeichen zu speichern, ist es mög lich, das
Wörterbuch zuerst
mit Sp plus dessen Verlängerung-Zeichen zu erstellen
und dann zu decodieren und Sp durch dessen entsprechende Zeichen
zu ersetzen. Da sich die Werte für
Sp bereits im Wörterbuch
als S plus ein Verlängerung-Zeichen
befinden, ist es auch möglich, die
Zeichen für
Sp auszugeben bevor das Wörterbuch
erstellt wird. Nachdem mehrere Möglichkeiten erklärt wurden,
wie ein Hilfsspeicher oder ein Wörterbuch
eingesetzt werden können,
kann die Reihenfolge der Schritte variiert werden, um dieses Ergebnis zu
erzielen.
-
Nachdem
erklärt
wurde wie ein großer
Speicher 27D verwendet werden kann, um decodierte Strings
an Lesezeigeradressen Sp zu speichern, wird es verstanden, dass
nur ein Teil jener Strings die Zeilen des Speichers einnimmt, die
als decodierte Strings gezeigt sind, und der andere Teil zur Rechten der
decodierten Strings ungenutzten Speicher darstellt. Obzwar der Speicherplatz
verschwendet wird, ist der Speicherplatz billig und die Zeit ist
wertvoll, und somit wird der Ersatz eines Hilfsspeichers 27D in einem
Decoder des in der 4 gezeigten Typs die Geschwindigkeit
des Decoders bedeutend erhöhen.
-
Betrachte
man nun die 9, die ein schematisches Blockdiagramm
eines Teils einer bevorzugten Ausführungsform des Decodersystems
zeigt, das automatisch Eingabe-Codes decodiert, die durch einen
herkömmlichen
Vorgang und ein String-Wörterbuch,
wie hier zuvor erklärt
wurde, nicht decodierbar sind. Im vorher erwähnten Artikel von Terry A. Welch
in IEEE, Computer wurde erklärt,
dass es eine Ausnahme zum herkömmlichen
Decodiervorgang gibt, wenn der String k S k S k an der Eingabe zum Komprimierer
erscheint und der String k S bereits im Komprimierer-String-Wörterbuch gespeichert ist. Das
Problem mit dem Erscheinen dieser Abfolge aus drei Zeichen und zwei
Strings besteht darin, dass das Dekomprimierer-String-Wörterbuch
noch keinen Codewert besitzt, der dem letzten Eingabe-Code entspricht.
Die 9 stellt einen vereinfachten Weg des Umgangs mit
dieser Bedingung dar und war in vorherigen Figuren nicht beinhaltet,
ist aber ein Teil des Systems, das in einen Computer (nicht gezeigt)
zum Ausführen
der vorher beschriebenen Erfindung programmiert ist.
-
Der
Dekomprimiereingabedatenstrom 36E wird gezeigt, wobei er
eine Reihe von nummerierten codierten Strings von S bis S5 umfasst
und diese bestimmten Strings werden in einen logischen Block 87 eingegeben,
der bestimmt, ob der neue String-Code, der am Block 87 empfangen
wurde, einen größeren Wert
als der größte Codewert
besitzt, der bereits in das Wörterbuch
geschrieben ist, wie von dem Code-Zähler 35E erzeugt wurde.
Wenn die Logik am Block 88 bestimmt, dass der neue Code,
der an die Logik 87 eingegeben wurde, sich im Wörterbuch
befindet, dann fährt
sie normal fort, den neuen Code wie hier zuvor erklärt wurde
mit Bezug auf die 4 bis 6 zu decodieren.
Wenn der neue Code größer ist als
der alte Code, dann schlussfolgert die Logik im Block 89,
dass der neue Code Sn sich noch nicht im Dekomprimier-Wörterbuch befindet. Der vorherige Code
Sp befindet sich jedoch im Wörterbuch
am letzten Code-Zähler,
und wenn er decodiert wird, ist er einem ersten Zeichen plus einem
String gleich. Der logische Block 91 erzeugt den neuen
Code für
Sn, wobei er den decodierten Wert für Sp verwendet, worin Sn gleich
dem Zeichen plus dem Stringwert für Sp plus dem ersten Zeichen
ist, das Sp gestartet hat, wobei er am Ende angehängt war.
Da der Wert für den
neuen Code Sn nun bekannt ist, ist es möglich, Sn als einen Sp-Codewert
aus dem Wörterbuch
zu decodieren und einen String von Zeichen an die Ausgabe auszugeben
wie am Block 92 gezeigt ist. Wenn einmal ferner der Wert
für Sn
als Sp decodiert wurde, kann er nun in einem der Wörterbücher gespeichert werden,
die hier zuvor erklärt
wurden, als Sp plus ein Verlängerung-Zeichen
im Wörterbuch
am nächsten Codewert.
-
Nachdem
erklärt
wurde, wie der vorherige Decoder individuelle Codes durch die Entnahme
der Verlängerung-Zeichen
decodiert hat, wird es verstanden, dass derartige Codes in der umgekehrten
Reihenfolge decodiert wurden, in der sie im Ausgabestring erscheinen
würden.
Entsprechend wurden die Zeichen in einen Stapelspeicher gegeben,
wo sie in einer "Letzter-Rein-Erster-Raus"-(LIFO)-Reihenfolge abgerufen werden
konnten. Entsprechend wurde jeder lange String zuvor decodiert,
wobei für
jedes Zeichen im String mehrere Zyklen verwendet wurden bis der
String durch Teilstrings erschöpft
war. Der Decoder der vorliegenden Erfindung macht eine einzige einfache
Bestimmung was anbetrifft, ob der String zuvor am Decoder gesehen
wurde, und wenn ja, sind die decodierten Zeichen in einem Hilfsspeicher
oder einem blockähnlichen
Speicher verfügbar
und werden unmittelbar in einem einzigen Zyklus decodiert. Es wird
verstanden, dass wenn das erste Mal ein String an der Eingabe des
Decoders der vorliegenden Erfindung erscheint und mehrfache Teilstrings beinhaltet,
muss er auf eine herkömmliche
oder halb-herkömmliche
Art und Weise decodiert werden und die decodierte Information muss
in einem Computer-ähnlichen
Blockübertragungsspeicher
oder in einem Speicher mit hoher Adressiergeschwindigkeit abgelegt
werden. Die decodierten Strings werden aus dem Speicher herausgelesen,
wenn sie das zweite Mal erscheinen. Sehr lange Strings beinhalten eine
große
Anzahl von Teilstrings, die gewöhnlich
einen übertrieben
großen
Speicher verbrauchen würden,
wobei sie die in der 8 gezeigte Ausführungsform
verwenden. Jedoch werden durch das Decodieren des ersten und des
zweiten Teilstrings darunter liegende Teilstrings für gewöhnlich im
unmittelbaren oder in dem Hilfsspeicher 27D gefunden wie hier
zuvor erklärt
wurde.
-
Es
ist möglich,
dass der Hilfsspeicher so groß gemacht
werden kann, dass sämtliche
normale Strings als decodierte Strings erscheinen würden, nachdem
ihnen einmal im Eingabedaten-String begegnet wurde. Wenn jedoch
das veränderte
System verwendet wird, das in der 8 gezeigt
wird, wenn sich der gesamte String nicht im Speicher befindet, kann
er herkömmlich
decodiert werden und in einem adressierbaren Speicher abgelegt werden.
Das veränderte
System hängt
sich nicht auf, weil ein abnormaler String das Fassungsvermögen des
zugeteilten Speichers überschreitet.
-
Eines
der Vorteile des unmittelbaren Decodierens von Eingabe-Codes aus
einem Komprimierer bei Hochgeschwindigkeiten besteht darin, dass
die Information nicht in Speichern gepuffert und dann decodiert
zu werden braucht, weil sie in Echtzeit decodiert werden kann wie
die Information eintrifft, sogar wenn die Information graphische
Information in der Form von Pixeldaten darstellt. Die vorliegende
Erfindung kann verwendet werden, um Seiten aus Katalogen und Bücher in
Echtzeit herunterzuladen. Wenn die vorliegende Erfindung mit anderen
bekannten Komprimierungsbildformaten verbunden wird, wird es möglich sein,
eine Videoeinzelbildformatgeschwindigkeit am Dekomprimierer zu erreichen.