Брэдли Адаптивный порог - Confused (вопросы)

Question

У меня есть несколько вопросов, возможно, глупых, о внедрении адаптивного порога Брэдли. Я прочитал статью об этом http://people.scs.carleton.ca:8008/~roth/iit-publications-iti/docs/gerh-50002.pdf и я немного запутался. Главным образом об этом утверждении:

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

Давайте предположим, что у нас есть этот вход:

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

и скажем так:

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

Значит, у нас есть окно 3х3, верно? Затем:

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

Что тогда считать? Если это количество пикселей в окне, почему оно равно 2*2=4, а не 3*3=9 в соответствии с алгоритмом? Кроме того, почему первоначальное значение пикселя умножается на количество?

В документе говорится, что значение сравнивается со средним значением окружающих пикселей, почему это не так

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

затем?

Может кто-нибудь, пожалуйста, объясните мне это? Это, наверное, очень глупый вопрос, но я не могу понять это.

Answer 1

Прежде чем мы начнем, давайте представим псевдокод алгоритма, написанный в их статье:

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 является интегральным изображением входного изображения до порогового значения в предположении оттенков серого.

---

Я успешно реализовал этот алгоритм, поэтому давайте поговорим о ваших сомнениях.

Что такое count затем? Если это количество пикселей в окне, почему оно равно 2*2=4, а не 3*3=9 в соответствии с алгоритмом?

В статье есть предположение, о котором они не говорят. Значение s должен быть нечетным, а управление окном должно быть:

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

count конечно, общее количество пикселей в окне, но вам также нужно убедиться, что вы не выходите за пределы. То что у вас там обязательно должно быть 3х3 окна и так s = 3не 2. Теперь, если s = 3, но если бы мы должны были выбрать i = 0, j = 0, Мы будем иметь x а также y значения, которые являются отрицательными. У нас не может быть этого и поэтому общее количество действительных пикселей в этом окне 3 x 3 с центром i = 0, j = 0 4 и так count = 4, Для окон, которые находятся в пределах изображения, тогда count будет 9.

Кроме того, почему первоначальное значение пикселя умножается на количество? В документе говорится, что значение сравнивается со средним значением окружающих пикселей, поэтому это не так:

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

затем?

Условие, на которое вы смотрите, находится в строке 20 алгоритма:

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

Причина, по которой мы смотрим на in[i,j]*count потому что мы предполагаем, что in[i,j] средняя интенсивность в пределах s x s окно. Поэтому, если мы рассмотрели s x s окно и сложить все интенсивности, это равно in[i,j] x count, Алгоритм довольно гениальный. В основном, мы сравниваем предполагаемую среднюю интенсивность (in[i,j] x count) в пределах s x s окно, и если это меньше, чем t% фактического среднего в этом s x s окно (sum x ((100-t)/100)), то на выходе устанавливается черный цвет. Если он больше, чем выход, установлен на белый. Тем не менее, вы красноречиво заявили, что это должно быть так:

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

По сути, это то же самое, что и строка 20, но вы разделили обе части уравнения на count, так что это все то же выражение. Я бы сказал, что это прямо говорит о том, что я говорил выше. Умножение на count конечно, сбивает с толку, и поэтому то, что вы написали, имеет больше смысла.

Поэтому вы просто видите это по-другому, и это совершенно нормально! Таким образом, чтобы ответить на ваш вопрос, то, что вы сформулировали, безусловно, правильно и эквивалентно выражению, которое видно в реальном алгоритме.

---

Надеюсь это поможет!