un nuevo algoritmo de detecciÓn de bordes en...

UN NUEVO ALGORITMO DE DETECCIÓN DE BORDES EN

IMÁGENES CON RUIDO GAUSSIANO

Gharbi Mohammed, Javier Vargas Caro, Alejandro Lucas Zubillaga.

Resumen

La detección de bordes en una imagen es una parte fundamental de una serie de algoritmos

utilizados en el reconocimiento de imágenes y segmentación. Dicha detección se ve afectada

negativamente por el ruido gaussiano, por lo que en el presente documento se mostrará un

nuevo algoritmo de detección de bordes robusto frente a ruido gaussiano.

1. Introducción

Los bordes constituyen unas de las informaciones más útiles que podemos encontrar en una

imagen. Delimitan los objetos, definiendo el límite entre ellos y el fondo. El reconocimiento de

objetos se sustenta en gran parte en la detección de bordes, de ahí su importancia.

Uno de los problemas que podemos encontrarnos en la detección de bordes es el ruido. El

ruido es toda información no deseada que contamina la imagen, pudiendo tener distintos

orígenes (adquisición de la imagen, transferencia, etc). El hecho de que dicho ruido pueda ser

introducido por medios externos, ajenos incluso a la adquisición de la imagen, implica el

planteamiento de métodos para su correcto tratamiento.

Los algoritmos de detección de bordes como Sobel, Roberts, LoG, etc, son muy sensibles al

ruido gaussiano, por lo que debemos de atacar el problema utilizando un nuevo enfoque.

Detección correcta de bordes (imagen sin ruido):

Detección incorrecta de bordes (imagen con ruido gaussiano):

2. Planteamiento teórico

Algunos tipos de ruido que pueden ser fácilmente solventados por una serie de algoritmos

específicos para ellos (ruido sal y pimienta por ejemplo), pero el ruido gaussiano es

especialmente complicado de arreglar.

En el ruido gaussiano cada píxel varía su valor original según una distribución normal o

gaussiana, por lo que no podemos devolver al píxel su valor original basándonos en los píxeles

vecinos (como se haría con otros tipos de ruido). Si aplicáramos un filtro de suavizado (filtro de

la mediana, media, gauss, etc.) conseguiríamos una reducción del ruido, pero a costa de perder

posibles bordes, por lo que no es posible aplicar un filtro de suavizado agresivo para reducir el

ruido gaussiano.

La idea fundamental del algoritmo se basa en que una buena binarización de la imagen

reducirá en gran medida el que aquellos píxeles que no eran bordes sean detectados como

bordes al estar afectados por ruido gaussiano, por lo que el primer paso del algoritmo

consistirá en encontrar un correcto umbral de binarización mediante la comparación de los

grupos obtenidos en ella, deteniéndose cuando la media de cada grupo tenga un valor similar.

Nos basamos en el hecho de que al binarizar una imagen estamos separando los píxeles en dos

grupos (aquellos que superen el umbral y aquellos que no lo superen), por lo que será difícil

que un píxel, f(x,y), afectado por ruido gaussiano, f(x,y) + e(x,y), pueda cambiar de grupo

original (pasar de ser mayor que el umbral a menor que el umbral, o viceversa) . Esto se

traduce en robustez frente a imágenes afectadas pos ruido gaussiano ya que un pixel que antes

era borde, al ser modificado por el ruido gaussiano, es muy probable que siga siendo un borde.

El siguiente paso, una vez binarizada la imagen, consiste en el boundary tracking por 8-

adyacencia, el cual obtendrá los bordes de la imagen. Dado un pixel en concreto, f(x,y), dicho

pixel será marcado como borde si logramos encontrar un vecino (en el entorno de la 8-

adyacencia) que sea distinto a él. En ese caso dicho píxel es borde, por lo que se marca como

píxel negro, y sus vecinos como píxeles blancos.

Pasos:

1. Encontrar T0,una primera aproximación al umbral

2. Segmentar la imagen en dos grupos, R1 y R2, usando el umbral TK

3. Obtener Z1 y Z2

Z1 = Nivel medio de gris de R1,

Z2 = Nivel medio de gris de R2

4. Calcular el nuevo umbral Tk+1

Tk+1 = (Z1 + Z2)/2

5.

-Si TK = Tk+1, binarizar la imagen e ir al paso 6

- Si no volver al paso 2

6. Definir los bordes usando boundary tracking por 8-adyacencia.

2.1 Filtro de detección de bordes:

Se ha intentado implementar una alternativa de detección de bordes que fuera más resistente

ante el ruido que alternativas tradicionales, como Sobel. Para ello se ha partido de ciertas ideas

bases:

- El pixel a analizar no es fiable. Puede tener su valor cambiado debido al ruido.

- Un pixel es borde si está entre 2 o más grupos diferenciados.

La primera pregunta es, por lo tanto, como establecemos la diferencia entre grupos (o

reformulando), como establecemos qué pixeles del entorno del pixel a considerar pertenecen a

qué grupo (paso necesario para establecer que existen dos o más grupos relevantes entre los

que esta nuestro pixel a considerar).

Se ha partido del criterio más simple posible (en imágenes en escala de grises). El valor

numérico del tono de gris. Esto es, los pixeles de un grupo dado deben de tener similares tonos

de gris (Umbral de agrupamiento). Cuanto de similares es una variable de entrada del

algoritmo.

Los grupos son representados por un pixel (esto es, un tono de gris). Un pixel puede ser

catalogado dentro de un grupo si la diferencia (en valor absoluto) de su valor con respecto al

elemento representativo del grupo es menor o igual al Umbral de agrupamiento.

Así, en este algoritmo nosotros vamos recorriendo el entorno más inmediato (los vecinos 8

adyacentes) y vamos catalogándolos en grupos. El criterio de catalogación ha sido el siguiente

(los 8 vecinos se recorren siempre de una misma forma para todos los pixeles):

1. Limpio la lista de grupos.

2. Para todos los pixeles vecinos al pixel en cuestión:

a. Busco en la lista de grupos si pueden ser catalogados en un grupo existente.

i. Si puede introducirse en un grupo se hace. En caso de poder introducirse en

más de uno, siempre se hace en el 1º que cumpla el requisito.

Si no, formamos un nuevo grupo, cuyo elemento representativo será el

pixel en cuestión.

3. Si existen 2 o más grupos con 2 o más pixeles, entonces el pixel será catalogado como pixel

borde.

Notar que las imposiciones de introducción en el primer grupo que cumpla requisitos es

meramente por cuestiones de eficiencia. Y que al estar acotado el número de pixeles vecinos

en 8, el algoritmo aunque es de orden N*V*2 (donde N son los pixeles de la imagen y V los

vecinos a considerar de un pixel dado, cota también de los grupos máximos formables en el

entorno de cada pixel), puede ser considerado lineal (dado que V está acotado).

Exigir que los grupos sean de 2 o más elementos normalmente hace que regiones ficticias

generadas por ruido de baja densidad (tipo sal y pimienta) normalmente no sean tomadas en

cuenta a la hora de catalogar un pixel como borde. Esto es una ventaja con respecto a Sobel,

donde basta con que un pixel único sea lo suficientemente distinto a sus vecinos para que se

detecte borde.

2.3 Tratamiento para eliminar falsos positivos:

Partiendo de la aplicación de un algoritmo de detección de borde, y asumiendo la salida de

este una imagen binaria (donde un color representa que el pixel es borde y otro que no), se ha

intentado calcular la probabilidad de que un pixel haya sido catalogado correctamente, o sea,

en cambio, su catalogación producto del ruido. Para ello se ha partido de ciertas ideas bases:

- Un borde, visto desde lo suficientemente cerca, se puede aproximar en un entorno

de un punto cualesquiera de él como una recta.

- Si asumimos que los bordes presentan en regiones pequeñas comportamiento

lineal, si en un pixel dado existe en su entorno pixeles que conformen una recta

que pase por su posición, es probable que el sea borde (independientemente si él

fue o no catalogado como borde). Y su reciproco, si no existe esta recta, es poco

probable que el sea realmente un borde.

Cabe preguntarse, entre otras cosas:

- ¿Que es un entorno cercano?

- Cuanto de probable según haya rectas que crucen por él.

- Deben de ser rectas perfectas, o permitimos que estas rectas tengan "huecos"

(resultados a su vez de, entre otros factores, de pixeles mal catalogados en la detección de

bordes).

Se ha asumido como entorno cercano los 4 vecinos más cercanos que estén en la recta.

1. Para todas las rectas que pasen por el pixel en cuestión, dado un umbral y un vector de

ponderación de los 4 vecinos más cercanos (valores positivos).

2. Inicializo MAX_T a 0.

3. Para cada recta que pasa por P:

a. Inicializo MAX_R a 0.

b. Para cada pixel vecino:

i. Si ha sido catalogado como borde, añado a MAX_R el valor de su elemento

correspondiente en el vector de ponderación.

c. Si MAX_R > MAX_T entonces hago MAX_T = MAX_R.

4. Si MAX_T es mayor o igual al umbral dado y el pixel ha sido catalogado como NO BORDE, lo

cambio a BORDE.

5. Si MAX_T es menor al umbral y ha sido catalogado como BORDE lo cambio a NO BORDE.

Vamos a intentar reducir la complejidad "infinita" de este algoritmo:

Dado el carácter discreto de los elementos participantes, el número de rectas distintas que

pasan por un pixel dado es finito.

Si asumimos que en el vector de ponderación el 1º y 4º elemento y el 2º y 3º son iguales,

podemos reducir el número de rectas a la mitad (solo miramos en una dirección dada, su

simétrica nos daría lo mismo).

En la implementación se ha optado por introducir como opcional el paso 4. El vector de

ponderación es variable, así como el umbral. El número de direcciones a considerar se ha

reducido a solo 4 (y=x / y = -x/ y = inf, y = 0). Por motivos de eficiencia (y que, como puede

asumir cualquiera que haya intentado trazar rectas mediantes pixeles, son rectas no ambiguas,

fácilmente implementables con sencillos bucles).

De hecho, dado que solo se consideran 4 direcciones y el conjunto finito y acotado de pixeles

mirados en cada dirección (4). Podemos poner una cota al tiempo de ejecución del algoritmo,

por lo que este seria nuevamente de orden N (donde N es el nº de pixeles de la imagen).

El valor umbral y los valores del vector ponderación permiten cambiar los resultados del

algoritmo de manera drástica, por ejemplo:

Nomenclatura de los vectores: Dado, siguiendo una recta, los pixeles V1 V2 P V3 V4, donde P es

el pixel a considerar y V1 V2 P V3 V4 sus vecinos en ese orden con respecto a la recta (esto es V1

el mas alejando a la derecha, V2 el más cercano a la derecha, V3 el más cercano a la izquierda

y V4 el más lejano a la derecha). Ui será el valor a acumular cuando Vi sea borde (con i entre 1 y

4), y se representaran (U1 U2 U3 U4).

Vector (0 0.5 0.5 0). Umbral 0.5: Pixeles que no tengan otro pixel considerado borde 8

adyacente son considerados NO BORDES.

Vector (0.25 0.25 0.25 0.25) Umbral 0.75: Al menos 3 pixeles deben de ser bordes para

que sea catalogado como borde.

3. Resolución practica:

Para la implementación del programa se ha usado el lenguaje de programación C#. Es un

lenguaje orientado a objetos, con recolección de basura, creado por Microsoft como un

contraataque a Java. La sintaxis es una evolución de la de los lenguajes Java/C++.

El lenguaje destaca (al igual que Java, y en contra de C++) por el Framework Net (en su versión

3.0). Este framework permite gestionar ventanas, cargado/guardado de ventanas, eventos,

etc... de manera sencilla (y es multiplataforma, gracias al proyecto Mono).

La elección de este lenguaje en detrimento de los dos anteriores (los otros dos candidatos más

viables para crear programas que procesen imágenes) ha sido la potencia de este Framework

(sin paragón en C++), así como la familiaridad mayor con el entorno Visual Studio 2008 (y su

debugger) en detrimento de las posibles alternativas en Java (Eclipse, NetBeans).

El rendimiento del código generado ha sido más que suficiente, tanto por la baja complejidad

de los algoritmos, muchos de ellos lineales, como por el hecho de que los programas

generados por C# son compilados en tiempo de ejecución a código nativo (esto en ciertas

implementaciones de la maquina virtual Java también se hace, pero no esta tan desarrollado),

así como, que C# permite trabajar con un modo "inseguro", directamente con punteros

tradicionales de C/C++, sin las comprobaciones extra que añade Java, y que hacen más lento el

acceso efectivo a memoria.

NET Framework gestiona el cargado/guardado de múltiples formatos de imagen de forma

transparente.

Como curiosidad, en la versión 3.0 en la que se ha desarrollado las imágenes siempre se

convertían íntegramente a imágenes RGB con 8 bits por canal, mientras que en 4.0 si la imagen

a cargar era en su formato nativo una imagen en escala de grises no se realizaba tal conversión

lo que provocaba una excepción al cargar imágenes en escala de grises con el programa. Este

error fue solucionado.

Como modelo inicial para saber cómo trataba C# las imágenes y como modificarlas hemos

usado de plantilla el proyecto de Reconocimiento de matriculas (PID, curso 2009/2010, era

nuestro proyecto a comentar).

Se han tomado (con pequeñas modificaciones) los algoritmos de conversión a escala de grises y

el filtro Sobel (en ambos se ha corregido un error en que no consideraban bytes de rellenos,

práctica normal en las formas de almacenamiento de imágenes en memoria, en las que se

introduces bytes "basura" al final de cada línea para disminuir tasas de errores en cache). En

Sobel además se ha modificado para que implemente más formalmente el algoritmo

tradicional (se comprueban los dos gradientes y se calcula la distancia euclídea).

El resto ha sido de implementación propia, exceptuando la idea tomada de

http://stackoverflow.com/questions/218060/random-gaussian-variables para la

implementación de una distribución gaussiana bajo C# medianamente parecida a la teórica

(siempre teniendo en cuenta que lo números no son aleatorios completamente, que no

tenemos control de la semilla generadora si nos atenemos al generador que viene con C#, etc.).

4. Experimentación

Veamos cómo se comporta el algoritmo frente a imágenes con ruido gaussiano.

Sobel Nuestro algoritmo

http://stackoverflow.com/questions/218060/random-gaussian-variables

(nótese la falta de consistencia de los bordes después de aplicar Sobel debido al ruido

gaussiano).

(nótese la diferencia de porcentaje de ruido que no ha podido eliminar Sobel)

5. Manual de usuario

Las funciones de los distintos controles son (numerados del 1 al 15).

1. (Cargar): Permite cargar una imagen en la aplicación. Entre otros los formatos soportados

son JPG, BMP, GIF y PNG. La nueva imagen sobre escribe a la imagen actual.

2. 2 (Guardar): Permite guardar la imagen mostrada en B en formato bmp (24 bits).

3. (Filtro Artículo): Ejecuta el filtro del artículo sobre la imagen cargada (Notar que si se ha

aplicado ruido a la imagen cargada, se aplicara sobre la versión con ruido de esta. Si esta

activo Aplicar Tratamiento, se aplicara el tratamiento tras ejecutar el filtro).

4. (Ejecutar Sobel): Ejecuta el filtro del Sobel la imagen cargada. Sobel se binarizara tomando

como umbral el número especificado en el recuadro inmediatamente inferior (Notar que si

se ha aplicado ruido a la imagen cargada, se aplicara sobre la versión con ruido de esta. Si

esta activo Aplicar Tratamiento, se aplicara el tratamiento tras ejecutar el filtro).

5. Ver anterior.

6. (Ejecutar Filtro Propio): Ejecuta el filtro propio. Como umbral de agrupamiento se usara el

especificado en el recuadro inmediatamente inferior (Notar que si se ha aplicado ruido a la

imagen cargada, se aplicara sobre la versión con ruido de esta. Si esta activo Aplicar

Tratamiento, se aplicara el tratamiento tras ejecutar el filtro).

7. Ver anterior.

8. (Siguiente paso): Cuando se ejecutan los filtros (3,4 y 6) estos consisten en 2 o más

operaciones. Hay que pulsar este botón para que se ejecuten las operaciones. La primera

operación de cada filtro se ejecuta de manera automática al aplicarlo. Mientras queden

operaciones se inhabilita el resto de operaciones.

9. (Reiniciar): Este botón vuelve a establecer como imagen a la que aplicar los filtros la

imagen cargada con 1 (y sin ruido en caso de que se le haya aplicado).

10. (Aplicar ruido): Este botón aplica sobre todos los pixeles de la imagen ruido gaussiano con

la desviación media especificada en el recuadro inmediatamente inferior. El ruido se aplica

sobre la imagen que se cargo con 1, y NO sobre la imagen ya afectada con ruido. Para cada

pixel se calcula un valor de ruido y se aplica a los canales de color.

11. Ver anterior.

12. (Umbral tratamiento): Aquí se especifica el umbral del tratamiento post-detección. Para

más detalle ver la documentación.

13. (Aplicar tratamiento): Si esta casilla no está marcada no se aplciara el tratamiento tras el

filtro. Si está marcada, el tratamiento se añadirá como última operación en la cola de

operaciones del filtro,

14. (Aplicar a todos): Si está marcada el tratamiento puede "promocionar" pixeles no bordes a

bordes, si pasa el umbral. En cualquier caso (este o no marcada) el filtro siempre

transforma pixeles catalogados como bordes en pixeles no borde si no pasan el umbral.

15. (4 recuadros). Permite establecer los valores del vector de ponderación. Ver

documentación para más detalles.

A: Miniatura de la imagen cargada.

B: Resultado de la última operación. Esta imagen es la que se guarda con el botón

correspondiente.

C (Notas): Aquí el programa informa sobre datos de la última operación aplicada. Notar que, si

por ejemplo, se ha introducido valores erróneos en los cuadros de texto (usándose puntos en

vez de comas para los números con decimales), el programa asumirá valores por defecto. Los

valores usados se muestran aquí, siendo esta la única forma de comprobar si se han

introducido los parámetros correctamente.

6. Conclusiones

El algoritmo del artículo resulta ineficaz para la gran mayoría de imágenes debido a que

binariza la imagen, y detectando únicamente bordes entre los 2 conjuntos establecidos en la

binarización. Esto resulta ineficaz para un algoritmo de propósito general de detección de

bordes.

Es más la "protección" que ofrece contra ruido gaussiano (foco en teoría del algoritmo) se

fundamente en que, si la imagen está compuesta por dos conjuntos de pixeles y estos se

encuentra lo suficientemente separados (sus tonos de gris), sus valores modificados por el

ruido (que sigue una distribución gaussiana, esto es, que la perturbación en el nivel de gris

sigue esa distribución, y por lo tanto suele modificar los pixeles +/- su desviación media, y

posee, en toda la imagen media 0) no "escaparan" al otro conjunto.

Si ponemos el umbral en medio de los niveles de gris representativos de los 2 conjuntos

anteriores, con suerte estará lo suficientemente alejado de la mayoría de pixeles de estos para

que estos una vez perturbados por un ruido gaussiano tengan poca probabilidad de cruzar el

umbral y ser catalogados como pertenecientes al otro conjunto.

Si solos nos interesan establecer donde se producen transiciones entre 2 conjuntos con tono de

gris medio muy distinto perfecto. Pero esto no es el caso habitual.

El cálculo del umbral de binarización sigue un método que además, no se comenta si es finito

(en la implementación se ha optado por acotar el número de iteraciones suficiente grande,

para todas las imágenes probada ha resultado finito, y de pocas iteraciones, pero no puede

hacerse a priori, sin un estudio más preciso esa asunción de manera general).

Podría mejorarse la idea de las siguientes formas:

No buscar transiciones entre 2 grupos (esto es binarizar simplemente la imagen), sino permitir

estables mas subgrupos. donde el nº de grupos a establecer sea entrada del usuario (del tipo

2N). Entonces el algoritmo catalogaría recursivamente los pixeles de un conjunto u otro N

veces. El algoritmo, que generaría un arbol binario completo de profundidad N, podría

"podarse", haciendo, por ejemplo un análisis de desviación típica de los pixeles. Si en un paso

dado llegamos a que el subconjunto obtenido posee una desviación típica menor que cierto

umbral, paramos de subdividir.

Esto permitiría captar bordes entre más de dos grupos característicos, aunque, en pos de

mantener la idea central del algoritmo (los grupos tienen que estar los suficientemente

alejados como para que el ruido tenga pocas posibilidades de introducir una catalogación

errónea), tampoco podrían ser muchos niveles (probablemente 4 - 8, dependiendo de las

desviación media del ruido gaussiano).

Otra idea es subdividir la imagen, en celdas, y aplicar el algoritmo localmente. Las celdas no

pueden tener un tamaño demasiado pequeño (pocos elementos para extraer conjuntos

representativos, además la suposición de un efecto promedio 0 del ruido gaussiano solo vale

para conjuntos de pixeles lo suficientemente grandes...). Esto no arreglaría la no detección de

bordes en regiones más pequeña que la celda, además de que podrían resultar "visibles" al re

combinar sus resultados (lo que es catalogado en un grupo u otro depende de la celda, y

podrían haber "roturas" de bordes, con el tamaño de la celda en toda la imagen.

El detector de bordes de cosecha propia podría mejorarse de muchísimas maneras. Partiendo

de la idea de detectar regiones distintas en torno al pixel a considerar, la catalogación en

bordes utilizada es la más simple posible (se miran los grupos, se asigna al primero valido, y si

no hay, se crea un nuevo grupo). Un algoritmo mas concienzudo de generación de grupos (que

realizara todas las permutaciones posibles de grupos) sería más eficaz a costa de una

complejidad muchísimo mayor.

Otra mejora seria no quedarse solo en los vecinos adyacentes, sino estudiar regiones más

amplias (como la mayoría de algoritmos de detección/ eliminación de ruido basados en Fuzzy,

como por ejemplo el del grupo 8).

Partiendo de que su algoritmo detectaba pixeles ruidosos de una celda amplia (7x7 centrada en

el pixel a analizar proponían como entorno genérico), la idea sería luego agrupar los pixeles

que hayan pasado el test, y usarlo para formar grupos (por supuesto la norma podría ser

distinta a la euclídea), Si 2 o más grupos formados (y como anotamos antes, la formación de

grupos podría ser mas muchísimo más compleja/exhaustiva) se encuentran alrededor del pixel

en cuestión, entonces es borde.

Son ideas para robustecer al algoritmo, ante ruido sobretodo, ya que ante ruido gaussiano es

tremendamente débil (su única manera de defenderse es volverse menos estricto con que

pixeles considera pertenecientes a un grupo, aumentado su umbral de agrupamiento, pero

esto afecta muy negativamente a su precisión) así como aumentar su tasa de acierto, eso sí a

cosa de una complejidad temporal (y de implementación, para que negarlo) muchísimo mayor.

El tratamiento post-detección podría mejorarse incluyendo mas trayectorias de análisis (y no

solo rectas). Esto evitaría los comportamientos anómalos que presenta ante giros bruscos. Y la

no detección de bordes que sigan según que recta incluso (por usarse en la implementación las

4 rectas más sencillas/rápidas).

O permitiendo analizar un entorno mayor que los 4 más cercanos (aunque al aumentar los

vecinos aumentamos de manera exponencial el número de rectas posibles, y por lo tanto la

complejidad temporal).

Estableciendo probabilidad condicionada (no solo si V1 es borde y V2 es borde, entonces la

probabilidad de ser borde de P es U1 y U2, sino que esos valores U1 U2 dependan entre sí, o de

un entorno más lejano).

Una manera de aproximar esto podría ser que el algoritmo tuviera múltiples pasadas. Esto es,

en la 2º pasada, los pixeles no añaden su probabilidad completa si son borde al acumulador,

sino solo dependiendo de lo probable que fueran ellos borde (calculado en una pasada

anterior). Muy seguramente el vector de ponderación debería de establecerse para cada

pasada.

7. Tabla de trabajo

Notación del campo actividad:

1 = Estudio del documento y posible implementación del algoritmo

2= Implementación del algoritmo

3= Creación de la presentación

4= Creación de la documentación

5 = Pruebas del algoritmo y sugerencias.

7.1 Reuniones de todo el grupo:

Fecha de reunión Inicio Fin Tiempo total Miembros Actividad

16-12-10 19:30 21:30 2h Simo, Javier, Lucas 1







Total horas en grupo: 28h

7.2 Javier y Simo


27-12-10 12:30 15:30 3h Javier, Simo 3

20-12-10 19:30 21:30 4h Javier, Simo 3

14-01-11 10:00 15:00 6h Javier, Simo 4

Total horas Javier y Simo: 28h + 13h = 41h

7.2 Lucas


26-12-10 11:30 17:30 6h Lucas 2

28-12-10 12:30 18:30 12h Lucas 2

30-01-11 15:00 17:00 14h Lucas 5

Total horas Lucas: 28h + 14h = 42h

un nuevo algoritmo de detecciÓn de bordes en...

Documents