otsu metodo algorithm image-processing adaptive-threshold

algorithm - metodo - Bradley Adaptive Thresholding-Confused(preguntas)



threshold opencv c++> (1)

Antes de comenzar, presentemos el pseudocódigo del algoritmo escrito en su artículo:

procedure AdaptiveThreshold(in,out,w,h) 1: for i = 0 to w do 2: sum ← 0 3: for j = 0 to h do 4: sum ← sum+in[i, j] 5: if i = 0 then 6: intImg[i, j] ← sum 7: else 8: intImg[i, j] ← intImg[i−1, j] +sum 9: end if 10: end for 11: end for 12: for i = 0 to w do 13: for j = 0 to h do 14: x1 ← i−s/2 {border checking is not shown} 15: x2 ← i+s/2 16: y1 ← j −s/2 17: y2 ← j +s/2 18: count ← (x2−x1)×(y2−y1) 19: sum ← intImg[x2,y2]−intImg[x2,y1−1]−intImg[x1−1,y2] +intImg[x1−1,y1−1] 20: if (in[i, j]×count) ≤ (sum×(100−t)/100) then 21: out[i, j] ← 0 22: else 23: out[i, j] ← 255 24: end if 25: end for 26: end for

intImg es la imagen integral de la imagen de entrada al umbral, asumiendo la escala de grises.

Implementé este algoritmo con éxito, así que hablemos de sus dudas.

¿Qué es count entonces? Si es el número de píxeles en la ventana, ¿por qué es 2 * 2 = 4, en lugar de 3 * 3 = 9 según el algoritmo?

Hay una suposición subyacente en el documento de la que no hablan. El valor de s debe ser impar, y la ventana debe ser:

x1 = i - floor(s/2) x2 = i + floor(s/2) y1 = j - floor(s/2) y2 = j + floor(s/2)

count es sin duda el número total de píxeles en la ventana, pero también debe asegurarse de no salirse de los límites. Lo que tiene allí sin duda debe ser una ventana de 3 x 3 y entonces s = 3 , no 2. Ahora, si s = 3 , pero si tuviéramos que elegir i = 0, j = 0 , tendremos valores y que son negativos No podemos tener esto, por lo que la cantidad total de píxeles válidos dentro de esta ventana de 3 x 3 centrada en i = 0, j = 0 es 4, y por lo tanto, count = 4 . Para ventanas que están dentro de los límites de la imagen, entonces el count sería 9.

Además, ¿por qué el valor original del píxel se multiplica por el conteo? El documento dice que el valor se compara con el valor promedio de los píxeles circundantes, por qué no lo es:

in[i,j] <= (sum/count) * ((100 - t) / 100)

¿entonces?

La condición que estás viendo está en la línea 20 del algoritmo:

20: (in[i, j]×count) ≤ (sum×(100−t)/100)

La razón por la que echamos un vistazo a la cuenta in[i,j]*count es porque suponemos que in[i,j] es la intensidad promedio dentro de la ventana de sxs . Por lo tanto, si examinamos una ventana de sxs y sxs todas las intensidades, esto es igual a in[i,j] x count . El algoritmo es bastante ingenioso. Básicamente, comparamos la intensidad media supuesta ( in[i,j] x count ) dentro de la ventana de sxs y si esto es menor que t% del promedio real dentro de esta ventana de sxs ( sum x ((100-t)/100) ), luego la salida se establece en negro. Si es más grande, entonces la salida se establece en blanco. Sin embargo, usted ha declarado con elocuencia que debería ser esto en su lugar:

in[i,j] <= (sum/count) * ((100 - t) / 100)

Esto es esencialmente lo mismo que la línea 20, pero dividiste ambos lados de la ecuación por count , por lo que sigue siendo la misma expresión. Diría que esto declara explícitamente de lo que hablé anteriormente. La multiplicación por count es ciertamente confusa, por lo que lo que has escrito tiene más sentido.

Por lo tanto, solo lo estás viendo de otra manera, ¡y eso está totalmente bien! Entonces, para responder a su pregunta, lo que ha dicho es ciertamente correcto y es equivalente a la expresión que se ve en el algoritmo real.

¡Espero que esto ayude!

Tengo algunas preguntas, probablemente estúpidas, sobre la implementación del umbral adaptativo por parte de Bradley. He leído un artículo sobre él http://people.scs.carleton.ca:8008/~roth/iit-publications-iti/docs/gerh-50002.pdf y estoy un poco confundido. Principalmente sobre esta declaración:

if ((in[i,j]*count) ≤ (sum*(100−t)/100)) then

Supongamos que tenemos esta entrada:

width, i [0] [1] [2] +---+---+---+ height [0] | 1 | 2 | 2 | j +---+---+---+ [1] | 3 | 4 | 3 | +---+---+---+ [2] | 5 | 3 | 2 | +---+---+---+

y digamos eso:

s = 2 s/2 = 1 t = 15 i = 1 j = 1 (we are at the center pixel)

Entonces eso significa que tenemos una ventana 3x3, ¿verdad? Entonces:

x1 = 0, x2 = 2, y1 = 0, y2 = 2

¿Qué es contar entonces? Si es el número de píxeles en la ventana, ¿por qué es 2 * 2 = 4, en lugar de 3 * 3 = 9 según el algoritmo? Además, ¿por qué el valor original del píxel se multiplica por el conteo?

El documento dice que el valor se compara con el valor promedio de los píxeles circundantes, por qué no es

in[i,j] <= (sum/count) * ((100 - t) / 100)

¿entonces?

¿Alguien puede explicarme esto? Probablemente sea una pregunta muy estúpida, pero no puedo entenderlo.