Java RGB Манипуляция с растровыми изображениями

Question

Этот вопрос может быть немного запутанным, но здесь мы идем!

Итак, я смотрел Notch, кодирующий игру, и он сделал что-то интересное. Он сделал класс растрового изображения, где он хранил каждый пиксель в массиве. (int array). Затем мне пришла в голову идея поиграть с растровыми изображениями, а потом у меня появилась идея манипулировать/изменять R, G и B растрового изображения.

Итак, как я пытался сделать это было так:

int rmod = 100; 
    int gmod = 100; 
    int bmod = 100; 
    for (int i = 0; i < 64*64; i++) { 
     int color = testBitmap.pixels[i]; 
     int r = color >> 16; 
     int g = color >> 8; 
     int b = color; 

     r = (r/100)*rmod; 
     g = (g/100)*gmod; 
     b = (b/100)*bmod; 

     testBitmap.pixels[i] = r+b+g; 
    } 

Так что да, идея заключается в том, что rmod, GMOD и BMOD работает как% от RG B. Таким образом, когда все они при 100, битмап отображается нормально, это идея. И затем, скажем, если вы измените rmod на 150, R будет на 50% «сильнее».

Теперь я знаю, что здесь я делаю неправильно. Я думаю, что int r, g и b верны. (хотя я действительно не понимаю, что такое «>>». Я знаю, что он меняет байты или что-то в этом роде, но на самом деле я их не получаю.) Получив rg и b, я получаю 1% от них, и умножьте их на проценты, объявленные в rmod, gmod и bmod. Тогда, я считаю, что я делаю что-то совершенно неправильное в строке, где я устанавливаю новый RGB текущего пикселя. (testBitmap.pixels [i] = r + g + b;)

Не совсем уверен, как это сделать. Если кто-нибудь попытается объяснить, как работает «>>», и почему он работает в этой ситуации, а также как управлять RGB через rmod, gmod и bmod, я был бы так счастлив!

Возможно, я предоставил слишком мало информации, поэтому, если вам нужно посмотреть классы и т. Д., Я тоже могу разместить их здесь!

Спасибо!

Answer 1

Прежде всего, оператор >> сдвигает бит шаблона справа, однако во многих местах. Правое смещение эквивалентно делению на две силы. Например, (все числа в двоичном формате), 1000 >> 3 = 0001 (сдвиг «1000» влево 3 раза). 1000 в двоичном виде 8, поэтому, 1000 >> 3 = 1000 /2 = 1.

Однако вы хотите двоичный сдвиг влево для вашего кода <<, равная умножению мощности два. Причина в том, что, поскольку вы имеете дело с значениями RGB (24 бит), вы хотите умножить красный на 2 , зеленый на 2 , а синий на 2 . Это 24 степени в 2, всего. Таким образом, 24 бит. Я не точно уверен, почему это так, я уверен, что кто-то еще может это объяснить.

Для вашего массива testBitmap.pixels[], я предполагаю, что это фактические данные RGB в растровом изображении. Это требует некоторого понимания того, как работает формат растрового файла, но в основном пиксели хранятся в обратном порядке; например Данные RGB сохраняются (относительно пикселей изображения) слева направо и вниз, вверх и вверх в триплетах, например. если первый триплет в файле был «00 00 FF», то нижний левый пиксель был бы красным.

Итак, вы понимаете, что вам нужен другой массив для фактического хранения пикселей, так как массив testBitmap.pixels содержит байты (в триплетах, в форме BGR).

Теперь, когда у нас есть это в стороне (если вы все еще не понимаете, есть много ресурсов для понимания форматов файлов растровых изображений и их чтения), чтобы преобразовать каждый триплет в один целочисленный пиксель, вам нужно сначала получить значение без знака каждого байта, добавив & 0xFF в конец ваших заданий r, g и b. Так,

int g = testBitmap.pixels[i] << 16 & 0xFF; 
int b = testBitmap.pixels[i+1] << 8 & 0xFF; 
int r = testBitmap.pixels[i+2] & 0xFF; 

Для преобразования этих значений в одно целое число пикселов, используйте побитового оператора между ними, таким образом,

int pixel = (r | g) | b; 

Затем, если вы хотите сохранить эти значения в изображении в позиции (x, y), используйте BufferedImage.setRGB(x, y, pixel). Но будьте осторожны, поскольку формат растрового файла хранит пиксели «вверх ногами».

Чтобы отредактировать эти значения, умножьте на каждое значение на константу, но помните, что значения могут быть только между 0 и 255.