DE3711201A1 - Binaerdatenverdichtungs- und -dehnungs-verarbeitungsgeraet - Google Patents

Description

Die Erfindung betrifft ein Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät, das Binärdaten mit hoher Geschwindigkeit zu verdichten und zu dehnen und insbesondere eine parallele Pipeline-Verarbeitung von nach einer Modifiziert- Modifiziert-Lese- oder M²R-Methode verdichteten Binärdaten durchzuführen und damit die Universal- oder Mehrzweckeinsatzfähigkeit zu verbessern vermag und bei dem zugeordnete Schaltungen unter Gewährleistung einer Kostensenkung auf einem (gemeinsamen) Chip angeordnet sind.

Für das Verdichten und Dehnen von Binärdaten sind von der CCITT empfohlene Codierverfahren, wie die MH-, die MR- und die M²R-Methode international standardisiert und verbreitet im Gebrauch. Von den drei genannten Codiermethoden bietet die M²-R-Methode die höchste Bildverdichtungsleistung.

Die M²-R-Methode ist als Codiermethode für Gruppe-IV- Faksimilesysteme bekannt. Nach dieser Methode werden

• a) ein Zeilendecode (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 ein 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 realisiert unter Verwendung eines Mehrzweck-Mikrorechners für die Durchführung der Dehnungsverarbeitung codierter Daten nach diesen Methoden. 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 M²-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 (advanced processing) 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 Bode.

Die Decodier- und Erzeugungsverarbeitung kann mithin mittels getrennter Hardware-Anordnungen parallel durchgeführt werden. Bei solchen Anordnungen wird, während eim Code gedehnt wird, der nächste Code decodiert, und die gesamte Verarbeitung kann dann als Pipeline-Verarbeitung ausgeführt (pipelined) werden. Wenn nach den MH- und MR-Methoden codierte Binärdaten gedehnt werden, ergibt sich bei der Vorausverarbeitung kein Problem. Die M²-Methode ist dagegen mit den folgenden Problemen behaftet:

Bei allen MH-, MR- und M²R-Methoden ist das (der) Anfangsstück oder -lauf (starting run) einer jeden Zeile jeweils ein weißer Lauf (run), 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 M²R-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 (run) und einen schwarzen Lauf nicht in Vorauslaufweise eingeleitet werden. Genauer gesagt: bei der Dehnungsverarbeitung nach der M²R-Methode bei einem herkömmlichen Gerät kann die Vorausverarbeitung nicht effektiv durchgeführt werden.

Eine andere Ursache für das Problem der Arbeitsgeschwindigkeit ist ein Problem des Systemaufbaus.

Wenn das Gerät nach der MH-Codiermethode betrieben wird, brauchen Bilddaten auf einer unmittelbar vorhergehenden Zeile nicht eingegeben zu werden. In den MR- und M²R- Methoden wird dagegen während der Verdichtungs- und Dehnungsverarbeitung auf Bildmusterdaten auf einer Zeile oder einer einer entsprechenden Verarbeitungszeile unmittelbar vorhergehenden Bezugszeile Bezug genommen.

Dies ist im folgenden in Verbindung mit der Dehnungsverarbeitung in einem herkömmlichen Verdichtungs/Dehnungsverarbeitungsgerät beschrieben. Dieses Gerät tauscht Bilddaten mit einem externen Bildspeicher über eine Bilddatenschiene (oder -bus) aus und bezeichnet eine Adresse des externen Bildspeichers über eine Bilddatenadreßschiene. Das Gerät tauscht verdichtete codierte Daten über eine Codedatenschiene aus. Das Gerät ist damit mit einer System(sammel)schiene eines Mikrorechners zum Steuern dieses Geräts für den Empfang von Befehlen oder Anweisungen und (zumindest eines Teils) einer Adresse auf der Systemschiene verbunden. Durch Dehnung (expanding) eines über die Codedatenschiene gelieferten Codes gewonnene Bilddaten werden auf der Bilddatenschiene ausgegeben, und Bildmusterdaten auf der Bezugszeile, die für die Dehnungsverarbeitung der augenblicklichen oder aktuellen Verarbeitungszeile nötig sind, werden ebenfalls über die Bilddatenschiene aus dem externen Bildspeicher ausgelesen.

Aus diesem Grund erweist sich bei der MR- und M²R-Methode eine Datenübertragungsrate oder -geschwindigkeit auf der Bilddatenschiene, die normalerweise eine große Datenmenge handhaben muß, häufig als Engpaß für die Gesamtleistung. Bei der MR- und M²R-Methode ist daher ein(e) Dehnungsrate oder -grad im Vergleich zur MH-Methode erheblich eingeschränkt.

Da der Bildspeicher logischerweise zweidimensionale Adressen aufweist, wird eine komplexe Schaltung zur Umwandlung dieser Adressen in eindimensionale physikalische Adressen benötigt. Beim genannten Gerät ist normalerweise ein Bilddaten- Adreßgenerator wichtig. Selbst wenn letzterer jedoch aus hochqualitativen Bauelementen hergestellt wird, kann er normalerweise nicht effektiv in dem dieses bisherige Verdichtungs/ Dehnungsverarbeitungsgerät verwendenden System eingesetzt werden.

Zur Gewährleistung einer Hochgeschwindigkeitsverarbeitung für andere Bildverarbeitungsfunktionen, z. B. Flächen- oder Bereichsauszug, Vergrößerung, Verkleinerung, Drehung und dgl., muß häufig ein ähnlicher Adreßgenerator wie beim genannten Gerät für eine externe Schaltung vorgesehen sein.

Für die Realisierung eines kompakt gebauten, leichten und kostengünstigen System ist im Handel eine Vorrichtung erhältlich, bei der das Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät auf einem Halbleiter-Chip montiert ist. Bei dieser Vorrichtung muß jedoch die Bilddatenschiene eine Ausgabeoperation bei der Dehnung und eine Eingabeoperation bei der Verdichtung ausführen.

Aus diesem Grund müssen den betreffenden Stiften der Bilddatenschiene Treiber- und Empfänger-Ein/Ausgangsstifte zugewiesen sein. Da auch die Codedatenschiene eine Eingabeoperation bei Dehnung und eine Ausgabeoperation bei Verdichtung ausführen muß, benötigt sie ebenfalls sowohl die Treiber- als auch die Empfänger-Ein/Ausgangsstifte.

Wenn weiterhin das dieses Gerät verwendende System eine sog. Pipeline-Verarbeitung durchführt, muß die Datenflußrichtung bestimmt oder festgelegt werden. Für diesen Zweck müssen Bilddaten- und Codedatenschiene mittels eines Wähl(er)kreises umgeschaltet werden, wobei doppelte Bus- oder Schienenumschaltvorgänge innerhalb und außerhalb des Geräts nötig sind.

Wenn mithin das Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät als ein (bzw. auf einem) Halbleiter-Chip ausgelegt wird, nimmt es eine große Chipfläche ein. Da hierbei verschiedene System-Anwendungsfälle berücksichtigt werden müssen, kann der in das Gerät integrierte Adreßgenerator oftmals den Anforderungen des jeweiligen Anwendungsfalls nicht Rechnung tragen.

Wie erwähnt, ist das bisherige Gerät mithin mit Problemen bezüglich der Verarbeitungsgeschwindigkeit sowie der Einsatzfähigkeit für Universal- oder Mehrzweckanwendung behaftet.

Im Hinblick auf die oben geschilderten Gegebenheiten liegt damit der Erfindung die Aufgabe zugrunde, ein Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät zu schaffen, das Binärdaten mit hoher Geschwindigkeit zu verdichten und zu dehnen vermag, insbesondere bei der Dehnungsverarbeitung von Binärbilddaten, die nach der M²R-Methode codiert sind, welches zudem einen Eingabecode nach einer Pipeline-Methode parallel zu decodieren und einen Faksimileendeblock- oder EOFB-Code (mit demselben Muster wie zwei aufeinanderfolge EOL-Codes bei der MH- und MR-Methode auch dann zu erfassen vermag, wenn eine Erweiterungsfunktion, z. B. ein Nichtverdichtungsmodus, vorgesehen ist, welches eine Vorausverarbeitung (advanced processing) zur Ermöglichung einer Dehnungsverarbeitung mit hoher Geschwindigkeit und damit unter Verkürzung der Verarbeitungszeit ermöglicht, welches einen weiten Anwendungsbereich besitzt (z. B. eine Pipeline-Verarbeitung durchzuführen vermag), welches als ein einziges Halbleiterelement integriert werden kann und das demzufolge eine entsprechende Kostensenkung gewährleistet.

Diese Aufgabe wird bei einem Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät, das auf eine für die Hochgeschwindigkeits- Verdichtung und -Dehnung von Binärdaten befähigte Verdichtungs/Dehnungs-Verarbeitungssystemausgestaltung anwendbar ist, umfassend eine Verarbeitungseinheit zum Eingeben der Binärdaten mit einer vorbestimmten Datenlänge, zum Ausgeben der eingegebenen Binärdaten als Bezugszeilendaten in einem Verdichtungsmodus, zum Auslesen der Bezugszeilendaten entsprechend den eingegebenen Binärdaten, zum Durchführen einer Dehnungsverarbeitung an den Binärdaten in einem Dehnungsmodus und einer Verdichtungsverarbeitung an den Binärdaten im Verdichtungsmodus nach Maßgabe der ausgelesenen Bezugszeilendaten, zum Ausgeben von im Dehnungsmodus erzeugten, die vorbestimmte Datenlänge aufweisenden Bilddaten als die Bezugszeilendaten und zum Ausgeben der verarbeiteten Binärdaten zu einer externen Vorrichtung, erfindungsgemäß gelöst durch eine Bezugszeilendaten- Speichereinheit zum Speichern der eingegebenen Bezugszeilendaten von der Verarbeitungseinheit in Einheiten der vorbestimmten Datenlängen für eine augenblickliche oder aktuelle Verarbeitungszeile und eine nächste Verarbeitungszeile und zum Ausgeben der ausgelesenen Bezugszeilendaten zur Verarbeitungseinheit.

Erfindungsgemäß werden die folgenden Wirkungen erzielt:

• 1. Da beim Decodieren eines M²R-Codes eine Vorausverarbeitung zusammen mit Parallelverarbeitung nach Pipeline-Methode möglich ist, kann insbesondere 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 (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 (controller) 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.
• 6. Da die komplexe Bildspeicheradreßschaltung entfallen kann, kann die Dehnungsverarbeitung zur Ausführung einer Parallelverarbeitung von Binärdaten auf eine unbenutzte oder unbelegte Chipfläche gelegt werden, wodurch eine höhere Verarbeitungsgeschwindigkeit erreicht wird.
• 7. Da keine Adreßschaltung für einen Bildspeicher vorhanden ist, läßt sich das erfindungsgemäße Gerät auf ein System mit einer beliebigen Adreßanordnung anwenden.
• 8. Da eine Übertragungsrichtung einer Daten(sammel)- schiene oder -bus vorherbestimmt ist, läßt sich das Gerät ohne weiteres für ein Pipeline-System (pipelined system) auslegen.
• 9. Da die Übertragungsrichtung der Datenschiene vorherbestimmt ist, kann auch die Chipfläche verkleinert werden.

Im folgenden sind bevorzugte Ausführungsformen der Erfindung anhand der Zeichnung näher erläutert. Es zeigen:

Fig. 1 ein Blockschaltbild eines Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgeräts gemäß einer Ausführungsform der Erfindung,

Fig. 2 ein Blockschaltbild der Anordnung eines Decodier- und eines Codierendeverarbeitungsteils eines Decodierverarbeitungsteils gemäß Fig. 1,

Fig. 3 ein Blockschaltbild der Anordnung eines Zählerteils und eines Erzeugungsteils (generation section) 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 a1b1- 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 Decodier-Festwertspeichers oder -ROMs gemäß Fig. 2,

Fig. 9A ein Ausgabeformat des Decodier-ROMs nach Fig. 2,

Fig. 9B ein Ausgabeformat eines Lauflängendatenabschnitts des Ausgabeformats des Decodierer-ROMs gemäß Fig. 9A,

Fig. 10A bis 10F Zeitsteuerdiagramme zur Verdeutlichung der Arbeitsweise des Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgeräts gemäß der Erfindung,

Fig. 11 eine schematische Darstellung einer Systemkonfiguration des Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgeräts gemäß der Erfindung,

Fig. 12 eine schematische Darstellung einer anderen Ausführungsform des Systems nach Fig. 11 und

Fig. 13 eine schematische Darstellung noch einer anderen Ausführungsform des Systems nach Fig. 11.

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 (run length data), 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 Deodierteil 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 a1b1-Detektor 16 zum Erfassen von a1 und b1.

Die Steuereinheit 1 ist mit einem Taktgenerator 5 zum Erzeugen von Steuer-Taktsignalen verbunden, und sie steuert die Operationszeitpunkte oder -takte (timings) 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 Verreigelungsglied 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 RDTI15-08 zu Daten RDTI07-00 nach Maßgabe eines Steuersignals von der Steuereinheit 1, es verriegelt die neuen Eingabedaten als Daten RDTI15-08 und hält diese als 16-Bit-Daten zusammen mit den Daten RDTI07-00.

Die 16-Bit-Registerdaten RDTI15-00 werden über den Codierende- Verarbeitungsteil 12 zu einer Trichterschiebestufe (funnel shifter) 30 ausgegeben. Die Daten RDTI07-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 RDTI15-00 ausgezogen 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 LSHT08-00, das durch Linksverschiebung der DatenRDTI15-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 LSHT04-00 der Ausgabedaten LSHT08-00 als Daten G zum Erzeugungsverarbeitungsteil 8 ausgegeben. Die Daten LSHT08-00 werden zu den Daten LSHT10-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 LSHT08-06 oder LSHT08-07 entsprechenden Daten Y von der Steuereinheit 1. Diese Eingangs- oder Eingabedaten werden in Abhänigkgiet 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 DROM15-00 aus. Insbesondere werden dabei als Daten DROM07-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 DROM11-08 wird eine decodierte Datenlänge der Eingabedaten ausgegeben. Als Daten DROM15-12 werden Steuerdaten H zum Bezeichnen des nächsten Zustands (state) ausgegeben.

Die Daten DROM11-08 werden zu einer Addierstufe 34 ausgegeben, die gleichzeitig Daten vom Decodierzeiger 36 abnimmt. Dabei werden die Daten DROM11-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 a1b1- 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 2³-Bitdaten als Ergebnis der Addition durch die Addierstufe 34 zu Daten "1" werden, wird dies der Steuereinheit 1 mittels der Daten J gemeldelt. 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 RDTI15-08 in Einheiten von Bytes zu Daten RDTI07-00 nach Maßgabe des Steuersignals von der Steuereinheit 1. Durch das Verriegelungsglied 22 verriegelte neue Byte-Daten werden im Daten-RDTI15-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 RDTI07-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 dargestellt 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 a1b1-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 a1b1-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 EROM07-00 zum Wähler 48 aus.

Von den Daten EROM07-00 werden die Daten DROM07-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 EROM07-05 addiert, und die summierten Daten werden zum Wähler 54 ausgegeben.

Die Daten C werden vom a1b1-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 2³-Bit-Daten gleich "1" sind, wird dies durch Daten O der Steuereinheit 1 gemeldet.

Der Wähler 48 empfängt Daten EROM07-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 (barrel shifter) 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 RODT15-08 zum Register 62 aus.

Die Daten RODT07-00 und die Daten RODT15-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 RODT07-00 einem Register 62 zugeführt, welches die Daten RODT15-08 nach Maßgabe eines Steuersignals von der Steuereinheit 1 zu Daten RODT07-00 verschiebt. Die Daten RODT07-00 und die Daten RODT15-08 werden zum Wähler 64 ausgegeben.

Weiterhin werden die Daten RODT07-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 (run length data) 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 RIDT07-00, über den Codierende-Verarbeitungsteil 28, sowie Byte-Daten P, d. h. verarbeitete Bilddaten RODT07-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 Beschreibung des Registers 96 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 b1-Detektor 102 ausgegeben.

Der EOL-Detektor 81 erfaßt einen EOL-Code, wenn ein Fehler z. B. im Decodierverarbeitungsteils 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 a1b1-Detektors 16 des Erzeugungsverarbeitungsteils 8 ist nachstehend anhand von Fig. 5 erläutert.

Der a1b1-Detektor 16 wird häufig in einem Vertikalmodus und einem Durchlaßmodus (pass mode) in einem zweidimensionalen Modus benutzt.

Aus dem Randomspeicher bzw. RAM 94 ausgelesene Daten werden durch das Register 96 als Daten REF15-08 verriegelt. Das Register 96 verschiebt in Einheiten von Bytes Daten 07-04 zu Daten REF-4-1 und Daten REF15-08 zu Daten REF07-00 nach Maßgabe eines Steuersignals von der Steuereinheit 1, und es verriegelt Daten vom Randomspeicher 94 als Daten REF15-08. Einer Bezugszeile zugeordnete Daten U werden vom Register 96 zum b1-Detektor 102 geliefert. Daten F werden vom Codierende-Verarbeitungsteil 28 zu einem a1- Detektor 104 geliefert. Die b1- und a1-Detektoren 102 bzw. 104 nehmen eine Anzeigegröße a0 von einem a0-Zeiger 100 ab und erfassen jeweils Positionen a1 bzw. b1 von Pixels mit Farbänderungen auf einer Codierzeile und einer Bezugszeile an der rechten Seite der Position a0 an bzw. im Register 96.

Die durch den b1-Detektor 102 erfaßte Position b1 wird zu einer Subtrahierstufe 120 und einem Wähler 108 ausgegeben. Wenn der Punkt b1 nicht erfaßt wird, wird dies der Steuereinheit 1 mittels Daten A 2 gemeldet. In Verbindung mit dem Register 96 wird "+4" zur Position b1 hinzuaddiert. Die durch den a1-Detektor 104 erfaßte Position a1 wird zu den Wählern 116 und 114 ausgegeben. Der Wähler 116 wählt Daten vom a1-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 Substrahierstufe 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 a0-Zeiger 100 und ein Ausgangssignal (bzw. eine Ausgabegröße) b1 vom b1-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 a1 vom a1-Detektor 104, die Anzeigegröße vom a0-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 a0-Zeiger 100 als Anzeigegröße verriegelt. Die Anzeigegröße des a0-Zeigers 100 und Daten vom Stopadreßregister 80 werden durch den Komparator 106 verglichen, um damit festzustellen, daß (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 M²R-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 M²R-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 REF15-08 im Register 96 abgespeichert zu werden. Nach dem Verschieben der im Register 96 gespeicherten Daten zu Daten REF07-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 REF15-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 a0-Zeiger 100 gesetzt wird. Die Farbe wird dabei zwangsweise auf "Weiß" gesetzt.

Beispielsweise sei angenommen, daß ein nach der M²R-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 RDTI15-08 nach Maßgabe eines Steuersignals von der Steuereinheit 1 zu Daten RDTI07-00 verschoben, und neue Eingabedaten werden als Daten RDTI15-08 verriegelt und zusammen mit Daten RDTI07-00 als 16-Bit-Daten gehalten. Auf diese Weise werden am Anfang einer Seite 2-Byte-Binärdaten eingegeben.

16-Bit-Registerdaten RDTI15-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 RDTI15-00 werden daher über den Verarbeitungsteil 28 zur Trichterschiebestufe 30 ausgegeben.

Der Decodierzeiger 36 zeigt die LSB-Position eines als nächstes auszuziehenden Codes vom oder aus den Registerdaten RDTI15-00 an, die der Trichterschiebestufe 30 eingegeben wurden. Letztere erzeugt eine 9-Bit-Ausgabe LSHT08-00, die durch Linksverschieben der Daten RDTI15-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 RDTI11-03 aus den Eingabedaten RDTI15-00 und gibt diese als Daten LSHT08-00 aus.

Die Daten LSHT08-00 werden zu den den Daten LSHT10-09 von der Steuereinheit 1 entsprechenden Daten hinzuaddiert, und das Ergebnis wird zum Wähler 31 ausgegeben, der außerdem Daten entsprechend den Daten LSHT06-08 oder LSHT07-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 M²R-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 LSHT08-00 geliefert werden.

Falls der Wähler 31 den Abschluß nicht abwartet, kann ein weißer Vorsatz oder Lauf (white run) 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 Vorausverarbeitung (advanced processing) 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 M²R-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 M²R- 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 LSHT10-00 werden nach Maßgabe eines Steuersignals von der Steuereinheit 1 zum Decodierer-ROM 32 ausgegeben. Wenn Daten Y08-06 gewählt sind, wird der 08-06-Bitabschnitt oder der 08-07-Bitabschnitt der Daten LSHT10-00 als der entsprechende Abschnitt oder Teil der Daten LSHT gewählt, und der Datenabschnitt LSHT08-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 DROM15-00 des in Fig. 9A gezeigten Formats nach Maßgabe eines Adressenformats gemäß Fig. 8 aus. Insbesondere werden dabei Lauflängendaten als Daten DROM07-00, Codelängendaten als Daten DROM11-08 und Daten für die Bezeichnung des nächsten Zustands als Daten DROM15-12 ausgegeben. Die Adressen- und Ausgangsformate werden später noch näher erläutert werden.

Die Daten DROM11-08 werden zur Addierstufe 34 ausgegeben, welche gleichzeitig Daten vom Zeiger 36 abnimmt. Die Daten DROM11-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 a1b1-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 2³-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 RDTI15-08 in Einheiten von Bytes nach links zu Daten RDTI07-00 zu verschieben. Durch das Verriegelungsglied 22 verriegelte neue Byte-Daten werden als Daten RDTI15-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 RDTI07-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 (make-up code), 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 (white run one- dimensional codes) 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 LSHT10-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 LSHT10-09 der eindimensionalen Schwarzlauf-Codetabelle 1 geliefert, während ein Code "00" als Daten LSHT08-07 geliefert wird. Der Code "01" wird von der Steuereinheit 1 als Daten LSHT10-09 der eindimensionalen Schwarzlauf- Codetabelle 2 geliefert. Ein MH-Codeabschnitt eines Codes im Horizontalmodus, nach der MR- oder M²R-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 LSHT10-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 LSHT10-06 geliefert. Für den Nichtverdichtungsmodus (uncompressed mode) sind Nichtverdichtungs-Codetabellen 1 und 2 vorgesehen. Codes "10100" und "10101" werden von der Steuereinheit 1 jeweils als Daten LSHT10-06 dieser Tabellen geliefert. Ein Steuercode "10111" wird von der Steuereinheit 1 als Daten LSHT10-06 für die andere Tabelle geliefert.

Das Ausgabeformat des Decodierer-ROMs 32 ist in Fig. 9A gezeigt. Der 07-00-Bitabschnitt der Daten DROM15-00 repräsentiert die Lauflängendaten eines decodierten Codes. Der 11-08-Bitabschnitt der Daten DROM15-00 repräsentiert die Codelängendaten eines decodierten Codes in Einheiten von Bits. Der 15-12-Bitabschnitt der Daten DROM15-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 DROM07-00 ist in Fig. 9B dargestellt. Insbesondere zeigen dabei bei einer eindimensionalen Codierung des Ergänzungscodes 6 Bits der Daten DROM05-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 DROM05-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 DROM03-00 den Zustand (state) der Lauflänge an, d. h. eine durch Subtrahieren von "4" von einer Differenz zwischen a1 und b1 erhaltene Größe. In einem zweidimensionalen Codier-Durchlaßmodus zeigen 4 Bits der Daten DROM03-00 "1100" an.

Im Nichtverdichtungsmodus geben weiterhin Daten DROM02-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, 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 DROM07-00 und die Codelängendaten "0110" als Daten DROM11-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 anzeigenden 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 "Nullen" 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 (to refer to).

In einen 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 (succeed for), 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 M²R- 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 (uncompressed mode) 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 dageben bei der M²R-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 M²R-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 M²R-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 M²R-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 M²R-Methode kein EOL-Code benutzt, vielmehr ist stattdessen ein EOFB-Code am Ende der Codes für eine Seite vorgesehen.

Wenn der Zustand (state) 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 M²R-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 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 RODT07-00 oder RODT15-08. In diesem Fall entsprechen die zu erzeugenden Lauflängendaten einem Ergänzungscode, und die Daten RODT15-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 RODT07-00 des Registers 62 auszugeben.

Wenn beispielsweise die Anzeigedaten des Zeigers gleich "3" sind, werden die Daten vom Wähler 64 als Daten RODT02-00 und die Daten von der Trommelschiebestufe 50 als Daten RODT07-03 gewählt. Da bei der obigen Operation ein Bilddatenmuster für ein Byte erzeugt wird, werden die Daten RODT07-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 M²R- 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 REF15-08 im Register 96 verriegelt. Zu diesem Zeitpunkt ist oder wird ein Inhalt des a0-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 RODT15-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 RODT15-08 nach Maßgabe der Anzeigedaten vom Bildzeiger 56 zusammengesetzt, und die zusammengesetzten Daten werden dem Datenabschnitt RODT07-00 des Registers 62 eingegeben. Dabei werden Daten entsprechend der Länge der Ausgabebildmusterdaten vom Codierer-ROM 46 zur Addierstufe 52 als Daten EROM07-05 ausgegeben. Als Ergebnis wird die Größe des Bildzeigers 56 aktualisiert. Wenn dabei 2³ Bits im Ausgangssignal der Addierstufe 52 zu "1" werden, wird dies der Steuereinheit 1 in Form von Daten O gemeldet, um sie zu informieren, daß die Verarbeitung für ein Byte abgeschlossen ist. Wenn die Dateneinheit O ausgegeben wird, gibt das Register 62 Daten RODT07-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 2³ Bits nicht gleich "1" sind, werden die Daten RODT07-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 RODT07-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 M²R-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 b1 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. Dies Erzeugungsverarbeitung des Bilddatenmusters erfolgt auf dieselbe Weise wie beim Ergänzungscode eines Horizontalmodus. Die Anzeigedaten des Bildzeigers 54 bleiben unverändert.

Wenn b1 durch den b1-Detektor 102 des a1b1-Detektors 16 festgestellt oder erfaßt wird, wird b1 zum Wähler 108 geliefert. Da die Größe b1, 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 a0-Zeiger 100 ausgegeben.

Nachstehend ist ein Fall beschrieben, in welchem ein Nichtverdichtungsmoduscode eingegeben wird. DieserCode 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 RDTI07-00 zum Bezugszeilen-Speicherteil 4 als Bezugszeildendaten 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 RDTI07-00 gehaltene Bilddaten zum a1-Detektor 104 ausgegeben, und es werden Daten 320(2560 ÷ 8) im RL-Zähler 42 vorgegeben. Der durch den a1-Detektor 104 erfaßte a1-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 Dehnungsverarbeitung 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 DROM11-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 dieselben 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 Bezugszeilendaten werden aus dem Speicherteil 4 ausgelesen, zum Register 96 ausgegeben und als (Daten) REF15-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 DROM15-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 a1-Detektor 104 ein Farbänderungspunkt a1 festgestellt w 22207 00070 552 001000280000000200012000285912209600040 0002003711201 00004 22088ird, d. h. wenn der Inhalt der Daten LSHT08-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 (make- up code) 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 RODT15-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 EROM07-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 RODT07-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 RODT15-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 (terminating code) 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 M²R-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 RDTI07-00 als Dateneinheit F a1 nicht festgestellt wird und auch b1 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 a1 als auch b1 festgestellt oder erfaßt werden, wird die Verdichtungsverarbeitung von zweidimensionalen Codes eingeleitet.

Die erfaßten Größen oder Einheiten a1 und b1 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 b1 gewählt und dem a0-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 zum 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 M²R-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 Bildmusterzeugung 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 M²R-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 in (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.

Die Konfiguration bzw. der Aufbau des Systems, auf welche das oben beschriebene Binärdatenverdichtungs- und -dehnungs- Verarbeitungsgerät angewandt ist, ist nachstehend näher erläutert.

Fig. 11 veranschaulicht eine andere Ausführungsform der Erfindung. Das System gemäß dieser Ausführungsform umfaßt einen Verdichtungs/Dehnungs-Verarbeitungsteil 327, einen Bezugszeilen- Adreßgenerator 328 und einen Speicher 326 zum Speichern von Bezugszeilendaten. Der Verarbeitungsteil 327 ist derselbe wie der Verdichtungs- und Dehnungs-Verarbeitungsteil 2 bei der vorher beschriebenen Ausführungsform, während der Generator 328 dem Generator 3 entspricht. Der Speicher 326 entspricht dem Bezugszeilen-Speicherteil 4 und umfaßt einen statischen Hochgeschwindigkeits-RAM. Der Verarbeitungsteil 327 und der Generator 328 sind in einem großintegrierten Schaltkreis (LSI) 320 integriert.

Der LSI-Schaltkreis 320 weist eine Eingabedatenschiene oder -bus 321 und eine Ausgabedatenschiene oder -bus 322 mit einer 1-Byte-Breite oder -Weite auf. Bei der Dehnungsverarbeitung empfängt der LSI-Schaltkreis 320 Codedaten von der Eingabedatenschiene 321, und er gibt Bilddaten als Ergebnis der Dehnungsverarbeitung auf der Ausgabedatenschiene 322 aus. Bei der Verdichtungsverarbeitung empfängt der LSI-Schaltkreis 320 Bilddaten über die Eingabedatenschiene 321, während er einen Code als Ergebnis der Verdichtungsverarbeitung auf der Ausgabedatenschiene 322 ausgibt.

Der LSI-Schaltkreis 320 liefert auf einer Adreßleitung 323 eine Adresse zum statischen Randomspeicher oder RAM 326. Der Schaltkreis 320 gibt Anweisungen für Lese/Einschreibmodus, Ausgabefreigabemodus und dgl. über eine Anzahl von Steuerleitungen 324 aus und stellt einen Zugriff zu Bilddaten auf einer Bezugsleitung oder -zeile über eine Daten(sammel)schiene 325 her. Im Gegensatz zum erwähnten herkömmlichen Verarbeitungsgerät benötigt der Schaltkreis 320 keine Bildspeicher-Adressierschaltung, und er braucht lediglich mit einem kleinen Bezugszeilen-Adreßgenerator 328 versehen zu sein, der hauptsächlich durch einen Zähler gebildet wird. Durch Ausnützung einer restlichen Chipfläche kann ein mit hoher Geschwindigkeit arbeitender Verdichtungs/Dehnungs-Parallelverarbeitungsteil 327 angeordnet werden.

Im folgenden ist der Unterschied der Grundoperationen zwischen dem in Fig. 11 gezeigten System und einem herkömmlichen System bei der Dehnungsverarbeitung beschrieben. Im grundsätzlichen Betrieb der Dehnungsverarbeitung werden codierte Daten beim herkömmlichen System über eine Systemsammelschiene und bei der dargestellten Ausführungsform über die Eingabeschiene 321 empfangen oder abgenommen, wobei Bilddaten in Übereinstimmung mit einem decodierten M²R-Code erzeugt werden. In diesem Fall ist eine Operation, die stets für jedes Byte der Bilddaten ausgeführt wird, von besonderer Wichtigkeit, wobei die Ausführgeschwindigkeit bei dieser Operation die Gesamtleistung bestimmt. Dies wird später noch näher erläutert werden.

Um beim herkömmlichen System Bilddaten auf einer Bezugszeile auszulesen, werden deren Adresse berechnet und auf eine Bilddaten-Adreßschiene ausgegeben, während ein Leseanforderungssignal zu einem Bildspeicher geliefert wird. In einer Steuerschaltung für den Bildspeicher ist ein Funktions- oder Folgegenerator (arbiter) nötig, um eine Anzahl von Zugriffsanforderungen zu verarbeiten und sie von denen höherer Prioritäten aus auszuführen. Über eine Bilddatenschiene werden ausgelesene Bilddaten eingegeben und von einem Verdichtungs/Dehnungsverarbeitungsteil empfangen. Die Dehnungsverarbeitung erfolgt auf der Grundlage eines dem Verarbeitungsteil auf einer Codedatenschiene eingegebenen M²R-Codes und der vom Bildspeicher über die Bilddatenschiene eingegebenen Bilddaten, wobei die resultierenden Bilddaten auf der Bilddatenschiene übermittelt werden. Gleichzeitig wird eine Adresse des Bildspeichers, in welche die Bilddaten eingeschrieben werden sollen, durch einen Bilddaten-Adreßgenerator berechnet und auf der Adreßleitung ausgegeben. Da die Bilddatenschiene nicht nur für die Ausgabe des Dehnungsverarbeitungsergebnisses, sondern auch für das Auslesen von Bilddaten auf einer Bezugszeile benutzt wird, ist in diesem Fall die Dehnungsverarbeitungsgeschwindigkeit des herkömmlichen Systems beschränkt. Bei diesem herkömmlichen System ist daher ein Randomspeicher mit einer Kapazität entsprechend derjenigen des Bildspeichers und des Funktions- oder Folgegenerators (arbiter) in der Steuerschaltung erforderlich; der Randomspeicher besitzt dabei eine niedrige Zugriffgeschwindigkeit.

Da das erfindungsgemäße System gemäß Fig. 11 den Spezialzweck- Bezugszeilen-Pufferspeicher 326 aufweist, braucht die Ausgabedatenschiene 322 nur für die Ausgabe des resultierenden Bilds von der Dehnungsverarbeitung benutzt zu werden. Die Adreßberechnung für einen nicht dargestellten Bildspeicher erfolgt nicht im LSI-Schaltkreis 320. Normalerweise muß das Bildverarbeitungssystem verschiedene Verarbeitungsarten ausführen, z. B. Bildvergrößerung, -verkleinerung u. dgl., und eine für die jeweiligen Systeme geeignete Hochgeschwindigkeits-Adreßrechenschaltung (nicht dargestellt) aufweisen. Bei Verwendung einer solchen Schaltung werden die von der Datenschiene 322 abgenommenen Bilddaten in den Bildspeicher eingeschrieben.

Während die 1-Byte-Bilddaten auf der Ausgabedatenschiene 322 übermittelt werden, können die Sammelschiene 325, die Adreßleitung 323 und die Steuerleitung 324 für das Auslesen von Bezugszeilendaten und für den Einschreibzugriff des Dehnungsverarbeitungsergebnisses doppelt bzw. zweifach genutzt werden. Im Gegensatz zum Bildspeicher beim bisherigen System ist der Bezugszeilen-Pufferspeicher 326 jedoch speziell für diesen Zweck vorgesehen. Da somit der Pufferspeicher 326 keinen Funktionsgenerator für beliebige Funktionen (arbitration) erfordert und nur eine sehr kleine Kapazität (etwa 1 kB) zu besitzen braucht, ist es dabei einfach, den Lese/Einschreibzugriff mit der doppelten Geschwindigkeit wie beim bisherigen Bildspeicher durchzuführen.

Wie erwähnt, dient die Eingabeschiene 321 gemäß Fig. 11 für die Abnahme von Codedaten und Bilddaten, doch wird sie auch für die Abnahme oder den Empfang von Steuerdaten für z. B. die Bezeichnung einer Verdichtungs/Dehnungsmethode (MH-, MR- oder M²R-Methode), der Zahl der Bits pro Zeile u. dgl. benutzt. Die Ausgabeschiene 322 dient zum Ausgeben von Bilddaten und Codedaten und wird auch für das Aussenden von Statusdaten (Bereit, Belegt, Vorhandensein/Fehlen von Fehlern u. dgl.) benutzt. Die Austauschsteuerung von Steuerdaten und Statusdaten kann durch Lese/Einschreibzugriff eines normalen Ein/Ausgabe-Registers realisiert werden.

Fig. 12 veranschaulicht eine Ausführungsform, bei welcher das erfindungsgemäße System in einem Einchip -LSI- Schaltkreis 330 mit dem Bezugszeilen-Pufferspeicher 326 gemäß Fig. 11 angeordnet bzw. integriert ist. Dies läßt sich durch Verwendung eines in letzter Zeit entwickelten, teilweise speziell angefertigten großintegrierten Schaltkreises (LSI) eines Standardzellentyps erzielen.

Fig. 13 veranschaulicht eine Ausführungsform, bei welcher ein eine große Kapazität besitzender Hochgeschwindigkeits- Chronologiespeicher bzw. FIFO-Speicher (z. B. PD41101C der Fa. NEC) als Bezugszeilen-Pufferspeicher 344 vorgesehen ist. Da bei dieser Ausführungsform der Adreßgenerator 328 weggelassen werden kann, können einseitig gerichtete Sammelschienen oder -busse angewandt werden. Da Eingangsschiene 341 und Ausgangsschiene 343 voneinander getrennt sind, braucht keine Operation mit doppelter Geschwindigkeit durchgeführt zu werden.

Claims (19)

1. Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät zum Verdichten und Dehnen von Binärdaten mit hoher Geschwindigkeit, umfassend
eine Verarbeitungseinheit zum Eingeben der Binärdaten mit einer vorbestimmten Datenlänge, zum Ausgeben der eingegebenen Binärdaten als Bezugszeilendaten in einem Verdichtungsmodus, zum Auslesen der Bezugszeilendaten entsprechend den eingegebenen Binärdaten, zum Durchführen einer Dehnungsverarbeitung an den Binärdaten in einem Dehnungsmodus und einer Verdichtungsverarbeitung an den Binärdaten im Verdichtungsmodus nach Maßgabe der ausgelesenen Bezugszeilendaten, zum Ausgeben von im Dehnungsmodus erzeugten, die vorbestimmte Datenlänge aufweisenden Bilddaten als die Bezugszeilendaten und zum Ausgeben der verarbeiteten Binärdaten zu einer externen Vorrichtung, gekennzeichnet durch eine Bezugszeilendaten-Speichereinheit (4) zum Speichern der eingegebenen Bezugszeilendaten von der Verarbeitungseinheit in Einheiten der vorbestimmten Datenlängen für eine augenblickliche oder aktuelle Verarbeitungszeile und eine nächste Verarbeitungszeile und zum Ausgeben der ausgelesenen Bezugszeilendaten zur Verarbeitungseinheit.

2. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die Bezugszeilendaten-Speichereinheit (4) ein Chronologiespeicher bzw. FIFO-Speicher ist.

3. Gerät nach Anspruch 1, mit einer Bezugszeilenadreß- Generatoreinheit (3) zum Erzeugen einer Adresse, wenn die Verarbeitungseinheit einen Zugriff zur Bezugszeilendaten- Speichereinheit (4) herstellt, dadurch gekennzeichnet, daß die Bezugszeilendaten-Speichereinheit (4) ein statischer Hochgeschwindigkeits-Randomspeicher bzw. -RAM ist.

4. Gerät nach Anspruch 3, dadurch gekennzeichnet, daß die Verarbeitungseinheit und die Bezugszeilenadreß-Generatoreinheit (3) in einem einzigen integrierten Schaltkreis zusammengefaßt sind.

5. Gerät nach Anspruch 3, dadurch gekennzeichnet, daß die Verarbeitungseinheit, die Bezugszeilenadreß-Generatoreinheit (3) und die Bezugszeilendaten-Speichereinheit (4) in einem einzigen integrierten Schaltkreis zusammengefaßt sind.

6. Gerät nach Anspruch 3, dadurch gekennzeichnet, daß die Bezugszeilenadreß-Generatoreinheit (3) folgendes umfaßt: eine Zählereinheit (82) zum Zählen der Zahl der Verarbeitungshäufigkeiten an den eingegebenen Binärdaten in der Verarbeitungseinheit und zum Ausgeben der gezählten Daten oder Zähldaten als ein erster Teil der Adresse für einen Zugriff zur Bezugszeilendaten-Speichereinheit (4),
eine Addiereinheit (86) zum Addieren einer Versatzdateneinheit (offset data) zu den Zähldaten von der Zählereinheit (82) und zum Ausgeben der Summe als zweiter Teil der Adresse,
eine Wählereinheit (86) zum selektiven Ausgeben des ersten Teils der Adresse von der Zählereinheit (82) bzw. des zweiten Teils der Adresse von der Addiereinheit (84) als ein dritter Teil der Adresse und
eine Adreßregistereinheit (88) zum Ausgeben des dritten Teils der Adresse von der Wählereinheit (86) als die Adresse und zum Ausgeben der eingegebenen Adresse zur Bezugszeilendaten-Speichereinheit (4) zusammen mit einer eingegebenen Anzeigedateneinheit, welche einen Speicherbereich für die Bezugszeilendaten für die augenblickliche Verarbeitungszeile bei einer Leseoperation und für die nächste Verarbeitungszeile bei einer Einschreiboperation angibt.

7. Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät zum Verdichten und Dehnen von Binärdaten mit hoher Geschwindigkeit, gekennzeichnet durch
einen Bezugszeilendaten-Speicher (4) zum Speichern von Bezugszeilendaten und
eine Verdichtungs/Dehnungsverarbeitungseinheit (2) zum Eingeben der Binärdaten über eine Eingabedatenschiene, zum Ausgeben der eingegebenen Binärdaten als Bezugszeilendaten zum Bezugszeilendaten-Speicher (4) in einem Verdichtungsmodus, zum Auslesen der Bezugszeilendaten entsprechend den eingegebenen Binärdaten aus dem Bezugszeilendaten- Speicher (4), zum Durchführen einer Dehnungsverarbeitung an den eingegebenen Binärdaten in einem Dehnungsmodus und einer Verdichtungsverarbeitung an den eingegebenen Binärdaten in einem Verdichtungsmodus nach Maßgabe der ausgelesenen Bezugszeilendaten, zum Ausgeben der verarbeiteten Binärdaten im Dehnungsmodus als Bezugszeilendaten zum Bezugszeilendaten-Speicher (4) und zum Ausgeben der verarbeiteten Binärdaten zu einer externen Vorrichtung über eine Ausgabedatenschiene,
und weiterhin dadurch gekennzeichnet, daß die Verdichtungs/ Dehnungsverarbeitungseinheit (2) die Binärdaten über die Eingabedatenschiene eingibt, eine Pipeline-Verarbeitung an den eingegebenen Binärdaten in einer vorbestimmten Richtung ausführt und die verarbeiteten Binärdaten über die Ausgabedatenschiene ausgbit.

8. Gerät nach Anspruch 7, dadurch gekennzeichnet, daß die Bezugszeilendaten-Speichereinheit (4) die Bezugszeilendaten für eine augenblickliche oder aktuelle Verarbeitungszeile und eine nächste Verarbeitungszeile speichert.

9. Gerät nach Anspruch 7, dadurch gekennzeichnet, daß die Bezugszeilendaten-Speichereinheit (4) ein Chronologiespeicher bzw. FIFO-Speicher ist.

10. Gerät nach Anspruch 7, mit einer Bezugszeilenadreß- Generatoreinheit (3) zum Erzeugen einer Adresse, wenn die Verarbeitungseinheit einen Zugriff zur Bezugszeilendaten- Speichereinheit (4) herstellt, dadurch gekennzeichnet, daß die Bezugszeilendaten-Speichereinheit (4) ein statischer Hochgeschwindigkeits-Randomspeicher bzw. -RAM ist.

11. Gerät nach Anspruch 10, dadurch gekennzeichnet, daß die Verdichtungs/Dehnungsverarbeitungseinheit (2) und die Bezugszeilenadreß-Generatoreinheit (3) in einem einzigen integrierten Schaltkreis zusammengefaßt sind.

12. Gerät nach Anspruch 10, dadurch gekennzeichnet, daß die Verdichtungs/Dehnungsverarbeitungseinheit (2), die Bezugszeilenadreß-Generatoreinheit (3) und die Bezugszeilendaten- Speichereinheit (4) in einem einzigen integrierten Schaltkreis zusammengefaßt sind.

13. Gerät nach Anspruch 10, dadurch gekennzeichnet, daß die Bezugszeilenadreß-Generator- oder -Erzeugungseinheit (3) folgendes umfaßt:
eine Zählereinheit (82) zum Zählen der Zahl der Verarbeitungshäufigkeiten an den eingegebenen Binärdaten in der Verarbeitungseinheit und zum Ausgeben der gezählten Daten bzw. Zähldaten als Teil der Adresse für einen Zugriff zur Bezugszeilendaten-Speichereinheit (4),
eine Addiereinheit (86) zum Addieren einer Versatzdateneinheit zu den Zähldaten von der Zählereinheit (82) und zum Ausgeben der Summe als Teil der Adresse,
eine Wählereinheit (86) zum selektiven Ausgeben eines Teils der Adresse von der Zählereinheit (82) und desjenigen von der Addiereinheit (84) und
eine Adreßregistereinheit (88) zum Eingeben des von der Wählereinheit (86) ausgegebenen Teils der Adresse und zum Ausgeben des eingegebenen Teils der Adresse zur Bezugszeilendaten-Speichereinheit (4) zusammen mit eingegebenen oder Eingabe-Anzeigedaten, die einen Speicherbereich für die Bezugszeilendaten für die augenblickliche Verarbeitungszeile in einer Leseoperation und für die nächste Verarbeitungszeile in einer Einschreiboperation anzeigen.

14. Gerät nach Anspruch 7, dadurch gekennzeichnet, daß die Verdichtungs/Dehnungsverarbeitungseinheit folgendes umfaßt:
eine Decodierverarbeitungseinheit (7) zum Eingeben von Binärcodedaten über die Eingabedatenschiene, zum Decodieren der eingegebenen Binärcodedaten zwecks Erzeugung einer Lauflängendateneinheit entsprechend den eingegebenen Binärcodedaten im Dehnungsmodus und zum Eingeben von Binärbilddaten über die Eingabedatenschiene zur Bestimmung, daß alle Bits der eingegebenen Binärbilddaten von derselben Farbe sind, wenn die eingegebenen Binärbilddaten mittels eindimensionaler Codierung codiert werden, sowie zum Erzeugen einer Bitlänge von Bits derselben Farbe bei Feststellung, daß nicht alle Bits von derselben Farbe sind, im Verdichtungsmodus, und
eine Erzeugungsverarbeitungseinheit (8) zum Auslesen der Bezugszeilendaten für die augenblickliche Verarbeitungszeile aus der Bezugszeilendaten-Speichereinheit (4), zum Erzeugen der Binärbilddaten entsprechend den eingegebenen Binärcodedaten nach Maßgabe der erzeugten Lauflängendaten unter Bezugnahme auf die ausgelesenen Bilddaten und zum Ausgeben der erzeugten Bilddaten zur Bezugszeilendaten- Speichereinheit (4) als Bezugszeilendaten für die nächste Verarbeitungszeile und zu einer externen Vorrichtung über die Ausgabedatenschiene in einem Dehnungsmodus, sowie zum Auslesen der Bezugszeilendaten für die augenblickliche Verarbeitungszeile aus der Bezugszeilendaten-Speichereinheit (4), zum Erzeugen von Binärcodedaten entsprechend den der Decodierverarbeitungseinheit (7) eingegebenen Bilddaten nach Maßgabe des Erfassungsergebnisses unter Bezugnahme auf die ausgelesenen Bilddaten und zum Ausgeben der erzeugten Binärcodedaten zu einer externen Vorrichtung über die Ausgabedatenschiene im Verdichtungsmodus.

15. Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät zum Verdichten und Dehnen von Binärdaten mit hoher Geschwindigkeit, gekennzeichnet durch
eine Decodierverarbeitungseinheit (7) zum sequentiellen Empfangen oder Abnehmen der einen (n + 1)ten Codeblock enthaltenden Codedaten in Einheiten von ersten vorbestimmten Datenlängen aus einer Reihe oder Kette von Codedaten, die durch einen Identifiziercode, einen Ergänzungscode, einen Beendigungscode, einen Durchlaßmoduscode und einen Vertikalmoduscode als Decodiereinheit des Codeblocks gebildet sind, zum Decodieren des (n + 1)ten Codeblocks der empfangenen Codedaten und zum Erzeugen einer Lauflängendateneinheit entsprechend dem decodierten Codeblock, wobei die Decodierung in einem Verarbeitungsschritt abgeschlossen ist, wenn der (n + 1)te Codeblock kleiner oder kürzer ist als eine zweite vorbestimmte Datenlänge, während die Decodierung in mehreren Verarbeitungsschritten vollständig durchgeführt wird, wenn der (n + 1)te Codeblock mehr als die zweite vorbestimmte Datenlänge beträgt, und die Lauflängendateneinheit erzeugt wird, wenn die Erzeugung von Bilddaten entsprechend dem n-ten Codeblock abgeschlossen ist, und
eine Erzeugungsverarbeitungseinheit (8) zum Erzeugen von Bilddaten für die Lauflängendateneinheit entsprechend dem n-ten Codeblock, während der (n + 1)te Codeblock in der Decodierverarbeitungseinheit (7) decodiert wird, zum Kombinieren der erzeugten Bilddaten mit einer restlichen Bilddateneinheit in jedem Verarbeitungsschritt und zum Ausgeben der Bilddaten für die erste vorbestimmte Datenlänge aus den kombinierten Bilddaten, wenn eine Länge der kombinierten Bilddaten der ersten vorbestimmten Datenlänge entspricht oder größer ist als diese, wobei die Bilddaten, ausschließlich der ausgegebenen oder Ausgabebilddaten aus den kombinierten Bilddaten erhalten bleiben und die Erzeugung der Bilddaten mittels mindestens eines Verarbeitungsschritts in Übereinstimmung mit der Lauflängendateneinheit erfolgt.

16. Gerät nach Anspruch 15, dadurch gekennzeichnet, daß die Decodierverarbeitungseinheit (7) eine Einheit (7) zum Einleiten der Decodierung des (n + 1)ten Codeblocks während der Erzeugung der Bilddaten entsprechend dem n-ten Codeblock, zum Anhalten der Decodierung bis zum Abschluß der Erzeugung der Bilddaten entsprechend dem n-ten Codeblock und zum vollständigen Durchführen der Decodierung des (n + 1)ten Codeblocks nach vollständig erfolgter Erzeugung der Bilddaten entsprechend dem (n + 1)ten Codeblock, wenn letzterer in einem einzigen Verarbeitungsschritt decodiert werden kann, umfaßt.

17. Gerät nach Anspruch 15, dadurch gekennzeichnet, daß die Decodierverarbeitungseinheit (7) eine Einheit (7) zum Einleiten eines ersten Verarbeitungsschritts der Decodierung während der Erzeugung der Bilddaten entsprechend dem n-ten Codeblock, zum Anhalten der Decodierung bis zum vollständigen Abschluß der Erzeugung der Bilddaten entsprechend dem n-ten Codeblock, zum vollständigen Durchführen des ersten Verarbeitungsschritts der Decodierung nach vollständiger Erzeugung der Bilddaten entsprechend dem n-ten Codeblock und zum anschließenden Ausführen eines zweiten Verarbeitungsschritts der Decodierung und sodann, wenn mehrere Verarbeitungsschritte erforderlich sind, zum Decodieren des (n + 1)ten Codeblocks umfaßt und
die Erzeugungsverarbeitungseinheit (8) eine Einheit (8) umfaßt, die während des zweiten Verarbeitungsschritts der Decodierung des (n + 1)ten Codeblocks und der anschließenden Ausführung abwartet (in einem Wartezustand verbleibt) und die Erzeugung der Bilddaten entsprechend dem (n + 1)ten Codeblock nach vollständiger Decodierung des (n + 1)ten Codeblocks ausführt.

18. Gerät nach Anspruch 15, dadurch gekennzeichnet, daß die Decodierverarbeitungseinheit (7) weiterhin eine Einheit (7) aufweist, um den ersten Verarbeitungsschritt der Decodierung eines nächsten Codeblocks als weiße Farbe wieder einzuleiten, wenn mittels der Erzeugung der Bilddaten festgestellt wird, daß die Verarbeitung zum Ende der betreffenden Verarbeitungszeile fortgeschritten ist.

19. Gerät nach Anspruch 15, dadurch gekennzeichnet, daß die Decodierverarbeitungseinheit (7) weiterhin eine Einheit (7) umfaßt, um den zweiten Verarbeitungsschritt der Decodierung und den anschließenden Schritt (and thereafter) auszuführen, ohne den vollständigen Abschluß der Erzeugung der Bilddaten abzuwarten, wenn in den Codedaten enthaltene "Nullen" für oder auf eine vorbestimmte Zahl von Bits folgen, nachdem der erste Verarbeitungsschritt der Decodierung vollständig abgeschlossen ist.