-
TECHNISCHES
GEBIET
-
Die
vorliegende Erfindung betrifft ein Verfahren und ein System zum Übertragen
von Bildern zwischen einem Client und einem Server. Das Verfahren und
das System sind besonders gut geeignet zur Übertragung von Teilen von Bildern,
die in einem Server gespeichert sind.
-
HTNTERGRUND
DER ERFINDUNG UND STAND DER TECHNIK
-
Digitale
Bilder können
auf Servern gespeichert und über
ein Telekommunikationsnetzwerk verteilt bzw. vertrieben werden.
Bilder können
auch auf physikalischen Ebenen unter Verwendung von beispielsweise
einer CD-ROM gespeichert werden. Wenn das Bild groß ist, könnte es
einige Zeit dauern, das Bild zu übertragen.
Um die Übertragung
zu beschleunigen, könnte
der Client einen Bereich des Bilds auswählen, der vitaler bzw. lebendiger
ist, und dann nur den Bereich empfangen. Dies ist als Codierung
für einen
Bereich von Interesse (ROI = Region of Interest) bekannt.
-
Bei
heutigen Client-Server-Systemen wird dann, wenn ein Client wünscht, auf
ein Bild von einem Server zuzugreifen, eine Verbindung zwischen dem
Anwenderprogramm auf der Client-Seite
und dem Server aufgebaut. Das Anwenderprogramm sendet dann eine
Anforderung zum Bekommen des erwünschten
Bilds. Der Server reagiert durch Holen der Datei und beginnt die Übertragung.
Das Anwenderprogramm kann zu jeder Zeit eine neue Anforderung zum
Server senden, wie z.B. eine Anforderung für Teile einer Datei. Wenn die Übertragung
beendet ist, wird die Verbindung geschlossen. Ein solches System
ist in Fielding, et al, Hypertext Transfer Protocol – http/1.1
rev 05, HTTP Working Group, INTERNET-DRAFT, 11. September 1998 (Work
in Progress) beschrieben.
-
Jedoch
gibt es ein Problem bei den meisten der Standbild-Kompressionstechniken,
wie bei z.B. JPEG, das darin besteht, dass sie einen Bitstrom erzeugen,
der eine untrennbare Codiereinheit ist. Somit zwingt dann, wenn
ein Bereich von Interesse ausgewählt
ist, das Fehlen von unabhängig
decodierbaren Einheiten den Server, eine vollständige Decodierung durchzuführen, der
eine neue Codierung des gesamten Bitstroms folgt. In Abhängigkeit
von der Server-Software
muss er manchmal sogar das Bild vom Speichermedium neu laden. Der
Nachteil dabei besteht darin, dass ein zeitaufwendiges und rechenkomplexes
Schema erforderlich ist, was hohe Anforderungen an die Rechenleistung
des Servers stellen wird.
-
Weiterhin
wird bei dem entstehenden Standbildstandard JPEG2000 ein unabhängiges Entropiecodieren
von so genannten Codiereinheiten (CU) verwendet. Eine Codiereinheit
kann beispielsweise ein Unterband im Transformationsbereich, und
zwar im Fall von z.B. einer Wavelet-Transformation, ein Teil eines
Unterbands, wie beispielsweise eine Bitebene oder ein Block einer
bestimmten Größe (beispielsweise
16 × 16)
oder eine Bitebene für
einen Bereich innerhalb eines Unterbands sein.
-
Zusätzlicher
zugehöriger
Stand der Technik ist von BLUMBERG R; HUGHES P, in "Visual realism and
interactivity for the Internet",
COMPCON 97. PROCEEDINGS, IEEE SAN DOSE, CA, USA, 23.–26. FEB.
1997, LOS ALAMITOS, CA, USA, 23. FEBRUAR 1997 (1997-02-23) SEITEN
269–273, XP010219548
IEEE Comput. Soc, UC, offenbart, welches Dokument eine Übertragung
eines in unabhängig
decodierbaren Codiereinheiten gespeicherten Bilds beschreibt.
-
ZUSAMMENFASSUNG
-
Es
ist eine Aufgabe der vorliegenden Erfindung, die Probleme zu überwinden,
wie sie oben umrissen sind, und insbesondere das Ausmaß an Verarbeitung
und Codierung in einem Server zu reduzieren, wenn ein Client einen
ROI oder einen Teil des Bilds anfordert.
-
Diese
Aufgabe und andere werden durch Speichern von Bildern als eine Gruppe
von unabhängig
decodierbaren Einheiten (CUs) auf einem Server erreicht. Wenn ein
Client einen bestimmten Teil des Bilds anfordert, wird dann nur
Information von den CUs, die nicht bereits übertragen worden ist, erneut codiert,
was eine Menge an Verarbeitungszeit im Server einspart.
-
Dies
wird durch die Anforderung für
einen neuen Teil des Bilds mit Information darüber erreicht, an welcher Bildinformation
der Client interessiert ist, und auf welcher Information über das
Bild der Client bereits Zugriff hat.
-
Beispielsweise
gibt ein Client eine Reihe von Anforderungen für eine Bildinformation aus.
Jede Anforderung enthält
eine Anforderungsnummer, Information darüber, welche Bildinformation
der Client als nächstes
zu sehen wünscht,
und Information darüber,
welche Bildinformation der Client zu der Zeit empfangen hatte, zu
welcher die Anforderung ausgegeben wurde. Der Server muss keinerlei
Zustandsinformation (z.B. vorherige Anforderungen) speichern. Beim
Empfangen einer Anforderung sendet der Server eine Markierung für einen
erneuten Start, eine Bestätigung über die
Anforderungsnummer und inkrementale Bildinformation entsprechend
der Anforderung.
-
Die
Verwendung des Verfahrens und des Systems, wie sie hierin beschrieben
sind, wird darin resultieren, dass keine Decodierung des gesamten Bitstroms
im Server erforderlich sein wird. Dies wird eine Menge an Zeit auf
der Senderseite (Serverseite) einsparen, da er kein vollständiges Decodieren
des Stroms durchführen
muss.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
vorliegende Erfindung wird nun detaillierter und unter Bezugnahme
auf die beigefügten
Zeichnungen beschrieben werden, in welchen:
-
1 die
Grundschritte zeigt, die in einem Client-Server-Prozess ausgeführt werden.
-
2 die
Schritte zeigt, die in einem Client-Server-Prozess gemäß einem ersten Ausführungsbeispiel
ausgeführt
werden.
-
3 die
Schritte zeigt, die in einem Client-Server-Prozess gemäß einem zweiten Ausführungsbeispiel
ausgeführt
werden.
-
4 die
Schritte zeigt, die in einem Client-Server-Prozess gemäß einem dritten Ausführungsbeispiel
ausgeführt
werden.
-
5 die
Schritte zeigt, die in einem Client-Server-Prozess gemäß einer ersten Alternative des
dritten Ausführungsbeispiels
ausgeführt
werden.
-
6 die
Schritte zeigt, die in einem Client-Server-Prozess gemäß einer zweiten Alternative des
dritten Ausführungsbeispiels
ausgeführt
werden.
-
7 die
Schritte zeigt, die in einem Client-Server-Prozess gemäß einer dritten Alternative des
dritten Ausführungsbeispiels
ausgeführt
werden.
-
8 die
Schritte zeigt, die in einem Client-Server-Prozess gemäß einem vierten Ausführungsbeispiel
ausgeführt
werden.
-
DETAILLIERTE
BESCHREIBUNG
-
In 1 ist
eine grundlegende Interaktion zwischen einem Client und einem Server
gezeigt. Somit fordert der Client zuerst ein Bild an, Schritt 101. Als
Nächstes
beginnt der Server in einem Schritt 103, das Bild zu dem
Client zu übertragen.
Dann fordert der Client zu irgendeiner Zeit während einer Übertragung
einen Teil des Bilds an, das gerade übertragen wird, Schritt 105.
Dann beginnt der Server in Antwort auf die Anforderung im Schritt 105 damit,
den angeforderten Teil zu übertragen,
Schritt 107. Der Client kann auch zusätzliche Teile des Bilds zu
irgendeiner Zeit anfordern, wie es im Schritt 109 angezeigt
ist. Die Übertragung
kann zu irgendeiner Zeit auf einer niedrigeren Protokollebene, wie
beispielsweise TCP oder HTTP, unterbrochen werden.
-
In
der folgenden Beschreibung und in den entsprechenden Zeichnungen
werden die folgenden Definitionen, Syntax und Schreibweisen bzw.
Darstellungen verwendet:
- – Eine Codiereinheit (CU) ist
ein Teil eines Bitstroms, der unabhängig decodierbar ist. Somit
ist es möglich,
einen bestimmten Teil des Bitstroms zu decodieren, ohne den gesamten
Strom decodieren zu müssen.
- – Ein
TAG oder eine Neusynchronisierungsmarkierung ist eine Kombination
aus Bits, die nicht von dem Entropiecodierer erzeugt werden kann.
-
Syntaxelemente
im Client-Server-Prozess
-
Mehrere
detaillierte Fälle
eines grundlegenden Client-Server-Prozesses werden nachfolgend beschrieben.
Sie entsprechen verschiedenen spezifischen Formaten der Syntaxelemente
im Client-Server-Prozess.
-
<Bilddatenanforderung> kann die folgenden Formate
haben:
- – <Bilddatenanforderung
1> = Senden der ersten <Nummer> Unterbänder
- – <Bilddatenanforderung
2> = Senden der ersten <Nummer> Bitebenen
- – <Bilddatenanforderung
3> = Senden der ersten <Nummer> Unterbänder des
ROI <ROI-Nummer> <ROI-Beschreibung>
- – <Bilddatenanforderung
4> = Senden der ersten <Nummer> Bitebenen des ROI <ROI-Nummer> <ROI-Beschreibung>
- – <Bilddatenanforderung
5> = <CU-Sequenz> senden <Beschreiben, welche
CUs angefordert werden>
-
<Bilddatenbestätigung> kann die folgenden Formate
haben:
- – <Bilddatenbestätigung 1> = <Bilddatenbestätigungsmarkierer> Bits/Bytes/CUs, die
empfangen sind <Nummer>
- – <Bilddatenbestätigung 2> = <Bilddatenbestätigungsmarkierer> CUs, die empfangen
sind <Nummer> <CU n1> <CU n2> ... <CU nn>, wobei <Cu n> die Nummer ist, die
zu einer empfangenen CU zugeordnet ist.
-
Die
Version 1 wird bei einem Übertragungsprotokoll
eines erneuten Sendens und eines Ordnens in Paketen verwendet, wie
beispielsweise TCP. Die Version 2 wird bei einem Übertragungsprotokoll
einer verbindungslosen besten Anstrengung, wie beispielsweise UDP,
verwendet.
-
<Bilddaten> können die folgenden Formate haben:
- – <Bilddaten 1> = <CU-Strom> entsprechend der ersten <Nummer> von übrigen Unterbändern
- – <Bilddaten 2> = <CU-Strom> entsprechend der ersten <Nummer> von übrigen Bitebenen
- – <Bilddaten 3> = <CU-Strom> entsprechend der ersten <Nummer> von übrigen Unterbändern des ROI <ROI-Nummer>
- – <Bilddaten 4> = <CU-Strom> entsprechend den ersten übrigen <Nummer> Bitebenen des ROI <ROI-Nummer>
- – <Bilddaten 5> = <CU-Strom> entsprechend den CUs, die in <Bilddatenanforderung
5> spezifiziert sind.
-
Mehrere
unterschiedliche Formate von <CU-Strom> sind möglich:
- – <CU-Strom 1> = <Anfangsblock> <Länge CU1> <Länge
CU2> ... <Länge CUN> <CU1> <CU2> ... <CUN>
- – <CU-Strom 2> = <Anfangsblock> <Länge CU1> <CU1> <Länge CU2> <CU2> ... <Länge CUN> <CUN>
- – <CU-Strom 3> = <Anfangsblock> <Tag
1> <CU1> <Tag 2> <CU2> ... <Tag N> <CUN>
- – <CU-Strom 4> = <Anfangsblock> <CU1> <Tag 1> <CU2> <Tag 2> ... <CUN> <Tag N>
-
Der
Bildanfangsblock ist nicht erforderlich, wenn er vom Client bereits
empfangen worden ist.
-
<Bildtranscodier-Anfangsblock> enthält eine Beschreibung
der Transcodieroperationen, die am ursprünglichen Bild durchgeführt wurden,
um das transcodierte Bild zu erzeugen. Der Client verwendet diese
Information zum Abbilden von CUs vom ursprünglichen Bild zu dem transcodierten
Bild und zum Abbilden von CUs vom transcodierten Bild zum ursprünglichen
Bild.
-
<Bildeingabemitteilung> wird dafür verwendet,
dem Client mitzuteilen, dass das transcodierte Bild beim Server gespeichert
ist. Sie ergibt die URL des transcodierten Bilds. Eine Auszeit kann
optional enthalten sein, was anzeigt, dass das Bild nur für eine spezifizierte
Zeit gesichert sein wird.
-
In 2 ist
ein erstes Ausführungsbeispiel der
vorliegenden Erfindung gezeigt. Somit wünscht in diesem Fall der Client,
auf Teile des gespeicherten Bilds zuzugreifen. Dies könnten bestimmte
Bitebenen, Unterbänder
oder im Voraus gespeicherte Bereiche von Interesse sein. In diesem
Fall verwendet der Server keinerlei speziellen Funktionen zum Antworten
auf die Anforderung, außer
denjenigen, die im Kommunikationsprotokoll (z.B. HTTP) verwendet werden.
Ein Prozess dafür
ist in 2 gezeigt.
-
In
einem Schritt 201 sendet der Client und fordert ein gespeichertes
Bild an. Das Bild ist als komprimierter Bitstrom und in einem Format
mit unabhängig
codierten Codereinheiten (CU) gespeichert. In einem Schritt 203 antwortet
der Server und beginnt die Übertragung.
In einem Schritt 205 entscheidet der Client, dass ein Teil
des Bilds wichtiger ist. Der Client bekommt die Information darüber, wo er
gespeichert ist, vom Bild-Anfangsblock und sendet eine Anforderung
zum Server für
den erwünschten Teil.
Der Teil kann ein ROI oder Bilddaten sein, welche die Qualität des gesamten
Bilds erhöhen.
In einem Schritt 207 kann der Server nun eine Markierung für ein erneutes
Starten senden und startet die Übertragung
der gewünschten
CUs.
-
Die
Funktionalität
eines Markierers für
einen erneuten Start kann auch durch ein niedrigeres Protokoll im
Stapel, wie z.B. TCP oder HTTP, zur Verfügung gestellt werden. Der Markierer
für einen
erneuten Start kann optional ausgeschlossen werden, wenn er aus
Information in den niedrigeren Protokollebenen abgeleitet werden
kann.
-
In 3 ist
ein anderer Typ eines Client-Server-Prozesses gezeigt. In dem in 3 gezeigten Prozess
wird keine fortgeschrittene Verarbeitung auf der Serverseite durchgeführt. Bei
dem in Verbindung mit 3 beschriebenen Beispiel beginnt
ein Client ein Empfangen eines Bildes und entscheidet dann in der
Mitte der Übertragung,
dass irgendein Teil des Bildes vitaler bzw. lebendiger ist und er
nur wünscht, dass
ein Teil übertragen
wird. Dies könnten
eine Anzahl von Bitebenen, Unterbändern oder Bereichen von Interesse
sein. Es sollte beachtet werden, dass das Bild in diesem Fall mit
einem Bereich von Interesse (ROI) gespeichert sein könnte, der
Anwender aber wünscht,
einen andere ROI auszuwählen.
-
In
einem solchen Fall muss der Server einige zusätzliche Funktionen zum Finden
der angeforderten Teile des komprimierten Bilds verwenden. Die Interaktion
zwischen dem Client und dem Server und die Operation bzw. der Betrieb
auf jeder Seite kann dann wie folgt sein, wobei aus Klarheitsgründen Bestätigungsmeldungen
und ähnliche
Meldungen nicht gezeigt sind. Dabei kann man beispielsweise IP, TCP/UDP,
HTTP oder ähnliche
Protokolle für
solche Meldungen verwenden.
-
Bei
einem Schritt 301 sendet ein Client und fordert ein gespeichertes
Bild an. Das Bild ist als komprimierter Bitstrom und in einem Format
mit unabhängig
codierten Codiereinheiten (CU) gespeichert. In einem Schritt 303 antwortet
der Server und beginnt die Übertragung.
In einem Schritt 305 entscheidet der Client, dass ein Teil
des Bilds wichtiger ist, und wenn ein Bereich von Interesse ausgewählt ist,
sendet er auch die Form des ausgewählten Bereichs und einige andere
Informationen, die nötig sind.
Diese könnten
z.B. die chronologische Nummer der Anforderung, die Anzahl von empfangenen
CUs oder Bytes, in 4 mit (*) markiert, sein. An
dieser Stelle hat der Client eine Maske im Transformationsbereich
beispielsweise unter Verwendung des Verfahrens erzeugt, das in Charilaos
Christopoulos (Herausgeber), JPEG 2000 Verification Model Version 1.2,
ISO/IEC JTC1/SC29/WG1 N982, 14. August 1998 beschrieben ist, welches
die Koeffizienten auswählt,
die für
den Server nötig
sind, um zu entscheiden, welche CUs vom Server benötigt werden.
-
In
einem Schritt 307 bekommt der Server die Anforderung. Der
Server verwendet Information im Bitstrom, wie beispielsweise TAGS,
um die erwünschten
CUs zu finden. Der Server sendet nun eine Markierung für einen
erneuten Start, und dann, wenn es nötig ist, die Längen der übrigen CUs.
Er beginnt dann die Übertragung
der angeforderten CUs.
-
Im
Folgenden wird die Situation behandelt, in welcher ein Client ein
Empfangen eines Bilds beginnt und dann in der Mitte der Übertragung
entscheidet, dass ein gewisser Teil des Bilds vitaler ist und er
nur wünscht,
dass ein Teil übertragen
wird. Dies ist auch als Auswahl eines Bereichs von Interesse bekannt. Es
sollte beachtet werden, dass das Bild in diesem Fall mit einem Bereich
von Interesse (ROI) gespeichert werden könnte, der Anwender aber wünscht, einen
anderen ROI auszuwählen.
Beim nachfolgenden Beispiel wird das JPEG2000-Fortschreitend-durch-Auflösung-(PBR)-Schema
verwendet. Ein ähnliches
Verfahren kann jedoch bei Fortschreitend-durch-Genauigkeit-(PBA)-Schemen
angewendet werden, wie es in Charilaos Christopoulos (Herausgeber),
JPEG 2000 Verification Model Version 1.2, ISO/IEC JTC1/SC29/WG1
N982, 14. August 1998, beschrieben ist.
-
In 4 ist
das Fortschreitend-durch-Auflösung-Schema
in JPEG2000 gezeigt. Im PBR-Mode von JPEG2000 kann jedes Unterband
auf eine vereinfachte Weise als Codereinheit CU angesehen werden,
da das gesamte Unterband unabhängig
entropiecodiert ist. Dies ist dann der Fall, wenn der so genannte
nicht adaptive Mode verwendet wird, da ein Unterband in diesem Fall
dasselbe wie eine Sequenz ist. Dies wird es möglich machen, irgendein Unterband
unabhängig
einer Entropiedecodierung zu unterziehen, wenn der Client weiß, wo es
im Bitstrom zu finden ist. Bei dem sehr grundlegenden Mode von JPEG2000
wird dies durch ein Feld unterstützt,
das im Bild-Anfangsblock gespeichert ist, welches die Längen von
jeder-CU in Bits/Bytes enthält.
Somit ist es für
den Client möglich,
den Bitstrom zu zerlegen, da er die Länge jedes entropiecodierten
Unterbands kennt.
-
Der
Client sendet eine Anforderung zu einem Server und fordert ein gespeichertes
Bild an. Das Bild ist als komprimierter Bitstrom gespeichert. Der
Server bekommt den Bitstrom und beginnt die Übertragung. Bei einem bevorzugten
Ausführungsbeispiel
ist die Interaktion zwischen dem Client und dem Server und der Betrieb
auf jeder Seite wie folgt, wobei Bestätigungsmeldungen und ähnliche
Meldungen aus Klarheitsgründen
weggelassen sind.
- – Zuerst sendet der Client
und fordert ein gespeichertes Bild an. Das Bild ist als komprimierter
Bitstrom und in einem CU-Format
gespeichert.
- – Der
Server antwortet dann und beginnt die Übertragung.
- – Bei
irgendeiner Stelle während
der Übertragung entscheidet
der Client, dass ein Teil des Bilds wichtiger ist, und sendet die
Form des ausgewählten
Bereichs und irgendwelche andere Information, die nötig ist.
Diese kann z.B. die chronologische Nummer der Anforderung, die Anzahl
von empfangenen CUs oder Bytes, in 4 mit (*) markiert,
sein.
- – Der
Server bekommt dann die Anforderung für den ROI und führt eine
Entropiedecodierung für die
CUs durch, die nicht gesendet worden sind. In diesem Fall sind es
die Unterbänder,
die noch nicht gesendet worden sind. Die Entropiedecodierung wird
die quantisierten Transformationskoeffizienten ergeben. Der Server
erzeugt eine Maske im Transformationsbereich. Dann kann der Server die
Koeffizienten auswählen,
die für
den Bereich von Interesse nötig
sind, und zwar beispielsweise unter Verwendung des Verfahrens, das
in Charilaos Christopoulos (Herausgeber), JPEG 2000 Verification
Model Version 1.2, ISO/IEC JTC1/SC29/WG1 N982, 14. August 1998,
beschrieben ist. Somit wählt
der Server durch Verwenden der Maske aus, welche Koeffizienten in jedem
der übrigen
Unterbänder
nötig sind.
Die quantisierten Koeffizienten, die zu dem Bereich von Interesse
gehören,
werden dann unterbandweise einer Entropiecodierung unterzogen. Somit wird
dieselbe CU-Struktur beibehalten. Der Server kann nun eine Markierung
für ein
erneutes Starten und die Längen
der zu sendenden CUs senden und beginnt die Übertragung der CUs.
- – Der
Client bekommt die Antwort vom Server, die beschreibt, welcher Typ
von Transcodierung verwendet worden ist. Der Client erzeugt dann
die erwünschte
Maske im Transformationsbereich, beispielsweise unter Verwendung
des Verfahrens, das in Charilaos Christopoulos (Herausgeber), JPEG
2000 Verification Model Version 1.2, ISO/IEC JTC1/SC29/WG1 N982,
14. August 1998 beschrieben ist, das die Koeffizienten auswählt, die
für die
Antwort vom Server nötig
sind.
-
Vom
Standpunkt des Clients aus wird das Ergebnis darin bestehen, dass
der Bereich von Interesse eine vollständige Auflösung haben wird, während der
Hintergrund eine reduzierte Auflösung
haben wird (welche sich in späteren
Stufen verbessern könnte,
wenn das oben beschriebene Verfahren unter Verwendung der Verschiebung
verwendet wird). Das Ausmaß an
Reduzierung eines Verlaufs hängt davon
ab, wann die Anforderung für
einen Bereich von Interesse durchgeführt wurde.
-
Wenn
die Anforderung für
den Bereich von Interesse in der Mitte einer CU eintrifft, was der
wahrscheinlichste Fall sein wird, gibt es zwei Arten zum Weitermachen.
Entweder wird die CU, wo die Anforderung eintrifft, erneut übertragen,
oder wird die Übertragung
der CU beendet und beginnt dann ein erneutes Codieren.
-
Im
Fall des Fortschreitend-durch-Genauigkeit-Modes in JPEG2000 kann
dieselbe Idee wie beim vorherigen Beispiel ohne irgendwelche größeren Änderungen
verwendet werden. In diesem Fall ist eine CU eine Bitebene. Somit
wird der Bitstrom durch Genauigkeit geordnet. Zuerst wird die höchste Bitebene übertragen
und dann die zweithöchste,
und so weiter.
-
Die
Interaktion zwischen dem Client und dem Server und die Operation
auf jeder Seite sind die folgenden, wobei Bestätigungsmeldungen und ähnliche Meldungen
weggelassen sind.
- – Zuerst sendet der Client
und fordert ein gespeichertes Bild an. Das Bild ist als komprimierter
Bitstrom und in einem CU-Format
gespeichert.
- – Der
Server antwortet und beginnt die Übertragung.
- – der
Client entscheidet, dass ein Teil des Bilds wichtiger ist, und sendet
die Form des ausgewählten
Bereichs und irgendwelche andere Information, die nötig ist.
Diese könnte
z.B. die chronologische Nummer der Anforderung, die Anzahl von empfangenen
CUs oder Bytes, in 4 mit (*) markiert, sein. An
dieser Stelle hat der Client eine Maske im Transformationsbereich
beispielsweise unter Verwendung des Verfahrens erzeugt, das in Charilaos
Christopoulos (Herausgeber), JPEG 2000 Verification Model Version
1.2, ISO/IEC JTC1/SC29/WG1 N982, 14. August 1998 beschrieben ist,
welches die Koeffizienten auswählt, die
für die
Antwort vom Server nötig
sind.
- – Der
Server bekommt die Anforderung für
den ROI und führt
eine Entropiedecodierung für
die CUs durch, die nicht gesendet worden sind. In diesem Fall sind
es die Bitebenen, die noch nicht gesendet worden sind. Die Entropiedecodierung wird
die übrigen
Teile der quantisierten Transformationskoeffizienten ergeben. Der
Server erzeugt eine Maske im Transformationsbereich. Dann kann der
Server die Koeffizienten auswählen,
die für
den Bereich von Interesse nötig
sind, und zwar beispielsweise unter Verwendung des Verfahrens, das
in Charilaos Christopoulos (Herausgeber), JPEG 2000 Verification
Model Version 1.2, ISO/IEC JTC1/SC29/WG1 N982, 14. August 1998 beschrieben
ist. Somit wählt
der Server unter Verwendung der Maske aus, welche Koeffizienten
in jeder der Bitebenen nötig
sind. Die übrigen
Teile der quantisierten Koeffizienten, die zu dem Bereich von Interesse
gehören,
werden dann bitebenenweise einer Entropiecodierung unterzogen. Somit
wird dieselbe CU-Struktur beibehalten. Der Server kann nun eine
Markierung für
ein erneutes Starten und die Längen
der zu sendenden CUs senden und beginnt die Übertragung der CUs.
-
Anstatt
dass man eine Reduzierung der Auflösung im Hintergrund hat, wie
beim vorherigen Beispiel, ist die Genauigkeit der Pixel, die nicht
zum Bereich von Interesse gehören,
reduziert. Dies wird durch einfaches Überspringen der übrigen Bitebenen für Bitebenen,
die zum Hintergrund gehören,
durchgeführt.
-
Beim
Empfangen einer Anforderung transcodiert der Server das ursprüngliche
Bild. Das transcodierte Bild wird entweder zu einem Ausgangspuffer gesendet,
nachfolgende Prozesse C1 und C2, oder als neues Bild eingegeben,
nachfolgender Prozess C3. Eine neue Client-Anforderung wird sich
immer auf ein eingegebenes Bild beziehen, und zwar entweder das
ursprüngliche
Bild, wie bei C1 und C2, siehe unten, oder das eingegebene transcodierte
Bild, wie bei C3, siehe unten. Der Client ist verantwortlich für ein Transformieren
zwischen Bildformaten, so dass empfangene Bildinformation in Bezug
auf das ursprüngliche
Bild in der Kopie des Clients des transcodierten Bilds wieder verwendet
werden kann. Eine erfolgreiche Wiederverwendung wird zum Server
in <Bilddatenbestätigung>-Meldungen berichtet.
-
Client-Server-Prozess
C1 (optimiert für
eine Herunterladegeschwindigkeit)
-
Dieser
Prozess könnte
ohne irgendeinen vorherigen Transfer von Bildinformation beginnen. Ein
Client-Server-Prozess gemäß Fällen, die
oben in Zusammenhang mit den 2 oder 3 beschrieben
sind, könnte
jedoch aufgetreten sein. Irgendeine der CUs des ursprünglichen
Bilds könnte
während dieses
Prozesses zum Client transferiert worden sein. Der Client weiß über diese
vorherige Aktivität, aber
der Server speichert keinerlei solche Zustandsinformation.
- – Client-Anforderung
1) <Anforderungsnummer> <Bilddatenbestätigung> <Bilddatenanforderung>
- – Serverantwort
1) <Markierer für erneutes
Starten> <Anforderungsnummer> <Bildtranscodier-Anfangsblock> <Bildanfangsblock> <CU-Strom> (der Anfangsblock
des transcodierten Bilds wird gesendet)
-
Wenn
der Client das neue Format nicht versteht, kann er den Strom auf
der TCP-Ebene unterbrechen. Eine neue Gruppe von Client-Server-Austauschen
kann sich fortsetzen. Sie werden sich immer auf das ursprüngliche
Bild beziehen, da das transcodierte Bild normalerweise nicht vom
Server gehalten wird. Wenn eine neue Anforderung gemäß einem
Fall erfolgt, wird der Server normalerweise die Transcodieroperation
wiederholen. Der Server könnte
entscheiden, eine in einem Cache gespeicherte Kopie des transcodierten
Bilds zu sichern, aber dies kann vom Client nicht angenommen werden.
-
Client-Server-Prozess
C2 (optimiert für
eine niedrige Bandbreite)
-
Dieser
Prozess kann auch ohne irgendeinen vorherigen Transfer von Bildinformation
beginnen. Ein Client-Server-Prozess gemäß Fällen, die oben in Zusammenhang
mit 2 oder 3 beschrieben sind, könnte jedoch
aufgetreten sein. Einige der CUs des ursprünglichen Bilds könnten während dieses Prozesses
zum Client transferiert worden sein. Der Client weiß über diese
vorherige Aktivität,
aber der Server speichert keinerlei solche Zustandsinformation.
- – Clientanforderung
1) <Anforderungsnummer> <Bilddatenbestätigung> <Bilddatenanforderung>
- – Serverantwort
1) <Markierer für erneutes
Starten> <Anforderungsnummer> <Bildtranscodier-Anfangsblock> <Bildanfangsblock> (der Server hat nur den Anfangsblock
des transcodierten Bilds berechnet. Ein vollständiges Transcodieren ist nicht
durchgeführt
worden)
- – Clientanforderung
2) <Anforderungsnummer> <Bilddatenbestätigung> <Bilddatenanforderung> (Der Client bestätigt, dass
er das transcodierte Format handhaben kann. Die Anforderung wird wiederholt,
da der Server die alte Anforderung nicht sichert)
- – Serverantwort
2) <Markierer für erneutes
Starten> <Anforderungsnummer> <CU-Strom> (der Server führt ein vollständiges Transcodieren durch
und sendet den Körper
der Bilddatei zum Ausgangspuffer)
-
Client-Server-Prozess
C3 (ein transcodiertes Bild wird durch den Server eingegeben)
-
Dieser
Prozess könnte
ohne irgendeinen vorherigen Transfer von Bildinformation beginnen. Ein
Client-Server-Prozess gemäß Fällen, die
oben im Zusammenhang mit 2 oder 3 beschrieben sind,
könnte
jedoch aufgetreten sein. Einige der CUs des ursprünglichen
Bilds könnten
während
dieses Prozesses zum Client transferiert worden sein. Der Client
weiß über diese
vorherige Aktivität,
aber der Server speichert keinerlei solche Zustandsinformation.
- – Clientanforderung
1) <Anforderungsnummer> <Bilddatenbestätigung> <Bilddatenanforderung>
- – Serverantwort
1) <Markierer für erneutes
Starten> <Anforderungsnummer> <Bildtranscodier-Anfangsblock> <Bildanfangsblock> <Bildeingabemitteilung>
- – Clientanforderung
2) (Der Client adressiert nun das eingegebene transcodierte Bild
auf der http-Protokollebene) <Anforderungsnummer> <Bildanfangsblockbestätigung> <Bilddatenbestätigung> <Bilddatenanforderung> (Der Client ist verantwortlich
für ein
Transformieren von CUs vom ursprünglichen
Bild zu dem Format des transcodierten Bilds. Das Ergebnis dieser
Operationen wird in <Bilddatenbestätigung> gelegt)
- – Serverantwort
2) <Markierer für erneutes
Starten> <Anforderungsnummer> <CU-Strom>
-
Eine
neue Gruppe von Client-Server-Austauschen kann sich fortsetzen.
Sie können
sich auf das ursprüngliche
oder transcodierte Bild gemäß Entscheidungen
durch den Client beziehen.
-
Es
sollte beachtet werden, dass in einigen Situationen die Anzahl von
empfangenen CUs oder Bits/Bytes nicht nötig ist. Dies ist dann der
Fall, wenn der Client damit fortfährt, Bilddaten zu empfangen, nachdem
die Anforderung(en) gesendet worden ist (sind). Der Server sendet
den Markierer für
erneutes Starten und vielleicht irgendwelche andere Information,
um den Client darüber
zu informieren, dass von nun an die angeforderte Bitebene, das angeforderte Unterband
oder der angeforderte Bereich von Interesse kommt.
-
Nachfolgend
werden zusätzliche
Beispiele einer interaktiven Auswahl von Bereichen von Interesse
während
einer Übertragung von
Bitströmen, wenn
der Strom den erwünschten
Bereich von Interesse nicht enthält,
beschrieben. Die Beispiele stellen die unterschiedlichen Bitstromformate <CU-Strom 1> – <CU-Strom
4> dar.
-
Oben
ist in Zusammenhang mit 4 der PBR-Mode des JPEG2000-Codierers
beschrieben. Eine Modifikation des oben beschriebenen Schemas würde darin
bestehen, die Länge
der CU zusammen mit den Daten zu senden. Somit dann, wenn der Server
die Anforderung für
den ROI bekommt und ein Entropiedecodieren für die CUs durchführt, die
nicht gesendet worden sind. Anstelle eines Sendens eines Markierers
für erneutes
Starten und der Längen
der zu sendenden CUs und eines Beginnens der Übertragung der CUs kann der
Server nun einen Markierer für
erneutes Starten und die Länge
der folgenden CU senden.
-
Der
resultierende Client-Server-Prozess ist in 5 gezeigt.
Dieser wird darin resultieren, dass es keine Notwendigkeit zum erneuten
Senden des Felds von CU-Längen
gibt, wie es in 4 gezeigt ist.
-
Es
ist auch möglich,
TAGS oder Neu- bzw. Resynchronisations-Markierungen im Bitstrom zu verwenden.
Somit kann anstelle eines Habens eines Felds, das die Länge jeder
CU beschreibt, oben in Zusammenhang mit 4, die CU
im Bitstrom durch ein Bitmuster markiert sein, das nicht durch den
Entropiecodierer erzeugt ist. Der Bitstrom wird auf eine sequentielle
Weise durchsucht, um die anderen Codiereinheiten zu finden. Die
Interaktion zwischen dem Client und dem Server und der Betrieb auf
jeder Seite wird so geändert,
dass anstelle eines Sendens eines Markierers für erneutes Starten und der
Längen
der zu senden CUs und eines Beginnens der Übertragung der CUs, der Server
einen Markierer für erneutes
Starten und ein TAG vor der entsprechenden CU senden kann. Der resultierende
Client-Server-Prozess ist in 6 gezeigt.
-
Es
sollte beachtet werden, dass eine alternative Art darin besteht,
ein Senden der TAGs nach jeder CU oder jedem Anfangsblock zu verwenden,
anstatt vor der CU, wie es in 7 gezeigt
ist. Somit ist die Interaktion zwischen dem Client und dem Server und
der Betrieb auf jeder Seite so geändert, dass anstelle eines
Sendens eines Markierers für
erneutes Starten und der Längen
der zu sendenden CUs und eines Beginnens der Übertragung der CUs der Server
einen Markierer für
erneutes Starten und ein TA nach der entsprechenden CU sendet.
-
Eine
weitere Lösung
könnte
darin bestehen, dass "skalierungsbasierte
Verfahren" in JPEG2000 für den Rest
der Unterbänder
zu verwenden. Dies bedeutet, dass die ROI-Maske für die übrigen Unterbänder noch
erzeugt wird, aber kein anderes Codieren der ROI-Maskenkoeffizienten
durchgeführt
werden muss. Die ROI-Maskenkoeffizienten werden durch einen bestimmten
Faktor aufskaliert. Dann wird ein Codieren der Unterbänder sich
ohne Änderungen
fortsetzen. Der Verschiebungswert bzw. Schaltwert muss im Bitstrom
gespeichert werden, so dass der Client nach unten verschieben kann.
Somit wird die Interaktion zwischen dem Client und dem Server und
der Betrieb auf jeder Seite so geändert, dass anstelle eines
Sendens eines Markierers für
erneutes Starten und der Längen
der zu sendenden CUs und eines Beginnens der Übertragung der CUs der Server
nun einen Markierer für
erneutes Starten und einen TAG nach der entsprechenden CU senden kann.
-
Bei
den Schemen, die oben in Zusammenhang mit den 4–7 beschrieben
sind, muss der Server eine Entropiedecodierung und dann eine Entropiecodierung
der quantisierten Koeffizienten durchführen. Dies ist dann nicht so
gut, wenn ein wirklich schneller Zugriff auf unterschiedliche Teile des
Bilds erwünscht
ist.
-
Die
Lösung
für dieses
Problem besteht darin, dass das Bild in Blöcke aufgeteilt wird, die unabhängig decodierbar
sind. Diese werden die CUs sein. Die Interaktion zwischen dem Client
und dem Server und der Betrieb auf jeder Seite sind die folgenden,
wie es in 8 gezeigt ist. Es sollte beachtet
werden, dass Bestätigungsmeldungen
und ähnliche
Meldungen weggelassen sind.
- – Schritt 801,
Der Client sendet und fordert ein gespeichertes Bild an. Das Bild
ist als komprimierter Bitstrom gespeichert.
- – Schritt 803,
Der Server antwortet und beginnt die Übertragung.
- – Schritt 805,
Der Client entscheidet, dass ein Teil des Bilds wichtiger ist, und
erzeugt eine Maske im Transformationsbereich, siehe Ref. 1, die
die benötigten
CUs auswählt.
Die erwünschten
CUs werden zum Server gesendet.
- – Schritt 807,
Der Server beginnt die Anforderung für die CUs. Der Server kann
nun einen Markierer für
erneutes Starten und den TAG dafür
vor seiner entsprechenden CU senden.
-
Das
Verfahren und das System, wie sie hierin beschrieben sind, stellen
eine Anzahl von Vorteilen im Vergleich mit früheren Client-Server-Systemen zum
Wiedergewinnen von Bildern zur Verfügung. Somit benötigt der
Server keinerlei Speicher zum Speichern von Information darüber, welche
Teile er gesendet hat. Beim ersten Ausführungsbeispiel muss der Server
keinerlei Verarbeitung diesbezüglich durchführen, um
dem Client die gewünschten
erwünschten
Teile des Bitstroms zu geben. Der Client wird die Information diesbezüglich, wo
die angeforderten Teile gespeichert sind, aus dem Bildanfangsblock
bekommen. Beim ersten und beim zweiten Ausführungsbeispiel muss der Server
keinerlei Entropiedecodierung durchführen, und er muss nur die angeforderten
CUs senden. Somit erniedrigt sich die Übertragungszeit drastisch.
Beim dritten Ausführungsbeispiel
muss der Server nicht den gesamten Bitstrom decodieren. Dies wird
eine Menge an Zeit auf der Senderseite (Serverseite) einsparen,
da er kein vollständiges
Decodieren des Stroms durchführen
muss.
-
Das
Verfahren und das System, wie sie hierin beschrieben sind, können auch
derart erweitert werden, dass sie zusammen mit einem Videokompressionsalgorithmus
verwendet werden, der unabhängige
decodierbare Einheiten im komprimierten Videostrom hat.