DE3711200C2 - - Google Patents

Info

Publication number
DE3711200C2
DE3711200C2 DE3711200A DE3711200A DE3711200C2 DE 3711200 C2 DE3711200 C2 DE 3711200C2 DE 3711200 A DE3711200 A DE 3711200A DE 3711200 A DE3711200 A DE 3711200A DE 3711200 C2 DE3711200 C2 DE 3711200C2
Authority
DE
Germany
Prior art keywords
code
data
decoding
run
dimensional
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE3711200A
Other languages
English (en)
Other versions
DE3711200A1 (de
Inventor
Fumitaka Oome Tokio/Tokyo Jp Sato
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Publication of DE3711200A1 publication Critical patent/DE3711200A1/de
Application granted granted Critical
Publication of DE3711200C2 publication Critical patent/DE3711200C2/de
Granted legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/41—Bandwidth or redundancy reduction
    • H04N1/411—Bandwidth or redundancy reduction for the transmission or storage or reproduction of two-tone pictures, e.g. black and white pictures
    • H04N1/413—Systems or arrangements allowing the picture to be reproduced without loss or modification of picture-information
    • H04N1/417—Systems or arrangements allowing the picture to be reproduced without loss or modification of picture-information using predictive or differential encoding
    • H04N1/4175—Systems or arrangements allowing the picture to be reproduced without loss or modification of picture-information using predictive or differential encoding involving the encoding of tone transitions with respect to tone transitions in a reference line
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/005—Statistical coding, e.g. Huffman, run length coding
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/46—Conversion to or from run-length codes, i.e. by representing the number of consecutive digits, or groups of digits, of the same kind by a code word and a digit indicative of that kind

Description

Die Erfindung betrifft ein Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät nach dem Oberbegriff des Patentanspruches 1. Ein solches Gerät vermag Binärdaten mit hoher Geschwindigkeit zu dehnen und insbesondere nach der M2R-Methode (vgl. unten) verdichtete Binärdaten nach dem Pipeline-Verfahren parallel zu decodieren.
Für das Verdichten und Dehnen von Binärdaten sind von der CCITT empfohlene Codierverfahren, wie die MH-, die MR- und die M2R-Methode international standardisiert und verbreitet im Gebrauch. Unter MH-Code ist dabei ein modifizierter Huffman-Code zu verstehen, während der MR-Code einen modifizierten Lese-Code (Modified Read Code) und der M²R-Methode einen modifizierten Lese-Code bedeuten (vgl. auch Abschnitte T.4 und T.6 der CCITT-Norm).
Von den drei genannten Codiermethoden bietet die M²R- Methode die höchste Bildverdichtungsleistung.
Die M2R-Methode ist als Codiermethode für Gruppe-IV- Faksimilesysteme bekannt. Nach dieser Methode werden
  • a) ein Zeilencode (EOL-Code) ausgelassen und
  • b) ein Parameter k auf Unendlich gesetzt, wobei
  • c) alle Bits einer Bezugszeile am Anfang einer Seite jeweils weiße Pixels (Bildelemente) darstellen.
Unter diesen Voraussetzungen kann das Datenverdichtungsverhältnis gegenüber der MR-Methode verbessert werden. Falls etwaige Übertragungs- bzw. Übermittlungsfehler auftreten, wird der Fehler sequentiell zu anschließenden Abtastzeilen übertragen, was ein grundsätzliches Problem darstellt. Zur Vermeidung dieses Problems werden in die Verdichtungsverarbeitung eindimensionale Codierabtastzeilen eingesetzt. Der Parameter k stellt die Zahl der zweidimensionalen Codierabtastzeilen zwischen diesen eindimensionalen Codierabtastzeilen dar.
Ein bisheriges Binärdatenverdichtungs- und -dehnungs- Verarbeitungsgerät wurde in Software unter Verwendung eines Mehrzweck-Mikrorechners für die Durchführung der Dehnungsverarbeitung codierter Daten nach diesen Methoden realisiert. Bei dieser Verarbeitung ergibt sich kein Problem, wenn ein solches Gerät auf ein Faksimilesystem angewandt wird, dessen Datenübermittlungsrate oder -geschwindigkeit auf 9600 bps (Bits/s) begrenzt ist. Wenn jedoch das bisherige Gerät für die Wiedergabe von Bilddaten an Arbeitsstationen eines Rechnersystems eingesetzt wird, kann eine gute Mensch/Maschine-Schnittstelle, z. B. eine Seitenansprechzeit von 1/2 s oder weniger, nicht erzielt werden. Wenn daher die sequentielle Dehnungsverarbeitung nach der M2R-Methode ausgeführt wird, ist die Arbeitsgeschwindigkeit im Vergleich zur MH-Methode erheblich herabgesetzt.
Eine Ursache für das obige Problem liegt im Verarbeitungsverfahren des gesamten Systems. Insbesondere erfolgt in einem herkömmlichen System die Decodierung bitseriell. Zur Lösung des genannten Problems werden verbreitet eine Parallelverarbeitung, eine Vorausverarbeitung und eine Pipeline-Verarbeitung ausgeführt. Die Binärdatendehnungsverarbeitung läßt sich ersichtlicherweise in folgendes aufteilen:
  • a) Decodierverarbeitung von Code(s)
  • b) Erzeugungsverarbeitung von Bilddaten für den decodierten Code
Die Decodier- und Erzeugungsverarbeitung kann mithin mittels getrennter Hardware-Anordnungen parallel durchgeführt werden. Bei solchen Anordnungen wird, während ein Code gedehnt wird, der nächste Code decodiert, und die gesamte Verarbeitung kann dann als Pipeline-Verarbeitung ausgeführt werden. Wenn nach den MH- und MR-Methoden codierte Binärdaten gedehnt werden, ergibt sich bei der Vorausverarbeitung kein Problem. Die M2R-Methode ist dagegen mit den folgenden Problemen behaftet:
Bei allen MH-, MR- und M2R-Methoden ist das (der) Anfangsstück oder -lauf einer jeden Zeile jeweils ein weißer Lauf, der zu weißen Pixels decodiert werden muß. Im Fall der MH- und MR-Methoden wird ein EOL-Code benutzt. Demzufolge kann ein Decodierverarbeitungsteil, der die Vorausverarbeitung ausführt, den Anfang der nächsten Zeile aufgrund des Vorhandenseins eines EOL-Codes unabhängig vom Verlauf der Erzeugungsverarbeitung durch einen Erzeugungsverarbeitungsteil erfassen.
Da jedoch bei der M2R-Methode kein EOL-Code vorhanden ist, kann der Anfang der nächsten Zeile nur dann erfaßt oder festgestellt werden, wenn der Erzeugungsverarbeitungsteil jeden Code entwickelt und ein Ende der Zeile erreicht. Wenn mithin der Anfang der nächsten Zeile unbestimmt ist, kann nicht bestimmt werden, ob die Farbe dieses Abschnitts zwangsweise zu Weiß bestimmt wird.
Infolgedessen kann eine Horizontalmodus-Decodieroperation unter Verwendung getrennter Codetabellen für einen weißen Lauf und einen schwarzen Lauf nicht in Vorauslaufweise eingeleitet werden. Genauer gesagt: bei der Dehnungsverarbeitung nach der M2R-Methode bei einem herkömmlichen Gerät kann die Vorausverarbeitung nicht effektiv durchgeführt werden.
Wie erwähnt, ist das bisherige Gerät mit Problemen bezüglich der Verarbeitungsgeschwindigkeit sowie der Fähigkeit für Universal- oder Mehrzweckanwendung behaftet.
Aus der DE-PS 31 37 704 ist eine Vorrichtung zum Decodieren eines baumförmigen Codes variabler Länge bekannt. Um mit dieser bekannten Vorrichtung Codedaten zu decodieren, muß ein Zähler abwärts zählen, wozu verschiedene Takte erforderlich sind. Da die Codedaten in einen Serien-Parallel-Umsetzer biseriell eingegeben werden, sind für die Lieferung von 4-Bit-Codedaten vier Takte erforderlich. Aufgrund dieser bitseriellen Lieferung der Codedaten ist bei der bekannten Vorrichtung die Betriebsgeschwingkeit relativ niedrig.
In der DE-PS 35 34 081 ist ein Datendemodulator beschrieben, der M²-modulierte Daten zu demodulieren vermag, und in der GB-OS 21 46 874 ist ein Gerät erläutert, bei dem Codedaten zu einem Serien/Parellel-Schieberegister in bitserieller Weise gespeist werden, so daß auch hier eine bitserielle Verarbeitung vorgenommen wird. Da beispielsweise acht Takte erforderlich sind, um 8-Bit-Codedaten in das Schieberegister zu speisen, ist die Decodiergeschwindigkeit entsprechend niedrig.
Schließlich beschäftigt sich die US-PS 45 82 484 mit dem schnellen Decodieren von zweidimensionalen Standard-Faksimile-Codes.
Es ist Aufgabe der vorliegenden Erfindung, ein Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät zu schaffen, das Binärdaten mit hoher Geschwindigkeit zu decodieren, Eingabebinärcodedaten nach einer Pipeline- Methode parallel zu decodieren, insbesondere bei der Dehnungsverarbeitung von nach der M²-Methode codierten Binärcodedaten, und einen EOFB-Code (mit einem Muster entsprechend zwei nachfolgenden EOL-Codes bei der MH- oder MR-Methode) mit hoher Geschwindigkeit zu erfassen vermag, um damit eine Vorausverarbeitung zu ermöglichen und eine Hochgeschwindigkeits-Dehnungsverarbeitung zu erreichen.
Diese Aufgabe wird bei einem Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät nach dem Oberbegriff des Patentanspruches 1 erfindungsgemäß durch die in dessen kennzeichnendem Teil enthaltenen Merkmale gelöst.
Vorteilhafte Weiterbildungen der Erfindung ergeben sich aus den Patentansprüchen 2 bis 18.
Es werden insbesondere die folgenden Vorteile erreicht:
  • 1. Da beim Decodieren eines M2R-Codes eine Vorausverarbeitung zusammen mit Parallelverarbeitung nach Pipeline-Methode möglich ist, kann speziell die Dehnungsverarbeitung mit hoher Geschwindigkeit durchgeführt werden. MH- und MR-Codes können derselben Verarbeitung unterworfen werden, so daß ihre Verarbeitungsgeschwindigkeit im Vergleich zum bisherigen Gerät verbessert (bzw. erhöht) werden kann.
  • 2. Obgleich eine Vorausverarbeitung durchgeführt wird, kann eine Wiederdecodierverarbeitung, wenn eine zu verarbeitende Zeile aktualisiert wird, leicht durchgeführt werden.
  • 3. Eine Steuereinheit kann am Ende einer Zeile (zwei Takte später) augenblicklich feststellen, daß der Decodierverarbeitungsteil 1/2 eines EOFB-Codes erfaßt, auch wenn eine spezielle Verarbeitung an der Grenze von Zeilen zum Diskriminieren des EOFB-Codes nicht ausgeführt wird.
  • 4. Da ein Bezugszeilenpuffer vorgesehen ist, braucht kein Bildspeicher für das Auslesen von Bezugszeilenbilddaten benutzt zu werden, was zu einer Hochgeschwindigkeitsverarbeitung führt.
  • 5. Da der Bezugszeilenpuffer vorgesehen ist, kann auf eine komplexe Schaltung zum Erzeugen einer Bezugszeilendatenadresse für den Bildspeicher verzichtet werden.
Im folgenden ist eine bevorzugte Ausführungsform der Erfindung anhand der Zeichnung näher erläutert. Es zeigt
Fig. 1 ein Blockschaltbild eines Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgeräts gemäß einer Ausführungsform der Erfindung,
Fig. 2 ein Blockschaltbild der Anordnung eines Decodierteils und eines Codierendeverarbeitungsteils eines Decodierverarbeitungsteils gemäß Fig. 1,
Fig. 3 ein Blockschaltbild der Anordnung eines Zählerteils und eines Erzeugungsteils eines Erzeugungsverarbeitungsteils gemäß Fig. 1,
Fig. 4 ein Blockschaltbild der Anordnung eines Bezugszeilenadreßgenerators und eines EOL-Detektors des Decodierverarbeitungsteils nach Fig. 1,
Fig. 5 ein Blockschaltbild der Anordnung eines a 1 b 1-Detektors des Erzeugungsverarbeitungsteils nach Fig. 1,
Fig. 6 eine schaubildliche Darstellung einer Decodiersequenz des Decodierverarbeitungsteils gemäß Fig. 2,
Fig. 7 eine schaubildliche Darstellung einer Erzeugungssequenz des Decodierverarbeitungsteils gemäß Fig. 2,
Fig. 8 ein Adressenformat eines Decodierer-Festwertspeichers oder -ROMs gemäß Fig. 2,
Fig. 9A ein Ausgabeformat des Decodierer-ROMs nach Fig. 2,
Fig. 9B ein Ausgabeformat eines Lauflängendatenabschnitts des Ausgabeformats des Decodierer-ROMs gemäß Fig. 9A und
Fig. 10A bis 10F Zeitsteuerdiagramme zur Verdeutlichung der Arbeitsweise des Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgeräts gemäß der Erfindung.
Im folgenden ist zunächst die Anordnung oder der Aufbau eines Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgeräts gemäß einer Ausführungsform der Erfindung anhand von Fig. 1 beschrieben.
Das Gerät gemäß Fig. 1 umfaßt eine Binärdatenverarbeitungs- Steuereinheit 1 zur Steuerung des Betriebs des gesamten Geräts, einen Verdichtungs- und Dehnungs-Verarbeitungsteil 2 zum Erzeugen von Binärbildmusterdaten, wenn die eingegebenen Binärdaten ein Code sind, und zum Erzeugen eines Codes, wenn die eingegebenen Binärdaten Bildmusterdaten sind, einen Bezugszeilendaten-Speicherteil 4 zum Speichern von Bezugszeilendaten, einen Bezugszeilen-Adreßgenerator 3 zum Erzeugen von Adreßdaten für den Speicherteil 4 sowie einen Taktgenerator zum Erzeugen von Steuer-Taktsignalen.
Der Verdichtungs- und Dehnungs-Verarbeitungsteil 2 umfaßt einen Decodier(verarbeitungs)teil 7 zum Erzeugen von Lauflängendaten, wenn die eingegebenen Binärdaten ein Code sind, und einen Erzeugungs(verarbeitungs) teil 8 zum Erzeugen von Binärbildmusterdaten, die nach Maßgabe der Lauflängedaten verarbeitet sind oder werden.
Der Decodierverarbeitungsteil 7 umfaßt einen EOL-Detektor 11 zur Prüfung, ob eine Erzeugungsverarbeitung bis zum Ende einer Zeile abgeschlossen ist, und zum Erfassen oder Detektieren eines EOL-Codes unter einer vorgegebenen Bedingung, einen zur Erzeugung eines EOL-Codes während der Verdichtungsverarbeitung dienenden Codierende-Verarbeitungsteil 12 und einen Decodierteil 13.
Der Erzeugungsverarbeitungsteil 8 umfaßt einen Zählerteil 14 zum Verriegeln eines Ausgangssignals vom Decodierteil 13 und zum Zählen der Zahl der verarbeiteten Bytes, einen Erzeugungsteil 15 zum Erzeugen von auf der Grundlage von Daten vom Zählerteil 14 verarbeiteten Binärdaten sowie einen a 1 b 1-Detektor 16 zum Erfassen von a 1 und b 1.
Die Steuereinheit 1 ist mit einem Taktgenerator 5 zum Erzeugen von Steuer-Taktsignalen verbunden, und sie steuert die Operationszeitpunkte oder -takte des Decodierverarbeitungsteils 7, des Erzeugungsverarbeitungsteils 8 und des Bezugszeilenadreßgenerators 3 auf der Grundlage von Takten bzw. Taktsignalen vom Generator 5, und sie gibt ferner die nötigen Anweisungen oder Befehle im Verlauf der Verarbeitung aus.
Die Anordnung der einzelnen Teile ist nachstehend anhand der Fig. 2 bis 5 näher beschrieben. Es ist darauf hinzuweisen, daß aus Vereinfachungsgründen ein Steuersignal in den Figuren nicht dargestellt ist.
Zunächst ist der Decodierverarbeitungsteil 7 im einzelnen erläutert, dessen Codierende-Verarbeitungsteil 12 und Decodierteil 13 in Fig. 2 veranschaulicht sind. Der EOL- Detektor 11 wird später zusammen mit dem Bezugszeilenadreßgenerator 3 anhand von Fig. 4 näher erläutert werden.
Der Decodierteil 13 ist durch eine in Fig. 2 gezeigte Schaltung, mit Ausnahme des Codierende-Verarbeitungsteils 12, gebildet. Ein-Byte-Daten werden von einer Eingabedatenschiene (oder -bus) einem Verriegelungsglied 22 eingegeben und durch dieses verriegelt. Die durch das Verriegelungsglied 22 verriegelten Binärdaten werden durch einen Inverter 24 invertiert und dann als Daten K einem Register 26 und dem EOL-Detektor 11 eingegeben. Das Register 26 verschiebt vorher eingegebene Byte-Daten RDTI 15-08 zu Daten RDTI 07-00 nach Maßgabe eines Steuersignals von der Steuereinheit 1, es verriegelt die neuen Eingabedaten als Daten RDTI 15-08 und hält diese als 16-Bit-Daten zusammen mit den Daten RDTI 07-00.
Die 16-Bit-Registerdaten RDTI 15-00 werden über den Codierende- Verarbeitungsteil 12 zu einer Trichterschiebestufe (funnel shifter) 30 ausgegeben. Die Daten RDTI 07-00 werden als Byte-Daten F zum Bezugszeichendaten-Speicherteil 4 ausgegeben. Ein Decodierzeiger 36 zeigt eine Position LSB (niedrigstwertiges Bit) eines zu decodierenden Codes oder einen Teil des Codes an, der als nächster aus den der Trichterschiebestufe 30 eingegebenen Registerdaten RDTI 15-00 ausgegeben werden soll. Eine Anzeigegröße vom Decodierzeiger 36 wird der Trichterschiebestufe 30 nach Maßgabe eines Steuersignals von der Steuereinheit 1 zugeführt.
Die Trichterschiebestufe 30 erzeugt ein 9-Bit-Ausgangssignal LSHT 08-00, das durch Linksverschiebung der Daten RDTI 15-00 durch die Anzeigegröße vom Decodierzeiger 36 erhalten wurde, und gibt dieses Ausgangssignal zu einem Wähler 31 aus. Im Fall der Verarbeitung im Nichtverdichtungsmodus werden Daten LSHT 04-00 der Ausgabedaten LSHT 08-00 als Daten G zum Erzeugungsverarbeitungsteil 8 ausgegeben. Die Daten LSHT 08-00 werden zu den Daten LSHT 10-09 entsprechend den Daten X von der Steuereinheit 1 hinzuaddiert und als 11-Bit-Daten zum Wähler 31 ausgegeben. Der Wähler 31 empfängt die den Daten LSHT 08-06 oder LSHT 08-07 entsprechenden Daten Y von der Steuereinheit 1. Diese Eingangs- oder Eingabedaten werden in Abhängigkeit von einem Steuersignal von der Steuereinheit 1 gewählt und als 11-Bit-Adreßdaten zu einem Decodierer-Festwertspeicher oder -ROM 32 ausgegeben. Die Daten X werden ebenfalls dem Decodierer-ROM 32 zugeführt. Der Decodierer-ROM 32 gibt 16-Bit-Daten DROM 15-00 aus. Insbesondere werden dabei als Daten DROM 07-00 Eingabebinärdaten im Fall der Verdichtungsverarbeitung ausgegeben, während im Fall der Dehnungsverarbeitung Lauflängendaten ausgegeben werden. Lauflängendaten I werden zum Erzeugungsverarbeitungsteil 8 übermittelt. Als Daten DROM 11-08 wird eine decodierte Datenlänge der Eingabedaten ausgegeben. Als Daten DROM 15-12 werden Steuerdaten H zum Bezeichnen des nächsten Zustands ausgegeben. Ein Adressenformat und ein Ausgabedatenformat werden später noch näher erläutert werden.
Die Daten DROM 11-08 werden zu einer Addierstufe 34 ausgegeben, die gleichzeitig Daten vom Decodierzeiger 36 abnimmt. Dabei werden die Daten DROM 11-08 zu den Daten vom Decodierzeiger 36 addiert, und die summierten Daten werden zum Wähler 38 ausgegeben. Der Wähler 38 nimmt außerdem vom a 1 b 1- Detektor 16 Daten D ab, die bei der Verdichtungsverarbeitung, nicht aber bei der Dehnungsverarbeitung benutzt werden. Wenn daher die Dehnungsverarbeitung nach Maßgabe eines Steuersignals von der Steuereinheit 1 ausgeführt wird, werden die summierten Daten wiederum zum Inhalt des Decodierzeigers 36. Letzterer zeigt auf diese Weise eine LSB-Position eines dem decodierten Code am nächsten liegenden Codes an.
Wenn 23-Bitdaten als Ergebnis der Addition durch die Addierstufe 34 zu Daten "1" werden, wird dies der Steuereinheit 1 mittels der Daten J gemeldet. Dies bedeutet, daß die Verarbeitung für ein Byte abgeschlossen ist. Die Steuereinheit 1 gibt nach Maßgabe der Daten J von der Addierstufe 34 ein Steuersignal zum Register 26 aus. Das Register 26 bewirkt eine Linksverschiebung der Daten RDTI 15-08 in Einheiten von Bytes zu Daten RDTI 07-00 nach Maßgabe des Steuersignals von der Steuereinheit 1. Durch das Verriegelungsglied 22 verriegelte neue Byte-Daten werden im Daten-RDTI 15-08-Abschnitt des Registers 26 nach Maßgabe des Steuersignals von der Steuereinheit 1 verriegelt. Die unteren drei Bits der summierten Daten von der Addierstufe 34 werden zum Zeiger 36 ausgegeben, so daß die LSB-Position eines zu decodierenden Codes stets in den Daten RDTI 07-00 des Registers 26 vorhanden ist.
Der Zählerteil 14 und der Erzeugungsteil 15 des Erzeugungsverarbeitungsteils 13 sind nachstehend anhand von Fig. 3 im einzelnen beschrieben. Der Zählerteil 14 umfaßt Wähler 40 und 44 sowie einen RL-Zähler 42. Der Erzeugungsteil 15 ist - unter Ausschluß des Zählerteils 14 - durch eine in Fig. 3 dargestellte Schaltung gebildet.
Das Decodierergebnis I vom Decodierer-ROM 32 wird dem Wähler 40 eingegeben, der auch Daten L von der Steuereinheit 1 abnimmt. Diese Daten werden nach Maßgabe eines Steuersignals von der Steuereinheit 1 gewählt und zum RL- Zähler 42 ausgegeben. Von den Ausgabedaten vom Zähler 40 wird ein 02-00-Bitabschnitt auch zum Wähler 44 ausgegeben. Der RL-Zähler 42 ist ein Zähler mit einer 12-Bit-Länge, und er verriegelt Daten vom Wähler 40 in einer vorbestimmten Position oder Stelle nach Maßgabe eines Steuersignals von der Steuereinheit 1. Unter Heranziehung der Ausgabedaten vom Wähler 40 als Vorgabegröße zählt der RL-Zähler 42 in Übereinstimmung mit den Zählimpulsen von der Steuereinheit 1 herab, und er gibt die Zählung oder den Zählstand als Daten B zum Wähler 44 und zum a 1 b 1-Detektor 16 aus.
Das Ausgangssignal vom RL-Zähler 40 wird auch als Daten M zur Steuereinheit 1 ausgegeben, um zu bestätigen, ob die Zahl der durch den decodierten Code bestimmten Verarbeitungsoperationen vollständig ist. Der Wähler 44 empfängt das Ausgangssignal vom Zähler 42, das Ausgangssignal vom Wähler 40 sowie Daten A vom a 1 b 1-Detektor 16, und er wählt eine dieser Einheiten nach Maßgabe eines Steuersignals von der Steuereinheit 1, um die gewählten Daten zu einem Codierer-ROM 46 auszugeben.
Der Codierer-ROM 46 nimmt die Daten N, einschließlich der Daten für Farbbezeichnung und Daten für die Anzeige oder Angabe einer Dehnungs- oder Verdichtungsverarbeitung, von der Steuereinheit 1 ab. Der Codierer-ROM 46 empfängt Daten vom Wähler 44 und Daten N von der Steuereinheit 1 als Adreßdaten und gibt 8-Bit-Daten EROM 07-00 zum Wähler 48 aus.
Von den Daten EROM 07-00 werden die Daten DROM 07-05 zu einer Addierstufe 52 ausgegeben. Eine durch die Addierstufe 52, den Wähler 54 und einen Bildzeiger 56 gebildete Schaltung arbeitet auf dieselbe Weise wie die Schaltungen des Decodierteils 8. Insbesondere erzeugt dabei der Bildzeiger 56 eine Angabe- oder Anzeigegröße. Nach Abschluß der Erzeugungsverarbeitung für den decodierten Code wird die Anzeigegröße vom Bildzeiger 56 durch die Addierstufe 52 zu den Daten EROM 07-05 addiert, und die summierten Daten werden zum Wähler 54 ausgegeben.
Die Daten C werden vom a 1 b 1-Detektor 16 dem Wähler 54 eingegeben und in Abhängigkeit von einem Steuersignal von der Steuereinheit 1 gewählt, um als Anzeigegröße des Bildzeigers 56 zu dienen. Wenn aufgrund der Addition durch die Addierstufe 52 die 23-Bit-Daten gleich "1" sind, wird dies durch Daten O der Steuereinheit 1 gemeldet.
Der Wähler 48 empfängt Daten EROM 07-00 und Daten G vom Decodierverarbeitungsteil 7 über ein Verriegelungsglied 58 und wählt eine dieser Dateneinheiten in Abhängigkeit vom Steuersignal von der Steuereinheit 1, um die gewählten Daten zu einer Trommelschiebestufe 50 auszugeben. Letztere dreht die Eingabedaten nach Maßgabe der Anzeigegröße vom Bildzeiger 56 und gibt die gedrehten Daten zum Wähler 60 aus. Gleichzeitig gibt die Schiebestufe 50 die gedrehten Daten als Daten RODT 15-08 zum Register 62 aus.
Die Daten RODT 07-00 und die Daten RODT 15-08 werden durch den Wähler 64 in Übereinstimmung mit einem Steuersignal von der Steuereinheit 1 gewählt, und das Wählergebnis wird dem Wähler 60 eingegeben. Ein Ausgangssignal vom Wähler 60 wird als Daten RODT 07-00 einem Register 62 zugeführt, welches die Daten RODT 15-08 nach Maßgabe eines Steuersignals von der Steuereinheit 1 zu Daten RODT 07-00 verschiebt. Die Daten RODT 07-00 und die Daten RODT 15-08 werden zum Wähler 64 ausgegeben.
Weiterhin werden die Daten RODT 07-00 als Daten P zum Bezugszeilendaten- Speicherteil 4 ausgegeben, wenn Bilddaten für ein Byte erzeugt werden, und sie werden außerdem zu einem dem Inverter 24 ähnlichen Inverter 66 ausgegeben, um letztlich auf einer Ausgabedatenschiene ausgegeben zu werden.
Die Anordnung des Bezugszeilen-Adreßgenerators 3, des EOL-Detektors 11 des Decodierverarbeitungsteils 7 und des Bezugszeilendaten-Speicherteils 4 ist nachstehend anhand von Fig. 4 erläutert.
Der EOL-Detektor 11 des Decodierverarbeitungsteils 7 umfaßt ein Stopadreßregister 80, einen Komparator 90 und einen EOL-Detektor 81. Der Bezugszeilen-Adreßgenerator 3 umfaßt einen Adreßzähler 82, eine Addierstufe 84, einen Wähler 86 und ein Adreßregister 88. Der Bezugszeilendaten- Speicherteil 4 umfaßt seinerseits einen Wähler 92 und einen Bezugszeilen-Puffer-Randomspeicher bzw. -RAM 94.
Das Stopadreßregister 80 verriegelt im voraus Einzeilen- Lauflängendaten und gibt die oberen 10-Bit-Daten zu einem Komparator 90 aus. Der Adreßzähler 82 nimmt Daten Q von der Steuereinheit 1 ab. Die Daten Q werden dem Zähler 82 jedesmal dann eingegeben, wenn eine Einbyte-Binärdatenverarbeitung abgeschlossen ist, und der Zähler 82 speichert die Daten Q auf, bis die Einzeilenverarbeitung beendet ist. Ein Ausgangssignal vom Adreßzähler 82 zeigt mithin die Byte-Position an, bis zu welcher die Binärdatenverarbeitung auf der entsprechenden Verarbeitungszeile fortgeschritten ist.
Nach Beendigung der Einzeilenverarbeitung wird der Adreßzähler 82 entsprechend einem Steuersignal von der Steuereinheit 1 rückgesetzt, und er beginnt wieder zu zählen, wenn die Verarbeitung einer neuen Zeile eingeleitet wird. Eine Zählgröße oder ein Zählstand des Adreßzählers 82 wird zum Komparator 90, zum Wähler 86 und zur Addierstufe 84 ausgegeben. Der Komparator 90 nimmt auch Lauflängendaten für eine Zeile vom Stopadreßregister 80 in Einheiten von Bytes ab und vergleicht sie mit dem Zählstand des Adreßregisters 82. Wenn dazwischen eine Koinzidenz festgestellt wird, bedeutet dies, daß die Bilderzeugung eine Byte-Position vor dem Ende der entsprechenden Verarbeitungszeile erreicht hat. Zu diesem Zeitpunkt werden Daten T zur Steuereinheit 1 ausgegeben.
Die Addierstufe 84 nimmt Daten R von der Steuereinheit 1 ab und addiert sie zum Zählstand (bzw. zur Zählgröße) des Adreßzählers 82, um die Summe zum Wähler 86 auszugeben. Der Wähler 86 wählt Adreßdaten vom Adreßzähler 82 sowie Adreßdaten von der Addierstufe 84 nach Maßgabe eines Steuersignals von der Steuereinheit 1, um das Wählergebnis zum Adreßregister 88 auszugeben.
Das Adreßregister 88 empfängt auch Daten S von der Steuereinheit 1 und gibt diese Daten zusammen mit dem Ausgangssignal vom Wähler 86 zum Bezugszeilen-Puffer-RAM 94 aus.
Der Puffer-RAM 94 speichert Bilddaten auf einer bzw. für eine Bezugszeile und Bilddaten für die entsprechende Verarbeitungszeile zum Verarbeiten der nächsten Zeile. Bilddaten für zwei Zeilen werden somit im Randomspeicher bzw. RAM 94 abgespeichert, und Daten S werden von der Steuereinheit 1 zum Adreßregister 88 geliefert, um die Bezeichnungsspeicherbereiche umzuschalten, d. h. zu bestimmen, welcher Bereich (bzw. Speicherplatz) gewählt werden soll.
Der Wähler 92 empfängt die eingegebenen Byte-Bilddaten F, d. h. die Daten RIDT 07-00, über den Codierende-Verarbeitungsteil 28, sowie Byte-Daten P, d. h. verarbeitete Bilddaten RODT 07-00, und wählt eine dieser Dateneinheiten nach Maßgabe eines Steuersignals von der Steuereinheit 1, um dabei das Wählergebnis im Bezugszeilen-Puffer-RAM 94 abzuspeichern.
Wie aus der vorstehenden Beschreibung hervorgeht, wählt der Wähler 86 beim Auslesen von Bezugszeilendaten die Ausgangs- oder Ausgabedaten von der Addierstufe 84, während er bei Speicherung der Bezugszeilendaten die Ausgabedaten vom Adreßzähler 82 wählt, um sie auszugeben.
Wenn zu Beginn der Verarbeitung für eine neue Zeile Bezugszeilendaten ausgelesen werden, werden (Daten) "2" und "1" als Daten R von der Steuereinheit 1 der Addierstufe 84 eingegeben, um für das Register 96 nötige Bezugsdaten auszugeben. Das Register 96 kann sodann die nötigen Bezugszeilendaten halten. Die Daten REF -3-10 vom Register 96 werden als Daten U zu einem b 1-Detektor 102 ausgegeben.
Der EOL-Detektor 81 erfaßt einen EOL-Code, wenn ein Fehler z. B. im Decodierverarbeitungsteil 7 oder im Erzeugungsverarbeitungsteil 8 auftritt. Der Detektor 81 empfängt Daten H vom Decodierverarbeitungsteil 7 und meldet die Erfassung oder Detektierung eines EOL-Codes zur Steuereinheit 1 mittels Daten Z.
Die Anordnung des a 1 b 1-Detektors 16 des Erzeugungsverarbeitungsteils 8 ist nachstehend anhand von Fig. 5 erläutert. Der a 1 b 1-Detektor 16 wird häufig in einem Vertikalmodus und einem Durchlaßmodus in einem zweidimensionalen Modus benutzt.
Aus dem Randomspeicher bzw. RAM 94 ausgelesene Daten werden durch das Register 96 als Daten REF 15-08 verriegelt. Das Register 96 verschiebt in Einheiten von Bytes Daten 07-04 zu Daten REF -4-1 und Daten REF 15-08 zu Daten REF 07-00 nach Maßgabe eines Steuersignals von der Steuereinheit 1, und es verriegelt Daten vom Randomspeicher 94 als Daten REF 15-08. Einer Bezugszeile zugeordnete Daten U werden vom Register 96 zum b 1-Detektor 102 geliefert. Daten F werden vom Codierende-Verarbeitungsteil 28 zu einem a 1- Detektor 104 geliefert. Die b 1- und a 1-Detektoren 102 bzw. 104 nehmen eine Anzeigegröße a 0 von einem a 0-Zeiger 100 ab und erfassen jeweils Positionen a 1 bzw. b 1 von Pixels mit Farbänderungen auf einer Codierzeile und einer Bezugszeile an der rechten Seite der Position a 0 an bzw. im Register 96.
Die durch den b 1-Detektor 102 erfaßte Position b 1 wird zu einer Subtrahierstufe 120 und einem Wähler 108 ausgegeben. Wenn der Punkt b 1 nicht erfaßt wird, wird dies der Steuereinheit 1 mittels Daten A 2 gemeldet. In Verbindung mit dem Register 96 wird "+4" zur Position b 1 hinzuaddiert. Die durch den a 1-Detektor 104 erfaßte Position a 1 wird zu den Wählern 116 und 114 ausgegeben. Der Wähler 116 wählt Daten vom a 1-Detektor 104 und Daten +4 von der Steuereinheit 1 nach Maßgabe eines Steuersignals von der Steuereinheit 1, und er gibt das Wählergebnis zur Subtrahierstufe 120 aus.
Die Subtrahierstufe 120 gibt das Rechenergebnis als Daten A zum Erzeugungsteil 15 aus. Der Wähler 108 empfängt die Anzeigegröße vom a 0-Zeiger 100 und ein Ausgangssignal (bzw. eine Ausgabegröße) b 1 vom b 1-Detektor 102, während der Wähler 110 eine Größe -4 von der Steuereinheit 1 sowie Daten B vom Erzeugungsteil 15 abnimmt. Die Wähler 108 und 110 wählen die jeweiligen Ausgänge oder Ausgaben nach Maßgabe von Steuersignalen von der Steuereinheit 1 und geben diese zur Addierstufe 112 aus.
Die Addierstufe 112 liefert die Summe zum Wähler 114, der außerdem das Ausgangssignal a 1 vom a 1-Detektor 104, die Anzeigegröße vom a 0-Zeiger 100 sowie Daten W von der Steuereinheit 1 empfängt und ein Ausgangssignal (oder eine Ausgabe) nach Maßgabe eines Steuersignals von der Steuereinheit 1 wählt. Das gewählte Ausgangssignal wird als Daten C dem Erzeugungsteil 15 und außerdem als Daten D dem Decodierteil 13 zugeliefert. Das Ausgangssignal vom Wähler 114 wird weiterhin durch den a 0-Zeiger 100 als Anzeigegröße verriegelt. Die Anzeigegröße des a 0-Zeigers 100 und Daten vom Stopadreßregister 80 werden durch den Komparator 106 verglichen, um damit festzustellen, ob die Verarbeitung der letzten Daten, die kleiner sind als ein Byte, abgeschlossen ist; das Vergleichsergebnis wird als Daten V zur Steuereinheit 1 ausgegeben.
Im folgenden ist die Arbeitsweise des erfindungsgemäßen Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgeräts beschrieben.
Nachstehend ist zunächst die Dehnungsverarbeitung im einzelnen erläutert.
Wenn eine Dehnungsverarbeitung für eine neue Seite eingeleitet wird, werden Steuerdaten, einschließlich von Daten zur Bestimmung der MH-, MR- oder M2R-Methode, im Fall eines Faksimilesystems geliefert. Die Steuerdaten enthalten Daten zur Anzeige einer Lauflänge für eine Zeile. Das Stopadreßregister 80 speichert die Lauflängendaten für eine Zeile. Bei der Verarbeitung nach der M2R-Methode sind alle Bits der Bilddaten auf der Bezugszeile am Anfang einer Seite weiß oder gleich "0". In diesem Zustand wird zunächst durch den EOL-Detektor 81 ein EOL-Code erfaßt, um die Dehnungsverarbeitung einzuleiten.
Bei Einleitung einer Dehnungsverarbeitung für eine neue Zeile wird ein erforderlicher Zustand initialisiert. Beispielsweise wird die folgende Initialisierung ausgeführt: Der Adreßzähler 82 wird rückgesetzt, und von der Steuereinheit 1 werden Daten S zum Bit "10" des Adreßregisters 88 geliefert, um Adressen umzuschalten. Danach wird von der Steuereinheit 1 eine Dateneinheit "1" als Daten R der Addierstufe 84 eingegeben, und erste Byte-Daten auf der Bezugszeile werden aus dem Bezugszeilen- Puffer-RAM 94 ausgelesen, um als Daten REF 15-08 im Register 96 abgespeichert zu werden. Nach dem Verschieben der im Register 96 gespeicherten Daten zu Daten REF 07-00 wird (die Einheit) "2" als Daten R von der Steuereinheit 1 geliefert, und die aus dem RAM 94 ausgelesenen Byte-Daten werden auf dieselbe Weise, wie oben beschrieben, als Daten REF 15-08 im Register 96 gespeichert. Die Zeiger 36, 56 und 100 werden rückgesetzt. Daten W werden von der Steuereinheit 1 dem Wähler 114 eingegeben und entsprechend einem Steuersignal von der Steuereinheit 1 gewählt, so daß ein neuer Wert bzw. eine neue Größe im a 0-Zeiger 100 gesetzt wird. Die Farbe wird dabei zwangsweise auf "Weiß" gesetzt.
Beispielsweise sei angenommen, daß ein nach der M2R-Methode codierter Code über eine Eingabedatenschiene dem Decodierverarbeitungsteil 7 in Einheiten von 8 Bits, d. h. 1 Byte, nach Vornahme der erwähnten Initialisierung eingegeben und durch das Verriegelungsglied 22 nach Maßgabe eines Steuersignals von der Steuereinheit verriegelt wird.
In einem Register, das hauptsächlich zum Halten (oder Speichern) von Bilddaten und eines verdichteten Codes dient, entspricht das am weitesten links befindliche Bit dem Bit "0". In einem Register, das hauptsächlich zum Halten von binären Steuerdaten dient, entspricht das am weitesten rechts stehende Bit dem Bit "0". Infolgedessen müssen die eingegebenen Binärdaten invertiert werden. Dies erfolgt durch den Inverter 24, der die Binärdaten sodann zum Register 26 und zum EOL-Detektor 11 ausgibt. Im Register 26 werden vorher eingegebene Byte-Daten RDTI 15-08 nach Maßgabe eines Steuersignals von der Steuereinheit 1 zu Daten RDTI 07-00 verschoben, und neue Eingabedaten werden als Daten RDTI 15-08 verriegelt und zusammen mit Daten RDTI 07-00 als 16-Bit-Daten gehalten. Auf diese Weise werden am Anfang einer Seite 2-Byte-Binärdaten eingegeben.
16-Bit-Registerdaten RDTI 15-00 werden zum Codierende-Verarbeitungsteil 28 ausgegeben. Diese Schaltung wird nur bei der Verdichtungsverarbeitung betätigt, während sie bei der Dehnungsverarbeitung einfach Daten passieren läßt. Die 16-Bit-Registerdaten RDTI 15-00 werden daher über den Verarbeitungsteil 28 zur Trichterschiebestufe 30 ausgegeben.
Der Decodierzeiger 36 zeigt die LSB-Position eines als nächstes auszugebenden Codes vom oder aus den Registerdaten RDTI 15-00 an, die der Trichterschiebestufe 30 eingegeben wurden. Letztere erzeugt eine 9-Bit-Ausgabe LSHT 08-00, die durch Linksverschieben der Daten RDTI 15-00 um die Zahl der durch eine Anzeigegröße vom Zeiger 36 angegebenen Bits erhalten wurde. Wenn beispielsweise die Größe des Zeigers 36 gleich "3" ist, wählt die Trichterschiebestufe 30 Daten RDTI 11-03 aus den Eingabedaten RDTI 15-00 und gibt diese als Daten LSHT 08-00 aus.
Die Daten LSHT 08-00 werden zu den den Daten LSHT 10-09 von der Steuereinheit 1 entsprechenden Daten hinzuaddiert, und das Ergebnis wird zum Wähler 31 ausgegeben, der außerdem Daten entsprechend den Daten LSHT 06-08 oder LSHT 07-08 von der Steuereinheit 1 abnimmt. Diese Eingabedaten werden nach Maßgabe eines Steuersignals von der Steuereinheit 1 gewählt, und die gewählten Daten werden als 11-Bit-Adreßdaten zum Decodierer-ROM 32 ausgegeben.
Wenn in diesem Fall bei der M2R-Methode die Erzeugungsverarbeitung eines unmittelbar vorhergehenden decodierten Codes nicht beendet oder abgeschlossen ist, wird das dem Wähler 31 zugeordnete Steuersignal nicht erzeugt. Der Wähler 31 wartet daher den Abschluß der Erzeugungsverarbeitung in einem Zustand ab, in welchem die Daten LSHT 08-00 geliefert werden.
Falls der Wähler 31 den Abschluß nicht abwartet, kann ein weißer Vorsatz oder Lauf für einen Anfangscode der nächsten Zeile, nachdem die Verarbeitung bis zum Ende der augenblicklichen Verarbeitungszeile fortschreitet, nicht zwangsweise gesetzt werden. Wenn in diesem Fall die Decodierung für den Anfangscode durchgeführt wird, muß die Anzeigegröße des Decodierzeigers 36 rückgesetzt werden, und die Decodierung muß wieder aufgenommen werden, was Schwierigkeiten bedingt.
Falls jedoch eine solche Voraussetzung nicht durchgeführt wird, kann ein EOFB-Code (= Ende des Faksimileblocks: der EOFB-Code enthält doppelte EOL-Codes) am Ende einer Seite nicht decodiert werden, und die Verarbeitung wird am EOFB-Code angehalten. Wenn daher ein EOL-Code im EOFB-Code durch den EOL-Detektor 81 erfaßt wird, erfolgt erfindungsgemäß die Decodierung durch Vorausverarbeitung.
Da die MH- und MR-Methoden im Gegensatz zur M2R-Methode einen EOL-Code verwenden, kann eine Codedateneinheit durch Vorausverarbeitung decodiert werden, ohne daß der Abschluß der augenblicklichen Erzeugungsverarbeitung abgewartet zu werden braucht. Mit der Decodierverarbeitung nach der M2R- Methode kann somit auch die nach der MH- oder MR-Methode mit höherer Geschwindigkeit als beim bisherigen Gerät durchgeführt werden.
Die Daten LSHT 10-00 werden nach Maßgabe eines Steuersignals von der Steuereinheit 1 zum Decodierer-ROM 32 ausgegeben. Wenn Daten Y 08-06 gewählt sind, wird der 08-06-Bitabschnitt oder der 08-07-Bitabschnitt der Daten LSHT 10-00 als der entsprechende Abschnitt oder Teil der Daten LSHT gewählt, und der Datenabschnitt LSHT 08-00 wird durch entsprechende, zum Decodierer-ROM 32 auszugebende Bits zur MSB-Richtung verschoben.
Ein Adressenformat des Decodierer-ROMs 32 (noch zu beschreiben) zeigt an, wann und welche Daten zu wählen sind. Der Decodierer-ROM 32 gibt 16-Bit-Daten DROM 15-00 des in Fig. 9A gezeigten Formats nach Maßgabe eines Adressenformats gemäß Fig. 8 aus. Insbesondere werden dabei Lauflängendaten als Daten DROM 07-00, Codelängendaten als Daten DROM 11-08 und Daten für die Bezeichnung des nächsten Zustands als Daten DROM 15-12 ausgegeben. Die Adressen- und Ausgangsformate werden später noch näher erläutert werden.
Die Daten DROM 11-08 werden zur Addierstufe 34 ausgegeben, welche gleichzeitig Daten vom Zeiger 36 abnimmt. Die Daten DROM 11-08 werden somit zum Inhalt des Zeigers 36 addiert, und die summierten Daten werden zum Wähler 38 ausgegeben. Der Wähler 38 empfängt ein Signal D, das bei der Verdichtungsverarbeitung, nicht aber bei der Dehnungsverarbeitung benutzt wird, vom a 1 b 1-Detektor 16. Da jedoch im vorliegenden Fall die Dehnungsverarbeitung durchgeführt wird, wird das Ausgangssignal von der Addierstufe 34 nach Maßgabe eines Steuersignals von der Steuereinheit 1 gewählt. Aus diesem Grund werden die summierten Daten wiederum zum Inhalt des Zeigers 36. Der Zeiger 36 zeigt auf diese Weise die LSB-Position eines einem decodierten Code am nächsten gelegenen Codes an.
Wenn die 23-Bit-Daten als Ergebnis der Addition durch die Addierstufe 34 zu "1" werden, wird dies der Steuereinheit 1 mittels der Daten J gemeldet. Dies bedeutet, daß die Decodierverarbeitung für ein Byte abgeschlossen ist. Die Steuereinheit 1 gibt daraufhin ein Steuersignal zum Register 26 aus, um die Daten RDTI 15-08 in Einheiten von Bytes nach links zu Daten RDTI 07-00 zu verschieben. Durch das Verriegelungsglied 22 verriegelte neue Byte-Daten werden als Daten RDTI 15-08 nach Maßgabe eines Steuersignals von der Steuereinheit 1 im Register 26 verriegelt. Der Zeiger 36 nimmt die unteren drei Bits der summierten Daten von der Addierstufe 34 ab, so daß in den Daten RDTI 07-00 des Registers 26 stets die LSB-Position eines zu decodierenden Codes vorhanden ist.
Die Adressen- und Ausgangs- oder Ausgabeformate des Decodierer- ROMs 32 sind im folgenden anhand der Fig. 8, 9A und 9B beschrieben. Hierbei ist eine zu decodierende Codeeinheit ein Identifizier- oder Kenncode eines Horizontalmodus, ein Ergänzungscode, ein Beendigungscode, ein Vertikalmoduscode, ein Durchlaßmoduscode, ein Erweiterungscode oder dergleichen. Wenn der Ergänzungscode oder ein Beendigungscode neun Bits übersteigen, werden zwei Decodierverarbeitungen ausgeführt.
Eine Adresse des Decodierer-ROMs 32 besitzt eine 11-Bit- Konfiguration. Der ROM 32 enthält eine eindimensionale Weißlauf-Codetabelle 1, eine eindimensionale Schwarzlauf- Codetabelle 2, eine eindimensionale Schwarzlauf-Codetabelle 1, eine zweidimensionale Codetabelle, Spezialcode-Erfassungstabelle, Nichtverdichtungscodetabelle 1, Nichtverdichtungscodetabelle 2, Tabelle für Verarbeitung in anderen Biteinheiten, die für die Dehnungsverarbeitung vorbereitet werden, und eine Tabelle für Verdichtungsverarbeitung.
Nahezu alle eindimensionalen Weißlaufcodes bestehen aus 9 Bits oder weniger. Wenn eine Lauflänge 1792 Bits oder mehr übersteigt, besteht nur ein Ergänzungscode aus 10 Bits oder mehr, wobei dieser Ergänzungscode demjenigen für einen Schwarzlauf (black run) mit derselben Lauflänge identisch ist. Aus diesem Grund wird durch die eindimensionale Weißlauf-Codetabelle 1 ein eindimensionaler Weißlaufcode von 9 Bits oder weniger verarbeitet. Wenn ein Code aus 10 Bits oder mehr besteht, wird eine eindimensionale Schwarzlauf-Codetabelle 2 im Anschluß an die eindimensionale Weißlauf-Codetabelle 1 benutzt.
Ein Code "00" wird von der Steuereinheit 1 als Daten LSHT 10-09 der eindimensionalen Weißlauf-Codetabelle 1 geliefert. Nahezu alle eindimensionalen Schwarzlaufcodes bestehen aus 10 Bits oder mehr, wobei die maximale Länge 13 Bits beträgt. Ein Schwarzlauf-Ergänzungscode mit einer Lauflänge von von 1792 Bits oder mehr ist auch einem Weißlauf gemeinsam. Wenn somit ein Schwarzlaufcode aus 7 Bits oder weniger besteht, wird er mittels der eindimensionalen Schwarzlauf-Codetabelle 1 verarbeitet; wenn er aus 8 Bits oder mehr besteht, wird eine Zweischritt- Decodierverarbeitung unter Heranziehung der eindimensionalen Schwarzlauf-Codetabelle 2 im Anschluß an die eindimensionale Schwarzlauf-Codetabelle 1 durchgeführt.
Ein Code "10" wird von der Steuereinheit 1 als Daten LSHT 10-09 der eindimensionalen Schwarzlauf-Codetabelle 1 geliefert, während ein Code "00" als Daten LSHT 08-07 geliefert wird. Der Code "01" wird von der Steuereinheit 1 als Daten LSHT 10-09 der eindimensionalen Schwarzlauf- Codetabelle 2 geliefert. Ein MH-Codeabschnitt eines Codes im Horizontalmodus, nach der MR- oder M2R-Methode codiert, wird mittels der eindimensionalen Codetabellen verarbeitet.
Infolgedessen werden Codes eines Durchlaßmodus und eines Vertikalmodus sowie ein Identifiziercode in einem Horizontalmodus mittels der zweidimensionalen Codetabelle verarbeitet. Ein Code "1001" wird von der Steuereinheit 1 als Daten LSHT 10-07 geliefert.
Die Spezialcode-Erfassungstabelle dient zum Erfassen oder Detektieren eines EOL- oder EOFB-Codes sowie eines Erweiterungscodes für den Eintritt in den Nichtverdichtungsmodus. Für diesen Zweck wird ein 6-Bit-Code abgerufen. Ein Code "10110" wird von der Steuereinheit 1 als Daten LSHT 10-06 geliefert. Für den Nichtverdichtungsmodus sind Nichtverdichtungs-Codetabellen 1 und 2 vorgesehen. Codes "10100" und "10101" werden von der Steuereinheit 1 jeweils als Daten LSHT 10-06 dieser Tabellen geliefert. Ein Steuercode "10111" wird von der Steuereinheit 1 als Daten LSHT 10-06 für die andere Tabelle geliefert.
Das Ausgabeformat des Decodierer-ROMs 32 ist in Fig. 9A gezeigt. Der 07-00-Bitabschnitt der Daten DROM 15-00 repräsentiert die Lauflängendaten eines decodierten Codes. Der 11-08-Bitabschnitt der Daten DROM 15-00 repräsentiert die Codelängendaten eines decodierten Codes in Einheiten von Bits. Der 15-12-Bitabschnitt der Daten DROM 15-00 repräsentiert die nächsten Zustandsdaten, die für Steuerung benutzt werden, einschließlich der Daten zur Bezeichnung der als nächstes heranzuziehenden Tabelle, wodurch eine Farbe für den nächsten Code bezeichnet wird. Diese Daten signalisieren oder melden der Steuereinheit 1 die Klassifizierung des Decodierergebnisses, z. B. daß ein decodierter Code ein Beendigungscode im Horizontalmodus, ein Ergänzungscode im Horizontalmodus, der (im) Vertikalmodus, der Nichtverdichtungsmodus, der Erweiterungscode o. dgl. ist.
Das Ausgabeformat der Daten DROM 07-00 ist in Fig. 9B dargestellt. Insbesondere zeigen dabei bei einer eindimensionalen Codierung des Ergänzungscodes 6 Bits der Daten DROM 05-00 eine 64X-Größe an, die durch Dekrementieren einer praktischen Lauflänge um "1" erhalten wurde. Bei einem Beendigungscode für eindimensionale Codierung zeigen 6 Bits der Daten DROM 05-00 eine Bitgröße an, die durch Dekrementieren einer praktischen Lauflänge um "1" erhalten wurde. In einem zweidimensionalen Codier-Vertikalmodus geben 4 Bits der Daten DROM 03-00 den Zustand der Lauflänge an, d. h. eine durch Subtrahieren von "4" von einer Differenz zwischen a 1 und b 1 erhaltene Größe. In einem zweidimensionalen Codier-Durchlaßmodus zeigen 4 Bits der Daten DROM 03-00 "1100" an.
Im Nichtverdichtungsmodus geben weiterhin Daten DROM 02-00 eine Musterlänge an. Wenn daher ein Beendigungscode (000111) an der rechten Seite von einem durch den Zeiger 36 bezeichneten Punkt in vom Register 26 erhaltenen Daten eingegeben wird, werden Daten, die diesen Code als "Beendigungscode mit einer Weißlauflänge von 1" bezeichnen, in einen 07-00-Bitabschnitt ausgegeben, während Daten, welche den Code als eine Länge von 6 Bits besitzend angeben, in einem 11-08-Bitabschnitt vom Decodierer-ROM 32 ausgegeben werden, zu dem ein Zugriff mit 9 Bits hergestellt wird, beginnend mit diesem Bit-Muster, d. h. "000111xxx" (x = "0" oder "1").
Insbesondere werden die Lauflängendaten "01000000" als Daten DROM 07-00 und die Codelängendaten "0110" als Daten DROM 11-08 ausgegeben.
Im folgenden ist anhand von Fig. 6 eine Zustandsübergangssequenz beschrieben, die aufzeigt, auf welche Weise der Decodierteil 13 bei der Dehnungsverarbeitung auf die Tabellen Bezug nimmt.
Bei dieser Ausführungsform decodiert der Decodierteil 13 Codes für eine Zeile unter der Steuerung der Steuereinheit 1. Gemäß Fig. 6 zeigt ein Steuersignal 1 D an, ob eine zu decodierende Zeile eine nach der MH-Methode codierte Zeile ist. Das Steuersignal 1 D wird von der Steuereinheit 1 für jede Zeile geliefert. Wenn das Gerät beispielsweise im MH-Modus betrieben wird, wird das Steuersignal 1 D für alle Zeilen zu "1" und in anderen Betriebsarten als dem MH-Modus zu "0". Andere Übergangsbedingungen werden je nach dem Ausgangssignal vom Decodierer-ROM 32, d. h. den nächsten Zustandsdaten, bestimmt.
In Fig. 6 geben die verschiedene Zustände anzeigende Ellipsen an, auf welche Tabelle unter den verschiedenen, im Decodierer-ROM 32 gespeicherten Tabellen Bezug genommen wird. Da die eindimensionale Codierung in weiße und schwarze Läufe (oder auch Strecken) unterteilt ist, wird auf verschiedene eindimensionale Codetabellen A und B in Abhängigkeit von weißen und schwarzen Läufen Bezug genommen.
Bei der beschriebenen Ausführungsform kann der Decodierteil 13 in einem Zyklus einen Code bis zu 9 Bits verarbeiten. Da in den eindimensionalen Codes solche von 10 Bits oder mehr vorhanden sind, werden diese in zwei Zyklen verarbeitet. Zu diesem Zweck werden eindimensionale Codetabellen 1 und 2 aufgestellt oder vorbereitet, wobei die Tabelle 2 in der eindimensionalen Schwarzlauf-Codetabelle 2 als Codetabellen der zweiten Stufe der eindimensionalen Codes enthalten ist. Die eindimensionalen Codetabellen A und B werden für jede der Stufen 1 und 2 zur Unterscheidung zweier Läufe, d. h. weißer und schwarzer Läufe, in Horizontalmoduscodes benutzt.
Die eindimensionalen Codetabellen A und B können für jede Farbe der Läufe benutzt werden. Wenn die Codetabelle A für weiße Läufe benutzt wird, wird die Codetabelle B für schwarze Läufe eingesetzt. Die folgende Beschreibung setzt voraus, daß die Codetabelle A für weiße Läufe benutzt wird. Daher entsprechen Tabelle 1A der eindimensionalen Weißlauf- Codetabelle 1, Tabelle 1B der eindimensionalen Schwarzlauf- Codetabelle 1 und Tabellen 2A und 2B der eindimensionalen Schwarzlauf-Codetabelle 2.
Die Spezialcode-Erfassungstabelle ist getrennt für das Decodieren eines EOL-Codes und von Erweiterungscodes vorgesehen (von letzteren sind die durch die CCITT-Empfehlung bezeichneten Codes ein Identifizier- oder Kenncode für einen Nichtverdichtungsmodus). In den EOL- und Erweiterungscodes folgen "0"en für oder auf 6 Bits oder mehr.
Im folgenden ist ein Fall beschrieben, in welchem eine nach der MH-Methode codierte eindimensionale Codiermoduszeile decodiert wird. Da beim Decodieren einer eindimensionalen Codiermoduszeile das Steuersignal 1 D gleich "1" ist, wird zunächst eine eindimensionale Codetabelle 1A zum Decodieren eines Codes benutzt. Wenn der Code aus 9 Bits oder weniger besteht, kann das Decodieren nur mittels der eindimensionalen Codetabelle 1A abgeschlossen werden. Wenn dagegen der Code aus 10 Bits oder mehr besteht, wird anschließend die eindimensionale Codetabelle 2A benutzt. Ein eindimensionaler Weißlauf-Code, auch ein Ergänzungscode oder ein Beendigungscode, bestehen aus 9 Bits oder weniger, sofern es sich nicht um einen Ergänzungscode mit einer Lauflänge von 1792 Bits oder mehr handelt. Wenn daher für einen weißen Lauf Codes mit maximal 9 Bits, wie bei der beschriebenen Ausführungsform, in einem Zyklus decodiert werden, wird nur die eindimensionale Codetabelle 1A benutzt. Für einen Ergänzungscode mit einer Lauflänge von 1792 Bits oder mehr wird nach einer Bezugnahme auf die eindimensionale Codetabelle 1A der Decodierer-RAM 32 durch Daten X und Y von der Steuereinheit 1 auf der Grundlage der Daten DROM 15-12 in einen erstem Zyklus angesteuert, um auf die eindimensionale Codetabelle 2A Bezug zu nehmen.
In einem eindimensionalen Code folgt stets ein schwarzer Lauf auf einen weißen Lauf und umgekehrt, sofern es sich nicht um das Ende einer Zeile handelt. Nach dem Ende der Zeile wird der weiße Lauf zwangsweise gesetzt. Wenn daher die Decodierung eines Beendigungscodes unter Verwendung der eindimensionalen Codetabelle 1A oder 2A abgeschlossen ist, wird der nächste eindimensionale Code mittels der eindimensionalen Codetabelle 1B decodiert.
Nahezu alle Schwarzlaufcodes, auch Ergänzungs- und Beendigungscodes, bestehen aus 9 Bits oder mehr. Wenn daher in der Praxis ein Schwarzlaufcode decodiert wird, wird auf die eindimensionale Codetabelle 1B Bezug genommen, worauf auf die eindimensionale Codetabelle 2B in Abhängigkeit von Daten X und Y von der Steuereinheit 1 entsprechend der Ausgabe des Decodierergebnisses Bezug genommen wird. Wenn die Decodierung eines Beendigungscodes mittels der eindimensionalen Codetabelle 1B oder 2B abgeschlossen ist, wird die Farbbezeichnung eines Laufs zur Änderung der Daten X aktualisiert, worauf die eindimensionale Codetabelle 1A benutzt wird.
Auf diese Weise werden die eindimensionalen Codetabellen A und B zur Durchführung der Decodierung für eine Zeile abwechselnd benutzt. Wenn die Decodierung zum Ende der Zeile fortschreitet und dabei "Nullen" auf 8 Bits oder mehr vom Beginn eines Codes in den eindimensionalen Codetabellen 1 und 2 folgen, wird die Spezialcode-Erfassungstabelle benutzt, um einen EOL-Code zu erfassen und damit die EOL-Erfassungsverarbeitung auszuführen.
Im folgenden ist die Decodierung von nach der MR- oder M2R- Methode codierten Codes beschrieben. In diesem Fall entsprechen das Steuersignal 1 D einer "0" und das Signal 1 D einer "1". Der Decodierteil 13 bezieht sich daher zunächst auf die zweidimensionale Codetabelle. Da unter den zweidimensionalen Codes die Codes im Vertikal- und im Durchlaßmodus sowie ein Identifiziercode eines Horizontalmodus aus 6 Bits oder weniger bestehen, wird dieser in Übereinstimmung mit der zweidimensionalen Codetabelle verarbeitet, während der nächste Code ebenfalls in Übereinstimmung mit der zweidimensionalen Codetabelle nach Maßgabe der Daten X und Y von der Steuereinheit 1 verarbeitet wird.
Wenn die Identifizierung des Horizontalmoduscodes nach der zweidimensionalen Codetabelle decodiert wird, wird für den folgenden Code auf die eindimensionale Codetabelle 1A Bezug genommen, und zwar auf dieselbe Weise, wie bei dem nach der MH-Methode codierten Code. Derselbe Tabellenübergang trifft auch hierfür zu. Zu diesem Zeitpunkt wird auf die eindimensionale Codetabelle A für die erste Farbe, z. B. für den weißen Lauf, Bezug genommen. Wenn das Decodieren eines Beendigungscodes abgeschlossen ist, wird auf die eindimensionale Codetabelle B Bezug genommen, um einen Schwarzlaufcode zu decodieren.
Wenn die Decodierung des Beendigungscodes unter Heranziehung der eindimensionalen Codetabelle 1A oder 2B beendet ist, wird in Abhängigkeit von den Daten X und Y der Steuereinheit 1 nach Maßgabe der Ausgabe des Decodierergebnisses wiederum auf die zweidimensionale Codetabelle Bezug genommen.
Wenn "Nullen" für oder auf 6 Bits oder mehr vom Beginn eines decodierten Codes in einer zweidimensionalen Tabelle und "Nullen" für oder auf 8 Bits oder mehr in eindimensionalen Codetabellen folgen, wird die Spezialcode-Erfassungstabelle benutzt, um einen EOL-Code zu erfassen oder festzustellen und damit die EOL- oder EOFB-Erfassungsverarbeitung auszuführen.
Im folgenden ist der Nichtverdichtungsmodus beschrieben. Wenn bei der Bezugnahme auf die Spezialcode-Erfassungstabelle festgestellt wird, daß ein Code nicht ein EOL-Code ist, d. h. daß es sich um einen Identifiziercode eines Nichtverdichtungsmodus handelt, überführt die Steuereinheit 1 den Zustand auf die Nichtverdichtungscodetabelle 1. Mittels letzterer wird dann dieser Code decodiert. Wenn im Nichtverdichtungsmodus fünf "Nullen" folgen, wird eine "1" eingesetzt. Infolgedessen folgen nicht sechs "Nullen", außer für einen Identifiziercode für die Rückführung auf einen Normalcode.
Wenn "Nullen" für oder auf 6 Bits oder mehr folgen, wird auf die Nichtverdichtungscodetabelle 2 Bezug genommen, um zu prüfen, ob es sich um einen Endcode des Nichtverdichtungsmodus handelt. Wenn der Endcode festgestellt wird, kehrt die Decodierverarbeitung zu einem Normalcodiermodus zurück, d. h. zur zweidimensionalen Codetabelle oder zur eindimensionalen Codetabelle 1A oder 1B.
Wenn der EOL-Code festgestellt wird, wird eine Nachverarbeitung auf die vorher beschriebene Weise ausgeführt.
Im folgenden ist das Decodieren eines EOL-Codes beschrieben. Bei der MH- oder MR-Methode wird ein EOL-Code benutzt. Wie erwähnt, wird dagegen bei der M2R-Methode kein EOL-Code benutzt. Stattdessen wird ein Code EOFB (Ende des Faksimileblocks) mit zwei aufeinanderfolgenden EOL-Codes benutzt. Wenn auf die eindimensionale Codetabelle Bezug genommen wird, folgen, außer für den EOL-Code und einen Erweiterungscode, keine "Nullen" für bzw. auf 8 Bits oder mehr, sofern nicht ein Codierungsfehler auftritt. Zu diesem Zeitpunkt wird der EOL-Code durch Bezugnahme auf die Spezialcode- Erfassungstabelle nach Maßgabe der Daten X und Y von der Steuereinheit 1 erfaßt oder festgestellt.
Bei der MR- oder M2R-Methode folgen keine "Nullen" für oder auf 6 Bits oder mehr in der zweidimensionalen Codetabelle. Wenn "Nullen" für bzw. auf 6 Bits oder mehr vom Beginn eines in der zweidimensionalen Codetabelle decodierten Codes folgen, wird zur Erfassung des EOL-Codes auf die Spezialcode- Erfassungstabelle Bezug genommen.
Da bei der M2R-Methode Empfangsdaten zusammen mit Prüfdaten übermittelt werden, kann kein Übermittlungsfehler auftreten. Ein solcher Fehler kann dagegen bei der MH- und MR- Methode auftreten. Wenn festgestellt wird, daß ein decodierter Code einen Fehler enthält, wird ein Steuersignal 1 S ausgeführt, und die entsprechende Verarbeitungszeile wird bis zu ihrem Ende übersprungen. Sodann wird der EOL-Code durch den EOL-Detektor 81 erfaßt, und wenn er als EOL-Code bestätigt worden ist, wird die EOL-Erfassungsverarbeitung ausgeführt.
Genauer gesagt: Beim Auftreten eines Fehlers wird die Decodierung der betreffenden Verarbeitungszeile bis zur Fehlererfassung oder -feststellung abgeschlossen, und es wird die Decodierung der nächsten Verarbeitungszeile eingeleitet. Dieser EOL-Detektorteil wird auch für die Erfassung eines ersten, am Anfang einer Seite übermittelten EOL-Codes benutzt.
Bei der M2R-Methode wird, wie erwähnt, eine Fehlerprüfung bei der Übertragung von Daten durchgeführt. Wenn ein Fehlercode festgestellt wird, wird eine Wiederübertragungsanforderung erzeugt, worauf die richtigen Daten übermittelt werden. Eine Fehlererfassung kann daher entfallen. Wie erwähnt, wird bei der M2R-Methode kein EOL-Code benutzt, vielmehr ist stattdessen ein EOFB-Code am Ende der Codes für eine Seite vorgesehen.
Wenn der Zustand des Decodierteils 13 für die Vorausverarbeitung nicht einfach geändert wird, kann dann, wenn die Verarbeitung bis zum Ende der letzten Zeile fortschreitet, das Vorhandensein (der ersten Hälfte) des EOFB- Codes nicht geprüft werden. Dieses Problem kann wie folgt gelöst werden: Wenn in einem schraffierten Abschnitt von Fig. 6, d. h. während der Decodierung eines aus lauter Bits "0" bestehenden Codes (ein solcher Zustand) festgestellt wird und auf die Spezialcode-Erfassungstabelle Bezug genommen werden muß, kann der Zustand des Decodierteils 13 für die Vorausverarbeitung unabhängig von der vorher genannten Operation im EOL-Erfassungszustand geändert werden. Wenn somit die Verarbeitung zum Ende der letzten Zeile fortschreitet, kann der Decodierteil 13 die erste Hälfte des EOFB-Codes decodieren und damit anschließend die zweite Hälfte decodieren.
Wenn ein nach einer anderen Methode als der M2R-Methode, z. B. nach der MR- oder MH-Methode, codierter Code decodiert wird, kann erfindungsgemäß die Vorausverarbeitung innerhalb des Bereichs der Verarbeitung für einen Lauf fortschreiten. Wenn insbesondere festgestellt wird, daß nach der Bezugnahme auf die eindimensionale Codetabelle 1 auf die eindimensionale Codetabelle 2 oder die Spezialcode-Erfassungstabelle Bezug genommen wird, kann die Verarbeitung für die Bezugnahme auf die eindimensionale Codetabelle 2 oder die Spezialcode- Erfassungstabelle beendet werden, bevor die Erzeugungsverarbeitung für einen unmittelbar vorhergehenden decodierten Code abgeschlossen ist. Da nämlich diese Methoden EOL-Codes verwenden, wird auch dann, wenn der Zustand des Decodierverarbeitungsteils 7 für die Vorausverarbeitung geändert wird, kein Problem aufgeworfen, d. h. die Farbe des Anfangs der nächsten Zeile wird bestimmt. Das so decodierte Ergebnis wird zum Erzeugungsverarbeitungsteil 8 ausgegeben.
Im folgenden ist die Arbeitsweise des Erzeugungsverarbeitungsteils 8 für die Verarbeitung von Binärdaten auf der Grundlage des Decodierergebnisses vom Decodierverarbeitungsteil 7 beschrieben. Das Decodierergebnis, d. h. die Lauflängendaten, wird dem Erzeugungsverarbeitungsteil 8 eingegeben. Im folgenden ist ein Fall beschrieben, in welchem die Lauflängendaten eines eindimensionalen Moduscode zuerst eingegeben werden.
Es sei angenommen, daß das Decodierergebnis eines Ergänzungscodes vom Decodierer-ROM 32 dem Wähler 40 eingegeben wird. In diesem Fall empfängt der Wähler 40 Daten L als Lauflängendaten von der Steuereinheit 1. Wenn die Ausgabe bzw. das Ausgangssignal vom Decodierer-ROM 32 entsprechend einem Steuersignal von der Steuereinheit 1 gewählt wird, wird das Ausgangssignal dem RL-Zähler 42 eingegeben. Der RL-Zähler 42 ist ein solcher mit einer 12-Bit-Länge, und er speichert das Decodierergebnis des Ergänzungscodes vom Decodierer-ROM 32 in einem 08-03-Bitabschnitt von 6 Bits. Da die vom Decodierer-ROM 32 ausgegebenen Lauflängendaten des Ergänzungscodes eine Größe darstellen, die durch Dekrementieren einer praktischen Lauflänge um "1" erhalten wurde, wird dem 02-00-Bitabschnitt des RL-Zählers 42 "1" eingegeben, so daß sich "111" ergibt.
Diese Daten werden über den Wähler 44 als Adreßdaten zum Codierer-ROM 46 ausgegeben, welcher auch Daten mit Daten für Farbbezeichnung und Daten zur Anzeige der Verdichtungs- bzw. Dehnungsverarbeitung als Daten N von der Steuereinheit 1 abnimmt. In Abhängigkeit von den dem Codierer-ROM 46 eingegebenen Adreßdaten werden durch diesen ROM 46 8-Bit- Daten "00000000" oder "11111111" ausgegeben. Die ausgegebenen Daten werden der Trommelschiebestufe 50 über den Wähler 48 zugeliefert.
Der Erzeugungsverarbeitungsteil 8 weist eine dem decodierten Zeiger 36 ähnliche Schaltung auf. Die Trommelschiebestufe 50 nimmt Anzeigedaten vom Bildzeiger 56 ab und dreht die eingegebenen Daten für die Ausgabe der gedrehten Daten. Da jedoch alle Bits "0" oder "1" sind, macht es keinen Unterschied, ob die Daten gedreht werden oder nicht. Da zu diesem Zeitpunkt die Daten vom Codierer-ROM 46 in Einheiten von Bytes ausgegeben werden, gibt der ROM 46 keine Daten zur Addierstufe 52 aus. Dies ist deshalb der Fall, weil die Anzeigegröße des Bildzeigers 56 nicht geändert zu werden braucht, da die Erzeugungsverarbeitung in Einheiten von Bytes erfolgt.
Das Ausgangssignal von der Trommelschiebestufe 50 wird dem Wähler 60 und dem 15-08-Bitabschnitt des Registers 62 zugeführt. Der Wähler 60 empfängt über den Wähler 64 Daten RODT 07-00 oder RODT 15-08. In diesem Fall entsprechen die zu erzeugenden Lauflängendaten einem Ergänzungscode, und die Daten RODT 15-08 werden im Wähler 64 während der Verarbeitung des Codes gewählt. Außerdem nimmt der Wähler 60 vom Bildzeiger 56 dieselben Anzeigedaten wie die Trommelschiebestufe 50 ab.
Der Wähler 60 wählt Daten vom Wähler 64 ab der LSB-Position zu einer um "1" kleineren Bitposition aus den Anzeigedaten vom Bildzeiger 56 und wählt das Ausgangssignal von der Trommelschiebestufe 50 von bzw. aus den Anzeigedaten zur MSB-Position, um damit die gewählten Daten als Daten RODT 07-00 des Registers 62 auszugeben.
Wenn beispielsweise die Anzeigedaten des Zeigers gleich "3" sind, werden die Daten vom Wähler 64 als Daten RODT 02-00 und die Daten von der Trommelschiebestufe 50 als Daten RODT 07-03 gewählt. Da bei der obigen Operation ein Bilddatenmuster für ein Byte erzeugt wird, werden die Daten RODT 07-00 des Registers 62 auf einer Ausgabedatenschiene über einen dem Inverter 24 ähnlichen Inverter 66 ausgegeben und als Daten P zum Bezugszeilendaten-Speicherteil 4 geliefert, um in diesem an einer Adresse entsprechend der augenblicklichen Größe (dem Zählstand) des Adreßzählers 88 gespeichert zu werden. Daraufhin ist ein erster Schritt der Erzeugungsverarbeitung abgeschlossen, wobei dieser Zustand durch die Steuereinheit 1 festgestellt wird.
Nach Abschluß der Verarbeitung für ein Byte wird ein Takt als Dateneinheit Q an den Adreßzähler 82 angelegt, um diesen um "1" zu inkrementieren bzw. hochzählen zu lassen. Zu diesem Zeitpunkt wird im Fall eines nach der M2R- Methode codierten Codes die Größe bzw. der Zählstand des Zählers 82 mit der Größe bzw. dem Inhalt des Stopadreßregisters 80 verglichen und damit geprüft, ob die Verarbeitung bis zum Ende der Zeile fortgeschritten ist. Im Fall eines nach der MR- oder MH-Methode codierten Codes ergibt sich dabei kein Problem, weil der EOL-Code benutzt wird.
Die im Register 96 enthaltenen Daten werden um ein Byte in LSB-Richtung verschoben. Neue Bezugszeilendaten werden unter Heranziehung der Summe aus dem Zählstand des Adreßzählers 82 und den Daten R als Adresse aus dem Speicherteil 4 ausgelesen und als Daten REF 15-08 im Register 96 verriegelt. Zu diesem Zeitpunkt ist oder wird ein Inhalt des a 0-Zeigers nicht verändert. Daten M vom RL-Zähler 42 werden zur Steuereinheit 1 ausgegeben. Letztere prüft auf der Grundlage der Daten M vom RL-Zähler 42, ob die Erzeugungsverarbeitung des eingegebenen Ergänzungscodes abgeschlossen ist.
Ist dies nicht der Fall, so wird der Inhalt des RL-Zählers 42 um "1" dekrementiert bzw. herabgezählt und dann über den Wähler 44 zum Codierer-ROM 46 geliefert. Die Erzeugungsverarbeitung wird auf die vorstehend beschriebene Weise wiederholt, bis die Daten M vom RL-Zähler 42 den Daten "0" gleich sind. Wenn die Daten M den Daten "0" gleich sind, stellt die Erzeugungsverarbeitung für den entsprechenden Ergänzungscode einen letzten Schritt dar, woraufhin der Beendigungscode verarbeitet wird.
Wenn der Wähler 40 die Daten L wählt, wird ebenfalls dieselbe Verarbeitung wie für den Ergänzungscode durchgeführt. Wenn ein Lauf oder Durchlauf derselben Farbe für eine Länge von 2561 oder mehr andauert, wird ein die Lauflänge 2560 repräsentierender Code entsprechend der Lauflänge wiederholt. Die Wiederholungszahl und die die Lauflänge (2560-64) anzeigenden Daten werden als Daten L im RL-Zähler 42 gesetzt. Wenn die Erzeugungsverarbeitung für die Lauflänge 2560 abgeschlossen ist, wird die Wiederholungszahl um "1" dekrementiert, worauf die Erzeugungsverarbeitung wieder ausgeführt wird. Dabei wird die gesamte Erzeugungsverarbeitung wiederholt, bis die Daten M gleich "0" sind.
Nachstehend ist ein Fall beschrieben, in welchem das Decodierergebnis eines Beendigungscodes verarbeitet wird. Das Decodierergebnis oder die Lauflängendaten wird bzw. werden als Daten I über den Wähler 40 dem 05-00-Abschnitt des RL-Zählers 42 eingegeben. Der 05-03-Abschnitt des RL- Zählers 42 wird in Einheiten von Bytes auf dieselbe Weise wie der Ergänzungscode verarbeitet.
Der Inhalt des 05-03-Bitabschnitts wird jedesmal dann um "1" dekrementiert, wenn die Erzeugungsverarbeitung eines Bytes der Bilddaten abgeschlossen ist. Nach Beendigung der Verarbeitung der Bytedaten wird eine Dateneinheit 02-00, die kleiner ist als ein Byte, verarbeitet.
Die Dateneinheit 02-00 wird dem Wähler 44 eingegeben und durch diesen für die Eingabe in den Codierer-ROM 46 auf dieselbe Weise wie beim Ergänzungscode gewählt. Das durch den ROM 46 erzeugte Bilddatenmuster wird durch die Trommelschiebestufe 50 verschoben und dann zu einem Datenabschnitt RODT 15-08 des Registers 62 und zum Wähler 60 ausgegeben.
Anschließend wird das Bilddatenmuster durch den Wähler 60 mit den vorher verarbeiteten Daten RODT 15-08 nach Maßgabe der Anzeigedaten vom Bildzeiger 56 zusammengesetzt, und die zusammengesetzten Daten werden dem Datenabschnitt RODT 07-00 des Registers 62 eingegeben. Dabei werden Daten entsprechend der Länge der Ausgabebildmusterdaten vom Codierer-ROM 46 zur Addierstufe 52 als Daten EROM 07-05 ausgegeben. Als Ergebnis wird die Größe des Bildzeigers 56 aktualisiert. Wenn dabei 23 Bits im Ausgangssignal der Addierstufe 52 zu "1" werden, wird dies der Steuereinheit 1 in Form von Daten 0 gemeldet, um sie zu informieren, daß die Verarbeitung für ein Byte abgeschlossen ist. Wenn die Dateneinheit 0 ausgegeben wird, gibt das Register 62 Daten RODT 07-00 auf einer Datenschiene über den Inverter 66 in Abhängigkeit von einem Steuersignal von der Steuereinheit 1 aus, und es speichert diese Daten im Speicherteil 4 als Daten P. Wenn 23 Bits nicht gleich "1" sind, werden die Daten RODT 07-00 bis zur Erzeugung des nächsten Bilddatenmusters gehalten bzw. gespeichert.
Wenn das nächste Bilddatenmuster dem Wähler 60 eingegeben wird, werden die Daten RODT 07-00 des Registers 62 über den Wähler 64 dem Wähler 60 zugeführt. Auf diese Weise wird dieselbe Operation wiederholt.
Wenn ein Beendigungscode von weniger als einem Byte verarbeitet werden soll, wird im wesentlichen dieselbe Verarbeitung wie für die Daten von weniger als ein Byte durchgeführt, mit dem Unterschied, daß das Decodierergebnis unmittelbar dem Wähler 44 zugeführt und nicht durch den RL-Zähler 42 übertragen wird. Die oben beschriebene Operation kann für einen MH-Codeabschnitt oder -teil eines nach der MH-Methode codierten Horizontalmoduscodes oder die nach den MR- und M2R-Methoden codierten Codes durchgeführt werden.
Nachstehend ist die Erzeugungsverarbeitung für einen Code im Durchlaßmodus (pass mode) und Vertikalmodus als zweidimensionaler Codiermodus beschrieben. Wenn auf den Bezugszeilendaten im Register 96 eine Farbänderungsbitposition b 1 nicht festgestellt wird, wird diese Information zur Steuereinheit 1 als Dateneinheit A 2 übertragen, wobei ein Byte des Bilddatenmusters vom Codierer-ROM 46 nach Maßgabe der Daten N von der Steuereinheit 1 erzeugt wird. Diese Erzeugungsverarbeitung des Bilddatenmusters erfolgt auf dieselbe Weise wie beim Ergänzungscode eines Horizontalmodus. Die Anzeigedaten des Bildzeigers 54 bleiben unverändert.
Wenn b 1 durch den b 1-Detektor 102 des a 1 b 1-Detektors 16 festgestellt oder erfaßt wird, wird b 1 zum Wähler 108 geliefert. Da die Größe b 1, wie aus dem Register 96 ersichtlich ist, ab einer -4-Bitposition gezählt wird, wird zu ihr "+4" hinzuaddiert. Die Lauflängendateneinheit im Durchlaßmodus oder Vertikalmodus wird im RL-Zähler 42 verriegelt, und die Bilddaten werden auf die vorher beschriebene Weise erzeugt. Die Lauflängendaten werden als Dateneinheit B zum Wähler 110 ausgegeben. Diese, den Wählern 108 und 110 eingegebenen Daten werden in die Addierstufe 112 eingegeben und darin addiert. Wenn die addierten Daten 8 oder mehr betragen, werden die unteren 3-Bitdaten gewählt. Die unteren 3-Bitdaten der addierten Daten werden zum Wähler 54 als Dateneinheit C ausgegeben, nachdem die Erzeugungsverarbeitung des entsprechenden Bilddatenmusters abgeschlossen ist. Die unteren 3-Bitdaten werden auch zum a 0-Zeiger 100 ausgegeben.
Nachstehend ist ein Fall beschrieben, in welchem ein Nichtverdichtungsmoduscode eingegeben wird. Dieser Code wird als Dateneinheit G über das Register 58 dem Wähler 48 eingegeben oder eingespeist. Die folgende Verarbeitung erfolgt auf dieselbe Weise, wie oben beschrieben. Die Lauflängendaten dieses Codes werden zum RL-Zähler 42 ausgegeben und auf dieselbe Weise wie die Vertikal- und Durchlaßmoduscodes verarbeitet.
Im folgenden ist anhand von Fig. 7 die Verdichtungsverarbeitung beschrieben.
Zunächst ist die Verdichtungsverarbeitung für einen MH-Code erläutert. Bildmusterdaten werden von einer Eingabedatenschiene dem Verriegelungsglied 22 eingegeben und darin verriegelt. Die eingegebenen Bilddaten werden dem Register 26 über den Inverter 24 eingespeist. Zu diesem Zeitpunkt werden Registerdaten RDTI 07-00 zum Bezugszeilen-Speicherteil 4 als Bezugszeilendaten für die nächste Verarbeitungszeile ausgegeben und in diesem Speicherteil entsprechend den Daten vom Adreßregister 88 gespeichert. Ebenso werden im Datenteil oder -abschnitt RDTI 07-00 gehaltene Bilddaten zum a 1-Detektor 104 ausgegeben, und es werden Daten 320(2560 ÷ 8) im RL-Zähler 42 vorgegeben. Der durch den a 1-Detektor 104 erfaßte a 1-Punkt wird als Dateneinheit D über den Wähler 114 zum Wähler 38 ausgegeben.
Danach werden durch die Trichterschiebestufe 30 9 Bits nach Maßgabe der Anzeigedaten des Decodierzeigers 36 auf dieselbe Weise wie bei der Dehungsverarbeitung gewählt und zum Wähler 31 ausgegeben. Der Ausgang von der Trichterschiebestufe 30 wird durch den Wähler 31 gewählt und zum Decodierer-ROM 32 ausgegeben. Wenn ein Lauf oder Durchlauf mit derselben Farbe für mehr als eine Byte-Länge andauert, wird "1000", d. h. eine eine Länge eines Bytes anzeigende Dateneinheit, vom Decodierer-ROM 32 als Daten DROM 11-08 zur Addierstufe 34 ausgegeben, worauf als Ergebnis eine Dateneinheit J zur Steuereinheit 1 ausgegeben wird.
Die Größe des Decodierzeigers 36 wird nicht aktualisiert. Die Steuereinheit 1 gibt eine Dateneinheit Q zum Adreßzähler 82 auf dieselbe Weise wie bei der Dehnungsverarbeitung aus, um Adreßdaten zu aktualisieren. Außerdem wird der Inhalt des RL-Zählers 42 herabgezählt. Gleichzeitig wird auf dieselbe Weise wie bei der Dehnungsverarbeitung der Inhalt des Registers 96 um ein Byte nach links verschoben. Neue Bezugzeilendaten werden aus dem Speicherteil 4 ausgelesen, zum Register 96 ausgegeben und als (Daten) REF 15-08 verriegelt. Die Größe des Zeigers 100 wird nicht verändert.
Im eindimensionalen Modus, in welchem dieselbe Farbe vom Anfang eines Laufs fortlaufend vorliegt, wird von der Steuereinheit 1 nach Maßgabe von Daten DROM 15-12 vom Decodierer- ROM 32 ein Zählimpuls dem RL-Zähler 42 eingegeben, sobald eine Verarbeitung für eine Einheit abgeschlossen ist, um damit den RL-Zähler 42, wie bei in Fig. 7 gezeigt, herabzuzählen. Wenn durch den a 1-Detektor 104 ein Farbänderungspunkt a 1 festgestellt wird, d. h. wenn der Inhalt der Daten LSHT 08-00 nicht "00000000x" oder "11111111x" beträgt, wird das Zählergebnis bzw. der Zählstand des RL-Zählers 42 über den Wähler 42 dem Codierer-ROM 46 zugeführt. Die Dateneinheit N wird ebenfalls dem Decodierer- ROM 46 zugeliefert, um damit einen Ergänzungscode zu erzeugen.
Der erzeugte Ergänzungscode wird über den Wähler 48 zur Trommelschiebestufe 50 geliefert und in letzterer nach Maßgabe der Anzeigedaten vom Bildzeiger 56 gedreht. Der gedrehte Code wird dem Datenabschnitt RODT 15-08 des Registers 62 und auch dem Wähler 60 zugeführt. Im Wähler 60 wird der gedrehte Code auf dieselbe Weise wie bei der Dehnungsverarbeitung mit einem Ausgangssignal oder einer Ausgabe des Wählers 64 kombiniert, und zwar in Abhängigkeit von den Anzeigedaten des Bildzeigers 56. Gleichzeitig wird die Länge des erzeugten Ergänzungscodes vom Codierer- ROM 46 zur Addierstufe 52 als Daten EROM 07-05 ausgegeben, um diese zu den Anzeigedaten zu addieren. Die Summe stellt wiederum die Anzeigedaten des Zeigers 56 dar. Wenn die Dateneinheit O zur Steuereinheit 1 ausgegeben wird, werden Daten RODT 07-00 auf eine Ausgabedatenschiene ausgegeben.
Wenn die Länge des zu erzeugenden Ergänzungscodes 6 bis 10 Bits beträgt, wird ein restlicher Teil des Ergänzungscodes vom Codierer-ROM 46 geliefert und auf dieselbe Weise, wie vorstehend beschrieben, verarbeitet. Dabei werden Daten RODT 15-08 im Wähler 64 gewählt. Nach Beendigung der Erzeugungsverarbeitung des Ergänzungscodes wird der 11-03- Bitabschnitt des RL-Zählers 42 freigemacht, und der 02-00- Bitabschnitt wird zum 05-03-Bitabschnitt verschoben, während die restlichen Daten, die kleiner sind als ein Byte, dem 02-00-Bitabschnitt des RL-Zählers 42 eingegeben werden. Das Ergebnis wird ebenfalls zum Codierer-ROM 46 ausgegeben und auf dieselbe Weise wie im Fall des Ergänzungscodes verarbeitet, um einen verdichteten Beendigungscode auszugeben. Die Verarbeitung für die Länge eines Codes ist dieselbe wie für den Ergänzungscode. Auf diese Weise werden der Ergänzungs- und der Beendigungscode wie im Fall der Verdichtungsverarbeitung im Horizontalmodus erzeugt.
Die nach der MR- und M2R-Methode codierten Horizontalmoduscodes werden auf dieselbe Weise wie bei der Verdichtungsverarbeitung des MH-Codes verarbeitet, nur mit dem Unterschied, daß der Identifiziercode des Horizontalmodus vor dem ersten Ergänzungscode nach Maßgabe der Dateneinheit N von der Steuereinheit 1 hinzuaddiert wird.
Die Verdichtungsverarbeitung von zweidimensionalen Codes im Vertikal- und Durchlaßmodus ist nachstehend beschrieben. Wenn in den Daten RDTI 07-00 als Dateneinheit F a 1 nicht festgestellt wird und auch b 1 in den Daten REF -3-10 vom Register 96 nicht festgestellt wird, wird eine Sprungverarbeitung ausgeführt. Dabei werden beispielsweise ein Byte eines neuen Bilddatenmusters über die Eingabedatenschiene eingegeben und die Bezugszeilendaten im Register 96 aktualisiert. Wenn sowohl a 1 als auch b 1 festgestellt oder erfaßt werden, wird die Verdichtungsverarbeitung von zweidimensionalen Codes eingeleitet.
Die erfaßten Größen oder Einheiten a 1 und b 1 werden der Subtrahierstufe 120 zugeführt, deren Ausgangssignal als Dateneinheit A über den Wähler 44 zum Codierer-ROM 46 ausgegeben wird. Im Codierer-ROM 46 wird der Durchlaßmoduscode oder der Vertikalmoduscode erzeugt, der dann in der Trommelschiebestufe 50, im Wähler 60, im Bildzeiger 56 usw. auf dieselbe Weise wie der Horizontalmoduscode verarbeitet wird. Zu diesem Zeitpunkt wird im Wähler 114 b 1 gewählt und dem a 0-Zeiger 100 sowie dem Decodierzeiger 36 über den Wähler 38 als Dateneinheit D zugeliefert. Die folgende Verarbeitung entspricht derjenigen bei der Dehnungsverarbeitung.
Im Nichtverdichtungsmodus werden Daten vom Register 58 unmittelbar z 09408 00070 552 001000280000000200012000285910929700040 0002003711200 00004 09289um Wähler 48 geliefert und sodann durch diesen ausgegeben. Die folgende Verarbeitung ist dieselbe wie bei der Dehnungsverarbeitung. Die Codelänge wird dem Wähler 110 als Dateneinheit B zugeführt, und die Daten des Bildzeigers 56 werden durch die Dateneinheit B über die Addierstufe 112 und den Wähler 54 aktualisiert.
Die Betriebszeitsteuerung oder der Betriebstakt des Decodierverarbeitungsteils 7 beim Decodieren eines nach der M2R-Methode codierten Codes ist im folgenden im Zusammenhang mit der Arbeitsweise des Erzeugungsverarbeitungsteils 8 anhand der Fig. 10A bis 10F beschrieben. Im i-ten Schritt beginnt der Decodierverarbeitungsteil 7 eine Decodieroperation eines n-ten Laufs, doch wartet er ab, während er die Operation unvollendet läßt.
Obgleich die Bildmustererzeugung herkömmlicherweise in Einheiten von Bytes parallel durchgeführt werden kann, wird die Decodierung von Codes bitseriell ausgeführt.
Da im Gegensatz dazu erfindungsgemäß die Code-Decodierung, wie oben beschrieben, parallel ausgeführt wird, können die meisten Codes mit einer hohen Erscheinungsfrequenz in einem Zyklus decodiert werden.
Da bei der Decodierung nach der M2R-Methode nach dem Ergebnis vom Erzeugungsverarbeitungsteil 8 diskriminiert oder entschieden wird, ob die Decodierung bis zum Ende einer Zeile vollständig ausgeführt ist, führt der Decodierverarbeitungsteil 7 die Vorausverarbeitung für den nächsten Code nicht vollständig durch, sondern unterbricht die Verarbeitung unmittelbar vor der Änderung des Zustands. Wenn der Zustand des Decodierverarbeitungsteils 7 für die Vorausverarbeitung geändert wird, um z. B. einen Bit-Zeiger weiterzuschalten, kann eine Einrichtung zum Zurückstellen oder Zurückführen desselben erforderlich sein.
Wenn die Verarbeitung im Erzeugungsverarbeitungsteil 8 abgeschlossen ist und eine Position auf der entsprechenden Verarbeitungszeile des Laufs festgestellt wird, wird geprüft, ob diese Position mit der äußersten rechten Position einer Zeile koinzidiert. Wenn keine Koinzidenz festgestellt wird, führt der Decodierverarbeitungsteil 7, weil die normale Decodierung ausgeführt werden kann, die Decodierverarbeitung vollständig durch, und er sendet das Decodierergebnis zum Erzeugungsverarbeitungsteil 8 und startet die Verarbeitung des nächsten Laufs oder Durchlaufs.
Der Erzeugungsverarbeitungsteil 8 beginnt die Bildmustererzeugung auf der Grundlage der vom Decodierverarbeitungsteil 7 übermittelten Lauflängendaten. Wenn eine Position auf der entsprechenden Verarbeitungszeile des Laufs mit dem Ende der Zeile koinzidiert, nachdem der Erzeugungsverarbeitungsteil 8 die Verarbeitung für die Fertigstellung der augenblicklichen Verarbeitungszeile ausführt, erfolgt durch die Steuereinheit 1 eine Vorbereitung für die nächste Verarbeitungszeile, z. B. ein Umschalten der Speicherbereiche des Speicherteils 4 zum Halten oder Aufnehmen von Bezugszeilenbilddaten. In diesem Fall meldet der Erzeugungsverarbeitungsteil 8 das Ende der Zeile zum Decodierverarbeitungsteil 7 über die Steuereinheit 1.
Da der Anfang der Zeile, wie oben beschrieben, als weißes Lauf- bzw. Vorsatzstück festgestellt wird, bewirkt der Decodierverarbeitungsteil 7 unter Verwendung der Information vom Erzeugungsverarbeitungsteil 8 die Wiederdecodierung des betreffenden Codes zu "Weiß". Da zu diesem Zeitpunkt der Decodierverarbeitungsteil 7 die Vorausverarbeitung unter Zustandsänderung noch nicht beendet hat, kann er ein neues Decodierergebnis nur durch Änderung der Farbbezeichnung ableiten. Wenn ein Objekt der Vorausverarbeitung ein Code von 10 Bits oder mehr ist, der eine Zweischrittverarbeitung erfordert, wartet der Decodierverarbeitungsteil 7 die Information oder Anweisung vom Erzeugungsverarbeitungsteil 8 ab, ohne den ersten Schritt vollständig auszuführen.
Der Decodierverarbeitungsteil 7 vermag einen Code aus 9 Bits oder weniger in einem Schritt zu decodieren, und nahezu alle eingegebenen Codes bestehen normalerweise aus 9 Bits oder weniger. Selbst wenn daher die Vorausverarbeitung unterbrochen wird, ohne daß der Decodierverarbeitungsteil 7 veranlaßt wird, seinen Zustand zu ändern, kann der Decodierverarbeitungsteil 7 unmittelbar das Decodierergebnis des nächsten Laufs (oder Zeilendurchlaufs) ableiten, nachdem der Erzeugungsverarbeitungsteil 8 die Erzeugungsverarbeitung für den augenblicklichen Lauf abgeschlossen hat. Außerdem kann der Erzeugungsverarbeitungsteil 8 die Verarbeitung des betreffenden Laufs ohne Wartezeit einleiten.
Die Beziehung zwischen den Operationen des Decodierverarbeitungsteils 7 und des Erzeugungsverarbeitungsteils 8 ist im folgenden anhand der Fig. 10A bis 10C im einzelnen erläutert. Im i-ten Schritt beginnt der Decodierverarbeitungsteil 7 mit der Decodieroperation eines n-ten Laufs oder Zeilendurchlaufs, doch hält er vor vollständiger Ausführung dieser Operation an. Es sei angenommen, daß der Erzeugungsverarbeitungsteil 8 die Erzeugungsverarbeitung eines (n-1)ten Laufs durchführt und diese Verarbeitung in einem Schritt vollständig ausführt. Dabei führt der Decodierverarbeitungsteil 7 die Decodierung des n-ten Laufs vollständig durch und liefert damit das Decodierergebnis für den n-ten Lauf.
Genauer gesagt: Nach vollständiger Beendigung der Erzeugungsverarbeitung eines Bilddatenmusters im Erzeugungsverarbeitungsteil 8 ist in diesem Schritt auch die Verarbeitung durch den Decodierverarbeitungsteil 7 vollständig abgeschlossen. Danach beginnt in einem (+1)ten Schritt der Decodierverarbeitungsteil 7 die Decodierung eines Codes in einem (n + 1)ten Lauf, und er hält in einem Zustand unmittelbar vor vollständiger Durchführung der Decodierung an. Wenn der durch den Decodierverarbeitungsteil 7 decodierte n-te Lauf aus einem 3-Byte-Bilddatenmuster besteht, kann der Erzeugungsverarbeitungsteil 8 den n-ten Lauf nicht in einem Schritt verarbeiten. Der Decodierverarbeitungsteil 7 behält dabei den augenblicklichen Zustand auch nach dem (i + 2)ten Schritt bei.
Wenn der Erzeugungsverarbeitungsteil 8 die Verarbeitung für den n-ten Lauf im (i + 3)ten Schritt vollständig durchführt und dabei der Code im (n + 1)ten Lauf aus 9 Bits oder weniger besteht, führt der Decodierverarbeitungsteil 7 die Decodierverarbeitung des (n + 1)ten Laufs vollständig durch, und er leitet die Decodierung des nächsten, (n + 2)ten Laufs im (i + 4)ten Schritt ein. Der Erzeugungsverarbeitungsteil 8 beginnt ein Bilddatenmuster des (n + 1)ten Laufs nach Maßgabe des Decodierergebnisses vom Decodierverarbeitungsteil 7 zu erzeugen. Auf diese Weise kann der Erzeugungsverarbeitungsteil 8 normalerweise die Verarbeitung ohne jede Wartezeit beginnen.
Die Fig. 10D bis 10F veranschaulichen ein ähnliches Beispiel für die Operation in dem Fall, in welchem ein Code in einem (n + 1)ten Lauf aus 10 Bits oder mehr besteht. Der Decodierverarbeitungsteil 7 beginnt die Decodierung des (n + 1)ten Laufs im (i + 1)ten Schritt, doch unterbricht er die Verarbeitung, ohne sie vollständig auszuführen. Sobald der Erzeugungsverarbeitungsteil 8 die Verarbeitung des n-ten Laufs im (i + 3)ten Schritt vollständig ausgeführt hat, schließt der Decodierverarbeitungsteil 7 die erste Stufe der Decodieroperation des (n + 1)ten Laufcodes ab. Anschließend decodiert der Decodierverarbeitungsteil 7 die zweite Stufe des (n + 1)ten Laufcodes.
Der Erzeugungsverarbeitungsteil 8 hat im (i + 4)ten Schritt noch kein neues Decodierergebnis vom Decodierverarbeitungsteil 7 erhalten und legt somit eine Pause zum Empfangen dieses Ergebnisses ein. Wenn der Decodierverarbeitungsteil 7 die Decodierung des (n + 1)ten Laufcodes im (i + 4)ten Schritt abschließt, führt der Erzeugungsverarbeitungsteil 8 eine Bilddatenmuster-Erzeugungsverarbeitung des (n + 1)ten Laufs im (i + 5)ten Schritt durch.
Auf diese Weise arbeitet der Erzeugungsverarbeitungsteil 8 im Fall eines Codes mit 10 Bits oder mehr mit einer Wartezeit. Da jedoch die Erzeugungsfrequenz von Codes mit 10 Bits oder mehr niedrig ist, hat diese Wartezeit nahezu keinerlei Einfluß auf die Gesamtleistung des Geräts.

Claims (19)

1. Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät, zum Decodieren von Codedaten mit hoher Geschwindigkeit, mit:
  • - einer Halteeinheit (26) zum Halten von Codedaten von einer ersten vorbestimmten Länge,
  • - einer Adreßerzeugungseinrichtung (30, 31) und
  • - einer Decodiereinrichtung (32),
dadurch gekennzeichnet, daß:
  • - die Adreßerzeugungseinrichtung (30, 31) einen Teil der in der Halteeinheit (26) gehaltenen Codedaten nach Maßgabe von eingegebenen Bitpositionsdaten hält und aus eingegebenen Steuerdaten und dem gewählten Teil der Codedaten nach Maßgabe eines eingegebenen Erzeugungsbefehls Adreßdaten erzeugt,
  • - die Decodiereinrichtung (32) abhängig von den Adreßdaten von der Adreßerzeugungseinrichtung (30, 31) Decodiereinheitslängendaten und selektiv Lauflängendaten erzeugt, von denen die Decodiereinheitslängendaten eine Länge einer vorbestimmten Decodiereinheit ab einem Startbit des gewählten Teils der Codedaten und die Lauflängendaten eine Lauflänge für eine vorbestimmte und wenigstens eine Decodiereinheit einschließende Codeeinheit darstellen, und
  • - eine Bitpositionsbezeichnungseinrichtung (34, 36) die gehaltenen Bitpositionsdaten liefert sowie zur Adreßerzeugungseinrichtung (30, 31) ausgibt und die Bitpositionsdaten nach Maßgabe der Decodiereinheitslängendaten von der Decodiereinrichtung (32) aktualisiert, um wahlweise einen Datenwert aus den aktualisierten Bitpositionsdaten und einem Teil der aktualisierten Bitpositionsdaten zu halten.
2. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die Bitpositionsbezeichnungseinrichtung (34, 36) folgendes umfaßt:
eine Bitpositionsdatenhalteeinheit (36) zum Halten der eingegebenen Bitpositionsdaten zum Ausgeben der gehaltenen Bitpositionsdaten an die Adreßerzeugungseinrichtung (30, 31) und
eine Addiereinheit (34) zum Addieren der Bitpositionsdaten von der Bitpositionsdatenhalteeinheit (36) und der Decodiereinheitslängendaten von der Decodiereinrichtung (32) und zum selektiven Ausgeben eines Datenwerts aus dem Additionsergebnis und einem Teil des Additionsergebnisses als die Bitpositionsdaten zur Bitpositionsdatenhalteeinheit (36).
3. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die Halteeinheit (26) die Codedaten von einer zweiten vorbestimmten Länge empfängt, wenn die aktualisierten Bitpositionsdaten gleich den die zweite vorbestimmte Länge oder mehr darstellenden Daten sind, und die letzten Codedaten von der ersten vorbestimmten Länge hält.
4. Gerät nach Anspruch 1, gekennzeichnet durch eine Steuereinrichtung (1) zum Liefern des Erzeugungsbefehls an die Adreßerzeugungseinrichtung (30, 31), wenn eine Bilderzeugungsverarbeitung für die Codeeinheit unmittelbar vor der vorliegenden Decodiereinheit abgeschlossen ist.
5. Gerät nach Anspruch 4, dadurch gekennzeichnet, daß die Steuereinrichtung (1) unmittelbar den Erzeugungsbefehl an die Adreßerzeugungseinrichtung (30, 31) liefert, wenn ein EOL-Code decodiert wird.
6. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die Decodiereinrichtung (32) weiterhin eine Zustandsinformation abhängig von den Adreßdaten erzeugt und daß eine Steuereinrichtung (1) Steuerdaten an die Adreßerzeugungseinrichtung (30, 31) nach Maßgabe der Zustandsinformation von der Decodiereinrichtung (32) abgibt.
7. Gerät nach Anspruch 6, dadurch gekennzeichnet, daß eine Zeilenendedetektoreinheit (11) erfaßt, daß die Decodierverarbeitung zu einem Zeilenende fortschreitet, und daß die Steuereinrichtung (1) die Steuerdaten zur Adreßerzeugungseinrichtung (30, 31) nach Maßgabe der Zustandsinformation so ausgibt, daß die im Anschluß an die gerade verarbeitete Decodiereinheit nächste Decodiereinheit als weiße Farbe decodiert wird, wenn durch die Zeilenendedetektoreinheit (11) erfaßt wird, daß die Decodierverarbeitung zum Zeilenende fortschreitet.
8. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die Codeeinheit ein Ergänzungscode, ein Beendigungscode, ein Identifiziercode eines Horizontalmodus, ein Vertikalmoduscode, ein Durchlaufmoduscode oder ein EOL-Code ist.
9. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die Codeeinheit jeweils einer von zwei Teilabschniten eines Ergänzungscodes, einer von zwei Teilabschnitten eines Beendigungscodes, ein Identifiziercode eines Horizontalmodus, ein Vertikalmoduscode, ein Durchlaufmoduscode und einer von zwei Teilabschnitten eines EOL-Codes ist.
10. Gerät nach Anspruch 9, dadurch gekennzeichnet, daß eine Registereinheit (58) einen nicht verdichteten Code als die Decodiereinheit enthält, daß die Decodiereinrichtung (32) weiterhin die Lauflängendaten für den nicht verdichteten Code als die Decodiereinheit erzeugt, und daß die Adreßerzeugungseinrichtung (30, 31) weiterhin den nicht verdichteten Code als die Decodiereinheit zur Registereinheit (58) abgibt.
11. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die Decodiereinrichtung (32) mehrere Codetabellen enthält, aus denen eine Codetabelle nach Maßgabe der Steuerdaten gewählt ist, um beim Decodieren der Decodiereinheit auf die gewählte Codetabelle Bezug zu nehmen.
12. Gerät nach Anspruch 11, dadurch gekennzeichnet, daß die Decodiereinheit ein Ergänzungscode oder ein Beendigungscode ist und daß die Decodiereinrichtung (32) eine eindimensionale Weißlauf-Codetabelle zum Decodieren eines Weißlauf-Ergänzungscodes und eines Weißlauf-Beendigungscodes sowie eine eindimensionale Schwarzlauf-Codetabelle zum Decodieren eines Schwarzlauf-Ergänzungscodes und eines Schwarzlauf- Beendigungscodes enthält.
13. Gerät nach Anspruch 11, dadurch gekennzeichnet, daß die Decodiereinheit ein Ergänzungscode, ein Beendigungscode, ein Identifiziercode eines Horizontalmodus, ein Vertikalmoduscode, ein Durchlaufmoduscode oder ein EOL- Code ist und daß die Decodiereinrichtung (32) eine eindimensionale Weißlauf-Codetabelle für das Decodieren eines Schwarzlauf-Ergänzungscodes und eines Weißlauf-Beendigungscodes, eine eindimensionale Schwarzlauf-Codetabelle für das Decodieren eines Schwarzlauf-Ergänzungscodes und eines Schwarzlauf-Beendigungscodes, eine zweidimensionale Codetabelle für das Decodieren des Identifiziercodes des Horizontalmodus, des Vertikalmoduscodes und des Durchlaufmoduscodes sowie eine Spezialcodetabelle für das Decodieren des EOL-Codes enthält.
14. Gerät nach Anspruch 13, dadurch gekennzeichnet, daß die Steuereinrichtung (1) ferner eine Einheit (1) zum Ausgeben der Steuerdaten zur Adreßeinrichtung (31) aufweist, so daß die nächste Decodiereinheit als Weißlauf decodiert wird, wenn die Decodierverarbeitung bis zum Ende einer Zeile abgeschlossen ist.
15. Gerät nach Anspruch 14, dadurch gekennzeichnet, daß die Steuereinrichtung (1) eine Einheit (1) zum Ausgeben der Steuerdaten zur Adreßeinrichtung (31) nach Maßgabe der nächsten Zustandsdaten zum Decodieren der Decodiereeinheit aufweist, so daß auf die zweidimensionale Codetabelle Bezug genommen wird, wenn der Vertikalmoduscode und der Durchlaufmoduscode decodiert werden, so daß auf die eindimensionale Weißlauf-Codetabelle Bezug genommen wird, wenn der Identifiziercode im Horizontalmodus decodiert wird, so daß auf die eindimensionale Schwarzlauf-Codetabelle Bezug genommen wird, wenn der Schwarzlauf-Beendigungscode decodiert wird, und so daß auf die Spezialcodetabelle Bezug genommen wird, wenn "0"-Bits für sechs Bits oder mehr in der zweidimensionalen Codetabelle folgen und "0"-Bits für acht Bits oder mehr in den eindimensionalen Weiß- und Schwarz- Codetabellen folgen.
16. Gerät nach Anspruch 11, dadurch gekennzeichnet, daß die Decodiereinheit jeweils einer von zweigeteilten Abschnitten eines Ergänzungscodes, jeweils einer von zweigeteilten Abschnitten eines Beendigungscodes, ein Identifiziercode in einem Horizontalmodus, ein Vertikalmoduscode, ein Durchlaufmoduscode sowie jeweils einer von zweigeteilten Abschnitten eines EOL-Codes ist und die Decodiereinrichtung (32) eine eindimensionale Weißlauf-Codetabelle 1 für das Decodieren erster Abschnitte des Weißlauf-Ergänzungscodes und des Weißlauf- Beendigungscodes, eine eindimensionale Weißlauf-Codetabelle 2 für das Decodieren zweiter Abschnitte des Weißlauf-Ergänzungscodes und des Weißlauf-Beendigungscodes, eine eindimensionale Schwarzlauf-Codetabelle 1 für das Decodieren erster Abschnitte des Schwarzlauf- Ergänzungscodes und des Schwarzlauf-Beendigungscodes, eine eindimensionale Schwarzlauf-Codetabelle 2 für das Decodieren zweiter Abschnitte des Schwarzlauf-Ergänzungscodes und des Schwarzlauf-Beendigungscodes, eine zweidimensionale Codetabelle für das Decodieren des Identifiziercodes des Horizontalmodus, des Vertikalmoduscodes und des Durchlaufcodes sowie eine Spezialcodetabelle für das Decodieren eines zweiten Abschnitts des EOL-Codes enthält.
17. Gerät nach Anspruch 16, dadurch gekennzeichnet, daß die Steuereinrichtung (1) ferner eine Einheit (1) zum Ausgeben der Steuerdaten zur Adreßeinrichtung (31) aufweist, so daß die nächste Decodiereinheit als Weißlauf decodiert wird, wenn die Decodierverarbeitung bis zum Ende einer Zeile abgeschlossen ist.
18. Gerät nach Anspruch 16, dadurch gekennzeichnet, daß die Steuereinheit (1) eine Einheit (1) zum Ausgeben der Steuerdaten zur Adreßeinrichtung (31) nach Maßgabe der nächsten Zustandsdaten aufweist, so daß zum Decodieren der nächsten Decodiereinheit auf die zweidimensionale Codetabelle Bezug genommen wird, wenn einer der Vertikalmodus-, der Durchlauf- und der Schwarzlauf- Beendigungscodes decodiert wird, so daß auf die eindimensionale Weißlauf-Codetabelle 1 Bezug genommen wird, wenn der Identifiziercode im Horizontalmodus bzw. der zweite Abschnitt des Weißlauf-Ergänzungscode decodiert wird, so daß auf die eindimensionale Weißlauf-Codetabelle 2 Bezug genommen wird, wenn einer der ersten Abschnitte des Weißlauf-Ergänzungscodes und des Weißlauf-Beendigungscodes decodiert wird, so daß auf die eindimensionale Schwarzlauf-Codetabelle 1 zum Decodieren der nächsten Decodiereinheit Bezug genommen wird, wenn der zweite Abschnitt des Weißlauf-Beendigungscodes oder der Schwarzlauf-Ergänzungscodes decodiert wird, so daß auf die eindimensionale Schwarzlauf- Codetabelle 2 zum Decodieren der nächsten Decodiereinheit Bezug genommen wird, wenn einer der ersten Abschnitte des Schwarzlauf-Ergänzungscodes und des Schwarzlauf-Beendigungscodes decodiert wird, und so daß auf die Spezialcodetabelle zum Decodieren der nächsten Decodiereinheit Bezug genommen wird, wenn "0"- Bits für sechs Bits oder mehr in der zweidimensionalen Codetabelle und "0"-Bits für acht Bits oder mehr in den eindimensionalen Weiß- und Schwarz-Codetabellen folgen.
DE19873711200 1986-02-28 1987-02-27 Binaerdatenverdichtungs- und -dehnungs-verarbeitungsgeraet Granted DE3711200A1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP4369386 1986-02-28

Publications (2)

Publication Number Publication Date
DE3711200A1 DE3711200A1 (de) 1987-12-23
DE3711200C2 true DE3711200C2 (de) 1990-03-08

Family

ID=12670910

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19873711200 Granted DE3711200A1 (de) 1986-02-28 1987-02-27 Binaerdatenverdichtungs- und -dehnungs-verarbeitungsgeraet

Country Status (4)

Country Link
US (1) US4800441A (de)
JP (1) JPS62283778A (de)
KR (1) KR900001821B1 (de)
DE (1) DE3711200A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4447554C2 (de) * 1993-03-19 1999-08-19 Mitsubishi Electric Corp Vorrichtung zur Bilddatenverarbeitung

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63299683A (ja) * 1987-05-29 1988-12-07 Matsushita Graphic Commun Syst Inc ２次元符号化信号の復号化装置
US4939583A (en) * 1987-09-07 1990-07-03 Hitachi, Ltd. Entropy-coding system
JP2672521B2 (ja) * 1987-09-21 1997-11-05 株式会社東芝 画像処理方法
JPH01274565A (ja) * 1988-04-27 1989-11-02 Matsushita Graphic Commun Syst Inc 復号装置
JP2766302B2 (ja) * 1989-04-06 1998-06-18 株式会社東芝 可変長符号並列解読方法および装置
JPH0831130B2 (ja) * 1989-05-12 1996-03-27 大日本スクリーン製造株式会社 線画像の処理方法
KR930006750B1 (ko) * 1989-06-29 1993-07-23 삼성전자 주식회사 화상데이터 부호화장치
EP0412809B1 (de) * 1989-08-09 1995-12-13 Fujitsu Limited Datenkompressionssystem
JP2877375B2 (ja) * 1989-09-14 1999-03-31 株式会社東芝 可変レートコーデックを用いたセル転送方式
DE4025026C2 (de) * 1989-12-07 1997-06-12 Dirr Josef Verfahren zur mehrstufigen Codierung von Information
EP0469716B1 (de) * 1990-07-03 1997-04-23 Canon Kabushiki Kaisha Bildverarbeitungsgerät
JPH0479421A (ja) * 1990-07-18 1992-03-12 Toshiba Corp 可変長符号化装置および可変長復号化装置
JPH0490268A (ja) * 1990-08-01 1992-03-24 Hitachi Ltd 画像信号復号化方式
JPH04216271A (ja) * 1990-12-17 1992-08-06 Murata Mach Ltd ファクシミリ送信方法
US5229863A (en) * 1990-12-24 1993-07-20 Xerox Corporation High speed CCITT decompressor
US5287193A (en) * 1991-04-10 1994-02-15 Industrial Technology Research Institute Parallel processing architecture of run-length codes
US5452101A (en) * 1991-10-24 1995-09-19 Intel Corporation Apparatus and method for decoding fixed and variable length encoded data
EP0562251A2 (de) * 1992-03-24 1993-09-29 Universities Research Association, Inc. Durch ein dynamisches wiederkonfigurierbares serielles Netzwerk gesteuertes Paralleldatenübertragungsnetzwerk
WO1994000973A2 (de) * 1992-11-06 1994-01-20 Josef Dirr Verfahren zur codierung und übertragung von information
JPH07240844A (ja) * 1993-03-19 1995-09-12 Mitsubishi Electric Corp 画像データ処理装置および画像データ処理方法
JPH0654212A (ja) * 1993-03-19 1994-02-25 Matsushita Graphic Commun Syst Inc 復号装置
FR2705805B1 (fr) * 1993-05-27 1996-06-28 Sgs Thomson Microelectronics Système de traitement d'images.
DE4447925B4 (de) * 1993-08-06 2009-04-02 Mitsubishi Denki K.K. Codierer und Decodierer
GB2316569B (en) * 1993-08-06 1998-06-03 Mitsubishi Electric Corp A coding system
JP3027089B2 (ja) * 1993-08-06 2000-03-27 三菱電機株式会社 符号化方式及び復号方式及び符号化復号方法
US6104751A (en) * 1993-10-29 2000-08-15 Sgs-Thomson Microelectronics S.A. Apparatus and method for decompressing high definition pictures
KR970068627A (ko) * 1996-03-22 1997-10-13 구자홍 최적화된 가변길이 테이블장치 및 최적 길이값 산출방법
US6721456B1 (en) 2000-02-23 2004-04-13 International Business Machines Corporation Color image data and control bit compression scheme with run length encoding
JP3865203B2 (ja) * 2001-04-24 2007-01-10 株式会社リコー 画像圧縮装置、画像形成装置、画像圧縮方法及び記録媒体
US6947604B2 (en) * 2002-01-17 2005-09-20 Intel Corporation Method and hardware to implement two-dimensional compression
TW565829B (en) * 2002-03-19 2003-12-11 Via Tech Inc Method and device for recovering decoded data
US7782326B2 (en) * 2004-02-25 2010-08-24 Marvell International Technology Ltd. Parallel video processing architecture
JP4502383B2 (ja) * 2004-11-16 2010-07-14 キヤノン株式会社 復号化装置およびその方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5755668A (en) * 1980-09-22 1982-04-02 Nippon Telegr & Teleph Corp <Ntt> Decoding method for run-length code
US4562484A (en) * 1983-08-19 1985-12-31 Advanced Micro Devices, Inc. Method and device for decoding two-dimensional facsimile signals
GB2146874A (en) * 1983-08-26 1985-04-24 British Telecomm Decoding of minimum redundancy codes
JPS61113172A (ja) * 1984-09-29 1986-05-31 Olympus Optical Co Ltd デ−タ復調装置
DE3543081A1 (de) * 1985-12-05 1987-06-11 Norbert Garich Mobile toilette
US4760461A (en) * 1986-02-28 1988-07-26 Kabushiki Kaisha Toshiba Binary data compression and expansion processing apparatus
US4760459A (en) * 1986-07-30 1988-07-26 Kabushiki Kaisha Toshiba Binary data compression and expansion processing apparatus

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4447554C2 (de) * 1993-03-19 1999-08-19 Mitsubishi Electric Corp Vorrichtung zur Bilddatenverarbeitung
DE4447553C2 (de) * 1993-03-19 1999-08-19 Mitsubishi Electric Corp Vorrichtung zur Bilddatenverarbeitung

Also Published As

Publication number Publication date
JPS62283778A (ja) 1987-12-09
DE3711200A1 (de) 1987-12-23
US4800441A (en) 1989-01-24
KR900001821B1 (ko) 1990-03-24
KR870008445A (ko) 1987-09-26

Similar Documents

Publication Publication Date Title
DE3711200C2 (de)
DE3711201C2 (de)
DE2264090C3 (de) Datenverdichtung
DE2139731C2 (de) Anordnung zur Code-Umsetzung
DE2825930A1 (de) Sichtanzeigegeraet mit komprimierter bildwiederholung
DE2558264C3 (de) Verfahren zur Verdichtung binärer Bilddaten
DE2508706A1 (de) Codieren und decodieren mit einem code variierbarer wortlaenge und gegebenem bitzahlverhaeltnis
DE3214521A1 (de) Verfahren und einrichtung zur bildverarbeitung
DE2640414A1 (de) Schaltungsanordnung fuer die kompressionscodierung unter verwendung einer korrelation zwischen zweidimensionalen, aus zweiwertigen digitalen bildern abgeleiteten matrizen
DE2728889C3 (de) Verfahren und Vorrichtung zum Übertragen eines Zweipegel-Faksimilesignals
DE1499225B2 (de) Schaltungsanordnung zur reduzierung von datenwortlaengen
DE3330845C2 (de)
DE2233796B2 (de) Verfahren zur Video-Signal-Kompression und Expansion und Vorrichtungen zur Durchführung des Verfahrens
DE3416795A1 (de) Bilddaten-kompressionssystem
DE60009502T2 (de) Lzw datenkomprimierung/dekomprimierungsgerät und - verfahren mit eingebetteter lauflängenkodierung/dekodierung
DE3744791C2 (de)
DE3047695A1 (de) Verfahren und vorrichtung zum herstellen einer speichertabelle fuer farbkontrollbedingungen
DE3406624C2 (de)
DE1964570B2 (de) Verfahren zum wiederauffinden gespeicherter informationen
DE2414239C3 (de) Verfahren und Vorrichtung zum Komprimieren einer binären Informationsfolge
DE2826454C3 (de) Faksimilesignal-Codiersystem
DE2000565A1 (de) Fehlerkorrigierendes System zur Korrektur mehrfacher,zufaelliger Fehler
DE2440768A1 (de) Verfahren und vorrichtung zur datenkompression fuer die faksimile-uebertragung graphischer information
DE3417262C2 (de)
DE3502317A1 (de) Verfahren zur bildfehlerkorrektur

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
D2 Grant after examination
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee