DE69935729T2

DE69935729T2 - Teilauffindung von bildern im kompromierten bereich

Info

Publication number: DE69935729T2
Application number: DE69935729T
Authority: DE
Inventors: Mathias Larsson; Charilaos Christopoulus; Magnus JÄNDEL; Diego Santa Cruz; Touradj Ebrahimi
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1998-10-21
Filing date: 1999-10-13
Publication date: 2007-08-16
Anticipated expiration: 2019-10-14
Also published as: SE9803593L; AU1425200A; EP1127452B1; DE69941743D1; EP1127452A1; JP4764549B2; KR100595400B1; CN1166171C; KR20010085937A; US7571382B2; US20030110299A1; AU766874B2; WO2000024188A1; DE69935729D1; CA2348622A1; CA2348622C; SE513353C2; JP2002528969A; SE9803593D0; EP1715672B1

Description

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.

Claims

Verfahren zum Übertragen eines Bilds, das als Anzahl von unabhängig decodierbaren Codiereinheiten gespeichert ist, zwischen einem Server und einem Client, wobei das Verfahren die folgenden Schritte aufweist: – Übertragen (101) einer Anforderung für Bilddaten vom Client zum Server, – Beginnen einer Übertragung (103) der angeforderten Bilddaten vom Server zum Client, – Übertragen (105) einer Anforderung für einen neuen Teil des Bilds während oder nach seiner Übertragung, wobei die Anforderung Information darüber aufweist, an welcher Bildinformation der Client interessiert ist, und auf welche Information über das Bild der Client bereits einen Zugriff hat, und – Übertragen (107) des angeforderten neuen Teils des Bilds vom Server zum Client unter Verwendung von Nur-Codiereinheiten, die nicht bereits übertragen sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Bild im Transformationsbereich gespeichert wird.
Verfahren nach einem der Ansprüche 1–2, dadurch gekennzeichnet, dass jede Anforderung vom Client eine Anforderungsnummer aufweist.
Verfahren nach einem der Ansprüche 1–3, dadurch gekennzeichnet, der Server, nachdem er angeforderte Information zum Client übertragen hat, direkt alle Information wegwirft, die vom Client geliefert ist.
Verfahren nach einem der Ansprüche 1–4, dadurch gekennzeichnet, dass der Server einen Markierercode vor einem Übertragen von angeforderten Codiereinheiten überträgt.
Verfahren nach einem der Ansprüche 1–5, dadurch gekennzeichnet, der Server eine Transcodierung vor einem Übertragen des neuen Bildteils durchführt.
Server in Verbindung mit einem Client, wobei Bilder als Anzahl von Codiereinheiten im Server gespeichert sind, wobei der Server folgendes aufweist: – eine Einrichtung zum Empfangen einer Anforderung für Bilddaten vom Client, – eine Einrichtung zum Übertragen der angeforderten Bilddaten zum Client, – eine Einrichtung zum Empfangen einer Anforderung für einen neuen Teil des Bilds während oder nach seiner Übertragung, wobei die Anforderung vom Client Information darüber aufweist, an welcher Bildinformation der Client interessiert ist, und auf welche Information über das Bild der Client bereits einen Zugriff hat, und – eine Einrichtung zum Übertragen des angeforderten neuen Teils des Bilds zum Client unter Verwendung von Nur-Codiereinheiten, die nicht bereits übertragen sind.
Server nach Anspruch 7, gekennzeichnet durch eine Einrichtung zum Speichern der Bilder im Transformationsbereich.
Server nach einem der Ansprüche 7–8, wobei jede Anforderung vom Client eine Anforderungsnummer aufweist.
Server nach einem der Ansprüche 7–9, dadurch gekennzeichnet, dass der Server angeordnet und eingerichtet ist, direkt alle Information wegzuwerfen, die durch einen Client geliefert ist, nachdem er sie verarbeitet hat.
Server nach einem der Ansprüche 7–10, dadurch gekennzeichnet, dass der Server angeordnet und eingerichtet ist, einen Markierercode vor einem Übertragen von angeforderten Codiereinheiten zu übertragen.
Server nach einem der Ansprüche 7–11, dadurch gekennzeichnet, dass der Server angeordnet und eingerichtet ist, ein Transcodieren der Codiereinheiten durchzuführen, die nicht bereits übertragen sind, vor einem Übertragen des neuen Bildteils.