1

Transmision de secuencias de imagenes JPEG 2000usando actualizacion condicional controlada por el

clienteJose Juan Sanchez Hernandez

Director: Vicente Gonzalez Ruiz

Resumen—Este trabajo propone una estrategia parala visualizacion remota e interactiva de secuencias deimagenes JPEG 2000 de alta resolucion. Las secuenciaspueden ser visualizadas en cualquier orden (hacia delante yhacia atras) y siguiendo cualquier patron de reproducciony temporizacion (por ejemplo, parando y continuandola reconstruccion de la secuencia despues de un tiempoindefinido y en cualquier parte de esta). Ademas por unrequerimiento del procedimiento de visualizacion, el rangode imagenes que forman estas secuencias es tıpicamentedefinido en el instante de la visualizacion, lo que implicaque previamente no ha sido posible aplicar ningun procesode compresion que explote la redundancia temporal. Sinembargo, cierta cantidad de redundancia temporal existehabitualmente en estas secuencias. Para incrementar lacalidad de la reconstruccion explotando esta fuente deredundancia, en este trabajo se presenta y se evaluaun algoritmo de actualizacion condicional de imagenes.Nuestra solucion se beneficia de la escalabilidad de tipoSNR y espacial que ofrece el estandar JPEG 2000 paradeterminar que regiones de la siguiente imagen deben sertransmitidas y que otras regiones pueden ser reutilizadasde la imagen previamente reconstruida. Los resultadosdemuestran que, incluso sin compensacion de movimientoy con una transmision controlada exclusivamente porel cliente, las reconstrucciones son mejores de formaconsistente, tanto desde un punto de vista visual comoatendiendo a la curva rate-distortion, cuando comparamoscon aquellas tecnicas que solo eliminan la redundanciaespacial. Otras ventajas de nuestra propuesta son: 1) queno se genera un overhead de datos durante la transmision,2) que el incremento en complejidad computacional esmuy pequeno en comparacion con tecnicas similares y 3)es completamente compatible con cualquier servidor JPIPestandar.

Palabras clave—JPEG 2000, actualizacion condicional,transmision de vıdeo.

I. INTRODUCCION

ENTRE las principales caracterısticas delestandar JPEG 2000 [1] podemos destacar una

alta eficiencia en la compresion de imagenes con

y sin perdida, la posibilidad de poder acceder deforma aleatoria al code-stream comprimido sin tenerque transmitir toda la imagen, la realizacion deuna descompresion progresiva de la imagen y unagran escalabilidad en resolucion y calidad. Estascaracterısticas hacen que JPEG 2000 sea el estadodel arte para la exploracion de imagenes remotas degran resolucion. Usando el protocolo JPIP (JPEG2000 Interactive Protocol), definido en la Parte 9[2] del estandar JPEG 2000, los clientes puedenexplorar interactivamente imagenes remotas especi-ficando una ventana de interes, a la que llamaremosa partir de ahora en este documento solo WOI(Window Of Interest). Este intercambio de datosentre cliente y servidor, usa todo el ancho de bandadisponible de una forma eficiente y no requierede ninguna codificacion o proceso adicional. Elservidor extrae solamente los datos requeridos de lasimagenes solicitadas y los transmite a sus clientes.

JPEG 2000 ha sido usado satisfactoriamente enmuchas areas cientıficas como por ejemplo, tele-microscopıa o tele-medicina. Una aplicacion prom-etedora en las ciencias del espacio es el proyectoJHelioviewer [3], desarrollado por la Agencia Espa-cial Europea (ESA) [4] en colaboracion con la Ad-ministracion Nacional de Aeronautica y del Espaciode los Estados Unidos (NASA) [5]. Su principalobjetivo es ofrecer una exploracion interactiva de lasimagenes que son enviadas por el observatorio solarSDO (Solar Dynamics Observatory) [6] a la tierra.El observatorio SDO recoge imagenes del sol cada12 segundos en diez bandas espectrales ultravioletasdiferentes con una resolucion de 4096× 4096 pıxe-les, lo que quiere decir que envıa aproximadamentela cantidad de 1.4 TBytes de imagenes por dıa.

Desde un punto de vista cientıfico, este elevadovolumen de datos plantea varios problemas comopueden ser el acceso a los datos y la exploracion

2

de las imagenes de una forma eficiente. Hoy endıa, la combinacion del protocolo JPIP y el estandarde compresion JPEG 2000 parece ofrecer la mejorsolucion para poder examinar de forma eficientevolumenes de datos de esta magnitud.

La funcionalidad basica de JHelioviewer es per-mitir a los usuarios la exploracion de imagenessolares en un determinado instante de tiempo odentro de un rango de tiempo establecido. Losusuarios pueden solicitar toda la imagen o puedenestablecer una WOI, tambien se pueden moversuavemente a traves de una secuencia de imagenessolares, mientras se van visualizando los cambiosque producidos en la WOI a lo largo del tiempo delrango establecido.

La comunicacion cliente/servidor esta basada enel intercambio de peticiones y respuestas. Con cadapeticion, el cliente especifica, entre otros paramet-ros, el nombre del archivo remoto que quiere visu-alizar y una determinada WOI. Los archivos puedencontener una secuencia de N imagenes diferentes(en el caso de JHelioviewer, se corresponden aimagenes comprendidas en un determinado rango detiempo), ası que las peticiones deben incluir el rangode imagenes deseado [a, b], con 0 ≤ a ≤ b ≤ N−1.Sin ninguna interaccion extra del usuario, se debeobtener la misma WOI para todas las imagenescomprendidas dentro del rango.

Este trabajo por lo tanto se centra en aplica-ciones que hagan uso del protocolo JPIP, como esel caso de JHelioviewer, que han sido disenadaspara explorar secuencias de imagenes remotas. Lafigura 1 muestra un ejemplo de cinco instantesde tiempo durante una sesion de exploracion deimagenes remotas usando JHelioviewer. Una vezque el usuario ha seleccionado un rango de tiempo,el servidor construye un archivo JPEG 2000 virtualque contiene solamente enlaces a aquellas imagenescuya fecha y hora pertenecen al rango de tiempoespecificado. El cliente inicia una sesion JPIP paraeste archivo y solicita la primera imagen, que esmostrada en el instante de tiempo t0. El usuariopuede visualizar la secuencia de imagenes que estancomprendidas dentro del rango de tiempo, una auna, o saltando a cualquier imagen de la secuencia,y cambiando la direccion en cualquier momento. Eneste ejemplo, en el instante de tiempo t2 el usuariohace zoom sobre una cierta region de la imagen,cambiando de este modo la WOI actual. Desde estanueva WOI, el usuario continua moviendose hacia

delante continuando la secuencia, en los instantesde tiempo t3 y t4. En el “modo vıdeo”, donde lasimagenes son visualizadas sin ninguna pausa paraun frame-rate que el usuario puede controlar, lacantidad de datos que se obtienen del servidor JPIPdepende del ancho de banda disponible y del frame-rate establecido. En cualquier caso, las imagenesson transmitidas siguiendo una progresion en ordende calidad de modo que se va incrementando lacalidad de las reconstrucciones al mismo tiempo quese van recibiendo los datos del servidor.

El hecho de que el observatorio SDO tomeimagenes del sol a una alta frecuencia temporal,provoca que exista una gran correlacion espacialentre las imagenes consecutivas, alrededor de 33dBen terminos de PSNR (Peak Signal-to-Noise Ratio)como media entre imagenes1, y por lo tanto, unalto grado de redundancia temporal. Por esta razon,hemos centrado este trabajo en la eliminacion deesta redundancia haciendo uso de la tecnica deactualizacion condicional.

II. ARQUITECTURA JHELIOVIEWER

La figura 2 muestra un diagrama con la arqui-tectura de la aplicacion JHelioviewer. JHeliovieweresta basado en una arquitectura cliente/servidor,donde la comunicacion que se realiza entre elbrowser de la parte cliente y el servidor JPIPesta basada en mensajes de peticion y respuesta us-ando el protocolo JPIP, que viaja encapsulado dentrodel protocolo HTTP. Las imagenes JPEG 2000 estanalmacenadas en un repositorio de imagenes, mien-tras que los metadatos de las imagenes se encuen-tran en otro repositorio diferente. Este repositoriocontiene informacion de interes sobre las obser-vaciones realizadas en las imagenes JPEG 2000.El repositorio con los metadatos de las imagenespuede estar integrado directamente en el servidorde imagenes o puede interactuar como un elementoindependiente.

Cada elemento de la arquitectura JHelioviewerincluye a su vez varios elementos. De este modo, elbrowser incluye una interfaz de usuario, un decod-ificador de imagenes, un gestor de capas y eventos,

1Este valor ha sido determinado haciendo la media del PSNR deuna imagen respecto a la siguiente, en una secuencia de imagenestomadas con una cadencia de 432 segundos. Sin embargo, el obser-vatorio SDO ofrece la posibilidad de obtener imagenes con una mayorcadencia, aproximadamente cada 12 segundos lo que implicarıa aunmayores ındices de correlacion temporal.

3

t0 t1 t2 t3 t4

Figura 1. Un ejemplo donde se muestran diferentes instantes de tiempo de una sesion de exploracion de imagenes remotas.

un manejador de metadatos y una cache local deimagenes. El servidor contiene un parser JPEG2000 y un repositorio de imagenes JPEG 2000.

A continuacion se detalla la funcionalidad de cadauno de los elementos que interactuan en el browserdel lado del cliente:

La interfaz de usuario es la encargadade mostrar las imagenes y las animaciones.Tambien permite realizar algunas operacionesbasicas de procesamiento de imagenes.

La cache local de imagenes contiene unacache con los datos que han sido transmitidospor el servidor previamente.

El gestor de capas permite al usuario laposibilidad superponer capas con diferentesimagenes JPEG 2000.

El gestor de eventos solares interactua inter-namente con el gestor de capas y externamentecon el repositorio de eventos a traves de unWeb Service.

El renderizador de imagen recibe el streamJPIP con las cabeceras de la imagen y ren-deriza la peticion del usuario a la resolucionsolicitada.

Los elementos del lado del servidor incluyen lassiguientes funcionalidades:

El parser recibe una peticion de una imagencon una serie de parametros (como por ejem-plo: tamano de la ventana, offset, capas decalidad o niveles de resolucion). Este consultael repositorio de imagenes y devuelve unarespuesta al cliente con los datos solicitadosen forma de stream JPIP.

El repositorio de imagenes es un sistema dearchivos que almacena imagenes comprimidasen JPEG 2000 usando una estructura de di-rectorio jerarquico. Los metadatos asociados acada una de las imagenes (como por ejemplo:

fecha/hora de la observacion, instrumento, de-tector y observatorio) son almacenados en elcatalogo de metadatos.

El modelo de cache del cliente contiene in-formacion sobre la cache local de cada cliente.El parser utiliza esta informacion para evitarvolver a enviar informacion que ya ha sido en-viada al cliente y ya se encuentra almacenadaen la cache del cliente.

El catalogo de metadatos esta almacenado en unabase de datos relacional y es accesible a traves deun Web Service. El motivo de separar este catalogode metadatos del servidor JPIP fue para evitar queel rendimiento del servidor se viese afectado por elfuncionamiento de este.

El catalogo de eventos solares permite a losusuarios consultar y visualizar eventos solares decierta relevancia.

III. EL ESTANDAR JPEG 2000JPEG 2000 es un estandar de compresion y

codificacion digital de imagenes, que fue creado porel grupo JPEG (Joint Photographic Experts Group).En Marzo de 1997 los expertos en fotografıa delgrupo JPEG propusieron desarrollar un nuevo sis-tema de compresion de imagenes digitales, con laintencion de sustituir el formato original, cuyo nom-bre esta formado por las iniciales del grupo JPEG.Este nuevo sistema de compresion debıa resolver lascarencias que presentaba el actual formato JPEG,utilizar la Transformada Discreta Wavelet o DWT(Discrete Wavelet Transform) y cubrir las nuevasnecesidades que iban apareciendo con el avance delas nuevas tecnologıas.

Despues de mas de dos anos evaluando todaslas propuestas recibidas, una version modificadadel algoritmo EBCOT (Embedded Block Codingwith Optimized Truncation), desarrollado por DavidTaubman, fue finalmente la propuesta elegida comoel nucleo del nuevo estandar de compresion. Este

4

Servidor JHelioviewer

JPEG 2000

Parser

Modelo de cache

JPEG 2000

del cliente

Manejador demetadatos

Interfaz

de

usuario

JHelioviewer Browser

Gestor deeventos solares

Gestor decapas

Renderizador deimagenes

Cache local

Repositorio de imagenes

Peticion WOI

data-bins

Catalogo deMetadatos

Peticion

Metadatos

eventos solaresCatalogo deWeb Service

Peticion

Datos

Servidor de eventos solares

Figura 2. Arquitectura JHelioviewer. La arquitectura incluye tres partes basicas, el browser (cliente), el servidor JPIP y el servidor deeventos solares. El catalogo de metadatos se puede considerar que es un elemento que forma parte del servidor JPIP

nucleo fue complementado con la definicion de unnuevo formato de archivo, y una forma eficientede particionar los datos con el objetivo de sacarel maximo partido a la escalabilidad que ofreceel algoritmo EBCOT. Todo esto fue la base delnuevo estandar, que fue llamado JPEG 2000. Estaprimera parte son los requisitos mınimos requeridospor cualquier implementacion de este estandar.

Desde un punto de vista formal, podemos decirque JPEG 2000 esta dividido en 11 partes diferentes:

Parte 1: Describe los mınimos requisitos quedebe tener un codificador JPEG 2000. El ob-jetivo de esta parte es crear un conjunto deoperaciones basicas con el mayor grado deinteroperabilidad entre las diferentes imple-mentaciones del estandar.

Parte 2: Contiene extensiones opcionales quemejoran el rendimiento en algunos campos, delsistema basico de codificacion.

Parte 3: Hace referencia a “Motion JPEG2000”, un estandar para el vıdeo digital de alta

calidad.

Parte 4: Es un conjunto de pruebas de ver-ificacion que tienen el fin de certificar losprocesos de codificacion y decodificacion delestandar.

Parte 5: Conjunto de modelos software quedeben ser usados como referencia en el desar-rollo de productos JPEG 2000.

Parte 6: Su objetivo es establecer un conjuntode especificaciones para el uso de JPEG 2000en diferentes aplicaciones como puede ser elfax, publicaciones electronicas y aplicacionesnumericas.

Parte 7: Esta parte ha sido abandonada.

Parte 8: JPSEC (JPEG 2000 Secure). Estaparte se ocupa de aspectos de seguridad paraJPEG 2000 como puede ser la encriptacion, lasmarcas de agua, etc.

Parte 9: JPIP, protocolos interactivos y APIs(Application Protocol Interfaces). Esta parte

5

Figura 3. Screenshot de la aplicacion JHelioviewer. A la izquierda-centro de la imagen se puede ver el gestor de capas y los controles delmodo vıdeo.

define un protocolo interactivo de red y las her-ramientas especıficas para realizar el intercam-bio de imagenes JPEG 2000 y sus metadatos,de forma eficiente.

Parte 10: JP3D, imagenes volumetricas. Estaparte desarrolla aspectos como la reconstruc-cion de imagenes medicas en 3D.

Parte 11: Wireless JPWL. Esta parte hace ref-erencia a las aplicaciones wireless multimedia.Su objetivo es la deteccion y correccion deerrores JPEG 2000 en un entorno propenso aerrores.

III-A. CaracterısticasAlgunas de las caracterısticas que hacen que

este estandar sea el ideal para la codificacion ytransmision de imagenes son las siguientes:

Ofrece altos ratios de compresion, en terminosde calidad visual y PSNR (Peak Signal-to-Noise Ratio) a bit-rates muy pequenos. Inclusopor debajo de 0.25 bits/pıxel ofrece mejoresresultados que el algoritmo JPEG Baseline.

Es muy robusto ante la presencia de erroresy tiene capacidad de recuperacion ante losmismos.

Permite realizar compresion sin perdidas y conperdidas.

Permite acceder de forma aleatoria al code-

6

stream. De este modo es posible manipularciertas zonas de la imagen o regiones de in-teres.

Ofrece escalabilidad por resolucion y calidad.Es posible organizar el code-stream de modoque las reconstrucciones de la imagen vayanincrementando su calidad a medida que seva recibiendo mayor numero de bits. Esto esposible debido una decodificacion progresivapor planos de bits, donde vamos decodificandodesde el plano de bits mas significativo hastael menos significativo. El code-stream tambiense puede organizar por niveles de resolucion,de modo que vayamos incrementando el nivelde resolucion de las reconstrucciones de laimagen a medida que recibimos mayor numerode bits.

Permite la codificacion de regiones de in-teres (ROI) dentro de la imagen. El usuariopuede seleccionar determinadas regiones dela imagen para que sean codificadas con unamayor precision que el resto de la imagen. Porejemplo, un medico puede encontrar una ciertaregion (o varias regiones) de una radiografıadigital mas interesante que otras regiones. Porlo tanto, es posible comprimir la radiografıadigital de tal manera que la region de interesse comprima sin perdidas y el resto de laimagen con perdidas, de modo que podamosalmacenarla con el tamano de archivo deseado.

El estandar JPEG 2000 permite al usuarioseleccionar el tamano que desea que tenga elarchivo comprimido. Esto es posible porque elproceso de compresion se realiza por planos debits, de modo que el proceso es interrumpidocuando se alcanza el tamano deseado.

Dispone de un formato de archivo muy sencilloy flexible.

De todas las caracterısticas comentadas anterior-mente, la alta escalabilidad por resolucion y cal-idad son quizas las mas atractivas de todas. Laescalabilidad por resolucion permite al servidor ex-traer solamente los datos necesarios para reconstruiruna WOI especıfica, sin ningun procesamiento adi-cional. Gracias a la transformada DWT las imagenesson almacenadas con una representacion con multi-ples niveles de resolucion espacial, de modo que

un cliente puede obtener una WOI, a un bajo nivelde resolucion sin ningun procesamiento adicional.La escalabilidad en calidad permite al usuario vi-sualizar las reconstrucciones de las regiones so-licitadas con una calidad que va incrementandosea medida que se van recibiendo mas datos delservidor. Hoy en dıa no existe otro estandar queofrezca estas posibilidades.

III-B. Particiones de los datosEl estandar JPEG 2000 define una amplia var-

iedad de particiones para los datos de la imagen, conel objetivo de explotar al maximo la escalabilidadofrecida. Todos estos tipos de particiones permitenuna manipulacion eficiente de la imagen, o de partede esta. La figura 4 muestra un ejemplo grafico delas principales particiones que se pueden realizar.

Con el objetivo de comprender el concepto decada particion definida en el estandar JPEG 2000, esnecesario aclarar el concepto de canvas. El canvases una zona de dos dimensiones donde se mapeantodas las particiones relacionadas con la imagen. Apartir de ahora en adelante, todo el sistema de co-ordenadas utilizado esta relacionado con el canvas,cuyo tamano, ancho (I2) y alto (I1), se correspondencon el tamano total de la imagen asociada. Cadaparticion esta situada y mapeada sobre el canvasde una forma especıfica. Una imagen puede estarcompuesta por una o mas componentes. En lamayorıa de los casos las imagenes solamente tienentres componentes: rojo, verde y azul (RGB), con untamano igual al tamano del canvas.

El estandar JPEG 2000 permite dividir una im-agen en pequenas regiones rectangulares llamadastiles. Cada tile esta comprimido de forma indepen-diente respecto al resto, por lo tanto los parametrosutilizados durante el proceso de compresion puedenser diferentes para los distintos tiles. Por defectosiempre se utiliza un unico tile, que equivale a todala imagen.

Otra de las posibles aplicaciones del uso de lasparticiones en tiles es con imagenes que contienendiferentes elementos y estan visualmente separa-dos, como puede ser texto, graficos o materialesfotograficos. Cuando esto no sea ası, y las imagenessean continuas y homogeneas, no es recomendadoel uso de tiles porque este produce artefactos en losbordes de los tiles, causando el efecto de mosaico.Ademas, el tamano de imagen comprimida es mu-cho mayor si se usan tiles.

7

components

canvas

image

tile

precincttile-component

resolutionscode-block

Figura 4. Particiones de los datos definidas por el estandar JPEG 2000.

La transformada DWT y todas las etapas decuantificacion/codificacion son aplicadas de formaindependiente a cada uno de los tile-component. Untile-component, de un tile t y una componente c,esta definido por una zona bidimensional limitadapor t tomando en cuenta la zona ocupada por c.Esto quiere decir que, si una imagen tiene solamenteun tile, con tres componentes de color, hay trestile-components, que son comprimidas de formaindependiente.

Para cada tile-component, identificado por el tilet y la componente c, hay un total de Dt,c + 1resoluciones, donde Dt,c es el numero de etapasaplicadas en la DWT. El r-esimo nivel de resolu-cion de un tile-component comprimido se obtienedespues de aplicar r veces la transformada inversaDWT. El valor de r esta comprendido en el rango0 ≤ r ≤ Dt,c.

Cada tile-component, despues de aplicar la trans-formada DWT, es dividido en code-blocks, que soncodificados independientemente. En cada nivel deresolucion r de cada tile-component (t, c), los code-blocks son agrupados en precincts. Esta particionesta definida por el alto, P t,c,r

1 , y el ancho, P t,c,r2 , de

cada precinct. El numero de precincts en vertical,NP,t,c,r

1 , como en horizontal, NP,t,c,r2 viene dado por

la siguiente expresion:

NP,t,c,ri =

⌈Ii

2Dt,c−rP t,c,ri

⌉Los code-blocks hacen referencia a los coe-

ficientes wavelet generados por la transformada

DWT, en el dominio wavelet. Sin embargo, losprecincts hacen referencia a regiones rectangularesen el dominio de la imagen. La escalabilidad espa-cial ofrecida por el estandar es llevada a cabo porlos precincts.

El paquete es la unidad fundamental para la orga-nizacion del bit-stream comprimido de una imagen.Cada precinct contribuye al bit-stream con tantospaquetes como capas de calidad haya. Los datoscomprimidos de cada code-block estan divididosen diferentes segmentos llamados capas de calidad.Todos los code-blocks de todos los precincts delmismo tile estan divididos en el mismo numero decapas de calidad, ademas el numero de capas decalidad entre code-blocks puede ser diferente. Parauna cierta capa l, el conjunto de todas las capas lde todos los code-blocks relacionados con un mismoprecinct forman un paquete.

Para decodificar una determinada region de unaimagen es necesario decodificar todos los paquetesrelacionados con esa region.

Un paquete ζt,c,r,p,l esta identificado por el tile t,la componente c, el nivel de resolucion r, el precinctp (en coordenadas de precincts) y la capa de calidadl.

III-C. Organizacion del Code-stream

La Parte 1 del estandar JPEG 2000 define laestructura basica para organizar los datos comprim-idos de una imagen en code-streams. Un code-stream incluye todos los paquetes por el proceso de

8

compresion de una imagen mas un conjunto de mar-cadores, que se utilizan para senalar ciertas partes,ası como para incluir la informacion necesaria pararealizar la descompresion.

El code-stream es un sencillo formato de archivopara una imagen JPEG 2000. Cualquier descom-presor estandar deberıa entender un code-streamalmacenado en un archivo. A este formato basicode archivo tambien se le conoce como formato raw,y se suele utilizar con la extension “.J2C”.

Los marcadores tienen un unico identificador, queconsiste en un entero sin signo de 16 bits. Estosmarcadores pueden aparecer solos, o acompanadosde informacion adicional. Cuando un marcador vaacompanado de informacion adicional se le conocecomo marcador de segmento.

Los marcadores de segmento tienen, despuesdel identificador, otro entero sin signo de 16 bitsindicando el numero de bytes de los datos queacompanan al marcador, incluyendo tambien los dosbytes de este entero, pero sin contar los dos bytesdel identificador.

El code-stream siempre empieza con el mar-cador SOC (Start Of Code-stream), el cual nocontiene ninguna informacion adicional. Despuesde este marcador aparecen un conjunto de mar-cadores conocidos como cabecera principal. De-spues del marcador SOC siempre hay un marcadorSIZ (Image and tile Size), con la informacion globalnecesaria para poder descomprimir los datos, porejemplo: el tamano de la imagen, el tamano de lostiles, el punto de anclaje de los tiles, el numero decomponentes, los factores de sub-muestreo, etc.

Hay otros dos marcadores que deben aparecerde forma obligatoria en la cabecera: COD (Codingstyle Default), con la informacion relacionada ala codificacion de la imagen, como el numero decapas de calidad, el numero de etapas DWT, eltamano de los code-blocks, el tipo de progresion,etc.; y QCD (Quantization Default), que contienelos parametros de cuantificacion. Estos dos mar-cadores pueden aparecer en cualquier posicion dela cabecera principal, no importa en que orden perodeben aparecer.

El resto del code-stream, hasta la aparicion delmarcador EOC (End Of Code-stream), que debeaparecer justo al final, esta organizado como semuestra en la figura 5. Para cada tile de la imagen,hay un conjunto de datos. Este conjunto de datosse divide en uno o mas tile-parts. Cada tile-part

· · ·SOT

SOD

· · ·

· · ·

· · ·

· · ·

· · ·

SOC

SIZ

COD

QCD

SOC

· · ·SOT

SOD

· · ·SOT

SOD

packet

packet

· · ·

packet

· · ·packet

packet

· · ·packet

tile

tile

tile

tile

primer tile-part

Cabecera del

tile-part

tile-part

tile-part

Cabecera del

tile-part

tile-part

Cabecera del

Figura 5. Organizacion del code-stream de un fichero JPEG 2000.

esta compuesto por una cabecera y un conjuntode paquetes. La cabecera del primer tile-part es lacabecera principal del tile. La cabecera de cada tile-part empieza con el marcador SOT (Start Of Tile)y termina con el marcador SOD (Start Of Data),que es cuando empieza la secuencia de paquetes.La cabecera principal termina cuando se encuentrael primer marcador SOT.

Con el fin de permitir un acceso aleatorio alos datos del code-stream, JPEG 2000 ofrece laposibilidad de incluir los marcadores TLM (Tile-part Lengths, Main header), PLM (Packet Length,Main header) y/o PLT (Packet Length, Tile-partheader). Los marcadores TLM y PLM se incluyenen la cabecera principal, mientras que el marcadorPLT se incluye en la cabecera de un tile o untile-part. El objetivo de los marcadores TLM esalmacenar el tamano de cada tile-part que apareceen el code-stream. Este tamano incluye la cabeceray el conjunto de paquetes, de modo que para cono-cer donde esta el inicio de los datos es necesarioanalizar primeramente la cabecera. El marcadorPLM almacena el tamano de cada paquete de cadatile-part de cada code-stream. Cada paquete delcode-stream tiene un determinado tamano, que nopuede ser conocido a priori. Por lo tanto la inclusion

9

Cuadro IMARCADORES UTILIZADOS EN EL code-stream DE JPEG 2000.

Nombre ValorDelimiting Marker SegmentsStart of Codestream SOC 0xFF4FStart of tile-part SOT 0xFF90Start of data SOD 0xFF93End of code-stream EOC 0xFFD9Fixed Info Marker SegmentsImage and tile size SIZ 0xFF51Functional Marker SegmentsCoding style default COD 0xFF52Coding style component COC 0xFF53Region of interest RGN 0xFF5EQuantization default QCD 0xFF5CQuantization component QCC 0xFF5DProgression order default POD 0xFF5FPointer Marker SegmentsTile-part lengths, main header TLM 0xFF55Packet length, main header PLM 0xFF57Packet length, tile-part header PLT 0xFF58Packed packet header, main header PPM 0xFF60Packed packet header, tile-part header PPT 0xFF61In Bitstream Marker SegmentsStart of packet SOP 0xFF91End of packet header EPH 0xFF92Informational Marker SegmentComment and extension CME 0xFF64

de este marcador facilita el acceso aleatorio a lospaquetes. El marcador PLT tiene la misma funcionque el marcador PLM, pero a nivel de tile-part,de modo que este almacena el tamano de todoslos paquetes que pertenecen a un tile-part. Estemarcador es mas usado que el marcador PLM.

Los marcadores PLM y PLT producen un in-cremento del tamano del code-stream, ademas laforma de codificar el tamano de los paquetes ayudaa evitar excesivo overhead: un tamano L de undeterminado paquete, que puede ser representadocon BL bits, y es almacenado/codificado con

⌈BL

7

⌉bytes. Para un tamano L se genera una secuencia debytes donde solamente son usados los 7 bits menossignificativos. El bit mas significativo de cada byteindica si es (1) o no (0) el ultimo de la secuencia.Esta forma de codificar es bastante utilizada en laParte 9 del estandar, especialmente con el protocoloJPIP, donde se le conoce como VBAS (VariableByte-Aligned Segment).

III-D. ProgresionesLos paquetes generados en el proceso de compre-

sion JPEG 2000 no son independientes ni autosufi-cientes. Con un solo paquete y sin ningun tipo infor-

macion adicional, es imposible averiguar a que partede la imagen pertenece dicho paquete. El tamano delpaquete no puede ser determinado antes de realizarel proceso de compresion, y muchos paquetes nopueden ser descomprimidos si previamente no sehan descomprimido otros paquetes primero. Este esel principal motivo por el que es necesario el usode marcadores como TLM, PLT o PLM, que nospermiten acceder de forma aleatoria a los datos sintener que descomprimirlos.

Los paquetes de cada tile-part aparecen de acuer-do a la progresion especificada por el ultimo mar-cador COD o POD que se ha leıdo, antes delmarcador SOD. La Parte 1 del estandar JPEG 2000define cinco posibles tipos de progresiones paraordenar los paquetes dentro de un tile o tile-part.Cada progresion se identifica por medio de unacombinacion de cuatro letras: “L” para las capasde calidad, “R” para los niveles de resolucion, “C”para las componentes y “P” para los precincts.Cada letra identifica la particion de la progresion. Acontinuacion se muestran las diferentes progresionespermitidas en el estandar, y el orden en el queaparecerıan los paquetes en cada caso.

10

Progresion LRCP(Layer-Resolution-Component-Position)

for each layer lfor each resolution r

for each component cfor each precinct p

include the packet ζt,c,r,p,l

Progresion RLCP(Resolution-Layer-Component-Position)

for each layer rfor each resolution l

for each component cfor each precinct p

include the packet ζt,c,r,p,l

Progresion RPCL(Resolution-Position-Component-Layer)

for each layer rfor each resolution p

for each component cfor each precinct l

include the packet ζt,c,r,p,l

Progresion PCRL(Position-Component-Resolution-Layer)

for each layer pfor each resolution c

for each component rfor each precinct l

include the packet ζt,c,r,p,l

Progresion CPRL(Component-Position-Resolution-Layer)

for each layer cfor each resolution p

for each component rfor each precinct l

include the packet ζt,c,r,p,l

Elegir una progresion u otra depende del tipode aplicacion que se quiera desarrollar y de comose quiera descomprimir los paquetes. En el caso

de la transmision de imagenes, los paquetes debenseguir un orden especıfico o progresion cuandoson transmitidos. Cuando una imagen es transmi-tida desde un servidor a un cliente, el principalobjetivo es conseguir que el cliente pueda ver lasreconstrucciones de la imagen con una calidad quevaya incrementando a media que se van recibiendolos datos. La calidad de la reconstruccion debe sersiempre la maxima posible de acuerdo a la cantidadde datos recibida.

III-E. Formatos de archivo

Aunque el code-stream es completamente fun-cional como un formato de archivo basico, esteno permite la inclusion de informacion adicionalque podrıa ser necesaria en ciertas aplicaciones,por ejemplo: el uso de metadatos, informacion decopyright, o paletas de color. Haciendo uso del mar-cador COM podemos incluir informacion adicionaldentro de un code-stream, pero sin ningun tipo declasificacion ni ordenacion.

La Parte 1 del estandar define ademas un for-mato de archivo basado en “cajas” que permiteincluir dentro de un mismo archivo diferentes code-streams y diversa informacion de una forma cor-rectamente identificada. Estos archivos tienen laextension “.JP2”, extension que ademas es utilizadapara nombrar a este tipo de archivos.

Los archivos JP2 son facilmente extensibles.Tienen definida una estructura basica de caja, quecontiene cualquier tipo de informacion. Cada cajaesta identificada por medio de un identificador de4 bytes. Un mismo archivo puede contener variascajas con el mismo identificador. El estandar pro-pone un conjunto inicial de cajas, que puede serextendido de acuerdo a las necesidades de cadacaso. De hecho, el formato JP2 es la base del restode formatos y extensiones definidos en el resto departes del estandar.

Cada caja tiene una cabecera de 8 bytes. Losprimeros 4 bytes, L, forman un entero sin signoque indica el numero de bytes del contenido y lossiguientes 4 bytes, T , contienen el identificador deltipo de caja. Este identificador es tratado como unacadena ASCII de 4 caracteres. El valor de L incluyela cabecera, por lo tanto el tamano real del contenidode la caja es L − 8. L puede tener cualquier valormayor o igual a 8, pero tambien puede tener un valorigual a 1 o 0. Si L = 1 el tamano del contenido de

11

la caja es codificado como un entero sin signo de8 bytes, X , situados despues de T . En este caso lacabecera ocupa 16 bytes y el tamano del contenidoes X − 16. Si L = 0 el tamano del contenido de lacaja no esta definido, pero este caso solamente esposible para la ultima caja del archivo.

IV. EL PROTOCOLO JPIPLa Parte 9 del estandar JPEG 2000 esta casi

completamente dedicada al desarrollo de sistemasde exploracion de imagenes remotas. En esta partese definen un conjunto de tecnologıas (protocolos,formatos de archivo, arquitecturas, etc.) que per-miten explotar de manera eficiente todas las carac-terısticas del sistema de compresion JPEG 2000. Laprincipal tecnologıa en la que se centra la Parte 9 esel protocolo JPIP (JPEG 2000 Interactive Protocol).

IV-A. ArquitecturaEn la figura 6 se muestra como es la arquitectura

comun para un sistema cliente/servidor que permi-ta la exploracion de imagenes remotas usando elprotocolo JPIP para realizar la transmision de lasimagenes.

Como se puede observar en la figura, el clientese divide en cuatro modulos funcionales: Browser,Cliente JPIP, Descompresor y Cache. El modulo“Browser” es la interfaz que interacciona con elusuario y donde este puede especificar una WOIde la imagen. El protocolo JPIP permite el uso demultiples parametros para definir la WOI que sedebe transmitir, estos parametros son: numero decapas de calidad, numero de componentes, etc. Elprotocolo JPIP impone que las WOIs tienen queestar definidas sobre regiones rectangulares dentrode un nivel de resolucion determinado.

Una vez que el usuario ha definido la WOIdeseada, esta se envıa a los modulos “Cliente JPIP”y “Descompresor”. El primero de ellos es el en-cargado de la comunicacion con el servidor JPIPy para ello hace uso de los mensajes y sintaxisdefinida en el protocolo. Cuando el servidor recibeesta informacion, extrae los datos necesarios de laimagen para poder hacer la reconstruccion de laWOI solicitada, y enviarlos al cliente. Estos datos seenvıan encapsulados en data-bins. En el protocoloJPIP los diferentes elementos de las particiones deuna imagen JPEG 2000 son reordenados y encapsu-lados en data-bins, siendo estos la mınima unidadde transmision.

A medida que el cliente recibe los data-bins delservidor, los almacena en una cache interna (modulo“Cache”). La cache del cliente tambien esta orga-nizada en data-bins. Esta cache se utiliza continua-mente por del modulo “Descompresor” para generarreconstrucciones progresivas de la WOI, que sonenviadas al modulo “Browser” para que pueda servisualizada por el usuario.

Excepto el modulo “Cache” que actua como uncontenedor, el resto de modulos del cliente trabajande forma paralela. El “Browser” esta continuamenteinformando al “Cliente JPIP” la WOI que ha so-licitado el usuario. El “Cliente JPIP” mantiene lacomunicacion con el servidor para enviar la WOI ycuando recibe los datos los guarda en la cache. Losmodulos comienzan su ejecucion cuando el usuariodefine la primera WOI, y se detienen cuando se hanrecibido todos los datos de la WOI actual. El usuariopuede indicar una nueva WOI siempre que quiera,sin tener que esperar a recibir todos los datos de laanterior peticion.

La memoria cache del cliente almacena todos losdata-bins recibidos desde el servidor, para todaslas WOIs de todas las imagenes que han sidoexploradas por el usuario. El servidor mantieneun modelo con el contenido de esta cache, estole permite no tener que volver a enviar al clientedatos que ya han sido enviados anteriormente. Porejemplo, supongamos que un usuario despues de laexploracion de la WOIA, solicita una nueva WOIBque se solapa con la WOIA. Si el servidor mantieneactualizado el modelo de cache del cliente, cuandose solicita la WOIB, el servidor solamente envıalos data-bins necesarios para reconstruir la partede WOIB que no es comun con WOIA. Si todoslos data-bins que permiten reconstruir una ciertaWOIi se definen como D(WOIi), podemos decirque el servidor envıa los data-bins D(WOIB) −(D(WOIA)

⋂D(WOIB)).

IV-B. Particion en Data-bins

Los data-bins encapsulan diferentes elementos dela particion de una imagen JPEG 2000. Esta nuevaparticion de datos definida en el protocolo JPIPpermite identificar y recopilar las diferentes partesde una imagen para su transmision.

Cuando se inicia una comunicacioncliente/servidor, se define que tipo de streamde data-bins se va a utilizar. El protocolo JPIP

12

WOI

data-bins

WOI

data-bins

Cliente

status

Cache

imagen

BrowserCliente JPIP

Peticion WOI

Descompresorcache del cliente

Modelo de la

Servidor JPIP

Imagenes

JPEG 2000

Servidor

Figura 6. Arquitectura cliente/servidor del protocolo JPIP.

define dos tipos de streams, JPP, orientado aprecincts, y JPT, orientado a tiles. El tipo de streamindica que tipo de data-bins se deben usar para latransmision de datos. El mas utilizado es el tipoJPP.

Cada data-bin esta identificado de manera in-equıvoca por la imagen o code-stream al quepertenece, el tipo de data-bin y su identificador. Estainformacion esta incluida en la cabecera de cadadata-bin.

Los data-bins pueden ser segmentados para sutransmision. Un determinado conjunto de data-binsse puede dividir en un numero aleatorio de segmen-tos, y estos se pueden enviar en cualquier orden.Cada segmento de data-bin incluye la informacionnecesaria para su identificacion.

En la tabla II se puede observar la relacionentre los diferentes tipos de data-bins definidos enel protocolo JPIP. A continuacion se explican losprincipales tipos de data-bins:

Precinct data-bin: Contiene todos los paquetespara un nivel de resolucion r, una componentec y un tile t. Los paquetes estan ordenadosdentro del data-bin por capas de calidad, enorden creciente.Cada precinct data-bin es identificado por unındice I que se obtiene por medio de la sigu-iente expresion:

I = t+ ((c+ (s×Nc))×Nt) .

Nc y Nt son el numero de componentes yel numero de tiles de la imagen a los quepertenece el precinct. El ındice del tile, t aligual que e ındice de la componente c y el

valor s se inicializan con el valor cero. A cadaprecinct de cada tile-component, de todos losniveles de resolucion, se le asigna un uniconumero s de la secuencia. A todos los precinctsdel nivel de resolucion mas bajo se le asignaun numero de secuencia que empieza en cero,situado en la esquina superior izquierda, yse continua incrementando por columna y filarespectivamente.

Tile data-bin: Contiene todos los paquetes ymarcadores asociados a un tile. Esta com-puesto por la concatenacion de todos los tile-parts asociados a un tile, incluyendo los mar-cadores SOT, SOD y todo el resto de mar-cadores relevantes. Los data-bins de este tipose identifican por medio de un ındice incre-mental, que se inicializa en cero para el tilesituado en la esquina superior izquierda.

Tile header data-bin: Contiene todos losmarcadores asociados a un determinado tile.Esta formado por todos los marcadores detodas las cabeceras de todos los tile-parts deun tile, sin incluir los marcadores SOT ni SOD.El identificador de este data-bin tiene la mismanumeracion que la descrita en el caso anterior.

Header data-bin: Contiene la cabecera princi-pal del code-stream, desde el marcador SOC(incluido) hasta el primer marcador SOT (noincluido). Los marcadores SOD y EOC noestan incluidos.

Meta data-bins: Estos data-bins aparecen so-lamente si la imagen asociada es un archivo de

13

Cuadro IILISTA DE data-bins DEFINIDOS EN EL PROTOCOLO JPIP.

Data-bin Stream Informacion que contienePrecinct JPP Todos los paquetes de un precinct.Precinct extended JPP El mismo contenido con contenido adicional.Tile JPT Todos los paquetes y marcadores de un tile.Tile extended JPT El mismo contenido con contenido adicional.Tile header JPT Los marcadores de la cabecera de un tile.Header JPP/JPT Los marcadores de la cabecera de un code-stream.Meta-data JPP/JPT Metadatos de una imagen.

la familia JP2. Los meta data-bins contienenun conjunto de cajas del archivo de la imagen.El estandar no define como deben ser losidentificadores de estos data-bins ni dentro deque cajas deben ser almacenados, pero cuandoun meta data-bin tiene el identificador cero,quiere decir que este incluye todas las cajascontenidas en la imagen.

IV-C. Sesiones y canalesUna peticion de un cliente al servidor puede

ser con estado o sin estado. Las peticiones conestado se llevan a cabo dentro del contexto de unasesion de comunicacion, en la que el estado dela comunicacion es mantenido por el servidor. Laspeticiones sin estado no requieren el uso de ningunasesion. El uso de sesiones mejora el rendimiento delservidor porque, por ejemplo, cuando establecemosuna sesion con un determinado archivo de unaimagen, el servidor abre el archivo y lo prepara parapoder enviarlo en data-bins, ası que todas las peti-ciones asociadas a la misma sesion van a permitir alservidor tener que evitar volver a repetir el mismoproceso para cada una de ellas. Las peticiones sinestado se pueden considerar como sesiones unicasque terminan cuando el servidor envıa la respuestaal cliente.

Bajo una sesion, usando peticiones con estado,el cliente puede abrir multiples canales, siendocapaz de realizar multiples peticiones con estadoasociadas a la misma sesion. Este comportamientoes especialmente util para aplicaciones que muestrande forma simultanea diferentes regiones de interesde la misma imagen. Los canales se pueden abriry cerrar de forma independiente, sin que afecte ala sesion. Para cerrar una sesion habrıa que cerrartodos los canales abiertos asociados a la misma.

Cada sesion tiene asociado un conjunto deimagenes. Una sesion implica que el servidor tiene

que mantener un modelo de la cache del cliente.Este modelo solamente se mantiene mientras que lasesion permanezca activa. Un canal, para una deter-minada sesion, esta asociado a una determinada im-agen y a un tipo especıfico de data-bin stream (JPPo JPT). El canal se identifica de manera inequıvocapor medio de un codigo alfanumerico asignado porel servidor. Las sesiones no se identifican, ya queel identificador de canal debe ser suficiente paraidentificar el canal, ası como la sesion a la quepertenece.

Muchas veces los clientes estan interesados enmantener en el servidor su modelo de cache entrediferentes sesiones. El servidor por defecto no per-mite esta posibilidad, pero el protocolo JPIP defineuna serie de mensajes que permiten al cliente mod-ificar el modelo que el servidor tiene de su cache.Por lo tanto, cuando un cliente inicia una nuevasesion con el servidor, podrıa enviar un resumendel contenido actual de su cache para mejorar lacomunicacion con el servidor y evitar el reenvıo dedatos de los que ya dispone en su cache.

Los clientes pueden indicar en sus peticiones unparametro que le indique al servidor cual debe ser eltamano maximo de la respuesta. Gracias al modelode cache existente en el servidor, el cliente puederealizar la misma peticion de forma sucesiva perovariando los parametros, de modo que el servidorle puede enviar una respuesta de forma incremental.Por lo tanto, el cliente tiene cierto control y puedeadaptar el intercambio de informacion dependiendodel ancho de banda disponible y de la latencia dela red, pero hay que tener en cuenta que el servidorpuede modificar estos parametros y no devolverexactamente lo que el cliente habıa solicitado. Estemodo de comunicacion es el mas comun en lasimplementaciones existentes de JPIP.

14

IV-D. Mensajes

Las peticiones JPIP estan formadas por una se-cuencia ASCII de pares “parametro = valor”. Estopermite que una peticion JPIP pueda ser encapsula-da dentro de un mensaje GET del protocolo HTTP,junto al caracter ’?’, concatenando todos los parescon el sımbolo ’&’.

Algunos de los parametros disponibles para en-viar una peticion JPIP son los siguientes:

“fsiz=Rx,Ry”: Se utiliza para identificar laresolucion correspondiente a la ventana selec-cionada solicitada. El servidor elige el mayornivel de resolucion de la imagen tal que susdimensiones R′x×R′y satisfagan que R′x ≥ Rx

y R′y ≥ Ry. Por lo general este parametroincluye la resolucion de pantalla del usuario.

“roff=Px,Py”: Se utiliza para identificar laesquina superior izquierda (desplazamiento) dela region espacial correspondiente a la ventanaseleccionada solicitada. Si no se usa este cam-po, el servidor asume que el valor por defectodel desplazamiento es 0.

“rsiz=Sx,Sy”: Se utiliza para identificar eltamano horizontal y vertical de la region espa-cial correspondiente a la ventana seleccionadasolicitada. De no haberlo, la region va hasta laesquina inferior derecha de la imagen.

“len=numero de bytes”: El cliente informacon este parametro al servidor el numero maxi-mo de bytes que pueden ser incluidos en larespuesta. El servidor tiene en cuenta estelımite para la respuesta actual y para todas lasrespuestas que se realicen dentro de la mismasesion.

“target=imagen”: Este parametro identificael archivo de la imagen de la que queremosobtener los datos. Cuando el protocolo usa-do es HTTP, no es obligatorio especificarloporque el nombre del archivo de la imagen sepuede obtener de la propia URL utilizada enel mensaje GET.

“cnew=protocolo”: Se utiliza cuando elcliente quiere abrir un nuevo canal dentro dela misma sesion. Hay que indicar el protocoloque se va a utilizar en este nuevo canal. Losdistintos protocolos que podemos usar son“http” y “http-tcp”.

“cid=identificador de canal”: Cuando uncliente crea un nuevo canal, el servidor envıa elidentificador de canal y este debe ser utilizadoen todas las peticiones asociadas a este canal.

“cclose=identificador de canal”: Esteparametro se utiliza cuando un cliente quierecerrar un determinado canal. Solamente hayque indicar el identificador del canal que sequiere cerrar.

“type=tipo de stream”: Cuando se crea uncanal, el cliente debe indicar el tipo de data-bin stream que se va a utilizar. Los principalestipos que se pueden utilizar son JPP (“jpp-stream”) y JPT (“jpt-stream”).

“model=. . . ”: Como hemos comentado ante-riormente, el cliente puede necesitar informaral servidor del contenido de su cache paraque actualice su modelo de cache. Por ejem-plo, model=Hm,H*,M2,P0:20 quiere de-cir al servidor que incluya en el modelo decache la cabecera principal del code-stream,las cabeceras de todos los tiles, el meta data-bin numero 2 y los primeros 20 bytes delprecinct 0.

V. TRABAJOS PREVIOS

La actualizacion condicional, a la que llamare-mos partir de ahora en este documento solo porCR (Conditional Replenishment), ha sido utilizadacon exito desde hace algunos anos para codificarsecuencias de imagenes con poco movimiento.

La primera referencia data de finales de los sesen-ta [7], donde Mounts propuso un metodo para lacodificacion de senales de television en la que sehacıa uso de la correlacion temporal existente entrelos frames consecutivos, con el objetivo de reducirel bit-rate utilizado en la transmision de la senal.La tecnica propuesta solamente codificaba aquelloselementos que habıan cambiado entre frames con-secutivos en lugar de codificar todos los elementosque componıan cada frame.

En [8] a finales de los noventa, McCanne et al.exploraron la posibilidad de utilizar un codificadorde vıdeo basado en CR para el MBone (MulticastBackbone), gracias a su reducida complejidad y suresistencia a la perdida de datos.

15

Mas recientemente, fueron estudiadas otras posi-bles soluciones que ofrecıan buenos resultados des-de el punto de vista de la compresion y decodi-ficacion. En [9], Cheung y Ortega investigaron elrendimiento de un codec de vıdeo predictivo concompensacion de movimiento que estaba basado enla codificacion de vıdeo distribuido y permitıa lareproduccion del vıdeo hacia delante y hacia detras.

En 2009 [10], Devaux et al. propusieron unasolucion basada en CR para explotar la redundanciatemporal de secuencias de vıdeo-vigilancia que pre-viamente habıan sido codificadas en formato JPEG2000. Ademas esta aproximacion no se basaba enla compensacion de movimiento. En este caso elemisor (servidor) tiene que determinar, y enviar alreceptor (cliente), los puntos optimos a los cualeses mejor usar los datos del code-stream JPEG 2000que la prediccion (generada con la reconstrucciondel ultimo frame y una estimacion del background).

Finalmente, tambien desde 2009 el trabajo deNaman et al. es similar en esencia, pero en este caso,se propone el uso de CR con referencias a multiplesframes y el uso de compensacion de movimientopara codificar aquellas secuencias de imagenes conuna gran cantidad de movimiento [11] y la mismaarquitectura pero sin compensacion de movimientopara secuencias de imagenes mas estaticas [12].

Despues de un analisis de todas las aproxi-maciones que hemos comentado anteriormente, sepuede afirmar que nuestro trabajo esta motivado porlas siguientes razones:

1. Todas las aproximaciones propuestas necesi-tan algun procesamiento previo sobre la se-cuencia de imagenes en el lado del servidor ypor lo tanto la secuencia debe ser conocida apriori, y en algunos casos incluso el orden delas imagenes. En el caso de la aplicacion JHe-lioViewer esto es imposible de realizar porquesolo durante la interaccion con el usuario sedefine la composicion de las secuencias deimagenes.

2. Los recursos computacionales requeridos porel emisor para realizar una transmision entiempo real son extremadamente altos debidoa la gran cantidad de datos que debe sermanejada (recordemos que las imagenes conlas que estamos trabajando son imagenes de4096×4096 pıxeles, y necesitamos un frame-rate de al menos 20 imagenes por segundo).

I0 I1 I2 I3 IN−1. . .

T iempo

Figura 7. Una secuencia de imagenes capturadas en diferentesinstantes de tiempo. El subındice denota el instante de muestreo(uniforme) de la imagen en cuestion.

3. Ninguna de las aproximaciones anteriores escompletamente compatible con el estandarJPIP, porque requieren que ciertos datos adi-cionales sean transmitidos desde el servidorhasta los clientes, y el protocolo JPIP nopermite esto (excepto en forma de imagenescomprimidas).

Por lo tanto, ninguna de las soluciones existentespuede ser facilmente utilizada para realizar un sis-tema de exploracion interactiva de imagenes remo-tas como JHelioviewer. Ademas, en [13] se proponeuna estrategia de prefetching que podrıa mejorar laexperiencia del usuario y esta solucion es totalmentecompatible con la propuesta que hacemos en estetrabajo, pero podrıa ser bastante costoso y de difıcilimplementacion con las aproximaciones que se handescrito anteriormente.

VI. PROPUESTA

Como ya se ha explicado previamente, en lassecuencias de imagenes donde existen regiones queno cambian durante un largo perıodo de tiempo,podemos hacer uso de CR. En nuestro caso esta-mos trabajando con imagenes solares que han sidocapturadas con muy pocos segundos de diferenciaentre ellas, lo que nos va a permitir que el uso de CRaproveche toda la redundancia temporal que puedaexistir entre ellas.

Por otra parte, gracias a la combinacion de CRcon las caracterısticas que nos ofrece el estandarJPEG 2000, hemos conseguido disenar un algoritmoque permite hacer la reconstruccion en tiempo realde una secuencia de imagenes con una resolucionde 4096 × 4096 pıxeles usando un frame-rate de25 imagenes por segundo en una maquina con

16

modestos recursos computacionales y un limitadoancho de banda.

En la descripcion de nuestra propuesta y con elobjeto de simplificar la exposicion, vamos a suponerque el ancho de banda del canal de comunicacionentre el servidor JPIP y el cliente, al igual que elframe-rate seleccionado por el usuario, permanecenconstantes durante todo el proceso de visualizacionde la secuencia de vıdeo. Debe de tenerse en cuenta,sin embargo, que este hecho no afectarıa a la de-scripcion del algoritmo ni a la eficiencia del mismo.

Antes de describir el algoritmo propuesto vamos arepasar la notacion que se ha utilizado. La secuenciade imagenes ha sido denotada como I y In sera lan-esima imagen de la secuencia, donde 0 ≤ n <N . Las imagenes que finalmente son visualizadascon la tecnica de actualizacion condicional han sidodenotadas como I ′.2

Como ya se ha indicado en la Seccion III, de-bido a una de las caracterısticas que nos ofreceel estandar JPEG 2000, las imagenes pueden serdescomprimidas desde el mismo code-stream condiferentes niveles de resolucion espacial. Esta car-acterıstica es uno de los puntos claves de nuestrapropuesta. En nuestro caso, vamos a definir In =I0n como la imagen a la maxima resolucion espacial(vease la Figura 8) y Irn sera una version escalada

2Debe tenerse en cuenta que al tratarse de una visualizacionprogresiva en el tiempo, solo cuando la transmision de cada imagenha terminado se verifica que las imagenes reconstruidas son identicasa las originales. Mientras dicha transmision no ocurra, el usuarioremoto lo que ve siempre es solo una aproximacion (en calidadincremental en el tiempo) de las imagenes.

x/8y/8

y/4 x/4

x/2y/2

x

y

In = I0n

Irn

Figura 8. Diferentes niveles de resolucion espacial sobre un mismoflujo de datos JPEG 2000. Para este ejemplo se ha supuesto que laDWT se ha aplicado, al menos, 3 veces.

Cuadro IIIEJEMPLO DE LOS NIVELES DE RESOLUCION ESPACIAL PARA UNA

IMAGEN CON UN TAMANO ORIGINAL DE 4096× 4096 PIXELES(S = 4096) Y COMPRIMIDA CON 7 ETAPAS DWT (R = 7).

r Irn S/2r

0 I0n 4096/20 = 40961 I1n 4096/21 = 20482 I2n 4096/22 = 10243 I3n 4096/23 = 5124 I4n 4096/24 = 2565 I5n 4096/25 = 1286 I6n 4096/26 = 647 I7n 4096/27 = 32

a otro nivel de resolucion de la imagen In, quetiene una resolucion de S/2r y 0 ≤ r < R + 1,donde S es el tamano original de la imagen yR es el numero de etapas utilizado a la hora deaplicar la transformada DWT, durante el proceso decompresion de la imagen.

Para simplificar la descripcion del algoritmoasumimos que las imagenes con las que vamos a tra-bajar son cuadradas, por lo tanto solo sera necesarioutilizar un unico parametro (S/2r) para determinarel numero de pıxeles utilizado en cada nivel deresolucion espacial.

En la Tabla III, a modo de ejemplo, se puedenver los distintos niveles de resolucion que podemosobtener para una imagen con un tamano original de4096× 4096 pıxeles (S = 4096) y comprimida con7 etapas wavelet (R = 7). Como se puede apreciar,tenemos que 0 ≤ r < 8, y por lo tanto, la imagen demayor resolucion espacial sera I0n de 4096 × 4096pıxeles y la de menor resolucion espacial I7n de 32×32 pıxeles.

El ultimo parametro que aparece en la descripciondel algoritmo es el parametro Q, que hace referenciaal numero de capas de calidad con el que hansido comprimidas cada una de las imagenes de lasecuencia.

VI-A. Algoritmo

Todas las imagenes de la secuencia de vıdeo sevan a transmitir desde el servidor hasta los clientessiguiendo los criterios de una progresion LRCP, loque quiere decir que vamos a ir recibiendo poco apoco las diferentes capas de calidad con las que seha comprimido la imagen, y progresivamente iremosmejorando la calidad de la misma. Cuanto mayorsea el numero de capas de calidad recibidas mucho

17

mayor sera la calidad de la imagen visualizadaal comienzo de la transmision, aunque los code-streams crecerıan ligeramente.

Nuestro algoritmo trabaja de la siguiente manera:el servidor envıa progresivamente la primera imagende la secuencia durante un perıodo de tiempo, yesta es la primera imagen que se muestra en ellado del cliente. Dependiendo del ancho de bandaexistente entre el canal de comunicacion establecidoentre el servidor y el cliente, se recibira mayor omenor cantidad de datos y por lo tanto la imagenque se visualizara por primera vez tendra mas omenos calidad.

Una vez que se han recibido los datos de laprimera imagen se solicita la siguiente imagen dela secuencia, pero esta vez con el menor nivel deresolucion posible (IRn ). Gracias a una de las carac-terısticas del estandar JPEG 2000 que nos permitedescomprimir una imagen a diferentes niveles deresolucion espacial desde el mismo flujo de datos,tambien podemos obtener el menor nivel de resolu-cion de la primera imagen. De esta manera podemoscalcular de una forma muy sencilla cuales son lasdiferencias existentes entre las dos miniaturas de lasimagenes. Para conocer que es lo que ha cambiado,vamos a calcular el Error Cuadratico Medio (MSE)entre los precincts de las dos imagenes, de estamanera podemos conocer de una forma rapida ycomputacionalmente sencilla los precincts que debe-mos solicitar al servidor de la segunda imagen yhacer uso de la tecnica de actualizacion condicionalcon los datos que ya disponemos de la primeraimagen de la secuencia. Los paquetes de datos JPEG2000 que se han recibido para obtener la segundaimagen a la menor resolucion no han sido enviadosen vano ya que estos son necesarios para obtener laimagen a la mayor resolucion. El proceso descritoanteriormente se repite para todas las imagenes dela secuencia.

Una vez que hemos explicado cual es la basede nuestra idea, hacemos la siguiente propuesta deesquema de transmision de secuencias de imagenesJPEG 2000 usando actualizacion condicional con-trolada por el cliente:

1. Sea q ← 1 el numero de capas de calidadutilizadas en las reconstrucciones actuales.

2. Sea n ← 1 el ındice de imagenes reconstru-idas.

3. Obtenemos la siguiente capa de calidad dela imagen In−1 e inicializamos I ′n−1 con estevalor.

4. Obtenemos solamente la siguiente capa decalidad de la imagen n a la menor resolucionespacial IRn (la imagen en miniatura).

5. Calculamos el Error Cuadratico Medio (MSE)entre los precincts de las imagenes IRn−1 y IRn ,y los almacenamos en una lista L en ordendescendente (vease la Figura 9).

6. I ′n ← In(L)∪ (I ′n−1 ∩ In(L)). Copiamos de laimagen I ′n−1 a I ′n aquellos precincts que per-manecen “constantes” y actualizamos desde laimagen In aquellos precincts que estan en lalista L con una calidad q (vease la Figura 10).

7. n← n+ 1.

8. Si n < N − 1, ir al paso 4.

9. q ← q + 1.

10. Si q ≤ Q, ir al paso 2.

Con el objetivo de que el lector entienda con mascomodidad el funcionamiento de nuestro algoritmo,en la figura 11 se presenta un ejemplo de comoserıa la transmision de las cinco primeras imagenesde una secuencia de imagenes cualquiera, dondesolamente ocurren cambios en la region central. Lasimagenes que finalmente se muestran al usuario hansido etiquetadas como “Reconstruccion con CR”.Como se describe en la siguiente seccion, las recon-strucciones realizadas con CR son mejores que lasque se obtienen sin utilizar CR, obteniendo mejoresvalores de PSNR y una mejor reconstruccion visual.

Precincts IRn−1

Precincts IRn Precincts que permanecen constantes

Precincts que han cambiadoIRn−1

IRn

Figura 9. Etapa del algoritmo donde se realiza el calculo del ErrorCuadratico Medio (MSE) entre los precincts de las imagenes IRn−1 yIRn , y se almacena el resultado en una lista L en orden descendente.

18

I14

I′13

Imagenes originales I0 I1 I2 I3 I4

I′0 I

′1 I

′3 I

′4I

′2

Reconstruccion con CR I10 I11

I′10

I12

I′11

I13

I′12

Figura 11. Ejemplo con las cuatro primeras iteraciones de nuestro algoritmo.

InIn−1

I ′n

Precincts que permanecen constantes

Imagen reconstruida con CR

Precincts que han cambiado

Figura 10. Etapa donde copiamos de la imagen I ′n−1 a I ′n aquellosprecincts que permanecen “constantes” y actualizamos desde laimagen In aquellos precincts que estan en la lista L con una calidadq.

VII. EVALUACION

Nuestra propuesta ha sido testeada con dos se-cuencias de imagenes diferentes. La primera de ellasesta compuesta por un conjunto de 140 imagenes,tomadas desde el observatorio solar SDO/AIA, conuna resolucion espacial de 4096 × 4096 pıxeles, ytomadas con una cadencia de 432 segundos.

La segunda secuencia se trata de Akiyo, unasecuencia de benchmark conocida, formada porun conjunto de 300 imagenes con una resolucionespacial de 352 × 288 pıxeles. A diferencia de lasecuencia solar, esta segunda secuencia se trata deuna secuencia con muy poco movimiento global loque la convierte en una candidata ideal para sertransmitida utilizando nuestra propuesta.

La evaluacion ha consistido en la realizacionde multiples simulaciones sobre las dos secuenciasde imagenes que hemos mencionado anteriormente.Para cada una de la simulaciones realizadas se

han ido probando diferentes configuraciones, dondehemos alterado algunos parametros relacionadoscon la codificacion y la transmision, asignandolediferentes valores en cada caso. Los parametrosde codificacion que hemos modificado han sido:el tamano de precinct, los niveles de calidad ylos niveles de resolucion espacial. Tambien hemossimulado diferentes escenarios con distinto anchode banda para el canal de comunicacion establecidoentre el servidor y el cliente, con el fin de evaluar elcomportamiento de nuestro algoritmo, y ver comoreacciona ante situaciones donde disponemos demuy poco ancho de banda.

VII-A. Ejemplo 1. SDO/AIA

Los parametros de codificacion utilizados en lasecuencia de este ejemplo han sido los siguientes:

Tamano de precinct; P = 32.Q = 8 niveles de calidad.R = 7 niveles de resolucion espacial.

La transmision de la secuencia se ha simuladocon los siguientes parametros:

Bit-rate: 58× 104 bits por segundo.Frame-rate: 25 frames por segundo

En este caso estamos simulando que tenemosmuy poco ancho de banda entre cliente y servidor,lo que va a provocar que en cada iteracion delalgoritmo se actualicen muy pocos precincts de lasiguiente imagen. Aun ası obtenemos una mejorreconstruccion visual cuando se utiliza una trans-mision controlada por el cliente con CR que cuandose utiliza una transmision estandar (vease la Figura12). En esta simulacion, nuestra propuesta tambienobtiene mejores valores de PSNR, en la mayorıade reconstrucciones de la secuencia, al compararla

19

con las reconstrucciones obtenidas con el metodotradicional sin CR (vease la Figura 13).

VII-B. Ejemplo 2. SDO/AIA

Los parametros de codificacion utilizados en lasecuencia de este ejemplo han sido los siguientes:

Tamano de precinct; P = 32.Q = 8 niveles de calidad.R = 7 niveles de resolucion espacial.

La transmision de la secuencia se ha simuladocon los siguientes parametros:

Bit-rate: 224× 105 bits por segundo.Frame-rate: 25 frames por segundo

En este caso estamos simulando que tenemos elancho de banda suficiente para recibir del servidortodos los precincts de la siguiente imagen quehan cambiado con respecto a la imagen actual.La reconstruccion visual que se obtiene en estasimulacion es muy similar en ambos casos. Esmuy complicado apreciar alguna diferencia entrelas imagenes reconstruidas a simple vista (vease laFigura 14). Los valores de PSNR que obtenemosen todas las reconstrucciones de la imagen, cuandoutilizamos CR, son mucho mayores que cuandoutilizamos una transmision estandar (vease la Figura15).

VII-C. Ejemplo 3. Akiyo

Los parametros de codificacion utilizados en lasecuencia de este ejemplo han sido los siguientes:

Tamano de precinct; P = 32.Q = 8 niveles de calidad.R = 3 niveles de resolucion espacial.

La transmision de la secuencia se ha simuladocon los siguientes parametros:

Bit-rate: 38× 104 bits por segundo.Frame-rate: 25 frames por segundo

La secuencia utilizada en esta simulacion, Akiyo,contiene mayor redundancia temporal que la secuen-cia solar, SDO/AIA, por este motivo los resultadosobtenidos son mucho mejores que los obtenidos enel caso de la secuencia solar. A pesar de tenermuy poco ancho de banda entre el cliente y elservidor, las reconstrucciones visuales obtenidas con

la tecnica de CR son notablemente mejores (veasela Figura 14). Nuestra propuesta tambien obtienemejores valores de PSNR, en la gran mayorıa dereconstrucciones de la secuencia, al compararla conlas reconstrucciones obtenidas con el metodo tradi-cional sin CR (vease la Figura 15).

VII-D. Ejemplo 4. Akiyo

Los parametros de codificacion utilizados en lasecuencia de este ejemplo han sido los siguientes:

Tamano de precinct; P = 32.Q = 8 niveles de calidad.R = 3 niveles de resolucion espacial.

La transmision de la secuencia se ha simuladocon los siguientes parametros:

Bit-rate: 11× 106 bits por segundo.Frame-rate: 25 frames por segundo

Igual que en el Ejemplo 2, hemos simulado quetenemos el ancho de banda suficiente para recibirdel servidor todos los precincts de la siguienteimagen que han cambiado con respecto a la imagenactual. En este caso volvemos a obtener reconstruc-ciones muy parecidas, donde es muy complicadoapreciar alguna diferencia a simple vista (vease laFigura 14). Desde el punto de vista del PSNR obten-emos valores mucho mas altos cuando hacemos usode CR (vease la Figura 15).

VII-E. Ejemplo 5

En este ejemplo queremos mostrar los valores dePSNR que vamos obteniendo durante la ejecuciondel algoritmo, para las distintas capas de calidad(vease la Figura 20).

Los parametros de codificacion/transmision uti-lizados para ambas secuencias han sido los sigu-ientes:

Secuencia SDO/AIA:• Tamano de precinct; P = 128.• Q = 8 niveles de calidad.• R = 8 niveles de resolucion espacial.• Bit-rate: 27× 106 bits por segundo.• Frame-rate: 25 frames por segundo

Secuencia Akiyo:• Tamano de precinct: P = 32.• Q = 8 niveles de calidad.

20

• R = 3 niveles de resolucion espacial.• Bit-rate: 8× 105 bits por segundo.• Frame-rate: 25 frames por segundo

VIII. CONCLUSIONES Y TRABAJO FUTURO

Este trabajo muestra como se puede mejorar lavisualizacion de secuencias de imagenes JPEG 2000haciendo uso de la tecnica de actualizacion condi-cional controlada exclusivamente por el cliente. Elsistema propuesto tiene la gran ventaja de que escompletamente compatible con el estandar JPIPporque lo unico que hacemos con nuestro algoritmoes cambiar el orden de los datos que queremosobtener desde el servidor, de modo que siemprerecibimos primero los paquetes de aquellas regionesde la imagen donde se hayan producido mas cam-bios.

Como trabajo futuro, y con la idea de mejo-rar la calidad de las reconstrucciones de aquellassecuencias con un alto grado de movimiento, sepodrıan realizar predicciones de compensacion demovimiento en el lado del cliente. Esta mejora estotalmente compatible con nuestra propuesta y noafectarıa en ningun momento la compatibilidad delalgoritmo con el estandar JPEG 2000 y su protocolode transmision asociado JPIP.

AGRADECIMIENTOS

Me gustarıa agradecer la inestimable ayuda queme han ofrecido Juan Pablo Garcıa Ortiz y VicenteGonzalez Ruiz, con la cual el desarrollo de este tra-bajo ha sido mucho mas rapido y sencillo. Gracias.

BIBLIOGRAFIA

[1] International Organization for Standardization, “InformationTechnology - JPEG 2000 Image Coding System - Core CodingSystem,” ISO/IEC 15444-1:2004, September 2004.

[2] ——, “Information Technology - JPEG 2000 Image CodingSystem - Interactivity Tools, APIs and Protocols,” ISO/IEC15444-9:2005, November 2005.

[3] D. Muller, B. Fleck, G. Dimitoglou, B. W. Caplins, D. E.Amadigwe, J. P. G. Ortiz, A. A. B. Wamsler, V. K. Hughitt, andJ. Ireland, “JHelioviewer: Visualizing large sets of solar imagesusing JPEG 2000,” Computing in Science and Engineering,vol. 11, no. 5, pp. 38–47, September 2009.

[4] “European Space Agency,” http://www.esa.int.[5] “National Aeronautics and Space Administration,”

http://www.nasa.gov.[6] W. Pesnell, “The Solar Dynamics Observatory: Your eye on

the Sun,” in 37th COSPAR Scientific Assembly, ser. COSPAR,Plenary Meeting, vol. 37, 2008, pp. 2412–+.

[7] F. Mounts, “A video encoding system with conditional picture-element replenishment,” Bell System Technical Journal, vol. 48,pp. 2545 – 2554, September 1969.

[8] S. McCanne, M. Vetterli, and V. Jacobson, “Low-complexityvideo coding for receiver-driven layered multicast,” IEEE Jour-nal on Selected Areas in Communications, vol. 15, no. 6, pp.983 – 1001, August 1997.

[9] N.-M. Cheung and A. Ortega, “Flexible video decoding: Adistributed source coding approach,” in IEEE Workshop onMultimedia Signal Processing, October 2007, pp. 103 – 106.

[10] F.-O. Devaux, J. Meessen, C. Parisot, J.-F. Delaigle, B. Macq,and C. D. Vleeschouwer, “Remote interactive browsing of videosurveillance content based on jpeg 2000,” IEEE Transactionf onCircuits and Systems for Video Technology, vol. 19, no. 8, pp.1143 – 1157, August 2009.

[11] A. Naman and D. Taubman, “Rate-distortion optimizedjpeg2000-based scalable interactive video (jsiv) with motionand quantization bin side-information,” in IEEE InternationalConference on Image Processing, November 2009, p. 3081 –3084.

[12] ——, “Predictor selection using quantization intervals injpeg2000-based scalable interactive video (jsiv),” in IEEE In-ternational Conference on Image Processing, September 2010,pp. 2897 – 2900.

[13] J. G. Ortiz, V. G. Ruiz, I. Garcıa, D. Muller, and G. Dimitoglou,“Interactive browsing of remote jpeg 2000 image sequences,”in IEEE International Conference on Pattern Recognition. Is-tambul, Turkey: IEEE press, August 2010, pp. 3179 – 3182.

21

sin CRcon CR

Figura 12. Reconstruccion visual de una imagen de la secuencia SDO/AIA, simulando una transmision controlada por el cliente haciendouso de CR y una transmision estandar, utilizando un bit-rate de 58× 104 bits por segundo.

con CRsin CR

29.5

30

30.5

31

31.5

32

0 20 40 60 80 100 120 140

PSNR[dB]

Imagenes

Figura 13. Grafica que compara el PSNR obtenido para cada una de las imagenes de la secuencia SDO/AIA, cuando se utiliza una transmisioncontrolada por el cliente haciendo uso de CR y cuando se utiliza una transmision estandar. El bit-rate empleado para la transmision es de58× 104 bits por segundo.

22

con CR sin CR

Figura 14. Reconstruccion visual de una imagen de la secuencia SDO/AIA, simulando una transmision controlada por el cliente haciendouso de CR y una transmision estandar, utilizando un bit-rate de 224× 105 bits por segundo.

con CRsin CR

54

56

58

60

62

64

66

68

0 20 40 60 80 100 120 140

PSNR[dB]

Imagenes

Figura 15. Grafica que compara el PSNR obtenido para cada una de las imagenes de la secuencia SDO/AIA, cuando se utiliza una transmisioncontrolada por el cliente haciendo uso de CR y cuando se utiliza una transmision estandar. El bit-rate empleado para la transmision es de224× 105 bits por segundo.

23

con CR sin CR

Figura 16. Reconstruccion visual de una imagen de la secuencia Akiyo, simulando una transmision controlada por el cliente haciendo usode CR y una transmision estandar, utilizando un bit-rate de 38× 104 bits por segundo.

con CRsin CR

27.5

28

28.5

29

29.5

30

30.5

31

31.5

0 50 100 150 200 250 300

PSNR[dB]

Imagenes

Figura 17. Grafica que compara el PSNR obtenido para cada una de las imagenes de la secuencia Akiyo, cuando se utiliza una transmisioncontrolada por el cliente haciendo uso de CR y cuando se utiliza una transmision estandar. El bit-rate empleado para la transmision es de38× 104 bits por segundo.

24

con CR sin CR

Figura 18. Reconstruccion visual de una imagen de la secuencia Akiyo, simulando una transmision controlada por el cliente haciendo usode CR y una transmision estandar, utilizando un bit-rate de 11× 106 bits por segundo.

con CRsin CR

55

60

65

70

75

80

85

90

95

100

0 50 100 150 200 250 300

PSNR[dB]

Imagenes

Figura 19. Grafica que compara el PSNR obtenido para cada una de las imagenes de la secuencia Akiyo, cuando se utiliza una transmisioncontrolada por el cliente haciendo uso de CR y cuando se utiliza una transmision estandar. El bit-rate empleado para la transmision es de11× 106 bits por segundo.

25

40

45

50

55

60

65

70

20 40 60 80 100 120

PSNR[dB]

40

45

50

55

60

65

70

20 40 60 80 100 120

PSNR[dB]

Imagenes

30

35

40

45

50

55

60

50 100 150 200 250

PSNR[dB]

Imagenes

30

35

40

45

50

55

60

50 100 150 200 250

PSNR[dB]

Imagenes

con CR

sin CR

2 Capas de calidad

3 Capas de calidad

4 Capas de calidad

5 Capas de calidad

6 Capas de calidad

7 Capas de calidad

8 Capas de calidad

Figura 20. Comparacion entre nuestra propuesta (“con CR”) y el metodo estandar (“sin CR”). Arriba tenemos la secuencia SDO/AIA(bit-rate de 224× 105 bits por segundo). Abajo la secuencia Akiyo (bit-rate de 8× 105 bits por segundo).