DE3711200A1 - Binaerdatenverdichtungs- und -dehnungs-verarbeitungsgeraet - Google Patents
Binaerdatenverdichtungs- und -dehnungs-verarbeitungsgeraetInfo
- Publication number
- DE3711200A1 DE3711200A1 DE19873711200 DE3711200A DE3711200A1 DE 3711200 A1 DE3711200 A1 DE 3711200A1 DE 19873711200 DE19873711200 DE 19873711200 DE 3711200 A DE3711200 A DE 3711200A DE 3711200 A1 DE3711200 A1 DE 3711200A1
- Authority
- DE
- Germany
- Prior art keywords
- code
- data
- unit
- decoding
- run
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
- H04N1/41—Bandwidth or redundancy reduction
- H04N1/411—Bandwidth or redundancy reduction for the transmission or storage or reproduction of two-tone pictures, e.g. black and white pictures
- H04N1/413—Systems or arrangements allowing the picture to be reproduced without loss or modification of picture-information
- H04N1/417—Systems or arrangements allowing the picture to be reproduced without loss or modification of picture-information using predictive or differential encoding
- H04N1/4175—Systems or arrangements allowing the picture to be reproduced without loss or modification of picture-information using predictive or differential encoding involving the encoding of tone transitions with respect to tone transitions in a reference line
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/005—Statistical coding, e.g. Huffman, run length coding
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/46—Conversion to or from run-length codes, i.e. by representing the number of consecutive digits, or groups of digits, of the same kind by a code word and a digit indicative of that kind
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Signal Processing (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Compression Of Band Width Or Redundancy In Fax (AREA)
- Image Processing (AREA)
Description
Die Erfindung betrifft ein Binärdatenverdichtungs- und
-dehnungs-Verarbeitungsgerät, das Binärdaten mit hoher
Geschwindigkeit zu dehnen (expand) und insbesondere nach
der M2R-Methode verdichtete (compressed) Binärdaten nach
dem Pipeline-Verfahren parallel zu decodieren vermag.
Für das Verdichten und Dehnen von Binärdaten sind von der
CCITT empfohlene Codierverfahren, wie die MH-, die MR-
und die M2R-Methode international standardisiert und verbreitet
im Gebrauch. Von den drei genannten Codiermethoden
bietet die M2R-Methode die höchste Bildverdichtungsleistung.
Die M2R-Methode ist als Codiermethode für Gruppe-IV-
Faksimilesysteme bekannt. Nach dieser Methode werden
- a) ein Zeilenendecode (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
M2R-Methode ausgeführt wird, ist die Arbeitsgeschwindigkeit
im Vergleich zur MH-Methode erheblich herabgesetzt.
Eine Ursache für das obige Problem liegt im Verarbeitungsverfahren
des gesamten Systems. Insbesondere erfolgt in
einem herkömmlichen System die Decodierung bitseriell. Zur
Lösung des genannten Problems werden verbreitet eine
Parallelverarbeitung, eine Vorausverarbeitung (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 Code
Die Decodier- und Erzeugungsverarbeitung kann mithin mittels
getrennter Hardware-Anordnungen parallel durchgeführt werden.
Bei solchen Anordnungen wird, während ein Code gedehnt wird,
der nächste Code decodiert, und die gesamte Verarbeitung
kann dann als Pipeline-Verarbeitung ausgeführt (pipelined)
werden. Wenn nach den MH- und MR-Methoden codierte Binärdaten
gedehnt werden, ergibt sich bei der Vorausverarbeitung
kein Problem. Die M2R-Methode ist dagegen mit den folgenden
Problemen behaftet:
Bei allen MH-, MR- und M2R-Methoden ist das (der) Anfangsstück
oder -lauf (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 M2R-Methode kein EOL-Code vorhanden ist,
kann der Anfang der nächsten Zeile nur dann erfaßt oder
festgestellt werden, wenn der Erzeugungsverarbeitungsteil
jeden Code entwickelt und ein Ende der Zeile erreicht.
Wenn mithin der Anfang der nächsten Zeile unbestimmt ist,
kann nicht bestimmt werden, ob die Farbe dieses Abschnitts
zwangsweise zu Weiß bestimmt wird.
Infolgedessen kann eine Horizontalmodus-Decodieroperation
unter Verwendung getrennter Codetabellen für einen weißen
Lauf (run) und einen schwarzen Lauf nicht in Vorauslaufweise
eingeleitet werden. Genauer gesagt: bei der Dehnungsverarbeitung
nach der M2R-Methode bei einem herkömmlichen
Gerät kann die Vorausverarbeitung nicht effektiv durchgeführt
werden.
Wie erwähnt, ist das bisherige Gerät mit Problemen bezüglich
der Verarbeitungsgeschwindigkeit sowie der Fähigkeit
für Universal- oder Mehrzweckanwendung behaftet.
Im Hinblick auf die oben geschilderten Gegebenheiten liegt
der Erfindung damit die Aufgabe zugrunde, ein Binärdatenverdichtungs-
und -dehnungs-Verarbeitungsgerät zu schaffen,
das Binärdaten mit hoher Geschwindigkeit zu decodieren,
Eingabebinärcodedaten nach einer Pipeline-Methode parallel
zu decodieren, insbesondere bei der Dehnungsverarbeitung
von nach der M2R-Methode codierten Binärcodedaten, und
einen EOFB-Code (mit einem Muster entsprechend zwei nachfolgenden
EOL-Codes bei der MH- oder MR-Methode) mit hoher
Geschwindigkeit zu erfassen (detektieren) vermag, um damit
eine Vorausverarbeitung zu ermöglichen und eine Hochgeschwindigkeits-
Dehnungsverarbeitung zu erreichen.
Diese Aufgabe wird bei einem Binärdatenverdichtungs- und
-dehnungs-Verarbeitungsgerät, welches Codedaten nach einer
Pipeline-Methode (in a pipeline manner) zu decodieren vermag,
erfindungsgemäß gelöst durch eine Halteeinheit zum
Empfangen von Codedaten einer ersten vorbestimmten Länge
und zum Halten (oder Zwischenspeichern) der letzten Codedaten(einheit)
für eine zweite vorbestimmte Länge, eine
Blockausgabeeinrichtung zum Empfangen der in der Halteeinheit
gehaltenen Codedaten zum Erzeugen eines Codedatenblocks
aus Eingabesteuerdaten und einem nach Maßgabe von
eingegebenen Bitpositionsdaten gewählten Codedatenabschnitt
sowie zum Ausgeben des erzeugten Codedatenblocks
nach Maßgabe eines (einer) Ausgabebefehls oder -anweisung,
eine Decodiereinheit zum Erzeugen von eine Länge einer
Codeeinheit angebenden Daten und (Durch-)Lauflängendaten
entsprechend der Codeeinheit, beginnend von einem vorlaufenden
Bit des Codedatenblocks nach Maßgabe einer Eingabe
des Codedatenblocks, und eine Bitpositionsbezeichnungseinrichtung
zum Ausgeben der gehaltenen Bitpositionsdaten zur
Blockausgabeeinrichtung sowie zum Aktualisieren der Bitpositionsdaten
nach Maßgabe der Codeeinheitslängendaten
von der Decodiereinheit.
Gegenstand der Erfindung ist auch ein Binärdatenverdichtungs-
und -dehnungs-Verarbeitungsgerät, welches Codedaten parallel
zu decodieren vermag, das gekennzeichnet ist durch eine
Adressiereinheit zum Erzeugen von Adreßdaten aus Eingabesteuerdaten
und Eingabecodedaten, enthaltend eine Codeeinheit,
als Einheiten von zu decodierenden Codes, eine
Decodiereinheit mit einer Anzahl von Codetabellen zum
Decodieren von Codeeinheiten, zwecks Ausgabe von nächsten
Zustandsdaten (next state data), die eine Tabelle angeben,
auf die zum Decodieren der nächsten Codeeinheit und Lauflängendaten
der decodierten Codeeinheit Bezug genommen
werden soll, und eine Steuereinheit zum Ausgeben der
Steuerdaten zum Decodieren der augenblicklichen oder
aktuellen Codeeinheit nach Maßgabe der nächsten Zustandsdaten.
Erfindungsgemäß werden die folgenden Wirkungen erzielt:
- 1. Da beim Decodieren eines M2R-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.
Im folgenden ist eine bevorzugte Ausführungsform 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 Decodierteils
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 a 1 b 1-Detektors
des Erzeugungsverarbeitungsteils nach
Fig. 1,
Fig. 6 eine schaubildliche Darstellung einer Decodiersequenz
des Decodierverarbeitungsteils gemäß
Fig. 2,
Fig. 7 eine schaubildliche Darstellung einer Erzeugungssequenz
des Decodierverarbeitungsteils gemäß
Fig. 2,
Fig. 8 ein Adressenformat eines Decodierer-Festwertspeichers
oder -ROMs gemäß Fig. 2,
Fig. 9A ein Ausgabeformat des Decodierer-ROMs nach Fig. 2,
Fig. 9B ein Ausgabeformat eines Lauflängendatenabschnitts
des Ausgabeformats des Decodierer-ROMs gemäß
Fig. 9A und
Fig. 10A bis 10F Zeitsteuerdiagramme zur Verdeutlichung
der Arbeitsweise des Binärdatenverdichtungs- und
-dehnungs-Verarbeitungsgeräts gemäß der Erfindung.
Im folgenden ist zunächst die Anordnung oder der Aufbau
eines Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgeräts
gemäß einer Ausführungsform der Erfindung anhand
von Fig. 1 beschrieben.
Das Gerät gemäß Fig. 1 umfaßt eine Binärdatenverarbeitungs-
Steuereinheit 1 zur Steuerung des Betriebs des gesamten
Geräts, einen Verdichtungs- und Dehnungs-Verarbeitungsteil 2
zum Erzeugen von Binärbildmusterdaten, wenn die eingegebenen
Binärdaten ein Code sind, und zum Erzeugen eines Codes, wenn
die eingegebenen Binärdaten Bildmusterdaten sind, einen
Bezugszeilendaten-Speicherteil 4 zum Speichern von Bezugszeilendaten,
einen Bezugszeilen-Adreßgenerator 3 zum Erzeugen
von Adreßdaten für den Speicherteil 4 sowie einen
Taktgenerator zum Erzeugen von Steuer-Taktsignalen.
Der Verdichtungs- und Dehnungs-Verarbeitungsteil 2 umfaßt
einen Decodier(verarbeitungs)teil 7 zum Erzeugen von Lauflängendaten
(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 Decodierteil 13.
Der Erzeugungsverarbeitungsteil 8 umfaßt einen Zählerteil 14
zum Verriegeln eines Ausgangssignals vom Decodierteil 13
und zum Zählen der Zahl der verarbeiteten Bytes, einen Erzeugungsteil
15 zum Erzeugen von auf der Grundlage von
Daten vom Zählerteil 14 verarbeiteten Binärdaten sowie
einen a 1 b 1-Detektor 16 zum Erfassen von a 1 und b 1.
Die Steuereinheit 1 ist mit einem Taktgenerator 5 zum Erzeugen
von Steuer-Taktsignalen verbunden, und sie steuert
die Operationszeitpunkte oder -takte (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 Verriegelungsglied 22 eingegeben
und durch dieses verriegelt. Die durch das Verriegelungsglied
22 verriegelten Binärdaten werden durch einen
Inverter 24 invertiert und dann als Daten K einem Register
26 und dem EOL-Detektor 11 eingegeben. Das Register 26 verschiebt
vorher eingegebene Byte-Daten RDTI 15-08 zu Daten
RDTI 07-00 nach Maßgabe eines Steuersignals von der Steuereinheit
1, es verriegelt die neuen Eingabedaten als Daten
RDTI 15-08 und hält diese als 16-Bit-Daten zusammen mit den
Daten RDTI 07-00.
Die 16-Bit-Registerdaten RDTI 15-00 werden über den Codierende-
Verarbeitungsteil 12 zu einer Trichterschiebestufe
(funnel shifter) 30 ausgegeben. Die Daten RDTI 07-00 werden
als Byte-Daten F zum Bezugszeichendaten-Speicherteil 4
ausgegeben. Ein Decodierzeiger 36 zeigt eine Position LSB
(niedrigstwertiges Bit) eines zu decodierenden Codes oder
einen Teil des Codes an, der als nächster aus den der
Trichterschiebestufe 30 eingegebenen Registerdaten RDTI 15-00
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
LSHT 08-00, das durch Linksverschiebung der Daten RDTI 15-00
durch die Anzeigegröße vom Decodierzeiger 36 erhalten wurde,
und gibt dieses Ausgangssignal zu einem Wähler 31 aus. Im
Fall der Verarbeitung im Nichtverdichtungsmodus werden
Daten LSHT 04-00 der Ausgabedaten LSHT 08-00 als Daten G
zum Erzeugungsverarbeitungsteil 8 ausgegeben. Die Daten
LSHT 08-00 werden zu den Daten LSHT 10-09 entsprechend den
Daten X von der Steuereinheit 1 hinzuaddiert und als
11-Bit-Daten zum Wähler 31 ausgegeben. Der Wähler 31
empfängt die den Daten LSHT 08-06 oder LSHT 08-07 entsprechenden
Daten Y von der Steuereinheit 1. Diese Eingangs-
oder Eingabedaten werden in Abhängigkeit von einem Steuersignal
von der Steuereinheit 1 gewählt und als 11-Bit-Adreßdaten
zu einem Decodierer-Festwertspeicher oder -ROM 32 ausgegeben.
Die Daten X werden ebenfalls dem Decodierer-ROM 32
zugeführt. Der Decodierer-ROM 32 gibt 16-Bit-Daten DROM 15-00
aus. Insbesondere werden dabei als Daten DROM 07-00 Eingabebinärdaten
im Fall der Verdichtungsverarbeitung ausgegeben,
während im Fall der Dehnungsverarbeitung Lauflängendaten
ausgegeben werden. Lauflängendaten I werden zum Erzeugungsverarbeitungsteil
8 übermittelt. Als Daten DROM 11-08 wird
eine decodierte Datenlänge der Eingabedaten ausgegeben.
Als Daten DROM 15-12 werden Steuerdaten H zum Bezeichnen
des nächsten Zustands (state) ausgegeben. Ein Adressenformat
und ein Ausgabedatenformat werden später noch näher erläutert
werden.
Die Daten DROM 11-08 werden zu einer Addierstufe 34 ausgegeben,
die gleichzeitig Daten vom Decodierzeiger 36 abnimmt.
Dabei werden die Daten DROM 11-08 zu den Daten vom Decodierzeiger
36 addiert, und die summierten Daten werden zum
Wähler 38 ausgegeben. Der Wähler 38 nimmt außerdem vom a 1 b 1-
Detektor 16 Daten D ab, die bei der Verdichtungsverarbeitung,
nicht aber bei der Dehnungsverarbeitung benutzt werden. Wenn
daher die Dehnungsverarbeitung nach Maßgabe eines Steuersignals
von der Steuereinheit 1 ausgeführt wird, werden die
summierten Daten wiederum zum Inhalt des Decodierzeigers 36.
Letzterer zeigt auf diese Weise eine LSB-Position eines dem
decodierten Code am nächsten liegenden Codes an.
Wenn 23-Bitdaten als Ergebnis der Addition durch die Addierstufe
34 zu Daten"1" werden, wird dies der Steuereinheit 1
mittels der Daten J gemeldet. Dies bedeutet, daß die Verarbeitung
für ein Byte abgeschlossen ist. Die Steuereinheit
1 gibt nach Maßgabe der Daten J von der Addierstufe 34 ein
Steuersignal zum Register 26 aus. Das Register 26 bewirkt
eine Linksverschiebung der Daten RDTI 15-08 in Einheiten von
Bytes zu Daten RDTI 07-00 nach Maßgabe des Steuersignals von
der Steuereinheit 1. Durch das Verriegelungsglied 22 verriegelte
neue Byte-Daten werden im Daten-RDTI 15-08-Abschnitt
des Registers 26 nach Maßgabe des Steuersignals von der
Steuereinheit 1 verriegelt. Die unteren drei Bits der
summierten Daten von der Addierstufe 34 werden zum Zeiger
36 ausgegeben, so daß die LSB-Position eines zu decodierenden
Codes stets in den Daten RDTI 07-00 des Registers 26
vorhanden ist.
Der Zählerteil 14 und der Erzeugungsteil 15 des Erzeugungsverarbeitungsteils
13 sind nachstehend anhand von Fig. 3
im einzelnen beschrieben. Der Zählerteil 14 umfaßt Wähler
40 und 44 sowie einen RL-Zähler 42. Der Erzeugungsteil 15
ist - unter Ausschluß des Zählerteils 14 - durch eine in
Fig. 3 dargestellte Schaltung gebildet.
Das Decodierergebnis I vom Decodierer-ROM 32 wird dem
Wähler 40 eingegeben, der auch Daten L von der Steuereinheit
1 abnimmt. Diese Daten werden nach Maßgabe eines
Steuersignals von der Steuereinheit 1 gewählt und zum RL-
Zähler 42 ausgegeben. Von den Ausgabedaten vom Zähler 40
wird ein 02-00-Bitabschnitt auch zum Wähler 44 ausgegeben.
Der RL-Zähler 42 ist ein Zähler mit einer 12-Bit-Länge,
und er verriegelt Daten vom Wähler 40 in einer vorbestimmten
Position oder Stelle nach Maßgabe eines Steuersignals
von der Steuereinheit 1. Unter Heranziehung der Ausgabedaten
vom Wähler 40 als Vorgabegröße zählt der RL-Zähler 42
in Übereinstimmung mit den Zählimpulsen von der Steuereinheit
1 herab, und er gibt die Zählung oder den Zählstand
als Daten B zum Wähler 44 und zum a 1 b 1-Detektor 16 aus.
Das Ausgangssignal vom RL-Zähler 40 wird auch als Daten M
zur Steuereinheit 1 ausgegeben, um zu bestätigen, ob die
Zahl der durch den decodierten Code bestimmten Verarbeitungsoperationen
vollständig ist. Der Wähler 44 empfängt das
Ausgangssignal vom Zähler 42, das Ausgangssignal vom
Wähler 40 sowie Daten A vom a 1 b 1-Detektor 16, und er wählt
eine dieser Einheiten nach Maßgabe eines Steuersignals
von der Steuereinheit 1, um die gewählten Daten zu einem
Codierer-ROM 46 auszugeben.
Der Codierer-ROM 46 nimmt die Daten N, einschließlich der
Daten für Farbbezeichnung und Daten für die Anzeige oder
Angabe einer Dehnungs- oder Verdichtungsverarbeitung, von
der Steuereinheit 1 ab. Der Codierer-ROM 46 empfängt Daten
vom Wähler 44 und Daten N von der Steuereinheit 1 als
Adreßdaten und gibt 8-Bit-Daten EROM 07-00 zum Wähler 48
aus.
Von den Daten EROM 07-00 werden die Daten DROM 07-05 zu einer
Addierstufe 52 ausgegeben. Eine durch die Addierstufe 52,
den Wähler 54 und einen Bildzeiger 56 gebildete Schaltung
arbeitet auf dieselbe Weise wie die Schaltungen des Decodierteils
8. Insbesondere erzeugt dabei der Bildzeiger 56
eine Angabe- oder Anzeigegröße. Nach Abschluß der Erzeugungsverarbeitung
für den decodierten Code wird die Anzeigegröße
vom Bildzeiger 56 durch die Addierstufe 52 zu den Daten
EROM 07-05 addiert, und die summierten Daten werden zum
Wähler 54 ausgegeben.
Die Daten C werden vom a 1 b 1-Detektor 16 dem Wähler 54 eingegeben
und in Abhängigkeit von einem Steuersignal von
der Steuereinheit 1 gewählt, um als Anzeigegröße des
Bildzeigers 56 zu dienen. Wenn aufgrund der Addition durch
die Addierstufe 52 die 23-Bit-Daten gleich "1" sind, wird
dies durch Daten O der Steuereinheit 1 gemeldet.
Der Wähler 48 empfängt Daten EROM 07-00 und Daten G vom
Decodierverarbeitungsteil 7 über ein Verriegelungsglied 58
und wählt eine dieser Dateneinheiten in Abhängigkeit vom
Steuersignal von der Steuereinheit 1, um die gewählten
Daten zu einer Trommelschiebestufe (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 RODT 15-08 zum Register 62
aus.
Die Daten RODT 07-00 und die Daten RODT 15-08 werden durch
den Wähler 64 in Übereinstimmung mit einem Steuersignal
von der Steuereinheit 1 gewählt, und das Wählergebnis wird
dem Wähler 60 eingegeben. Ein Ausgangssignal vom Wähler 60
wird als Daten RODT 07-00 einem Register 62 zugeführt,
welches die Daten RODT 15-08 nach Maßgabe eines Steuersignals
von der Steuereinheit 1 zu Daten RODT 07-00 verschiebt.
Die Daten RODT 07-00 und die Daten RODT 15-08 werden
zum Wähler 64 ausgegeben.
Weiterhin werden die Daten RODT 07-00 als Daten P zum Bezugszeilendaten-
Speicherteil 4 ausgegeben, wenn Bilddaten
für ein Byte erzeugt werden, und sie werden außerdem zu
einem dem Inverter 24 ähnlichen Inverter 66 ausgegeben, um
letztlich auf einer Ausgabedatenschiene ausgegeben zu
werden.
Die Anordnung des Bezugszeilen-Adreßgenerators 3, des
EOL-Detektors 11 des Decodierverarbeitungsteils 7 und
des Bezugszeilendaten-Speicherteils 4 ist nachstehend
anhand von Fig. 4 erläutert.
Der EOL-Detektor 11 des Decodierverarbeitungsteils 7 umfaßt
ein Stopadreßregister 80, einen Komparator 90 und
einen EOL-Detektor 81. Der Bezugszeilen-Adreßgenerator 3
umfaßt einen Adreßzähler 82, eine Addierstufe 84, einen
Wähler 86 und ein Adreßregister 88. Der Bezugszeilendaten-
Speicherteil 4 umfaßt seinerseits einen Wähler 92 und
einen Bezugszeilen-Puffer-Randomspeicher bzw. -RAM 94.
Das Stopadreßregister 80 verriegelt im voraus Einzeilen-
Lauflängendaten und gibt die oberen 10-Bit-Daten zu einem
Komparator 90 aus. Der Adreßzähler 82 nimmt Daten Q von
der Steuereinheit 1 ab. Die Daten Q werden dem Zähler 82
jedesmal dann eingegeben, wenn eine Einbyte-Binärdatenverarbeitung
abgeschlossen ist, und der Zähler 82 speichert
die Daten Q auf, bis die Einzeilenverarbeitung beendet
ist. Ein Ausgangssignal vom Adreßzähler 82 zeigt mithin
die Byte-Position an, bis zu welcher die Binärdatenverarbeitung
auf der entsprechenden Verarbeitungszeile fortgeschritten
ist.
Nach Beendigung der Einzeilenverarbeitung wird der Adreßzähler
82 entsprechend einem Steuersignal von der Steuereinheit
1 rückgesetzt, und er beginnt wieder zu zählen,
wenn die Verarbeitung einer neuen Zeile eingeleitet wird.
Eine Zählgröße oder ein Zählstand des Adreßzählers 82 wird
zum Komparator 90, zum Wähler 86 und zur Addierstufe 84 ausgegeben.
Der Komparator 90 nimmt auch Lauflängendaten
(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 entsprechendenVerarbeitungszeile
erreicht hat. Zu diesem Zeitpunkt werden
Daten T zur Steuereinheit 1 ausgegeben.
Die Addierstufe 84 nimmt Daten R von der Steuereinheit 1 ab
und addiert sie zum Zählstand (bzw. zur Zählgröße) des
Adreßzählers 82, um die Summe zum Wähler 86 auszugeben.
Der Wähler 86 wählt Adreßdaten vom Adreßzähler 82 sowie
Adreßdaten von der Addierstufe 84 nach Maßgabe eines
Steuersignals von der Steuereinheit 1, um das Wählergebnis
zum Adreßregister 88 auszugeben.
Das Adreßregister 88 empfängt auch Daten S von der Steuereinheit
1 und gibt diese Daten zusammen mit dem Ausgangssignal
vom Wähler 86 zum Bezugszeilen-Puffer-RAM 94 aus.
Der Puffer-RAM 94 speichert Bilddaten auf einer bzw. für
eine Bezugszeile und Bilddaten für die entsprechende Verarbeitungszeile
zum Verarbeiten der nächsten Zeile. Bilddaten
für zwei Zeilen werden somit im Randomspeicher bzw.
RAM 94 abgespeichert, und Daten S werden von der Steuereinheit
1 zum Adreßregister 88 geliefert, um die Bezeichnungsspeicherbereiche
umzuschalten, d. h. zu bestimmen,
welcher Bereich (bzw. Speicherplatz) gewählt werden soll.
Der Wähler 92 empfängt die eingegebenen Byte-Bilddaten F,
d. h. die Daten RIDT 07-00, über den Codierende-Verarbeitungsteil
28, sowie Byte-Daten P, d. h. verarbeitete Bilddaten
RODT 07-00, und wählt eine dieser Dateneinheiten nach Maßgabe
eines Steuersignals von der Steuereinheit 1, um dabei
das Wählergebnis im Bezugszeilen-Puffer-RAM 94 abzuspeichern.
Wie aus der vorstehenden Beschreibung hervorgeht, wählt der
Wähler 86 beim Auslesen von Bezugszeilendaten die Ausgangs-
oder Ausgabedaten von der Addierstufe 84, während er bei
Speicherung der Bezugszeilendaten die Ausgabedaten vom
Adreßzähler 82 wählt, um sie auszugeben.
Wenn zu Beginn der Verarbeitung für eine neue Zeile Bezugszeilendaten
ausgelesen werden, werden (Daten) "2" und "1"
als Daten R von der Steuereinheit 1 der Addierstufe 84
eingegeben, um für das Register 96 nötige Bezugsdaten
auszugeben. Das Register 96 kann sodann die nötigen Bezugszeilendaten
halten. Die Daten REF -3-10 vom Register 96
werden als Daten U zu einem b 1-Detektor 102 ausgegeben.
Der EOL-Detektor 81 erfaßt einen EOL-Code, wenn ein Fehler
z. B. im Decodierverarbeitungsteil 7 oder im Erzeugungsverarbeitungsteil
8 auftritt. Der Detektor 81 empfängt Daten H
vom Decodierverarbeitungsteil 7 und meldet die Erfassung
oder Detektierung eines EOL-Codes zur Steuereinheit 1 mittels
Daten Z.
Die Anordnung des a 1 b 1-Detektors 16 des Erzeugungsverarbeitungsteils
8 ist nachstehend anhand von Fig. 5 erläutert.
Der a 1 b 1-Detektor 16 wird häufig in einem Vertikalmodus
und einem Durchlaßmodus (pass mode) in einem zweidimensionalen
Modus benutzt.
Aus dem Randomspeicher bzw. RAM 94 ausgelesene Daten werden
durch das Register 96 als Daten REF 15-08 verriegelt. Das
Register 96 verschiebt in Einheiten von Bytes Daten 07-04
zu Daten REF -4-1 und Daten REF 15-08 zu Daten REF 07-00 nach
Maßgabe eines Steuersignals von der Steuereinheit 1, und
es verriegelt Daten vom Randomspeicher 94 als Daten
REF 15-08. Einer Bezugszeile zugeordnete Daten U werden
vom Register 96 zum b 1-Detektor 102 geliefert. Daten F
werden vom Codierende-Verarbeitungsteil 28 zu einem a 1-
Detektor 104 geliefert. Die b 1- und a 1-Detektoren 102 bzw.
104 nehmen eine Anzeigegröße a 0 von einem a 0-Zeiger 100
ab und erfassen jeweils Positionen a 1 bzw. b 1 von Pixels
mit Farbänderungen auf einer Codierzeile und einer Bezugszeile
an der rechten Seite der Position a 0 an bzw. im
Register 96.
Die durch den b 1-Detektor 102 erfaßte Position b 1 wird
zu einer Subtrahierstufe 120 und einem Wähler 108 ausgegeben.
Wenn der Punkt b 1 nicht erfaßt wird, wird dies der
Steuereinheit 1 mittels Daten A 2 gemeldet. In Verbindung
mit dem Register 96 wird "+4" zur Position b 1 hinzuaddiert.
Die durch den a 1-Detektor 104 erfaßte Position a 1 wird zu
den Wählern 116 und 114 ausgegeben. Der Wähler 116 wählt
Daten vom a 1-Detektor 104 und Daten +4 von der Steuereinheit
1 nach Maßgabe eines Steuersignals von der Steuereinheit
1, und er gibt das Wählergebnis zur Subtrahierstufe
120 aus.
Die Subtrahierstufe 120 gibt das Rechenergebnis als Daten
A zum Erzeugungsteil 15 aus. Der Wähler 108 empfängt die
Anzeigegröße vom a 0-Zeiger 100 und ein Ausgangssignal (bzw.
eine Ausgabegröße) b 1 vom b 1-Detektor 102, während der
Wähler 110 eine Größe -4 von der Steuereinheit 1 sowie
Daten B vom Erzeugungsteil 15 abnimmt. Die Wähler 108 und
110 wählen die jeweiligen Ausgänge oder Ausgaben nach Maßgabe
von Steuersignalen von der Steuereinheit 1 und geben
diese zur Addierstufe 112 aus.
Die Addierstufe 112 liefert die Summe zum Wähler 114, der
außerdem das Ausgangssignal a 1 vom a 1-Detektor 104, die
Anzeigegröße vom a 0-Zeiger 100 sowie Daten W von der
Steuereinheit 1 empfängt und ein Ausgangssignal (oder eine
Ausgabe) nach Maßgabe eines Steuersignals von der Steuereinheit
1 wählt. Das gewählte Ausgangssignal wird als
Daten C dem Erzeugungsteil 15 und außerdem als Daten D
dem Decodierteil 13 zugeliefert. Das Ausgangssignal vom
Wähler 114 wird weiterhin durch den a 0-Zeiger 100 als Anzeigegröße
verriegelt. Die Anzeigegröße des a 0-Zeigers 100
und Daten vom Stopadreßregister 80 werden durch den Komparator
106 verglichen, um damit festzustellen, 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 M2R-Methode, im Fall eines
Faksimilesystems geliefert. Die Steuerdaten enthalten Daten
zur Anzeige einer Lauflänge für eine Zeile. Das Stopadreßregister
80 speichert die Lauflängendaten für eine Zeile.
Bei der Verarbeitung nach der M2R-Methode sind alle Bits
der Bilddaten auf der Bezugszeile am Anfang einer Seite
weiß oder gleich "0". In diesem Zustand wird zunächst durch
den EOL-Detektor 81 ein EOL-Code erfaßt, um die Dehnungsverarbeitung
einzuleiten.
Bei Einleitung einer Dehnungsverarbeitung für eine neue
Zeile wird ein erforderlicher
Zustand initialisiert. Beispielsweise wird die folgende
Initialisierung ausgeführt: Der Adreßzähler 82 wird rückgesetzt,
und von der Steuereinheit 1 werden Daten S zum
Bit "10" des Adreßregisters 88 geliefert, um Adressen umzuschalten.
Danach wird von der Steuereinheit 1 eine Dateneinheit
"1" als Daten R der Addierstufe 84 eingegeben, und
erste Byte-Daten auf der Bezugszeile werden aus dem Bezugszeilen-
Puffer-RAM 94 ausgelesen, um als Daten REF 15-08
im Register 96 abgespeichert zu werden. Nach dem Verschieben
der im Register 96 gespeicherten Daten zu Daten REF 07-00
wird (die Einheit) "2" als Daten R von der Steuereinheit 1
geliefert, und die aus dem RAM 94 ausgelesenen Byte-Daten
werden auf dieselbe Weise, wie oben beschrieben, als Daten
REF 15-08 im Register 96 gespeichert. Die Zeiger 36, 56 und
100 werden rückgesetzt. Daten W werden von der Steuereinheit
1 dem Wähler 114 eingegeben und entsprechend einem
Steuersignal von der Steuereinheit 1 gewählt, so daß ein
neuer Wert bzw. eine neue Größe im a 0-Zeiger 100 gesetzt
wird. Die Farbe wird dabei zwangsweise auf "Weiß" gesetzt.
Beispielsweise sei angenommen, daß ein nach der M2R-Methode
codierter Code über eine Eingabedatenschiene dem Decodierverarbeitungsteil
7 in Einheiten von 8 Bits, d. h. 1 Byte,
nach Vornahme der erwähnten Initialisierung eingegeben und
durch das Verriegelungsglied 22 nach Maßgabe eines Steuersignals
von der Steuereinheit verriegelt wird.
In einem Register, das hauptsächlich zum Halten (oder
Speichern) von Bilddaten und eines verdichteten Codes
dient, entspricht das am weitesten links befindliche Bit
dem Bit "0". In einem Register, das hauptsächlich zum
Halten von binären Steuerdaten dient, entspricht das am
weitesten rechts stehende Bit dem Bit "0". Infolgedessen
müssen die eingegebenen Binärdaten invertiert werden. Dies
erfolgt durch den Inverter 24, der die Binärdaten sodann zum
Register 26 und zum EOL-Detektor 11 ausgibt. Im Register 26
werden vorher eingegebene Byte-Daten RDTI 15-08 nach Maßgabe
eines Steuersignals von der Steuereinheit 1 zu Daten
RDTI 07-00 verschoben, und neue Eingabedaten werden als
Daten RDTI 15-08 verriegelt und zusammen mit Daten RDTI 07-00
als 16-Bit-Daten gehalten. Auf diese Weise werden am Anfang
einer Seite 2-Byte-Binärdaten eingegeben.
16-Bit-Registerdaten RDTI 15-00 werden zum Codierende-Verarbeitungsteil
28 ausgegeben. Diese Schaltung wird nur bei
der Verdichtungsverarbeitung betätigt, während sie bei der
Dehnungsverarbeitung einfach Daten passieren läßt. Die
16-Bit-Registerdaten RDTI 15-00 werden daher über den Verarbeitungsteil
28 zur Trichterschiebestufe 30 ausgegeben.
Der Decodierzeiger 36 zeigt die LSB-Position eines als
nächstes auszuziehenden Codes vom oder aus den Registerdaten
RDTI 15-00 an, die der Trichterschiebestufe 30 eingegeben
wurden. Letztere erzeugt eine 9-Bit-Ausgabe LSHT 08-00,
die durch Linksverschieben der Daten RDTI 15-00 um die Zahl
der durch eine Anzeigegröße vom Zeiger 36 angegebenen Bits
erhalten wurde. Wenn beispielsweise die Größe des Zeigers
36 gleich "3" ist, wählt die Trichterschiebestufe 30 Daten
RDTI 11-03 aus den Eingabedaten RDTI 15-00 und gibt diese als
Daten LSHT 08-00 aus.
Die Daten LSHT 08-00 werden zu den den Daten LSHT 10-09 von
der Steuereinheit 1 entsprechenden Daten hinzuaddiert, und
das Ergebnis wird zum Wähler 31 ausgegeben, der außerdem
Daten entsprechend den Daten LSHT 06-08 oder LSHT 07-08 von
der Steuereinheit 1 abnimmt. Diese Eingabedaten werden nach
Maßgabe eines Steuersignals von der Steuereinheit 1 gewählt,
und die gewählten Daten werden als 11-Bit-Adreßdaten zum
Decodierer-ROM 32 ausgegeben.
Wenn in diesem Fall bei der M2R-Methode die Erzeugungsverarbeitung
eines unmittelbar vorhergehenden decodierten
Codes nicht beendet oder abgeschlossen ist, wird das dem
Wähler 31 zugeordnete Steuersignal nicht erzeugt. Der
Wähler 31 wartet daher den Abschluß der Erzeugungsverarbeitung
in einem Zustand ab, in welchem die Daten LSHT 08-00
geliefert werden.
Falls der Wähler 31 den Abschluß nicht abwartet, kann ein
weißer Vorsatz oder Lauf (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 Voraussetzung (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 M2R-Methode
einen EOL-Code verwenden, kann eine Codedateneinheit durch
Vorausverarbeitung decodiert werden, ohne daß der Abschluß
der augenblicklichen Erzeugungsverarbeitung abgewartet zu
werden braucht. Mit der Decodierverarbeitung nach der M2R-
Methode kann somit auch die nach der MH- oder MR-Methode
mit höherer Geschwindigkeit als beim bisherigen Gerät
durchgeführt werden.
Die Daten LSHT 10-00 werden nach Maßgabe eines Steuersignals
von der Steuereinheit 1 zum Decodierer-ROM 32 ausgegeben.
Wenn Daten Y 08-06 gewählt sind, wird der 08-06-Bitabschnitt
oder der 08-07-Bitabschnitt der Daten LSHT 10-00 als der
entsprechende Abschnitt oder Teil der Daten LSHT gewählt,
und der Datenabschnitt LSHT 08-00 wird durch entsprechende,
zum Decodierer-ROM 32 auszugebende Bits zur MSB-Richtung
verschoben.
Ein Adressenformat des Decodierer-ROMs 32 (noch zu beschreiben)
zeigt an, wann und welche Daten zu wählen sind.
Der Decodierer-ROM 32 gibt 16-Bit-Daten DROM 15-00 des in
Fig. 9A gezeigten Formats nach Maßgabe eines Adressenformats
gemäß Fig. 8 aus. Insbesondere werden dabei Lauflängendaten
als Daten DROM 07-00, Codelängendaten als Daten
DROM 11-08 und Daten für die Bezeichnung des nächsten Zustands
als Daten DROM 15-12 ausgegeben. Die Adressen- und
Ausgangsformate werden später noch näher erläutert werden.
Die Daten DROM 11-08 werden zur Addierstufe 34 ausgegeben,
welche gleichzeitig Daten vom Zeiger 36 abnimmt. Die Daten
DROM 11-08 werden somit zum Inhalt des Zeigers 36 addiert,
und die summierten Daten werden zum Wähler 38 ausgegeben.
Der Wähler 38 empfängt ein Signal D, das bei der Verdichtungsverarbeitung,
nicht aber bei der Dehnungsverarbeitung
benutzt wird, vom a 1 b 1-Detektor 16. Da jedoch im
vorliegenden Fall die Dehnungsverarbeitung durchgeführt
wird, wird das Ausgangssignal von der Addierstufe 34 nach
Maßgabe eines Steuersignals von der Steuereinheit 1 gewählt.
Aus diesem Grund werden die summierten Daten
wiederum zum Inhalt des Zeigers 36. Der Zeiger 36 zeigt
auf diese Weise die LSB-Position eines einem decodierten
Code am nächsten gelegenen Codes an.
Wenn die 23-Bit-Daten als Ergebnis der Addition durch die
Addierstufe 34 zu "1" werden, wird dies der Steuereinheit 1
mittels der Daten J gemeldet. Dies bedeutet, daß die Decodierverarbeitung
für ein Byte abgeschlossen ist. Die Steuereinheit
1 gibt daraufhin ein Steuersignal zum Register 26
aus, um die Daten RDTI 15-08 in Einheiten von Bytes nach
links zu Daten RDTI 07-00 zu verschieben. Durch das Verriegelungsglied
22 verriegelte neue Byte-Daten werden als
Daten RDTI 15-08 nach Maßgabe eines Steuersignals von der
Steuereinheit 1 im Register 26 verriegelt. Der Zeiger 36
nimmt die unteren drei Bits der summierten Daten von der
Addierstufe 34 ab, so daß in den Daten RDTI 07-00 des
Registers 26 stets die LSB-Position eines zu decodierenden
Codes vorhanden ist.
Die Adressen- und Ausgangs- oder Ausgabeformate des Decodierer-
ROMs 32 sind im folgenden anhand der Fig. 8, 9A und 9B
beschrieben. Hierbei ist eine zu decodierende Codeeinheit
ein Identifizier- oder Kenncode eines Horizontalmodus, ein
Ergänzungscode (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
LSHT 10-09 der eindimensionalen Weißlauf-Codetabelle 1
geliefert. Nahezu alle eindimensionalen Schwarzlaufcodes
bestehen aus 10 Bits oder mehr, wobei die maximale Länge
13 Bits beträgt. Ein Schwarzlauf-Ergänzungscode mit einer
Lauflänge von von 1792 Bits oder mehr ist auch einem
Weißlauf gemeinsam. Wenn somit ein Schwarzlaufcode aus
7 Bits oder weniger besteht, wird er mittels der eindimensionalen
Schwarzlauf-Codetabelle 1 verarbeitet; wenn
er aus 8 Bits oder mehr besteht, wird eine Zweischritt-
Decodierverarbeitung unter Heranziehung der eindimensionalen
Schwarzlauf-Codetabelle 2 im Anschluß an die eindimensionale
Schwarzlauf-Codetabelle 1 durchgeführt.
Ein Code "10" wird von der Steuereinheit 1 als Daten
LSHT 10-09 der eindimensionalen Schwarzlauf-Codetabelle 1
geliefert, während ein Code "00" als Daten LSHT 08-07 geliefert
wird. Der Code "01" wird von der Steuereinheit 1
als Daten LSHT 10-09 der eindimensionalen Schwarzlauf-
Codetabelle 2 geliefert. Ein MH-Codeabschnitt eines Codes
im Horizontalmodus, nach der MR- oder M2R-Methode codiert,
wird mittels der eindimensionalen Codetabellen verarbeitet.
Infolgedessen werden Codes eines Durchlaßmodus und eines
Vertikalmodus sowie ein Identifiziercode in einem Horizontalmodus
mittels der zweidimensionalen Codetabelle verarbeitet.
Ein Code "1001" wird von der Steuereinheit 1 als
Daten LSHT 10-07 geliefert.
Die Spezialcode-Erfassungstabelle dient zum Erfassen oder
Detektieren eines EOL- oder EOFB-Codes sowie eines Erweiterungscodes
für den Eintritt in den Nichtverdichtungsmodus.
Für diesen Zweck wird ein 6-Bit-Code abgerufen. Ein Code
"10110" wird von der Steuereinheit 1 als Daten LSHT 10-06
geliefert. Für den Nichtverdichtungsmodus (uncompressed
mode) sind Nichtverdichtungs-Codetabellen 1 und 2 vorgesehen.
Codes "10100" und "10101" werden von der Steuereinheit
1 jeweils als Daten LSHT 10-06 dieser Tabellen geliefert.
Ein Steuercode "10111" wird von der Steuereinheit 1
als Daten LSHT 10-06 für die andere Tabelle geliefert.
Das Ausgabeformat des Decodierer-ROMs 32 ist in Fig. 9A
gezeigt. Der 07-00-Bitabschnitt der Daten DROM 15-00 repräsentiert
die Lauflängendaten eines decodierten Codes.
Der 11-08-Bitabschnitt der Daten DROM 15-00 repräsentiert
die Codelängendaten eines decodierten Codes in Einheiten
von Bits. Der 15-12-Bitabschnitt der Daten DROM 15-00 repräsentiert
die nächsten Zustandsdaten, die für Steuerung
benutzt werden, einschließlich der Daten zur Bezeichnung
der als nächstes heranzuziehenden Tabelle, wodurch eine
Farbe für den nächsten Code bezeichnet wird. Diese Daten
signalisieren oder melden der Steuereinheit 1 die Klassifizierung
des Decodierergebnisses, z. B. daß ein decodierter
Code ein Beendigungscode im Horizontalmodus, ein Ergänzungscode
im Horizontalmodus, der (im) Vertikalmodus, der Nichtverdichtungsmodus,
der Erweiterungscode o. dgl. ist.
Das Ausgabeformat der Daten DROM 07-00 ist in Fig. 9B dargestellt.
Insbesondere zeigen dabei bei einer eindimensionalen
Codierung des Ergänzungscodes 6 Bits der Daten DROM 05-00
eine 64X-Größe an, die durch Dekrementieren einer praktischen
Lauflänge um "1" erhalten wurde. Bei einem Beendigungscode
für eindimensionale Codierung zeigen 6 Bits der Daten
DROM 05-00 eine Bitgröße an, die durch Dekrementieren einer
praktischen Lauflänge um "1" erhalten wurde. In einem zweidimensionalen
Codier-Vertikalmodus geben 4 Bits der Daten
DROM 03-00 den Zustand (state) der Lauflänge an, d. h. eine
durch Subtrahieren von "4" von einer Differenz zwischen
a 1 und b 1 erhaltene Größe. In einem zweidimensionalen
Codier-Durchlaßmodus zeigen 4 Bits der Daten DROM 03-00
"1100" an.
Im Nichtverdichtungsmodus geben weiterhin Daten DROM 02-00
eine Musterlänge an. Wenn daher ein Beendigungscode (000111)
an der rechten Seite von einem durch den Zeiger 36 bezeichneten
Punkt in vom Register 26 erhaltenen Daten eingegeben
wird, werden Daten, die diesen Code als "Beendigungscode
mit einer Weißlauflänge von 1" bezeichnen, in einen
07-00-Bitabschnitt ausgegeben, während Daten, welche den
Code als eine Länge von 6 Bits besitzend angeben, in einem
11-08-Bitabschnitt vom Decodierer-ROM 32 ausgegeben werden, zu
dem ein Zugriff mit 9 Bits hergestellt wird, beginnend mit diesem
Bit-Muster, d. h. "000111xxx" (x = "0" oder "1").
Insbesondere werden die Lauflängendaten "01000000" als
Daten DROM 07-00 und die Codelängendaten "0110" als Daten
DROM 11-08 ausgegeben.
Im folgenden ist anhand von Fig. 6 eine Zustandsübergangssequenz
beschrieben, die aufzeigt, auf welche Weise der
Decodierteil 13 bei der Dehnungsverarbeitung auf die
Tabellen Bezug nimmt.
Bei dieser Ausführungsform decodiert der Decodierteil 13
Codes für eine Zeile unter der Steuerung der Steuereinheit
1. Gemäß Fig. 6 zeigt ein Steuersignal 1 D an, ob eine zu
decodierende Zeile eine nach der MH-Methode codierte Zeile
ist. Das Steuersignal 1 D wird von der Steuereinheit 1 für
jede Zeile geliefert. Wenn das Gerät beispielsweise im
MH-Modus betrieben wird, wird das Steuersignal 1 D für alle
Zeilen zu "1" und in anderen Betriebsarten als dem MH-Modus
zu "0". Andere Übergangsbedingungen werden je nach dem
Ausgangssignal vom Decodierer-ROM 32, d. h. den nächsten
Zustandsdaten, bestimmt.
In Fig. 6 geben die verschiedene Zustände anzeigende
Ellipsen an, auf welche Tabelle unter den verschiedenen,
im Decodierer-ROM 32 gespeicherten Tabellen Bezug genommen
wird. Da die eindimensionale Codierung in weiße und
schwarze Läufe (oder auch Strecken) unterteilt ist, wird
auf verschiedene eindimensionale Codetabellen A und B in
Abhängigkeit von weißen und schwarzen Läufen Bezug genommen.
Bei der beschriebenen Ausführungsform kann der Decodierteil
13 in einem Zyklus einen Code bis zu 9 Bits verarbeiten.
Da in den eindimensionalen Codes solche von 10 Bits oder
mehr vorhanden sind, werden diese in zwei Zyklen verarbeitet.
Zu diesem Zweck werden eindimensionale Codetabellen 1
und 2 aufgestellt oder vorbereitet, wobei die Tabelle 2 in
der eindimensionalen Schwarzlauf-Codetabelle 2 als Codetabellen
der zweiten Stufe der eindimensionalen Codes enthalten
ist. Die eindimensionalen Codetabellen A und B
werden für jede der Stufen 1 und 2 zur Unterscheidung
zweier Läufe, d. h. weißer und schwarzer Läufe, in Horizontalmoduscodes
benutzt.
Die eindimensionalen Codetabellen A und B können für jede
Farbe der Läufe benutzt werden. Wenn die Codetabelle A für
weiße Läufe benutzt wird, wird die Codetabelle B für
schwarze Läufe eingesetzt. Die folgende Beschreibung setzt
voraus, daß die Codetabelle A für weiße Läufe benutzt wird.
Daher entsprechen Tabelle 1A der eindimensionalen Weißlauf-
Codetabelle 1, Tabelle 1B der eindimensionalen Schwarzlauf-
Codetabelle 1 und Tabellen 2A und 2B der eindimensionalen
Schwarzlauf-Codetabelle 2.
Die Spezialcode-Erfassungstabelle ist getrennt für das
Decodieren eines EOL-Codes und von Erweiterungscodes vorgesehen
(von letzteren sind die durch die CCITT-Empfehlung
bezeichneten Codes ein Identifizier- oder Kenncode für
einen Nichtverdichtungsmodus). In den EOL- und Erweiterungscodes
folgen "0"en für oder auf 6 Bits oder mehr.
Im folgenden ist ein Fall beschrieben, in welchem eine
nach der MH-Methode codierte eindimensionale Codiermoduszeile
decodiert wird. Da beim Decodieren einer eindimensionalen
Codiermoduszeile das Steuersignal 1 D gleich "1" ist,
wird zunächst eine eindimensionale Codetabelle 1A zum Decodieren
eines Codes benutzt. Wenn der Code aus 9 Bits
oder weniger besteht, kann das Decodieren nur mittels der
eindimensionalen Codetabelle 1A abgeschlossen werden. Wenn
dagegen der Code aus 10 Bits oder mehr besteht, wird anschließend
die eindimensionale Codetabelle 2A benutzt. Ein
eindimensionaler Weißlauf-Code, auch ein Ergänzungscode
oder ein Beendigungscode, bestehen aus 9 Bits oder weniger,
sofern es sich nicht um einen Ergänzungscode mit einer Lauflänge
von 1792 Bits oder mehr handelt. Wenn daher für einen
weißen Lauf Codes mit maximal 9 Bits, wie bei der beschriebenen
Ausführungsform, in einem Zyklus decodiert
werden, wird nur die eindimensionale Codetabelle 1A benutzt.
Für einen Ergänzungscode mit einer Lauflänge von
1792 Bits oder mehr wird nach einer Bezugnahme auf die
eindimensionale Codetabelle 1A der Decodierer-RAM 32
durch Daten X und Y von der Steuereinheit 1 auf der Grundlage
der Daten DROM 15-12 in einen erstem Zyklus angesteuert,
um auf die eindimensionale Codetabelle 2A Bezug zu nehmen
(to refer to).
In einem eindimensionalen Code folgt stets ein schwarzer
Lauf auf einen weißen Lauf und umgekehrt, sofern es sich
nicht um das Ende einer Zeile handelt. Nach dem Ende der
Zeile wird der weiße Lauf zwangsweise gesetzt. Wenn daher
die Decodierung eines Beendigungscodes unter Verwendung
der eindimensionalen Codetabelle 1A oder 2A abgeschlossen
ist, wird der nächste eindimensionale Code mittels der
eindimensionalen Codetabelle 1B decodiert.
Nahezu alle Schwarzlaufcodes, auch Ergänzungs- und Beendigungscodes,
bestehen aus 9 Bits oder mehr. Wenn daher
in der Praxis ein Schwarzlaufcode decodiert wird, wird auf
die eindimensionale Codetabelle 1B Bezug genommen, worauf
auf die eindimensionale Codetabelle 2B in Abhängigkeit von
Daten X und Y von der Steuereinheit 1 entsprechend der Ausgabe
des Decodierergebnisses Bezug genommen wird. Wenn die
Decodierung eines Beendigungscodes mittels der eindimensionalen
Codetabelle 1B oder 2B abgeschlossen ist, wird die
Farbbezeichnung eines Laufs zur Änderung der Daten X
aktualisiert, worauf die eindimensionale Codetabelle 1A
benutzt wird.
Auf diese Weise werden die eindimensionalen Codetabellen
A und B zur Durchführung der Decodierung für eine Zeile
abwechselnd benutzt. Wenn die Decodierung zum Ende der
Zeile fortschreitet und dabei "Nullen" auf 8 Bits oder mehr
vom Beginn eines Codes in den eindimensionalen Codetabellen
1 und 2 folgen (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 M2R-
Methode codierten Codes beschrieben. In diesem Fall entsprechen
das Steuersignal 1 D einer "0" und das Signal 1 D
einer "1". Der Decodierteil 13 bezieht sich daher zunächst
auf die zweidimensionale Codetabelle. Da unter den zweidimensionalen
Codes die Codes im Vertikal- und im Durchlaßmodus
sowie ein Identifiziercode eines Horizontalmodus
aus 6 Bits oder weniger bestehen, wird dieser in Übereinstimmung
mit der zweidimensionalen Codetabelle verarbeitet,
während der nächste Code ebenfalls in Übereinstimmung mit
der zweidimensionalen Codetabelle nach Maßgabe der Daten
X und Y von der Steuereinheit 1 verarbeitet wird.
Wenn die Identifizierung des Horizontalmoduscodes nach der
zweidimensionalen Codetabelle decodiert wird, wird für den
folgenden Code auf die eindimensionale Codetabelle 1A Bezug
genommen, und zwar auf dieselbe Weise, wie bei dem nach
der MH-Methode codierten Code. Derselbe Tabellenübergang
trifft auch hierfür zu. Zu diesem Zeitpunkt wird auf die
eindimensionale Codetabelle A für die erste Farbe, z. B. für
den weißen Lauf, Bezug genommen. Wenn das Decodieren eines
Beendigungscodes abgeschlossen ist, wird auf die eindimensionale
Codetabelle B Bezug genommen, um einen Schwarzlaufcode
zu decodieren.
Wenn die Decodierung des Beendigungscodes unter Heranziehung
der eindimensionalen Codetabelle 1A oder 2B beendet ist,
wird in Abhängigkeit von den Daten X und Y der Steuereinheit
1 nach Maßgabe der Ausgabe des Decodierergebnisses
wiederum auf die zweidimensionale Codetabelle Bezug genommen.
Wenn "Nullen" für oder auf 6 Bits oder mehr vom Beginn eines
decodierten Codes in einer zweidimensionalen Tabelle und "Nullen"
für oder auf 8 Bits oder mehr in eindimensionalen
Codetabellen folgen, wird die Spezialcode-Erfassungstabelle
benutzt, um einen EOL-Code zu erfassen oder festzustellen
und damit die EOL- oder EOFB-Erfassungsverarbeitung auszuführen.
Im folgenden ist der Nichtverdichtungsmodus (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 dagegen bei der M2R-Methode kein EOL-Code benutzt.
Stattdessen wird ein Code EOFB (Ende des Faksimileblocks)
mit zwei aufeinanderfolgenden EOL-Codes benutzt.
Wenn auf die eindimensionale Codetabelle Bezug genommen
wird, folgen, außer für den EOL-Code und einen Erweiterungscode,
keine "Nullen" für bzw. auf 8 Bits oder mehr, sofern
nicht ein Codierungsfehler auftritt. Zu diesem Zeitpunkt
wird der EOL-Code durch Bezugnahme auf die Spezialcode-
Erfassungstabelle nach Maßgabe der Daten X und Y von der
Steuereinheit 1 erfaßt oder festgestellt.
Bei der MR- oder M2R-Methode folgen keine "Nullen" für oder
auf 6 Bits oder mehr in der zweidimensionalen Codetabelle.
Wenn "Nullen" für bzw. auf 6 Bits oder mehr vom Beginn eines
in der zweidimensionalen Codetabelle decodierten Codes
folgen, wird zur Erfassung des EOL-Codes auf die Spezialcode-
Erfassungstabelle Bezug genommen.
Da bei der M2R-Methode Empfangsdaten zusammen mit Prüfdaten
übermittelt werden, kann kein Übermittlungsfehler auftreten.
Ein solcher Fehler kann dagegen bei der MH- und MR-
Methode auftreten. Wenn festgestellt wird, daß ein decodierter
Code einen Fehler enthält, wird ein Steuersignal 1 S
ausgeführt, und die entsprechende Verarbeitungszeile wird
bis zu ihrem Ende übersprungen. Sodann wird der EOL-Code
durch den EOL-Detektor 81 erfaßt, und wenn er als EOL-Code
bestätigt worden ist, wird die EOL-Erfassungsverarbeitung
ausgeführt.
Genauer gesagt: Beim Auftreten eines Fehlers wird die Decodierung
der betreffenden Verarbeitungszeile bis zur Fehlererfassung
oder -feststellung abgeschlossen, und es
wird die Decodierung der nächsten Verarbeitungszeile eingeleitet.
Dieser EOL-Detektorteil wird auch für die Erfassung
eines ersten, am Anfang einer Seite übermittelten
EOL-Codes benutzt.
Bei der M2R-Methode wird, wie erwähnt, eine Fehlerprüfung
bei der Übertragung von Daten durchgeführt. Wenn ein Fehlercode
festgestellt wird, wird eine Wiederübertragungsanforderung
erzeugt, worauf die richtigen Daten übermittelt
werden. Eine Fehlererfassung kann daher entfallen. Wie erwähnt,
wird bei der M2R-Methode kein EOL-Code benutzt,
vielmehr ist stattdessen ein EOFB-Code am Ende der Codes
für eine Seite vorgesehen.
Wenn der Zustand (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 M2R-Methode,
z. B. nach der MR- oder MH-Methode, codierter Code decodiert
wird, kann erfindungsgemäß die Vorausverarbeitung innerhalb
des Bereichs der Verarbeitung für einen Lauf fortschreiten.
Wenn insbesondere festgestellt wird, daß nach der Bezugnahme
auf die eindimensionale Codetabelle 1 auf die eindimensionale
Codetabelle 2 oder die Spezialcode-Erfassungstabelle Bezug
genommen wird, kann die Verarbeitung für die Bezugnahme auf
die eindimensionale Codetabelle 2 oder die Spezialcode-
Erfassungstabelle beendet werden, bevor die Erzeugungsverarbeitung
für einen unmittelbar vorhergehenden decodierten
Code abgeschlossen ist. Da nämlich diese Methoden EOL-Codes
verwenden, wird auch dann, wenn der Zustand des Decodierverarbeitungsteils 7
für die Vorausverarbeitung geändert
wird, kein Problem aufgeworfen, d. h. die Farbe des Anfangs
der nächsten Zeile wird bestimmt. Das so decodierte Ergebnis
wird zum Erzeugungsverarbeitungsteil 8 ausgegeben.
Im folgenden ist die Arbeitsweise des Erzeugungsverarbeitungsteils
8 für die Verarbeitung von Binärdaten auf der
Grundlage des Decodierergebnisses vom Decodierverarbeitungsteil
7 beschrieben. Das Decodierergebnis, d. h. die Lauflängendaten,
wird dem Erzeugungsverarbeitungsteil 8 eingegeben.
Im folgenden ist ein Fall beschrieben, in welchem
die Lauflängendaten eines eindimensionalen Moduscode zuerst
eingegeben werden.
Es sei angenommen, daß das Decodierergebnis eines Ergänzungscodes
vom Decodierer-ROM 32 dem Wähler 40 eingegeben
wird. In diesem Fall empfängt der Wähler 40 Daten L als
Lauflängendaten von der Steuereinheit 1. Wenn die Ausgabe
bzw. das Ausgangssignal vom Decodierer-ROM 32 entsprechend
einem Steuersignal von der Steuereinheit 1 gewählt wird,
wird das Ausgangssignal dem RL-Zähler 42 eingegeben. Der
RL-Zähler 42 ist ein solcher mit einer 12-Bit-Länge, und
er speichert das Decodierergebnis des Ergänzungscodes vom
Decodierer-ROM 32 in einem 08-03-Bitabschnitt von 6 Bits.
Da die vom Decodierer-ROM 32 ausgegebenen Lauflängendaten
des Ergänzungscodes eine Größe darstellen, die durch Dekrementieren
einer praktischen Lauflänge um "1" erhalten
wurde, wird dem 02-00-Bitabschnitt des RL-Zählers 42
"1" eingegeben, so daß sich "111" ergibt.
Diese Daten werden über den Wähler 44 als Adreßdaten zum
Codierer-ROM 46 ausgegeben, welcher auch Daten mit Daten
für Farbbezeichnung und Daten zur Anzeige der Verdichtungs-
bzw. Dehnungsverarbeitung als Daten N von der Steuereinheit
1 abnimmt. In Abhängigkeit von den dem Codierer-ROM 46
eingegebenen Adreßdaten werden durch diesen ROM 46 8-Bit-
Daten "00000000" oder "11111111" ausgegeben. Die ausgegebenen
Daten werden der Trommelschiebestufe 50 über den
Wähler 48 zugeliefert.
Der Erzeugungsverarbeitungsteil 8 weist eine dem decodierten
Zeiger 36 ähnliche Schaltung auf. Die Trommelschiebestufe 50
nimmt Anzeigedaten vom Bildzeiger 56 ab und dreht die eingegebenen
Daten für die Ausgabe der gedrehten Daten. Da jedoch
alle Bits "0" oder "1" sind, macht es keinen Unterschied,
ob die Daten gedreht werden oder nicht. Da zu diesem
Zeitpunkt die Daten vom Codierer-ROM 46 in Einheiten
von Bytes ausgegeben werden, gibt der ROM 46 keine Daten
zur Addierstufe 52 aus. Dies ist deshalb der Fall, weil
die Anzeigegröße des Bildzeigers 56 nicht geändert zu
werden braucht, da die Erzeugungsverarbeitung in Einheiten
von Bytes erfolgt.
Das Ausgangssignal von der Trommelschiebestufe 50 wird dem
Wähler 60 und dem 15-08-Bitabschnitt des Registers 62
zugeführt. Der Wähler 60 empfängt über den Wähler 64 Daten
RODT 07-00 oder RODT 15-08. In diesem Fall entsprechen die
zu erzeugenden Lauflängendaten einem Ergänzungscode, und
die Daten RODT 15-08 werden im Wähler 64 während der Verarbeitung
des Codes gewählt. Außerdem nimmt der Wähler 60
vom Bildzeiger 56 dieselben Anzeigedaten wie die Trommelschiebestufe
50 ab.
Der Wähler 60 wählt Daten vom Wähler 64 ab der LSB-Position
zu einer um "1" kleineren Bitposition aus den Anzeigedaten
vom Bildzeiger 56 und wählt das Ausgangssignal von der
Trommelschiebestufe 50 von bzw. aus den Anzeigedaten zur
MSB-Position, um damit die gewählten Daten als Daten
RODT 07-00 des Registers 62 auszugeben.
Wenn beispielsweise die Anzeigedaten des Zeigers gleich "3"
sind, werden die Daten vom Wähler 64 als Daten RODT 02-00
und die Daten von der Trommelschiebestufe 50 als Daten
RODT 07-03 gewählt. Da bei der obigen Operation ein Bilddatenmuster
für ein Byte erzeugt wird, werden die Daten
RODT 07-00 des Registers 62 auf einer Ausgabedatenschiene
über einen dem Inverter 24 ähnlichen Inverter 66 ausgegeben
und als Daten P zum Bezugszeilendaten-Speicherteil 4
geliefert, um in diesem an einer Adresse entsprechend der
augenblicklichen Größe (dem Zählstand) des Adreßzählers 88
gespeichert zu werden. Daraufhin ist ein erster Schritt
der Erzeugungsverarbeitung abgeschlossen, wobei dieser
Zustand durch die Steuereinheit 1 festgestellt wird.
Nach Abschluß der Verarbeitung für ein Byte wird ein Takt
als Dateneinheit Q an den Adreßzähler 82 angelegt, um
diesen um "1" zu inkrementieren bzw. hochzählen zu lassen.
Zu diesem Zeitpunkt wird im Fall eines nach der M2R-
Methode codierten Codes die Größe bzw. der Zählstand des
Zählers 82 mit der Größe bzw. dem Inhalt des Stopadreßregisters
80 verglichen und damit geprüft, ob die Verarbeitung
bis zum Ende der Zeile fortgeschritten ist. Im
Fall eines nach der MR- oder MH-Methode codierten Codes
ergibt sich dabei kein Problem, weil der EOL-Code benutzt
wird.
Die im Register 96 enthaltenen Daten werden um ein Byte
in LSB-Richtung verschoben. Neue Bezugszeilendaten werden
unter Heranziehung der Summe aus dem Zählstand des Adreßzählers
82 und den Daten R als Adresse aus dem Speicherteil
4 ausgelesen und als Daten REF 15-08 im Register 96
verriegelt. Zu diesem Zeitpunkt ist oder wird ein Inhalt
des a 0-Zeigers nicht verändert. Daten M vom RL-Zähler 42
werden zur Steuereinheit 1 ausgegeben. Letztere prüft auf
der Grundlage der Daten M vom RL-Zähler 42, ob die Erzeugungsverarbeitung
des eingegebenen Ergänzungscodes abgeschlossen
ist.
Ist dies nicht der Fall, so wird der Inhalt des RL-Zählers
42 um "1" dekrementiert bzw. herabgezählt und dann über
den Wähler 44 zum Codierer-ROM 46 geliefert. Die Erzeugungsverarbeitung
wird auf die vorstehend beschriebene
Weise wiederholt, bis die Daten M vom RL-Zähler 42 den
Daten "0" gleich sind. Wenn die Daten M den Daten "0"
gleich sind, stellt die Erzeugungsverarbeitung für den
entsprechenden Ergänzungscode einen letzten Schritt dar,
woraufhin der Beendigungscode verarbeitet wird.
Wenn der Wähler 40 die Daten L wählt, wird ebenfalls dieselbe
Verarbeitung wie für den Ergänzungscode durchgeführt.
Wenn ein Lauf oder Durchlauf derselben Farbe für eine
Länge von 2561 oder mehr andauert, wird ein die Lauflänge
2560 repräsentierender Code entsprechend der Lauflänge wiederholt.
Die Wiederholungszahl und die die Lauflänge (2560-64)
anzeigenden Daten werden als Daten L im RL-Zähler 42 gesetzt.
Wenn die Erzeugungsverarbeitung für die Lauflänge
2560 abgeschlossen ist, wird die Wiederholungszahl um "1"
dekrementiert, worauf die Erzeugungsverarbeitung wieder
ausgeführt wird. Dabei wird die gesamte Erzeugungsverarbeitung
wiederholt, bis die Daten M gleich "0" sind.
Nachstehend ist ein Fall beschrieben, in welchem das Decodierergebnis
eines Beendigungscodes verarbeitet wird.
Das Decodierergebnis oder die Lauflängendaten wird bzw.
werden als Daten I über den Wähler 40 dem 05-00-Abschnitt
des RL-Zählers 42 eingegeben. Der 05-03-Abschnitt des RL-
Zählers 42 wird in Einheiten von Bytes auf dieselbe Weise
wie der Ergänzungscode verarbeitet.
Der Inhalt des 05-03-Bitabschnitts wird jedesmal dann um "1"
dekrementiert, wenn die Erzeugungsverarbeitung eines Bytes
der Bilddaten abgeschlossen ist. Nach Beendigung der Verarbeitung
der Bytedaten wird eine Dateneinheit 02-00, die
kleiner ist als ein Byte, verarbeitet.
Die Dateneinheit 02-00 wird dem Wähler 44 eingegeben und
durch diesen für die Eingabe in den Codierer-ROM 46 auf
dieselbe Weise wie beim Ergänzungscode gewählt. Das durch
den ROM 46 erzeugte Bilddatenmuster wird durch die Trommelschiebestufe
50 verschoben und dann zu einem Datenabschnitt
RODT 15-08 des Registers 62 und zum Wähler 60 ausgegeben.
Anschließend wird das Bilddatenmuster durch den Wähler 60
mit den vorher verarbeiteten Daten RODT 15-08 nach Maßgabe
der Anzeigedaten vom Bildzeiger 56 zusammengesetzt, und
die zusammengesetzten Daten werden dem Datenabschnitt
RODT 07-00 des Registers 62 eingegeben. Dabei werden Daten
entsprechend der Länge der Ausgabebildmusterdaten vom
Codierer-ROM 46 zur Addierstufe 52 als Daten EROM 07-05 ausgegeben.
Als Ergebnis wird die Größe des Bildzeigers 56
aktualisiert. Wenn dabei 23 Bits im Ausgangssignal der
Addierstufe 52 zu "1" werden, wird dies der Steuereinheit 1
in Form von Daten 0 gemeldet, um sie zu informieren, daß
die Verarbeitung für ein Byte abgeschlossen ist. Wenn die
Dateneinheit 0 ausgegeben wird, gibt das Register 62 Daten
RODT 07-00 auf einer Datenschiene über den Inverter 66 in
Abhängigkeit von einem Steuersignal von der Steuereinheit 1
aus, und es speichert diese Daten im Speicherteil 4 als
Daten P. Wenn 23 Bits nicht gleich "1" sind, werden die
Daten RODT 07-00 bis zur Erzeugung des nächsten Bilddatenmusters
gehalten bzw. gespeichert.
Wenn das nächste Bilddatenmuster dem Wähler 60 eingegeben
wird, werden die Daten RODT 07-00 des Registers 62 über den
Wähler 64 dem Wähler 60 zugeführt. Auf diese Weise wird
dieselbe Operation wiederholt.
Wenn ein Beendigungscode von weniger als einem Byte verarbeitet
werden soll, wird im wesentlichen dieselbe Verarbeitung
wie für die Daten von weniger als ein Byte durchgeführt,
mit dem Unterschied, daß das Decodierergebnis unmittelbar
dem Wähler 44 zugeführt und nicht durch den
RL-Zähler 42 übertragen wird. Die oben beschriebene
Operation kann für einen MH-Codeabschnitt oder -teil eines
nach der MH-Methode codierten Horizontalmoduscodes oder
die nach den MR- und M2R-Methoden codierten Codes durchgeführt
werden.
Nachstehend ist die Erzeugungsverarbeitung für einen Code
im Durchlaßmodus (pass mode) und Vertikalmodus als zweidimensionaler
Codiermodus beschrieben. Wenn auf den Bezugszeilendaten
im Register 96 eine Farbänderungsbitposition
b 1 nicht festgestellt wird, wird diese Information
zur Steuereinheit 1 als Dateneinheit A 2 übertragen,
wobei ein Byte des Bilddatenmusters vom Codierer-ROM 46
nach Maßgabe der Daten N von der Steuereinheit 1 erzeugt
wird. Diese Erzeugungsverarbeitung des Bilddatenmusters
erfolgt auf dieselbe Weise wie beim Ergänzungscode eines
Horizontalmodus. Die Anzeigedaten des Bildzeigers 54
bleiben unverändert.
Wenn b 1 durch den b 1-Detektor 102 des a 1 b 1-Detektors 16
festgestellt oder erfaßt wird, wird b 1 zum Wähler 108 geliefert.
Da die Größe b 1, wie aus dem Register 96 ersichtlich
ist, ab einer -4-Bitposition gezählt wird, wird zu
ihr "+4" hinzuaddiert. Die Lauflängendateneinheit im
Durchlaßmodus oder Vertikalmodus wird im RL-Zähler 42
verriegelt, und die Bilddaten werden auf die vorher beschriebene
Weise erzeugt. Die Lauflängendaten werden als
Dateneinheit B zum Wähler 110 ausgegeben. Diese, den Wählern
108 und 110 eingegebenen Daten werden in die Addierstufe 112
eingegeben und darin addiert. Wenn die addierten Daten 8
oder mehr betragen, werden die unteren 3-Bitdaten gewählt.
Die unteren 3-Bitdaten der addierten Daten werden zum
Wähler 54 als Dateneinheit C ausgegeben, nachdem die Erzeugungsverarbeitung
des entsprechenden Bilddatenmusters
abgeschlossen ist. Die unteren 3-Bitdaten werden auch zum
a 0-Zeiger 100 ausgegeben.
Nachstehend ist ein Fall beschrieben, in welchem ein Nichtverdichtungsmoduscode
eingegeben wird. Dieser Code wird
als Dateneinheit G über das Register 58 dem Wähler 48 eingegeben
oder eingespeist. Die folgende Verarbeitung erfolgt
auf dieselbe Weise, wie oben beschrieben. Die Lauflängendaten
dieses Codes werden zum RL-Zähler 42 ausgegeben
und auf dieselbe Weise wie die Vertikal- und Durchlaßmoduscodes
verarbeitet.
Im folgenden ist anhand von Fig. 7 die Verdichtungsverarbeitung
beschrieben.
Zunächst ist die Verdichtungsverarbeitung für einen MH-Code
erläutert. Bildmusterdaten werden von einer Eingabedatenschiene
dem Verriegelungsglied 22 eingegeben und darin
verriegelt. Die eingegebenen Bilddaten werden dem Register
26 über den Inverter 24 eingespeist. Zu diesem Zeitpunkt
werden Registerdaten RDTI 07-00 zum Bezugszeilen-Speicherteil
4 als Bezugszeilendaten für die nächste Verarbeitungszeile
ausgegeben und in diesem Speicherteil entsprechend
den Daten vom Adreßregister 88 gespeichert. Ebenso werden
im Datenteil oder -abschnitt RDTI 07-00 gehaltene Bilddaten
zum a 1-Detektor 104 ausgegeben, und es werden Daten
320(2560 ÷ 8) im RL-Zähler 42 vorgegeben. Der durch den
a 1-Detektor 104 erfaßte a 1-Punkt wird als Dateneinheit D
über den Wähler 114 zum Wähler 38 ausgegeben.
Danach werden durch die Trichterschiebestufe 30 9 Bits nach
Maßgabe der Anzeigedaten des Decodierzeigers 36 auf dieselbe
Weise wie bei der Dehungsverarbeitung gewählt und
zum Wähler 31 ausgegeben. Der Ausgang von der Trichterschiebestufe
30 wird durch den Wähler 31 gewählt und zum
Decodierer-ROM 32 ausgegeben. Wenn ein Lauf oder Durchlauf
mit derselben Farbe für mehr als eine Byte-Länge andauert,
wird "1000", d. h. eine eine Länge eines Bytes anzeigende
Dateneinheit, vom Decodierer-ROM 32 als Daten DROM 11-08
zur Addierstufe 34 ausgegeben, worauf als Ergebnis eine
Dateneinheit J zur Steuereinheit 1 ausgegeben wird.
Die Größe des Decodierzeigers 36 wird nicht aktualisiert.
Die Steuereinheit 1 gibt eine Dateneinheit Q zum Adreßzähler
82 auf dieselbe Weise wie bei der Dehnungsverarbeitung
aus, um Adreßdaten zu aktualisieren. Außerdem wird
der Inhalt des RL-Zählers 42 herabgezählt. Gleichzeitig
wird auf dieselbe Weise wie bei der Dehnungsverarbeitung
der Inhalt des Registers 96 um ein Byte nach links verschoben.
Neue Bezugzeilendaten werden aus dem Speicherteil
4 ausgelesen, zum Register 96 ausgegeben und als (Daten)
REF 15-08 verriegelt. Die Größe des Zeigers 100 wird nicht
verändert.
Im eindimensionalen Modus, in welchem dieselbe Farbe vom
Anfang eines Laufs fortlaufend vorliegt, wird von der
Steuereinheit 1 nach Maßgabe von Daten DROM 15-12 vom Decodierer-
ROM 32 ein Zählimpuls dem RL-Zähler 42 eingegeben,
sobald eine Verarbeitung für eine Einheit abgeschlossen
ist, um damit den RL-Zähler 42, wie bei
in Fig. 7 gezeigt, herabzuzählen. Wenn durch den a 1-Detektor
104 ein Farbänderungspunkt a 1 festgestellt wird, d. h. wenn
der Inhalt der Daten LSHT 08-00 nicht "00000000x" oder
"11111111x" beträgt, wird das Zählergebnis bzw. der Zählstand
des RL-Zählers 42 über den Wähler 42 dem Codierer-ROM
46 zugeführt. Die Dateneinheit N wird ebenfalls dem Decodierer-
ROM 46 zugeliefert, um damit einen Ergänzungscode (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 RODT 15-08 des
Registers 62 und auch dem Wähler 60 zugeführt. Im Wähler 60
wird der gedrehte Code auf dieselbe Weise wie bei der
Dehnungsverarbeitung mit einem Ausgangssignal oder einer
Ausgabe des Wählers 64 kombiniert, und zwar in Abhängigkeit
von den Anzeigedaten des Bildzeigers 56. Gleichzeitig
wird die Länge des erzeugten Ergänzungscodes vom Codierer-
ROM 46 zur Addierstufe 52 als Daten EROM 07-05 ausgegeben,
um diese zu den Anzeigedaten zu addieren. Die Summe stellt
wiederum die Anzeigedaten des Zeigers 56 dar. Wenn die
Dateneinheit O zur Steuereinheit 1 ausgegeben wird, werden
Daten RODT 07-00 auf eine Ausgabedatenschiene ausgegeben.
Wenn die Länge des zu erzeugenden Ergänzungscodes 6 bis 10
Bits beträgt, wird ein restlicher Teil des Ergänzungscodes
vom Codierer-ROM 46 geliefert und auf dieselbe Weise, wie
vorstehend beschrieben, verarbeitet. Dabei werden Daten
RODT 15-08 im Wähler 64 gewählt. Nach Beendigung der Erzeugungsverarbeitung
des Ergänzungscodes wird der 11-03-
Bitabschnitt des RL-Zählers 42 freigemacht, und der 02-00-
Bitabschnitt wird zum 05-03-Bitabschnitt verschoben,
während die restlichen Daten 12097 00070 552 001000280000000200012000285911198600040 0002003711200 00004 11978, 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 M2R-Methode codierten Horizontalmoduscodes
werden auf dieselbe Weise wie bei der Verdichtungsverarbeitung
des MH-Codes verarbeitet, nur mit dem Unterschied,
daß der Identifiziercode des Horizontalmodus vor
dem ersten Ergänzungscode nach Maßgabe der Dateneinheit N
von der Steuereinheit 1 hinzuaddiert wird.
Die Verdichtungsverarbeitung von zweidimensionalen Codes
im Vertikal- und Durchlaßmodus ist nachstehend beschrieben.
Wenn in den Daten RDTI 07-00 als Dateneinheit F a 1 nicht
festgestellt wird und auch b 1 in den Daten REF-3-10 vom
Register 96 nicht festgestellt wird, wird eine Sprungverarbeitung
ausgeführt. Dabei werden beispielsweise ein Byte
eines neuen Bilddatenmusters über die Eingabedatenschiene
eingegeben und die Bezugszeilendaten im Register 96 aktualisiert.
Wenn sowohl a 1 als auch b 1 festgestellt oder erfaßt
werden, wird die Verdichtungsverarbeitung von zweidimensionalen
Codes eingeleitet.
Die erfaßten Größen oder Einheiten a 1 und b 1 werden der
Subtrahierstufe 120 zugeführt, deren Ausgangssignal als
Dateneinheit A über den Wähler 44 zum Codierer-ROM 46
ausgegeben wird. Im Codierer-ROM 46 wird der Durchlaßmoduscode
oder der Vertikalmoduscode erzeugt, der dann
in der Trommelschiebestufe 50, im Wähler 60, im Bildzeiger
56 usw. auf dieselbe Weise wie der Horizontalmoduscode
verarbeitet wird. Zu diesem Zeitpunkt wird im Wähler 114
b 1 gewählt und dem a 0-Zeiger 100 sowie dem Decodierzeiger
36 über den Wähler 38 als Dateneinheit D zugeliefert. Die folgende
Verarbeitung entspricht derjenigen bei der Dehnungsverarbeitung.
Im Nichtverdichtungsmodus werden Daten vom Register 58
unmittelbar 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 M2R-Methode codierten Codes ist im folgenden im Zusammenhang
mit der Arbeitsweise des Erzeugungsverarbeitungsteils
8 anhand der Fig. 10A bis 10F beschrieben.
Im i-ten Schritt beginnt der Decodierverarbeitungsteil 7
eine Decodieroperation eines n-ten Laufs, doch wartet
er ab, während er die Operation unvollendet läßt.
Obgleich die 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 M2R-Methode nach dem Ergebnis
vom Erzeugungsverarbeitungsteil 8 diskriminiert oder
entschieden wird, ob die Decodierung bis zum Ende einer
Zeile vollständig ausgeführt ist, führt der Decodierverarbeitungsteil
7 die Vorausverarbeitung für den nächsten
Code nicht vollständig durch, sondern unterbricht die Verarbeitung
unmittelbar vor der Änderung des Zustands. Wenn
der Zustand des Decodierverarbeitungsteils 7 für die Vorausverarbeitung
geändert wird, um z. B. einen Bit-Zeiger weiterzuschalten,
kann eine Einrichtung zum Zurückstellen oder
Zurückführen desselben erforderlich sein.
Wenn die Verarbeitung im Erzeugungsverarbeitungsteil 8
abgeschlossen ist und eine Position auf der entsprechenden
Verarbeitungszeile des Laufs festgestellt wird, wird geprüft,
ob diese Position mit der äußersten rechten Position
einer Zeile koinzidiert. Wenn keine Koinzidenz festgestellt
wird, führt der Decodierverarbeitungsteil 7, weil die normale
Decodierung ausgeführt werden kann, die Decodierverarbeitung
vollständig durch, und er sendet das Decodierergebnis
zum Erzeugungsverarbeitungsteil 8 und startet die Verarbeitung
des nächsten Laufs oder Durchlaufs.
Der Erzeugungsverarbeitungsteil 8 beginnt die Bildmustererzeugung
auf der Grundlage der vom Decodierverarbeitungsteil
7 übermittelten Lauflängendaten. Wenn eine Position
auf der entsprechenden Verarbeitungszeile des Laufs mit
dem Ende der Zeile koinzidiert, nachdem der Erzeugungsverarbeitungsteil
8 die Verarbeitung für die Fertigstellung
der augenblicklichen Verarbeitungszeile ausführt, erfolgt
durch die Steuereinheit 1 eine Vorbereitung für die nächste
Verarbeitungszeile, z. B. ein Umschalten der Speicherbereiche
des Speicherteils 4 zum Halten oder Aufnehmen von Bezugszeilenbilddaten.
In diesem Fall meldet der Erzeugungsverarbeitungsteil
8 das Ende der Zeile zum Decodierverarbeitungsteil
7 über die Steuereinheit 1.
Da der Anfang der Zeile, wie oben beschrieben, als weißes
Lauf- bzw. Vorsatzstück festgestellt wird, bewirkt der
Decodierverarbeitungsteil 7 unter Verwendung der Information
vom Erzeugungsverarbeitungsteil 8 die Wiederdecodierung
des betreffenden Codes zu "Weiß". Da zu diesem Zeitpunkt
der Decodierverarbeitungsteil 7 die Vorausverarbeitung unter
Zustandsänderung noch nicht beendet hat, kann er ein neues
Decodierergebnis nur durch Änderung der Farbbezeichnung
ableiten. Wenn ein Objekt der Vorausverarbeitung ein Code
von 10 Bits oder mehr ist, der eine Zweischrittverarbeitung
erfordert, wartet der Decodierverarbeitungsteil 7 die Information
oder Anweisung vom Erzeugungsverarbeitungsteil 8
ab, ohne den ersten Schritt vollständig auszuführen.
Der Decodierverarbeitungsteil 7 vermag einen Code aus 9 Bits
oder weniger in einem Schritt zu decodieren, und nahezu
alle eingegebenen Codes bestehen normalerweise aus 9 Bits
oder weniger. Selbst wenn daher die Vorausverarbeitung
unterbrochen wird, ohne daß der Decodierverarbeitungsteil 7
veranlaßt wird, seinen Zustand zu ändern, kann der Decodierverarbeitungsteil
7 unmittelbar das Decodierergebnis des
nächsten Laufs (oder Zeilendurchlaufs) ableiten, nachdem
der Erzeugungsverarbeitungsteil 8 die Erzeugungsverarbeitung
für den augenblicklichen Lauf abgeschlossen hat. Außerdem
kann der Erzeugungsverarbeitungsteil 8 die Verarbeitung
des betreffenden Laufs ohne Wartezeit einleiten.
Die Beziehung zwischen den Operationen des Decodierverarbeitungsteils
7 und des Erzeugungsverarbeitungsteils 8 ist
im folgenden anhand der Fig. 10A bis 10C im einzelnen erläutert.
Im i-ten Schritt beginnt der Decodierverarbeitungsteil
7 mit der Decodieroperation eines n-ten Laufs oder
Zeilendurchlaufs, doch hält er vor vollständiger Ausführung
dieser Operation an. Es sei angenommen, daß der Erzeugungsverarbeitungsteil
8 die Erzeugungsverarbeitung eines (n-1)ten
Laufs durchführt und diese Verarbeitung in einem Schritt
vollständig ausführt. Dabei führt der Decodierverarbeitungsteil
7 die Decodierung des n-ten Laufs vollständig durch
und liefert damit das Decodierergebnis für den n-ten Lauf.
Genauer gesagt: Nach vollständiger Beendigung der Erzeugungsverarbeitung
eines Bilddatenmusters im Erzeugungsverarbeitungsteil
8 ist in diesem Schritt auch die Verarbeitung
durch den Decodierverarbeitungsteil 7 vollständig abgeschlossen.
Danach beginnt in einem (+1)ten Schritt der
Decodierverarbeitungsteil 7 die Decodierung eines Codes in
einem (n + 1)ten Lauf, und er hält in einem Zustand unmittelbar
vor vollständiger Durchführung der Decodierung an. Wenn
der durch den Decodierverarbeitungsteil 7 decodierte n-te
Lauf aus einem 3-Byte-Bilddatenmuster besteht, kann der
Erzeugungsverarbeitungsteil 8 den n-ten Lauf nicht in
einem Schritt verarbeiten. Der Decodierverarbeitungsteil 7
behält dabei den augenblicklichen Zustand auch nach dem
(i + 2)ten Schritt bei.
Wenn der Erzeugungsverarbeitungsteil 8 die Verarbeitung
für den n-ten Lauf 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.
Claims (18)
1. Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät,
welches Codedaten nach einer Pipeline-Methode (in a
pipeline manner) zu decodieren vermag, gekennzeichnet
durch
eine Halteeinheit (26) zum Empfangen von Codedaten einer ersten vorbestimmten Länge und zum Halten (oder Zwischenspeichern) der letzten Codedaten(einheit) für eine zweite vorbestimmte Länge,
eine Blockausgabeeinrichtung (30, 31) zum Empfangen der in der Halteeinheit (26) gehaltenen Codedaten zum Erzeugen eines Codedatenblocks aus Eingabesteuerdaten und einem nach Maßgabe von eingegebenen Bitpositionsdaten gewählten Codedatenabschnitt sowie zum Ausgeben des erzeugten Codedatenblocks nach Maßgabe eines (einer) Ausgabebefehls oder -anweisung,
eine Decodiereinheit (32) zum Erzeugen von eine Länge einer Codeeinheit angebenden Daten und (Durch-)Lauflängendaten entsprechend der Codeeinheit, beginnend von einem vorlaufenden Bit des Codedatenblocks nach Maßgabe einer Eingabe des Codedatenblocks, und
eine Bitpositionsbezeichnungseinrichtung (34, 36) zum Ausgeben der gehaltenen Bitpositionsdaten zur Blockausgabeeinrichtung (30, 31) sowie zum Aktualisieren der Bitpositionsdaten nach Maßgabe der Codeeinheitslängendaten von der Decodiereinheit (32).
eine Halteeinheit (26) zum Empfangen von Codedaten einer ersten vorbestimmten Länge und zum Halten (oder Zwischenspeichern) der letzten Codedaten(einheit) für eine zweite vorbestimmte Länge,
eine Blockausgabeeinrichtung (30, 31) zum Empfangen der in der Halteeinheit (26) gehaltenen Codedaten zum Erzeugen eines Codedatenblocks aus Eingabesteuerdaten und einem nach Maßgabe von eingegebenen Bitpositionsdaten gewählten Codedatenabschnitt sowie zum Ausgeben des erzeugten Codedatenblocks nach Maßgabe eines (einer) Ausgabebefehls oder -anweisung,
eine Decodiereinheit (32) zum Erzeugen von eine Länge einer Codeeinheit angebenden Daten und (Durch-)Lauflängendaten entsprechend der Codeeinheit, beginnend von einem vorlaufenden Bit des Codedatenblocks nach Maßgabe einer Eingabe des Codedatenblocks, und
eine Bitpositionsbezeichnungseinrichtung (34, 36) zum Ausgeben der gehaltenen Bitpositionsdaten zur Blockausgabeeinrichtung (30, 31) sowie zum Aktualisieren der Bitpositionsdaten nach Maßgabe der Codeeinheitslängendaten von der Decodiereinheit (32).
2. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die
Bitpositionsbezeichnungseinrichtung (34, 36) folgendes
umfaßt:
eine Bitpositionsdatenhalteeinheit (36) zum Halten der eingegebenen Bitpositionsdaten und
eine Addiereinheit (36) zum Addieren der Bitpositionsdaten von der Bitpositionsdatenhalteeinheit (36) und der Codeeinheitslängendaten von der Decodiereinheit (32) und zum Ausgeben eines Teils des Additionsergebnisses, als Bitpositionsdaten, zur Bitpositionsdatenhalteeinheit (36).
eine Bitpositionsdatenhalteeinheit (36) zum Halten der eingegebenen Bitpositionsdaten und
eine Addiereinheit (36) zum Addieren der Bitpositionsdaten von der Bitpositionsdatenhalteeinheit (36) und der Codeeinheitslängendaten von der Decodiereinheit (32) und zum Ausgeben eines Teils des Additionsergebnisses, als Bitpositionsdaten, zur Bitpositionsdatenhalteeinheit (36).
3. Gerät nach Anspruch 2, dadurch gekennzeichnet, daß die
Bitpositionsbezeichnungseinrichtung (34, 36) weiterhin
eine Einheit (34) zum Ausgeben eines Ergebnisses einer
Subtraktion von die erste vorbestimmte Länge angebenden
Daten vom Additionsergebnis als Bitpositionsdaten, wenn
das Additionsergebnis den Daten der ersten vorbestimmten
Länge oder mehr entspricht, und zum Ausgeben des
Additionsergebnisses als Bitpositionsdaten, wenn das
Additionsergebnis kleiner ist als die Daten der ersten
vorbestimmten Länge, sowie die Halteeinheit (26) zum
Empfangen der nächsten Codedaten der ersten vorbestimmten
Länge, wenn das Additionsergebnis von der Addiereinheit
(36) mindestens den Daten der ersten vorbestimmten Länge
entspricht, umfaßt.
4. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die
Ausgabeanweisung eingegeben wird, wenn eine Bilderzeugungsverarbeitung
für einen unmittelbar vor dem Code
entsprechend der augenblicklichen oder aktuellen (current)
Codeeinheit decodierten Code abgeschlossen ist.
5. Gerät nach Anspruch 4, dadurch gekennzeichnet, daß die
nach der M2R-Methode codierte Codeeinheit als nächstes
durch die Decodiereinheit (32) decodiert wird, wobei
die Decodiereinheit (32) eine Einheit (32) zum Ausgeben
von Zustandsinformationen zum Decodieren der nächsten
Codeeinheit aufweist, und daß das Gerät ferner umfaßt:
eine Zeilenendedetektoreinheit (11) zum Erfassen, daß die Decodierverarbeitung zu einem Zeilenende fortschreitet, und
eine Steuereinheit (1) zum Ausgeben der Steuerdaten zur Blockausgabeeinrichtung (30, 31) nach Maßgabe der Zustandsinformation, wobei die Steuerdaten so ausgegeben werden, daß die augenblickliche Codeeinheit als weiße Farbe decodiert wird, wenn festgestellt oder erfaßt wird, daß die Dekodierverarbeitung zum Zeilenende fortschreitet, und daß ferner die Ausgabeanweisung der Blockausgabeeinrichtung (30, 31) nach der Ausgabe der Steuerdaten als weiße Farbe eingegeben wird, wenn festgestellt wird, daß die Decodierverarbeitung zum Zeilenende fortschreitet.
eine Zeilenendedetektoreinheit (11) zum Erfassen, daß die Decodierverarbeitung zu einem Zeilenende fortschreitet, und
eine Steuereinheit (1) zum Ausgeben der Steuerdaten zur Blockausgabeeinrichtung (30, 31) nach Maßgabe der Zustandsinformation, wobei die Steuerdaten so ausgegeben werden, daß die augenblickliche Codeeinheit als weiße Farbe decodiert wird, wenn festgestellt oder erfaßt wird, daß die Dekodierverarbeitung zum Zeilenende fortschreitet, und daß ferner die Ausgabeanweisung der Blockausgabeeinrichtung (30, 31) nach der Ausgabe der Steuerdaten als weiße Farbe eingegeben wird, wenn festgestellt wird, daß die Decodierverarbeitung zum Zeilenende fortschreitet.
6. Gerät nach Anspruch 5, dadurch gekennzeichnet, daß die
Ausgabeanweisung der Blockausgabeeinrichtung (30, 31)
im Anschluß an die Decodierung eines ersten Zeilenende-
bzw. EOL-Codes eingegeben wird.
7. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die
Codeeinheit ein Ergänzungscode (make-up code), ein Beendigungscode
(terminating code), ein Identifiziercode
eines Horizontalmodus, ein Vertikalmoduscode, ein Durchlaufmoduscode
(pass mode code) oder der EOL-Code ist
und die Decodiereinheit (32) eine eindimensionale Codetabelle
zum Decodieren des Ergänzungscodes und des Beendigungscodes
sowie eine zweidimensionale Codetabelle
zum Decodieren des Identifiziercodes des Horizontalmodus,
des Vertikalmoduscodes, des Durchlaufmoduscodes
und des EOL-Codes enthält.
8. Gerät nach Anspruch 1, dadurch gekennzeichnet, daß die
Codeeinheit jeweils einer von mehreren Teilabschnitten
des Ergänzungscodes, einer von mehreren Teilabschnitten
des Beendigungscodes, der Identifiziercode des Horizontalmodus,
der Vertikalmoduscode, der Durchlaßmoduscode und
einer von mehreren Teilabschnitten des EOL-Codes ist.
9. Gerät nach Anspruch 8, dadurch gekennzeichnet, daß der
Ergänzungscode, der Beendigungscode und der EOL-Code in
zwei Abschnitte unterteilt sind, die Decodiereinheit (32)
eine eindimensionale Codetabelle 1 zum Decodieren erster
Abschnitte des Ergänzungscodes und des Beendigungscodes,
eine eindimensionale Codetabelle 2 für das Decodieren
zweiter Abschnitte des Ergänzungscodes und des Beendigungscodes,
eine zweidimensionale Codetabelle für das
Decodieren des Identifiziercodes des Horizontalmodus,
des Vertikalmoduscodes und des Durchlaßmoduscodes sowie
eine Spezialcodetabelle für das Decodieren des EOL-Codes
enthält, und
die Ausgabeanweisung der Blockausgabeeinrichtung (30, 31) eingegeben wird, wenn die Bilderzeugungsverarbeitung für den unmittelbar vorhergehenden Codes des Codes entsprechend der augenblicklichen Codeeinheit beendet oder abgeschlossen ist, und anschließend der Blockausgabeeinrichtung (30, 31) eingegeben wird, wenn die decodierte Codeeinheit einer der ersten Abschnitte des Ergänzungscodes, der Beendigungscode bzw. der EOL-Code ist.
die Ausgabeanweisung der Blockausgabeeinrichtung (30, 31) eingegeben wird, wenn die Bilderzeugungsverarbeitung für den unmittelbar vorhergehenden Codes des Codes entsprechend der augenblicklichen Codeeinheit beendet oder abgeschlossen ist, und anschließend der Blockausgabeeinrichtung (30, 31) eingegeben wird, wenn die decodierte Codeeinheit einer der ersten Abschnitte des Ergänzungscodes, der Beendigungscode bzw. der EOL-Code ist.
10. Gerät nach Anspruch 9, dadurch gekennzeichnet, daß die
Decodiereinheit weiterhin eine Nichtverdichtungscodetabelle
(uncompressed code table) zum Decodieren eines
nicht verdichteten Codes und zum Erzeugen der Lauflängendaten
als Codeeinheitslängendaten enthält, wobei ein
Identifiziercode des verdichteten Codes mittels (by)
der Spezialcodetabelle decodiert wird, und
ferner eine Registereinheit (58) zum Halten des nicht verdichteten Codes vorgesehen ist und
die Blockausgabeeinrichtung (30, 31) Mittel zum Ausgeben des nicht verdichteten Codes zur Registereinheit (58) aufweist.
ferner eine Registereinheit (58) zum Halten des nicht verdichteten Codes vorgesehen ist und
die Blockausgabeeinrichtung (30, 31) Mittel zum Ausgeben des nicht verdichteten Codes zur Registereinheit (58) aufweist.
11. Binärdatenverdichtungs- und -dehnungs-Verarbeitungsgerät,
welches Codedaten parallel zu decodieren vermag, gekennzeichnet
durch
eine Adressiereinheit (31) zum Erzeugen von Adreßdaten aus Eingabesteuerdaten und Eingabecodedaten, enthaltend eine Codeeinheit, als Einheiten von zu decodierenden Codes,
eine Decodiereinheit (32) mit einer Anzahl von Codetabellen zum Decodieren von Codeeinheiten, zwecks Ausgabe von nächsten Zustandsdaten (next state date), die eine Tabelle angeben, auf die zum Decodieren der nächsten Codeeinheit und Lauflängendaten der decodierten Codeeinheit Bezug genommen werden soll, und eine Steuereinheit (1) zum Ausgeben der Steuerdaten zum Decodieren der augenblicklichen oder aktuellen Codeeinheit nach Maßgabe der nächsten Zustandsdaten.
eine Adressiereinheit (31) zum Erzeugen von Adreßdaten aus Eingabesteuerdaten und Eingabecodedaten, enthaltend eine Codeeinheit, als Einheiten von zu decodierenden Codes,
eine Decodiereinheit (32) mit einer Anzahl von Codetabellen zum Decodieren von Codeeinheiten, zwecks Ausgabe von nächsten Zustandsdaten (next state date), die eine Tabelle angeben, auf die zum Decodieren der nächsten Codeeinheit und Lauflängendaten der decodierten Codeeinheit Bezug genommen werden soll, und eine Steuereinheit (1) zum Ausgeben der Steuerdaten zum Decodieren der augenblicklichen oder aktuellen Codeeinheit nach Maßgabe der nächsten Zustandsdaten.
12. Gerät nach Anspruch 11, dadurch gekennzeichnet, daß
die Codeeinheit ein Ergänzungscode oder ein Beendigungscode
ist und daß die Decodiereinheit (32) eine eindimensionale
Weiß(durch)lauf-Codetabelle zum Decodieren
eines Weißlauf-Ergänzungscodes und eines Weißlauf-
Beendigungscodes sowie eine eindimensionale Schwarz(durch)lauf-
Codetabelle zum Decodieren eines Schwarzlauf-
Ergänzungscodes und eines Schwarzlauf-Beendigungscodes
enthält.
13. Gerät nach Anspruch 11, dadurch gekennzeichnet, daß die
Codeeinheit ein Ergänzungscode (make-up code), ein Beendigungscode
(terminating code), ein Identifiziercode
eines Horizontalmodus, ein Vertikalmoduscode, ein
Durchlaufmoduscode (pass mode code) oder der EOL-Code
ist und die Decodiereinheit (32) eine eindimensionale
Weißlauf-Codetabelle für das Decodieren eines Schwarzlauf-
Ergänzungscodes und eines Schwarzlauf-Beendigungscodes,
eine zweidimensionale Codetabelle für das Decodieren
des Identifiziercodes des Horizontalmodus,
des Vertikalmoduscodes und des Durchlaßmoduscodes sowie
eine Spezialcodetabelle für das Decodieren des
EOL-Codes enthält.
14. Gerät nach Anspruch 13, dadurch gekennzeichnet, daß
die Steuereinheit (1) ferner eine Einheit (1) zum
Ausgeben der Steuerdaten zur Adressiereinheit (31)
aufweist, so daß die nächste Codeeinheit als Weißlauf
(white run) decodiert wird, wenn die Decodierverarbeitung
bis zum Ende einer Zeile abgeschlossen ist.
15. Gerät nach Anspruch 14, dadurch gekennzeichnet, daß
die Steuereinheit (1) eine Einheit (1) zum Ausgeben
der Steuerdaten zur Adressiereinheit (31) nach Maßgabe
der nächsten Zustandsdaten aufweist, so daß zum Decodieren
der nächsten Codeeinheit auf die zweidimensionale Codetabelle
Bezug genommen wird (is referred to), wenn der
Vertikalmoduscode und der Durchlaßmoduscode als Codeeinheit
decodiert werden oder sind, so daß zum Decodieren
der nächsten Codeeinheit auf die eindimensionale Weißlauf-
Codetabelle Bezug genommen wird, wenn der Identifiziercode
im Horizontalmodus decodiert wird, so daß
zum Decodieren der nächsten Codeeinheit auf die eindimensionale
Schwarzlauf-Codetabelle Bezug genommen
wird, wenn der Schwarzlauf-Beendigungscode decodiert
wird, und so daß zum Decodieren der nächsten Codeeinheit
auf die Spezialcodetabelle Bezug genommen wird, wenn
"0"-Bits für oder auf sechs Bits oder mehr in der zweidimensionalen
Codetabelle folgen (are successive for)
und "0"-Bits für oder auf acht Bits oder mehr in den
eindimensionalen Weiß- und Schwarz-Codetabellen folgen.
16. Gerät nach Anspruch 11, dadurch gekennzeichnet, daß die
Codeeinheit jeweils einer von zweigeteilten (two-divided)
Abschnitten eines Ergänzungscodes, jeweils einer von
zweigeteilten Abschnitten eines Beendigungscodes, ein
Identifiziercode in einem Horizontalmodus, ein Vertikalmoduscode,
ein Durchlaßmoduscode sowie jeweils einer
von zweigeteilten Abschnitten eines EOL-Codes ist und
die Decodiereinheit (32) eine eindimensionale Weißlauf-
Codetabelle 1 für das Decodieren erster Abschnitte des
Weißlauf-Ergänzungscodes und des Weißlauf-Beendigungscodes,
eine eindimensionale Weißlauf-Codetabelle 2 für
das Decodieren zweiter Abschnitte des Weißlauf-Ergänzungscodes
und des -Beendigungscodes, eine eindimensionale
Schwarzlauf-Codetabelle 1 für das Decodieren erster Abschnitte
des Schwarzlauf-Ergänzungscodes und des -Beendigungscodes,
eine eindimensionale Schwarzlauf-Codetabelle 2
für das Decodieren zweiter Abschnitte des
Schwarzlauf-Ergänzungscodes und des -Beendigungscodes,
eine zweidimensionale Codetabelle für das Decodieren
des Identifiziercodes des Horizontalmodus, des Vertikalmoduscodes
und des Durchlaßcodes sowie eine Spezialcodetabelle
für das Decodieren eines zweiten Abschnitts des
EOL-Codes enthält.
17. Gerät nach Anspruch 16, dadurch gkennzeichnet, daß die
Steuereinheit (1) ferner eine Einheit (1) zum Ausgeben
der Steuerdaten zur Adressiereinheit (31) aufweist, so
daß die nächste Codeeinheit als Weißlauf (white run)
decodiert wird, wenn die Decodierverarbeitung bis zum
Ende einer Zeile abgeschlossen ist.
18. Gerät nach Anspruch 16, dadurch gekennzeichnet, daß die
Steuereinheit (1) eine Einheit (1) zum Ausgeben der
Steuerdaten zur Adressiereinheit (31) nach Maßgabe der
nächsten Zustandsdaten aufweist, so daß zum Decodieren
der nächsten Codeeinheit auf die eindimensionale Codetabelle
Bezug genommen wird, wenn einer der Vertikalmodus-,
der Durchlaß- und der Schwarzlauf-Beendigungscodes
decodiert wird, so daß auf die eindimensionale
Weißlauf-Codetabelle 1 Bezug genommen wird, wenn der
Identifiziercode im Horizontalmodus bzw. der Weißlauf-
Ergänzungscode decodiert wird, so daß auf die eindimensionale
Weißlauf-Codetabelle 2 Bezug genommen wird,
wenn einer der ersten Abschnitte des Weißlauf-Ergänzungscodes
und des Weißlauf-Beendigungscodes decodiert wird,
so daß auf die eindimensionale Schwarzlauf-Codetabelle 1
Bezug genommen wird, wenn einer der Weißlauf-Beendigungs-
und Schwarzlauf-Ergänzungscodes decodiert wird, so daß
auf die eindimensionale Schwarzlauf-Codetabelle 2 Bezug
genommen wird, wenn einer der ersten Abschnitte des
Schwarzlauf-Ergänzungscodes und des -Beendigungscodes
decodiert wird, und so daß auf die Spezialcodetabelle
Bezug genommen wird, wenn "0"-Bits für oder auf sechs
Bits oder mehr in der zweidimensionalen Codetabelle
folgen und "0"-Bits für oder auf acht Bits oder mehr
in den eindimensionalen Codetabellen folgen.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP4369386 | 1986-02-28 |
Publications (2)
Publication Number | Publication Date |
---|---|
DE3711200A1 true DE3711200A1 (de) | 1987-12-23 |
DE3711200C2 DE3711200C2 (de) | 1990-03-08 |
Family
ID=12670910
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19873711200 Granted DE3711200A1 (de) | 1986-02-28 | 1987-02-27 | Binaerdatenverdichtungs- und -dehnungs-verarbeitungsgeraet |
Country Status (4)
Country | Link |
---|---|
US (1) | US4800441A (de) |
JP (1) | JPS62283778A (de) |
KR (1) | KR900001821B1 (de) |
DE (1) | DE3711200A1 (de) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE4025026A1 (de) * | 1989-12-07 | 1991-06-13 | Dirr Josef | Verfahren zur codierung von information |
EP0467678A2 (de) * | 1990-07-18 | 1992-01-22 | Kabushiki Kaisha Toshiba | Vorrichtung zur variablen Längenkodierung und Vorrichtung zur variablen Längendekodierung |
DE4408522A1 (de) * | 1993-03-19 | 1994-09-22 | Mitsubishi Electric Corp | Vorrichtung und Verfahren zur Bilddatenverarbeitung, die zur Verarbeitung von Bilddaten mit hoher Geschwindigkeit in der Lage sind |
DE4428860A1 (de) * | 1993-08-06 | 1995-03-09 | Mitsubishi Electric Corp | Kodiersystem |
DE4447925B4 (de) * | 1993-08-06 | 2009-04-02 | Mitsubishi Denki K.K. | Codierer und Decodierer |
Families Citing this family (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS63299683A (ja) * | 1987-05-29 | 1988-12-07 | Matsushita Graphic Commun Syst Inc | 2次元符号化信号の復号化装置 |
US4939583A (en) * | 1987-09-07 | 1990-07-03 | Hitachi, Ltd. | Entropy-coding system |
JP2672521B2 (ja) * | 1987-09-21 | 1997-11-05 | 株式会社東芝 | 画像処理方法 |
JPH01274565A (ja) * | 1988-04-27 | 1989-11-02 | Matsushita Graphic Commun Syst Inc | 復号装置 |
JP2766302B2 (ja) * | 1989-04-06 | 1998-06-18 | 株式会社東芝 | 可変長符号並列解読方法および装置 |
JPH0831130B2 (ja) * | 1989-05-12 | 1996-03-27 | 大日本スクリーン製造株式会社 | 線画像の処理方法 |
KR930006750B1 (ko) * | 1989-06-29 | 1993-07-23 | 삼성전자 주식회사 | 화상데이터 부호화장치 |
DE69024130T2 (de) * | 1989-08-09 | 1996-06-13 | Fujitsu Ltd | Datenkompressionssystem |
JP2877375B2 (ja) * | 1989-09-14 | 1999-03-31 | 株式会社東芝 | 可変レートコーデックを用いたセル転送方式 |
EP0469716B1 (de) * | 1990-07-03 | 1997-04-23 | Canon Kabushiki Kaisha | Bildverarbeitungsgerät |
JPH0490268A (ja) * | 1990-08-01 | 1992-03-24 | Hitachi Ltd | 画像信号復号化方式 |
JPH04216271A (ja) * | 1990-12-17 | 1992-08-06 | Murata Mach Ltd | ファクシミリ送信方法 |
US5229863A (en) * | 1990-12-24 | 1993-07-20 | Xerox Corporation | High speed CCITT decompressor |
US5287193A (en) * | 1991-04-10 | 1994-02-15 | Industrial Technology Research Institute | Parallel processing architecture of run-length codes |
US5452101A (en) * | 1991-10-24 | 1995-09-19 | Intel Corporation | Apparatus and method for decoding fixed and variable length encoded data |
EP0562251A2 (de) * | 1992-03-24 | 1993-09-29 | Universities Research Association, Inc. | Durch ein dynamisches wiederkonfigurierbares serielles Netzwerk gesteuertes Paralleldatenübertragungsnetzwerk |
EP0620960B1 (de) * | 1992-11-06 | 1999-03-10 | Josef Dirr | Verfahren zur codierung und übertragung von information |
JPH0654212A (ja) * | 1993-03-19 | 1994-02-25 | Matsushita Graphic Commun Syst Inc | 復号装置 |
DE4447554C2 (de) * | 1993-03-19 | 1999-08-19 | Mitsubishi Electric Corp | Vorrichtung zur Bilddatenverarbeitung |
FR2705805B1 (fr) * | 1993-05-27 | 1996-06-28 | Sgs Thomson Microelectronics | Système de traitement d'images. |
GB2316569B (en) * | 1993-08-06 | 1998-06-03 | Mitsubishi Electric Corp | A coding system |
US6104751A (en) * | 1993-10-29 | 2000-08-15 | Sgs-Thomson Microelectronics S.A. | Apparatus and method for decompressing high definition pictures |
KR970068627A (ko) * | 1996-03-22 | 1997-10-13 | 구자홍 | 최적화된 가변길이 테이블장치 및 최적 길이값 산출방법 |
US6721456B1 (en) | 2000-02-23 | 2004-04-13 | International Business Machines Corporation | Color image data and control bit compression scheme with run length encoding |
JP3865203B2 (ja) * | 2001-04-24 | 2007-01-10 | 株式会社リコー | 画像圧縮装置、画像形成装置、画像圧縮方法及び記録媒体 |
US6947604B2 (en) * | 2002-01-17 | 2005-09-20 | Intel Corporation | Method and hardware to implement two-dimensional compression |
TW565829B (en) * | 2002-03-19 | 2003-12-11 | Via Tech Inc | Method and device for recovering decoded data |
US7782326B2 (en) * | 2004-02-25 | 2010-08-24 | Marvell International Technology Ltd. | Parallel video processing architecture |
JP4502383B2 (ja) * | 2004-11-16 | 2010-07-14 | キヤノン株式会社 | 復号化装置およびその方法 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2146874A (en) * | 1983-08-26 | 1985-04-24 | British Telecomm | Decoding of minimum redundancy codes |
US4562484A (en) * | 1983-08-19 | 1985-12-31 | Advanced Micro Devices, Inc. | Method and device for decoding two-dimensional facsimile signals |
DE3137704C2 (de) * | 1980-09-22 | 1986-01-09 | Nippon Telegraph & Telephone Public Corp., Tokio/Tokyo | Vorrichtung zum Decodieren eines baumförmigen Codes variabler Länge |
DE3534081C2 (de) * | 1984-09-29 | 1987-03-19 | Olympus Optical Co., Ltd., Tokio/Tokyo | Datendemodulator |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3543081A1 (de) * | 1985-12-05 | 1987-06-11 | Norbert Garich | Mobile toilette |
US4760461A (en) * | 1986-02-28 | 1988-07-26 | Kabushiki Kaisha Toshiba | Binary data compression and expansion processing apparatus |
US4760459A (en) * | 1986-07-30 | 1988-07-26 | Kabushiki Kaisha Toshiba | Binary data compression and expansion processing apparatus |
-
1987
- 1987-02-24 US US07/018,334 patent/US4800441A/en not_active Expired - Fee Related
- 1987-02-27 JP JP62044541A patent/JPS62283778A/ja active Pending
- 1987-02-27 DE DE19873711200 patent/DE3711200A1/de active Granted
- 1987-02-28 KR KR1019870001792A patent/KR900001821B1/ko not_active IP Right Cessation
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE3137704C2 (de) * | 1980-09-22 | 1986-01-09 | Nippon Telegraph & Telephone Public Corp., Tokio/Tokyo | Vorrichtung zum Decodieren eines baumförmigen Codes variabler Länge |
US4562484A (en) * | 1983-08-19 | 1985-12-31 | Advanced Micro Devices, Inc. | Method and device for decoding two-dimensional facsimile signals |
GB2146874A (en) * | 1983-08-26 | 1985-04-24 | British Telecomm | Decoding of minimum redundancy codes |
DE3534081C2 (de) * | 1984-09-29 | 1987-03-19 | Olympus Optical Co., Ltd., Tokio/Tokyo | Datendemodulator |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE4025026A1 (de) * | 1989-12-07 | 1991-06-13 | Dirr Josef | Verfahren zur codierung von information |
EP0467678A2 (de) * | 1990-07-18 | 1992-01-22 | Kabushiki Kaisha Toshiba | Vorrichtung zur variablen Längenkodierung und Vorrichtung zur variablen Längendekodierung |
EP0467678A3 (en) * | 1990-07-18 | 1992-10-14 | Kabushiki Kaisha Toshiba | Variable length coding apparatus and variable length decoding apparatus |
US5304995A (en) * | 1990-07-18 | 1994-04-19 | Kabushiki Kaisha Toshiba | Variable lengthcoding apparatus and variable length decoding apparatus |
DE4408522A1 (de) * | 1993-03-19 | 1994-09-22 | Mitsubishi Electric Corp | Vorrichtung und Verfahren zur Bilddatenverarbeitung, die zur Verarbeitung von Bilddaten mit hoher Geschwindigkeit in der Lage sind |
DE4428860A1 (de) * | 1993-08-06 | 1995-03-09 | Mitsubishi Electric Corp | Kodiersystem |
DE4428860C2 (de) * | 1993-08-06 | 2002-10-10 | Mitsubishi Electric Corp | Kodiersystem |
DE4447925B4 (de) * | 1993-08-06 | 2009-04-02 | Mitsubishi Denki K.K. | Codierer und Decodierer |
Also Published As
Publication number | Publication date |
---|---|
KR870008445A (ko) | 1987-09-26 |
JPS62283778A (ja) | 1987-12-09 |
KR900001821B1 (ko) | 1990-03-24 |
DE3711200C2 (de) | 1990-03-08 |
US4800441A (en) | 1989-01-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE3711200C2 (de) | ||
DE3711201C2 (de) | ||
DE3587107T2 (de) | Drehungsverfahren und -geraet fuer binaere bilder. | |
DE69333742T2 (de) | Verfahren und Vorrichtung zur Bildatenkodierung | |
DE2264090C3 (de) | Datenverdichtung | |
DE2825930A1 (de) | Sichtanzeigegeraet mit komprimierter bildwiederholung | |
DE3047251A1 (de) | Rechner | |
DE2558264C3 (de) | Verfahren zur Verdichtung binärer Bilddaten | |
DE69329092T2 (de) | Huffman-Kode-Decodierungsschaltung | |
DE2728889C3 (de) | Verfahren und Vorrichtung zum Übertragen eines Zweipegel-Faksimilesignals | |
DE1499225B2 (de) | Schaltungsanordnung zur reduzierung von datenwortlaengen | |
DE3706470C2 (de) | ||
DE3038195A1 (de) | Vorrichtung zur verarbeitung von visueller information | |
DE3406624C2 (de) | ||
DE1964570B2 (de) | Verfahren zum wiederauffinden gespeicherter informationen | |
DE69428662T2 (de) | System mit geringem Speicherbedarf zur Kodierung und Dekodierung von Zweipegelsymbolen und zugehöriges Verfahren | |
DE60002218T2 (de) | Lzw datenkomprimierungsgerät und -verfahren, mit anwendung von mathematischer vorhersage von lauflängenverarbeitung | |
DE2414239C3 (de) | Verfahren und Vorrichtung zum Komprimieren einer binären Informationsfolge | |
DE69320147T2 (de) | Vorrichtung zur Bildkodierung | |
DE2000565A1 (de) | Fehlerkorrigierendes System zur Korrektur mehrfacher,zufaelliger Fehler | |
DE2826454C3 (de) | Faksimilesignal-Codiersystem | |
DE3604236C1 (de) | Universell programmierbare Tastatur | |
DE3417262C2 (de) | ||
EP0802678A2 (de) | Verfahren zur fraktalen Bildkodierung | |
DE3650069T2 (de) | Datenprozessor. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
D2 | Grant after examination | ||
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |