-
Die vorliegende Erfindung bezieht
sich allgemein auf Bilderfassungsgeräte und insbesondere auf ein
dynamisch programmierbares Bilderfassungsgerät.
-
Es gibt eine Vielzahl von Bilderfassungsgeräten, wie
zum Beispiel Digitalkameras (Video und Stehbild), Scanner, Kopiermaschinen,
Drucker, und Photoverarbeitungsmaschinen. Diese Geräte können relativ
einfach sein, oder sie können
hochkomplex sein, mit der Fähigkeit,
eine Vielzahl von Bild- und Photoverarbeitungsaufgaben durchzuführen, wie
zum Beispiel Raster-zu-Vektor-Umwandlung, Mosaikrückbildung
und optische Zeichenerkennung (OCR = Optical Character Recognition).
Diese Geräte
und/oder Funktionen wurden typischerweise in aufgabenspezifischer
Geräteform
geliefert. In letzter Zeit hat sich jedoch ein Markt für ein einzelnes
Gerät entwickelt,
das viele oder alle dieser Bilderfassungsfunktionen vereint. Leider
gibt es mehrere Probleme bei der Integration mehrerer Bilderfassungsfunktionen
in ein einzelnes Gerät.
-
Zunächst sind einzelne Geräte typischerweise
mit einer gerätespezifischen
Sprache programmiert. Beispielsweise sind Drucker üblicherweise
mit einer Druckersteuersprache (PCL = Printer Control Language)
programmiert. Diese unterschiedlichen Programmierschemata sind kein
Problem, weil die meisten dieser Geräte entwickelt wurden, um als
Peripheriegerät
in Zusammenarbeit mit einem Computer zu funktionieren. In solchen
Fällen
laufen Gerätetreiber
auf dem Computer und bilden eine Schnittstelle zwischen dem Computer
und dem Peripheriegerät. Leider
war es jedoch nicht praktisch, jedes getrennte Programmierschema
zum Durchführen
der verschiedenen Bilderfassungsfunktionen in ein einzelnes Gerät einzubauen.
Das heißt,
es ist nicht effizient, ein Gerät
zu verwenden, das in der Lage ist, die verschiedenen unterschied lichen
Programme, die in unterschiedlichen Maschinensprachen geschrieben sind,
getrennt auszuführen.
-
Ein anderes, aber verwandtes Problem
ist, daß selbst
wenn eine gemeinsame Maschinenprogrammiersprache in einem Multifunktionsgerät mit all den
verschiedenen Funktionen verwendet wird, eine gewaltige Speichermenge
(d.h. ROM-Firmware) erforderlich ist, um den Code zu speichern,
der benötigt wird,
um die vielen unterschiedlichen Aufgaben durchzuführen, die
Idealerweise auf einem solchen Gerät verfügbar wären.
-
Eine versuchte Lösung ist es, ein Universalbilderfassungsgerät (ICA =
Image Capture Appliance) zu verwenden, das nur System- und Hilfsprogrammsoftware
dauerhaft speichert und aufgabenspezifische Programme auf einer
Nach-Bedarf-Basis herunterlädt.
Ein Beispiel einer solchen Lösung
implementiert eine virtuelle Java-Maschine. (JVM = Java Virtual
Machine). Leider ist die JVM-Lösung
als auch andere ähnliche
Lösungen
interpretierend, was bedeutet, daß dieselben ineffizient sind
und an einer verschlechterten Leistungsfähigkeit leiden.
-
Es ist die Aufgabe der vorliegenden
Erfindung, eine Mehrfachfunktionsbilderfassungsvorrichtung, ein
Bilderfassungsvorrichtungscodeserversystem und ein System zum Ermöglichen
zumindest einer Funktion einer Mehrzahl von Funktionen für ein Bilderfassungsgerät mit verbesserten
Charakteristika zu schaffen.
-
Diese Aufgabe wird durch eine Vorrichtung gemäß Anspruch
1, ein System gemäß Anspruch
13 sowie ein System gemäß Anspruch
22 gelöst.
-
Eine Mehrfachfunktionsbilderfassungsvorrichtung,
die folgende Merkmale aufweist: eine Prozessoreinheit, die einen
Firmwarespeicher mit Befehlen zum Implementieren eines Betriebssystems
und einen Direktzugriffsspeicher zum Empfan gen zumindest eines ausführbaren
Codeabschnitts zum Durchführen
einer ausgewählten
von einer Mehrzahl von Bilderfassungs- und Dienstaufgaben aufweist;
ein Netzwerkzugriffsmodul zum kommunikativen Verbinden der Prozessoreinheit
mit einem Bilderfassungsgerät-(ICA-)
Codeserver, wobei die Prozessoreinheit ansprechend auf das Ausführen des
Betriebssystems und der Auswahl der Aufgabe durch einen Benutzer
angepaßt
wird, um von dem Server zumindest einen ausführbaren Codeabschnitt zum Durchführen der
ausgewählten
Aufgabe anzufordern und zu empfangen; und ein Bilderfassungsmodul
zum Empfangen und Umwandeln eines visuellen Bildes in ein digitales
Bildsignal und Verfügbarmachen
des Signals für
die Prozessoreinheit und Durchführen
auf derselben die ausgewählte
Aufgabe nach der Ausführung des
zumindest einen empfangenen ausführbaren Codeabschnitts.
-
Bevorzugte Ausführungsbeispiele der vorliegenden
Erfindung werden nachfolgend bezugnehmend auf beiliegende Zeichnungen
näher erläutert. Es
zeigen:
-
1 ein
Blockdiagramm eines Systems zum Implementieren eines Netzwerkgeräts, wie
zum Beispiel eines Bilderfassungsgeräts (ICA) der vorliegenden Erfindung;
-
2 ein
Blockdiagramm eines Ausführungsbeispiels
eines ICA-Codeserversystems der vorliegenden Erfindung;
-
3 ein
Blockdiagramm eines Ausführungsbeispiels
eines ICA der vorliegenden Erfindung;
-
4 ein
Ausführungsbeispiel
einer beispielhaften Schablone, die durch ein Ausführungsbeispiel
einer ICA-Codeliefermaschine der vorliegenden Erfindung verarbeitet
werden soll; und
-
5 ein
Flußdiagramm
eines Ausführungsbeispiels
einer Routine, die bei einem Ausführungsbeispiel einer ICA-Codeservermaschine
der vorliegenden Erfindung implementiert werden soll.
-
Die vorliegende Erfindung liefert
ein System zum Implementieren eines rationellen, dynamisch programmierbaren
Netzwerkgeräts,
wie zum Beispiel eines Bilderfassungsgeräts (ICA). Das ICA ist in der Lage,
mehrere Bilderfassungsfunktionen durchzuführen, zum Beispiel optische
Zeichenerkennung (OCR), Raster-zu-Vektor-Umwandlung, Photorestaurierung,
Photofertigstellung, Rahmung, usw. Das ICA ist auch in der Lage,
die erfaßten
und manipulierten Bilder über
eine Netzwerkverbindung bereitzustellen. Wenn ein Benutzer eine
Aufgabe, wie zum Beispiel OCR, auswählt, lädt das Gerät dynamisch ausführbaren
Code herunter (z.B. vom Web), der zum Durchführen der ausgewählten Funktion
notwendig ist. Daher erfordert das ICA keine riesigen Mengen an
Nurlesespeicher (ROM), die andernfalls zum Unterbringen aller Firmware
notwendig wären,
die zum Durchführen
der verfügbaren
Aufgaben notwendig ist. Auf diese Weise können mehrere Funktionen in einer
einzigen Anwendung geliefert werden, die vorzugsweise Speicher zum
Ausführen
einer Funktion zu einem Zeitpunkt benötigt. Dies führt zu einem
weniger aufwendigen Gerät,
das nach wie vor in der Lage ist, zahlreiche unterschiedliche und
auch komplexe, codeintensive Funktionen durchzuführen. Weil außerdem ein
Großteil
(falls nicht der Gesamtteil) des ausführbaren Codes desselben vorzugsweise von
einer zentralen Quelle auf einer Nach-Bedarf-Basis heruntergeladen wird, kann der
Code praktisch und fortlaufend aktualisiert werden, um das Gerät optimal
beizubehalten. Der dynamische heruntergeladene Code kann auch in
der Form eines interpretierten Skriptes sein, und es dadurch Benutzern
ermöglichen,
ihre eigenen Routinen zu schreiben. Dies kann ermöglicht werden
durch Liefern eines Abschnitts eines ausführbaren Codes in binärer Form, der
als ein Interpretierer wirkt, zusammen mit einer Skriptdatei.
-
Zusätzlich zum Herunterladen der
notwendigen Codesegmente zum Implementieren verschiedener ICA-Gerätfunktionen,
die bereits zu dem Zeitpunkt bekannt sind, zu dem das ICA-Gerät versandt wurde,
kann das ICA-Gerät
bei einem Ausführungsbeispiel
der Erfindung das ICA-Codeserversystem regelmäßig fragen, ob irgendwelche
neuen Funktionen für
dieses Gerät
verfügbar
sind. Der Benutzer kann durch das Benutzerschnittstellenmodul über sämtliche
neuen Funktionen informiert werden. Falls es beispielsweise eine
neue ICA-Funktion
gibt, die eine Bilderzeugungstransformation XYZ durchführt, die
zum Zeitpunkt des Kaufs nicht verfügbar war, kann dem Benutzer
die neue Funktionalität
in Rechnung gestellt werden, oder dieselbe könnte als eine Zugabe geliefert
werden.
-
1 zeigt
ein Ausführungsbeispiel
eines Netzwerkgerätesystems
der vorliegenden Erfindung. Das System umfaßt im allgemeinen das ICA-Codeserversystem 120,
das durch das Netzwerk 105, wie zum Beispiel das Internet,
mit einer Mehrzahl von ICAs 115 kommunikativ verbunden
ist. ICAs 115 können
entweder durch ein lokales Netzwerk 100 (z.B. Heim-LAN) oder durch eine
Direktkommunikationsverbindung 116, z.B. über eine
verdrahtete oder eine drahtlose Modemverbindung, mit dem Netzwerk 105 verbunden
sein. Beispielhafte lokale Netze 100 umfassen beispielsweise
Computer 111, Dateispeicherserver 113, Drucker 117 und
Fernseher 119, zusätzlich
zu dem ICA 115. Das ICA-Codeserversystem 120 umfaßt vorzugsweise
einen Datenbankserver 124, der wirksam mit dem ICA-Server 122 verbunden ist,
der mit dem Netzwerk 105 verbunden ist. Diese Server werden
nachfolgend mit Bezugnahme auf 2 näher adressiert.
-
Das Netzwerk 105 kann jedes
geeignete Netzwerk oder jede geeignete Netzwerkarchitektur umfassen,
wie z.B. das Internet, ein privates weites Netz (WAN = wide area
network), das beispielsweise über
das öffentliche
Fernsprechwählnetz
(PSTN = Public switched telephone network) oder jedes ande re geeignete
Netzwerk implementiert ist, das vorzugsweise eine Breitbandfähigkeit
aufweist und drahtgebunden oder drahtlos oder eine Kombination derselben
sein kann. Gleichartig dazu können
die Kommunikationsverbindungen 116 alle geeigneten Geräte zum Verbinden
von ICAs 115 mit dem Netzwerk 105 umfassen. Beispielsweise
könnten
dieselben Modemverbindungen (verdrahtet oder drahtlos), Direktnetzwerkverbindungen,
wie z.B. durch digitale Teilnehmeranschlußleitung (DSL = digital subscriber line),
ISDN, T1 und Hybridverbindungen, wie z.B. mit einer kombinierten
Satellit/Telefonverbindung umfassen, sind aber nicht darauf beschränkt. Gleichartig dazu,
wenn dieselben mit einem lokalen Netzwerk 100 verbunden
sind, können
die ICAs 115 über
jedes geeignete Schema mit dem lokalen Netzwerk 100 gekoppelt
sein. Beispielsweise könnte
dasselbe über eine
drahtlose Verbindung, USB, FIREWIRE oder dergleichen, mit einem
lokalen Netzwerk verbunden sein. Dann wiederum könnte das lokale Netzwerk 100 über eine
T1, T3, ISDN, ein Frame-Relay,
ATM, DSL, Kabelmodem oder jede andere geeignete Verbindung mit dem
Netzwerk 105 verbunden sein.
-
Wenn ein ICA beim Betrieb zum Durchführen einer
Bilderfassungs- oder Bereitstellungsaufgabe verwendet wird und derzeit
nicht den Code besitzt, der benötigt
wird, um die ausgewählte
Aufgabe durchzuführen,
sendet das ICA eine Anforderung an den ICA-Server 122 für die ausführbaren
Codeabschnitte, die benötigt
werden, um die ausgewählte Aufgabe
durchzuführen.
Ansprechend auf diese Anforderung gewinnt der ICA-Server 122 auf
der Basis des speziellen Typs von ICA 115 und der ausgewählten angeforderten
Aufgabe den notwendigen ausführbaren
Code zum Durchführen
der Aufgabe wieder. Der Code wird dann zurück zu dem ICA 115 übertragen,
wo derselbe in das ICA 115 geladen wird und zum Durchführen der
Aufgabe ausgeführt
wird. Abhängig
von der Aufgabe, die durchgeführt
wird, kann dann eine erfaßte
und/oder verarbeitete Bilddatei automatisch zu einem gewünschten
Bestimmungsort hochgeladen werden, wie z.B. einen Dateiserver, einer
Photoanzeigewebsite (z.B. myfamily.com, Ofoto.com, hpphoto.com),
eine Projekttypwebsite (z.B. bluemontain.com), oder eine Website eines
zusätzlichen
Verarbeitungstyps (z.B. netdocument.com, emniform.com). Falls die
Aufgabe die des Bereitstellens ist, wird der heruntergeladene Code das
ICA befähigen,
als ein Dateiserver zu wirken. Beispielsweise können angebotene Codeabschnitte Code
umfassen, der das Hypertextübertragungsprotokoll,
Dateiübertragungsprotokoll
oder andere Dateiübertragungsverfahren
implementiert. Ferner können mit
dynamisch herunterladbaren Codesegmenten herunterladbare Webadressen
und Websites überwacht
und aktualisiert werden.
-
Auf den Abschluß der Aufgabe hin kann der Code
dann gelöscht
werden. Dies würde
ausreichend Raum zum Empfangen anderer Codes beibehalten, um andere
Aufgaben handzuhaben. Alternativ kann der heruntergeladene Code
in dem ICA 115 beibehalten werden, bis der Speicherplatz
aufgebraucht ist. Zu diesem Zeitpunkt kann ein Löschverwalter bewirken, daß ein bestimmter
Code Raum für neuen
Code freigibt (oder derselbe überschrieben wird).
Ein Code kann auf der Basis von vorbestimmten Bedingungen gelöscht werden,
z.B. am wenigsten verwendet oder am längsten nicht verwendet.
-
2 zeigt
ein Ausführungsbeispiel
eines ICA-Codeserversystems 120 von 1. Das Codeserversystem 120 umfaßt im allgemeinen
einen ICA-Codeserver 122, der wirksam mit dem ICA-Datenbankserver 124 verbunden
ist. Der ICA-Codeserver 122 ist
ebenfalls mit dem Netzwerk 105 verbunden, wie es vorher
erörtert
wurde.
-
Der ICA-Codeserver 122 umfaßt im allgemeinen
eine ICA-Codeanbietermaschine 205,
eine Netzwerkschnittstelle 207 und eine Mehrzahl von ICA-Schablonen 209.
Die Netzwerkschnittstelle 207 ist kommunikativ mit der
ICA-Codeanbietermaschine 205 verbunden,
zum Empfangen von Codeanforderungen von ICAs und Liefern derselben
an die ICA-Codeanbietermaschine 205.
Die Netzwerkschnittstelle 207 kann jedes geeignete Programm zum
Empfangen von Codeanfor derungen von ICAs 115 sein. Der
spezifische Typ von Netzwerkschnittstellen 207 hängt von
dem Netzwerktyp 105 ab, der implementiert wird. Falls beispielsweise
das Internet als Netzwerk 105 verwendet wird, könnte eine
geeignete Hypertextübertragungsprotokoll-
(HTTP-) Serveranwendung (z.B. APACHE, MICROSOFT IIS, NETSCAPE ENTERPRISE
SERVER) verwendet werden, um die Netzwerkschnittstelle 207 zu
implementieren. Gleichartig dazu kann jedes geeignete Programmierschema
zum Implementieren der ICA-Codeanbietermaschine 125 verwendet
werden. Beispielsweise kann dieselbe mit einer Gemeinsame-Gatewayschnittstelle-
(CGI = common gateway Interface) Maschine implementiert sein (z.B.
mit Perl Scripts), die durch eine Codeanforderung von einem ICA
aufgerufen werden.
-
Eine Mehrzahl von ICA-Schablonen 209 werden
der ICA-Codeanbietermaschine 205 während einer
ICA-Codeserveroperation verfügbar
gemacht. Jede ICA-Schablone entspricht einem spezifischen ICA-Typ
und/oder einer spezifischen Aufgabe, die durchgeführt werden
soll. Die ICA-Schablonen umfassen Identifizierer (oder Bezeichner)
zum Definieren der notwendigen ausführbaren Codeabschnitte (oder
Module) die benötigt
werden zum Durchführen
einer angeforderten Aufgabe von einem spezifischen Typ von anforderndem
ICA 115. Wenn somit eine Codeanforderung durch die ICA-Codeanbietermaschine 205 empfangen
wird, gewinnt dieselbe von der Mehrzahl von ICA-Schablonen 209 eine spezifische
Schablone wieder, die dem anfordernden ICA-Typ und der Aufgabe,
die durchgeführt
werden soll, entspricht. Die Codeanbietermaschine 205 verarbeitet
dann die wiedergewonnene Schablone, um die identifizierten ausführbaren
Codeabschnitte (oder Segmente) von dem ICA-Datenbankserver 124 wiederzugewinnen
und richtig zusammenzusetzen (falls notwendig). Die identifizierten
Codesegmente werden dann zurück
zu der anfordernden ICA übertragen,
wo dieselben zum Durchführen
der spezifizierten Aufgabe ausgeführt werden.
-
Der ICA-Datenbankserver 124 umfaßt im allgemeinen
einen Bibliotheksordner 217 und einen Ausführbare-Aufgaben-Ordner 219.
Der Ausführbare-Aufgaben-Ordner 219 umfaßt ausführbare Aufgabencodeabschnitte,
die den verfügbaren
Aufgaben entsprechen, die die ICAs durchführen können. Gleichartig dazu umfaßt die Bibliothek 217 binäre (ausführbare)
Bibliotheksabschnitte, die durch einen oder mehrere der verschiedenen
ausführbaren
Aufgabenabschnitte verwendet werden können. Der Datenbankserver 124 ist
ein herkömmlicher
Datenbankserver zum Speichern und Liefern von ausführbaren Codeabschnitten
(Aufgabe, Bibliothek) an den ICA-Codeserver 122. Der Datenbankserver 124 kann mit
jedem geeigneten Datenbankschema implementiert werden, einschließlich, aber
nicht beschränkt auf,
Einheitsdatei-, hierarchische, relationale und objektorientierte
Datenbanken.
-
Gleichartig dazu können ICA-Code-
und Datenbank-Server 122, 124 mit jeder geeigneten
Kombination aus einem oder mehreren Computern implementiert werden,
einschließlich,
aber nicht beschränkt
auf, Großcomputer,
Workstations oder Personalcomputer, auf denen Betriebssysteme, wie
z.B. Windows NT, UNIX, LINUX oder jedes andere Computerbetriebssystem
laufen.
-
Wenn eine Aufgabenanforderung in
der ICA-Codeanbietermaschine 205 empfangen
wird, gewinnt die Codeanbietermaschine 205 eine geeignete
ICA-Schablone 209 wieder. Dieselbe verarbeitet dann die
Schablone, um einen geeigneten Ausführbare-Aufgabe-Abschnitt zu
identifizieren, zusammen mit jedem notwendigen ausführbaren
Bibliotheksabschnitt von der Bibliothek 217. Zusammen bilden
diese Aufgaben- und Bibliothekscodeabschnitte die notwendigen Codesegmente,
die durch die ICA 115 benötigt werden, um die spezifizierte
Aufgabe durchzuführen.
Die ICA-Codeprozessormaschine 205 kann diese
ausführbaren
Codeabschnitte einfach wiedergewinnen, und dieselben an das anfordernde
ICA 115 weiterleiten, oder dieselbe kann zusätzlich die Abschnitte
zum richtigen Laden und Ausführen
des Codes in dem anfordernden ICA 115 dynamisch laden und/oder
zusammensetzen.
-
Bei einem alternativen Ausführungsbeispiel umfaßt jeder
Aufgabenabschnitt (zum Durchführen einer
ausgewählten
Aufgabe) statt einer Schablone (oder Datei) zum Identifizieren der
notwendigen Codeabschnitte eine oder mehrere Identifiziererkennungen
zum Identifizieren der notwendigen Bibliotheksabschnitte, die durch
den speziellen Aufgabenabschnitt benötigt werden. Die Codeanbietermaschine 205 gewinnt
den/die geeigneten Aufgabenabschnitt e) auf der Basis der ausgewählten Aufgabe
und des speziellen Typs von anfordernder ICA wieder. Dieselbe verarbeitet
(liest) dann die wiedergewonnenen Aufgabenabschnitte, um alle Bibliothekabschnitte
zu identifizieren, die durch den/die Aufgabenabschnitt e) benötigt werden.
Mit jedem dieser Schemata müssen keine
vollständigen
Bibliotheken zu einem ICA heruntergeladen werden, statt dessen müssen nur
die Bibliotheksabschnitte, die durch das ICA benötigt werden, um die Aufgabe
durchzuführen,
heruntergeladen werden. Es ist anzumerken, daß eine große Funktion als Einzelsegment
heruntergeladen werden kann oder in mehrere Segmente unterteilt
werden kann. Jedes der mehreren Segmente kann getrennt heruntergeladen
werden. Die mehreren Segmente können
getrennt oder aufeinanderfolgend ausgeführt werden, um die große Funktion
zu erreichen.
-
3 zeigt
ein Ausführungsbeispiel
eines ICA 115 der vorliegenden Erfindung. Das ICA 115 umfaßt im allgemeinen
eine Hauptprozessoreinheit 310, ein Bilderfassungsmodul 320,
einen Eingabe-Ausgabe-Abschnitt 330, und eine Brücke (oder Busschnittstellenschaltung) 345.
Bei einem alternativen Ausführungsbeispiel
umfaßt
dasselbe auch einen Signalverarbeitungsabschnitt 350 und/oder Flash-Speicher 365.
Die Hauptprozessoreinheit 310 ist über den Hauptbus 318 mit
der Brücke 345 verbunden.
Gleichartig dazu ist das Bilderfassungsmodul 320 durch
den Bus 328 mit der Brücke 345 verbunden,
und der Eingabe/Ausgabeabschnitt 330 ist durch einen I/O-Bus 338 mit
der Brücke 345 verbunden.
Die Brücke 345 dient
dazu, die Kommunikation zwischen den Bussen 318, 328 und 338 zu
verhandeln, und somit zwischen dem Hauptprozessorabschnitt 310,
dem Bilderfassungsabschnitt 320 und dem I/O-Abschnitt 330.
Dasselbe kann mit jedem geeigneten Gerät oder jeder Kombination von
Geräten implementiert
werden, wie z.B. einem programmierbaren Logikbauelement, (wie z.B.
ein DSP) oder einer Decodiererkonfiguration. Dasselbe könnte auch mit
einem einzigen gemeinsamen Bus implementiert werden, wobei jeder
Abschnitt eine entsprechende Decodierfähigkeit aufweist.
-
Die Hauptprozessoreinheit 310 umfaßt den Mikroprozessor 312,
einen Direktzugriffsspeicher (RAM) 314 und Firmware 316.
Unter anderem ist der Mikroprozessor 312 verantwortlich
für das
Steuern und Überwachen
anderer Abschnitte 320 und 330. Außerdem führt derselbe
vorzugsweise ein eingebettetes Betriebssystem und/oder eine Aufgabenanforderungsanwendung
(in der Firmware 316 gespeichert) aus, um ansprechend auf
Aufgabenanforderungen von den Benutzern Aufgabencodewiedergewinnungen
von dem ICA-Server durchzuführen.
Derselbe organisiert vorzugsweise die empfangenen Codesegmente und
führt dieselben
aus, um das ICA zu steuern, um die angeforderte Aufgabe durchzuführen (z.B.
Photographie und Bild und Hochladen der Bilddatei zu einer gewünschten
Website). Der RAM 314 umfaßt ausreichenden Speicher zum
Bereitstellen eines VAR (Variablen) Programmabschnitts 314A und
eines Bilderfassungsabschnitt 314B. Der VAR-Programmabschnitt 314A umfaßt ferner
den Hauptsegmentabschnitt 314A1 und den Zusätzliche-Segmente-Abschnitt
314A2 zum Empfangen und Befähigen
des Mikroprozessors, um wiedergewonnene Codesegmente von einem ICA-Codeserver 122 auszuführen. Der
Bilderfassungsabschnitt 314B liefert ausreichenden Arbeitsbereich
zum Empfangen einer erfaßten
Bilddatei von dem Bilderfassungsabschnitt 320 und ermöglicht es dem
Mikroprozessor, mit demselben zu arbeiten.
-
Das Bilderfassungsmodul 320 umfaßt vorzugsweise
notwendige Hardware zum Erfassen und Digitalisieren eines Bildes
(z.B. von einem Dokument oder einem dreidimensionalen Objekt). Das
Bilderfassungsmodul 320 umfaßt eine Linse 322,
einen Bilderfassungssensor 324 und einen A/D-Wandler 326. Die
Linsenvorrichtung 322 umfaßt die physikalische optische
Vorrichtung zum optischen Empfangen des Bildes, das erfaßt werden
soll. Die Bilderfassungssensoren 324 umfassen die notwendigen
Komponenten zum Umwandeln des Bildes von einer optischen in eine
elektrische Form. Beispielsweise könnte der Bilderfassungssensor 324 eine
ladungsgekoppelte Schaltung (CCD = charge coupled device) umfassen,
wie z.B. ein lineares Abtastgerät
oder ein Flächenabtastgerät, wie z.B.
eine 2,8 Megapixel-CCD-Fläche
(1280 × 1600)
oder eine CMOS-VGA-Vorrichtung
(640 × 480,
oder SVGA 1024 × 768).
Die Bilderfassungssensoren empfangen das optische Bild von der Linse 322 und
wandeln dasselbe in ein analoges Bildsignal um, das an den A/D-Wandler 326 geliefert
wird. Der A/D-Wandler 326 wandelt
dann das analoge Bildsignal in ein digitales Bildsignal um, das
durch 328 an die Brücke 345 geliefert
wird. Der A/D-Wandler 326 kann jede geeignete Schaltungsanordnung
zum Durchführen
einer Analog/Digital-Umwandlung
auf dem empfangenen analogen Bildsignal umfassen.
-
Der Eingabe/Ausgabeabschnitt 330 ist
durch die Brücke 345 und
den I/O-Bus 338 kommunizierbar mit der Hauptprozessoreinheit 310 verbunden.
Der Eingabe/Ausgabe-Abschnitt 330 umfaßt die Bauelemente zum Implementieren
der verschiedenen Eingabe- und Ausgabefunktionen für das ICA 115.
Bei dem dargestellten Ausführungsbeispiel
umfaßt
der Eingabe/Ausgabe-Abschnitt 330 im allgemeinen ein Netzwerkzugriffsmodul 332,
ein lokales I/O-Modul 334, und einen Benutzerschnittstellenabschnitt 336. Jedes
dieser Module (oder jeder dieser Abschnitte) ist mit dem I/O-Bus 338 verbunden,
und ist dadurch getrennt über
die Brücke 345 für die Hauptprozessoreinheit 310 zugreifbar.
Das Netzwerkzugriffsmodul 332 ist verantwortlich zum Verbinden
des ICA
115 mit dem Netzwerk 105. Dasselbe kann
Bauelemente, wie z.B. ein Modem, ein drahtloses Schnittstellenmodul
oder jede andere Komponente umfassen, die zum kommunikativen Verbinden
des ICA mit dem Netzwerk 105 notwendig sind. Der lokale
I/O-Abschnitt 334 umfaßt
die verfügbaren
Eingabe- und Ausgabetore, die zum Verbinden des ICA 115 mit
externen Geräten
verwendet werden. Beispielsweise kann der I/O-Abschnitt 334 parallele, serielle,
802.11 Tore, Universeller-Serieller-Bus-(USB-)Tore, IEEE 394-FIREWIRE-Tore
und/oder BLUE-TOOTH-Drahtlosmodemgeräte (z.B. zum Verbinden des
ICA mit dem lokalen Netzwerk 100) umfassen. Der Benutzerschnittstellenabschnitt 336 entspricht
den verschiedenen Steuer- und Überwachungsgeräten, die
durch einen Benutzer zum Steuern und Zugreifen auf das ICA 115 verwendet
werden. Diese Geräte
könnten eine
Tastatur, ein Tastenfeld, Schalter und ein Cursorsteuergerät (z.B.
Maus, Berührungsfeld,
Joystick) umfassen. Sie könnten
auch eine Tafel umfassen, wie z.B. eine Flüssigkristallanzeige zum Anzeigen ausgewählter Funktionen,
Modi, Bilder und Befehle. Bei einem Ausführungsbeispiel umfaßt das Benutzerschnittstellenmodul 336 auch
speziell zugewiesene Knöpfe,
die entweder durch einen Hersteller vorprogrammiert sein können oder
durch einen Benutzer programmierbar sind, zum Durchführen spezieller
Aufgaben, wie z.B. Scannen eines Dokuments und Hochladen desselben
zu einem spezifischen Bestimmungsort.
-
Beim Betrieb wählt ein Benutzer vorzugsweise
durch die Benutzerschnittstelle 336 eine spezifizierte
Aufgabe aus. Dies bewirkt, daß die
Hauptprozessoreinheit 310 die unterschiedlichen Abschnitte
in dem ICA 115 zum Durchführen der spezifizierten Aufgabe
konfiguriert, und eine Aufgabencodeanforderung an den ICA-Codeserver 122 überträgt, falls
notwendig, beispielsweise durch das Webzugriffsmodul 322 oder
das lokale I/O-Modul 324, abhängig von dem speziellen Netzwerk 105,
das implementiert wird, und auch davon, wie das ICA-Gerät 115 mit dem
Netzwerk 105 verbunden ist. Der ICA-Codeserver 122 wiederum überträgt die angeforderten
Codeabschnitte zum Durchführen
der angeforderten Aufgaben zurück zu
dem ICA-Gerät 115.
Diese Codeabschnitte werden entweder durch das Webzugriffsmodul 322 oder
den lokalen I/O-Abschnitt 334 übertragen.
Von dort werden dieselben durch die Brücke 345 zu der Hauptprozessoreinheit 310 übertragen.
Die Hauptprozessoreinheit 310 verteilt dann die Codeabschnitte
an die geeigneten Speicherpositionen (z.B. in dem RAM 314),
abhängig
von der Aufgabe, die angefordert wird. Außerdem kann die Hauptprozessoreinheit 310 jeden
der Codeabschnitte verknüpfen und/oder
kompilieren, wie es für
die spezifische Funktion, die durchgeführt wird, erforderlich ist.
Von hier führt
der Prozessor den empfangenen Code aus, und bewirkt dadurch, daß das ICA 115 die
angeforderte Aufgabe durchführt.
-
Alternativ kann ein Code heruntergeladen werden,
der die Funktionen eines Interpretierers durchführt. Anforderungen für Skripte
können
auf gleiche Weise wie das Wiedergewinnen von anderem ausführbarem
Code verhandelt werden. Der Interpretierer kann dann dazu fortfahren,
das Skript zu verarbeiten und die geeigneten Aufgaben auszuführen, die
durch das Skript definiert sind. Bei einer alternativen Implementierung
können
Skripte angefordert werden, um die gewünschten Aufgaben durchzuführen, sobald
der Interpretierer geladen wurde. Die Skripte können durch den Hersteller geliefert werden
oder durch einen Endnutzer entwickelt werden, und liefern somit
einen hohen Grad an Flexibilität.
-
Bei einem weiteren Ausführungsbeispiel kann
das dargestellte ICA statt dem Durchführen aller Bildverarbeitungsaufgaben
in der Hauptprozessoreinheit auch einen Signalverarbeitungsabschnitt 350 umfassen,
zum Durchführen
von zumindest einigen dieser Aufgaben außerhalb der Prozessoreinheit. Dies
kann nicht nur das ICA beschleunigen, sondern auch dessen Gesamtfunktionalität erhöhen.
-
Der dargestellte optionale Signalverarbeitungsabschnitt 350 ist
durch die Brücke 345 und
den Bus 358 mit der Hauptprozessoreinheit 310 verbunden.
Derselbe umfaßt
den Bildpro zessor 352, den Komprimierungsprozessor 354 und
den allgemeinen Digitalsignalprozessor (DSP) 356. Jeder
dieser Prozessoren umfaßt
ferner variable Programmspeicherabschnitte (z.B. RAM-Abschnitte) 355A, 355B,
bzw. 355C zum Empfangen heruntergeladener ausführbarer
Codeabschnitte von der Hauptprozessoreinheit 310, abhängig von
der speziellen Aufgabe, die durchgeführt werden soll. Der Bildprozessor 352 kann
mit jeder geeigneten Kombination von Geräten zum Durchführen der
Bildverarbeitungsaufgaben implementiert sein, wie z.B. Echtzeitmosaikrückbildung, Farbkorrektur,
Weißabgleich,
Gammakorrektur und Bildvorausbetrachtung. Gleichartig dazu kann
der Komprimierungsprozessor 354 mit jeder geeigneten Kombination
von Geräten
zum Durchführen
von Aufgaben implementiert sein, wie z.B. Komprimierung (z.B. MPEG),
Verschlüsselung/Entschlüsselung
und andere Streamingfunktionen. Beispielsweise könnte derselbe mit herkömmlichen
MPEG-Komprimierungschips implementiert sein. Der DSP-Prozessor 356 ist
eine spezialisierte Prozessorvorrichtung zum Durchführen aller
notwendigen Signalverarbeitungsaufgaben, die nicht durch die Hauptprozessoreinheit 310,
den Bildprozessor 352 oder den Komprimierungsprozessor 354 adressiert
werden. Derselbe kann mit jeder geeigneten Digitalsignalverarbeitungskomponente
implementiert sein. Es sollte klar sein, daß jede Kombination dieser Komponenten
in ein ICA der vorliegenden Erfindung eingebaut werden kann. Abhängig von
spezifischen Entwurfsüberlegungen
können
die verschiedenen Bild- und/oder Signalverarbeitungsaufgaben durch
die Hauptprozessoreinheit 300 oder durch jede geeignete
Kombination der Hauptprozessoreinheit in Zusammenarbeit mit Komponenten
in dem Signalverarbeitungsabschnitt durchgeführt werden.
-
4 zeigt
ein Ausführungsbeispiel
einer beispielhaften Schablone zum Durchführen einer Bilderfassungsaufgabe
mit dem Bilderfassungsgerät 115 von 3. Die Schablone 400 umfaßt im allgemeinen
ein Typ/Aufgabenidentifiziererfeld 405 (zum Identifizieren einer
speziellen Schablone auf der Basis des anfordernden ICA und der
angeforderten Aufgabe), und einen oder mehrere Segmentidentifizierer in
dem Hauptsegmentabschnitt 410A und dem Zusatzabschnitt 410B.
Das dargestellte Hauptsegment 410A umfaßt einen einzigen Hauptsegmentidentifizierer,
während
der Zusatzabschnitt Zusatzsegmenteidentifizierer 420, 430 und 440 umfaßt. Die Hauptsegmentidentifizierer
identifizieren Codesegmente, die in die Hauptsegmentabschnitte 314A1 geladen
werden sollen, und die Zusatzsegmentidentifizierer identifizieren
Segmente, die in den Zusatz-RAM-Abschnitt 314A2 geladen
werden sollen. Das/die Hauptsegment e) sind verantwortlich für die Grund-
(oder Primär-)
Aufgabe (z.B. Bildabtastung), während
es die Zusatzsegmente der ICA ermöglichen, zusätzliche
Funktionen durchzuführen,
wie z.B. die Bildverarbeitungsfunktionen. Für jede Schablone hängen die
benötigten
Codesegmente von dem ICA-Typ 115 ab, und auch von der speziellen Aufgabe,
die angefordert wird. Bei dem dargestellten Ausführungsbeispiel umfaßt jeder
Abschnittsidentifizierer ein Datenfeld, ein Bibliotheksmodulefeld
und ein Aufgabenfeld zum Definieren der spezifischen ausführbaren
Codesegmente und Untersegmente, zusammen mit Anfangsbedingungsparametern
für die
spezifische Aufgabe oder Funktion, die durch den Segmentidentifizierer
implementiert wird. Bei der dargestellten Schablone umfaßt der Hauptprozessorsegmentidentifizierer
ein Datenfeld 412, ein Bibliotheksmodulfeld 414 und
ein Aufgabenfeld 416. Der Bildverarbeitungssegmentidentifizierer 420 umfaßt einen
Datenabschnitt 422, einen Bibliotheksmodulabschnitt 424 und
einen Aufgabenabschnitt 426. Gleichartig dazu umfaßt der Komprimierungsvorrichtungsverarbeitungssegmentidentifizierer
ein Datenfeld 432, ein Bibliotheksmodulfeld 434 und
ein Aufgabenfeld 436. Schließlich umfaßt der DSP-Verarbeitungssegmentidentifizierer 440 ein
Datenfeld 442, ein Bibliotheksmodulefeld 444 und ein
Aufgabenmodul 446.
-
5 zeigt
ein Ausführungsbeispiel
einer Routine 500, die durch die ICA-Codeanbietermaschine 205 implementiert
ist. Diese beispielhafte Routine wird in Verbindung mit dem ZCA 115 von 3 und der ICA-Aufgaben/Typschablone 400 von
-
4 erörtert. Anfangs
empfängt
und identifiziert die Codeanbietermaschine bei Block 502 die Aufgabenanforderung
von dem ICR 115. Bei Block 504 identifiziert dieselbe
den Typ von ICA-Gerät 115, zusammen
mit den spezifischen Aufgaben, die angefordert werden. Danach gewinnt
dieselbe bei Block 506 die spezielle Aufgaben/Typschablone
wieder, die der ICA-Aufgaben und Typanforderung zugeordnet ist.
Danach, bei Block 508, gewinnt dieselbe die geeigneten
ausführbaren
Codeabschnitte vom Datenbankserver 124 wieder, einschließlich Aufgabenabschnitten
und Bibliotheksabschnitten gemäß der vorher
wiedergewonnenen Schablone. Schließlich überträgt die Codeanbietermaschine
bei Block 510 die wiedergewonnenen Codeabschnitte zurück zu dem anfordernden
ICA 115, die dann in die geeigneten Speicherabschnitte
des ICA 115 geladen werden. Die ausführbaren Codeabschnitte (z.B.
von dem Aufgabenordner und der Bibliothek) können auch, falls notwendig,
durch die Codeanbietermaschine verknüpft und/oder kompiliert werden.