Android Question Rotate RGB channels of an Image

[Johan Schoeman]

I am seeing the forest for the trees with the attached project. The object is to rotate the R, G, B channels independently based on the 3 x seekbar values and then combine them into a "twisted" RGB image. The rotation around the centre point seems to be working fine but if you for eg select only the Green channel to view, the image is not only green. Same with the Blue only channel. I suspect the Red channel suffers from the same sickness although not as obvious as Green and Blue channels. Can someone perhaps see where I am missing whatever it is that I am missing? Will really appreciate it.

I have a similar project (but without rotation) where the same images split perfectly into separate R,G, and B channels. But I don't want to follow that route. Would like to understand what it is that I am missing in the attached project.

Note:
The check boxes -> select channel(s) to display in converted image
The Seekbars -> set degrees to rotate color channel(s) by

(Making use of JPEG library by @agraham)

Edit: If you click on any of the two displayed images it will load a new/different image (5 different images in the project)

 

[James Chamblin]

notice the extra AND's at the set pixel. for some reason it's needed even if you ANDed the value before already.

if you don't do it you get white dots for some unclear reason.

That is because rd, gn, and bl are defined as bytes. Colors.ARGB takes Ints as parameters. Since bytes are signed, any pixel value over 127 will be interpreted as a negative numbers and converted to a negative Int when passed to Colors.ARGB. Using AND on the number simply strips the negative part of the number leaving an Int in the range of 0-255 which is what we want.

 

[sorex]

well that still doesn't explain it all.

when I set r & g to 0 and b that value like

Jpgr.SetBmpPixel(x, y, Colors.ARGB(255,0,0, img_bl(x,y) ))

it still gives white pixels between the blue ones (see piccy) even when r & b are forced to 0 so that's impossible.

this

Jpgr.SetBmpPixel(x, y, Colors.ARGB(255,0,0, Bit.AND(img_bl(x,y),255) ))

works right tho.

 

[James Chamblin]

Let me try to explain. img_bl(x,y) holds a signed byte in the range of -128 to 127. Pixel values are unsigned in the range of 0 to 255. If the blue component is 255, it will be stored in img_bl(x,y) as the value -1. The function Colors.ARGB takes ints for it's parameters. The byte -1 is converted to the int -1 before sending it to the function. This is done by extending the sign throughout the additional 24 bits. This extension will corrupt the red and green components which is why you end up with white.
Unfortunately, this is just the way Java works. Nothing B4A can do about it without complicating the whole works. The most common way to deal with it is the same way you already found. AND the value with 255 which strips away the signed portion, leaving you with what you want.

 

[sorex]

then the library should've catched this issue since it's requesting the 4 individual a,r,g,b values it should've ANDed it in the lib to make sure things like this won't happen

either that or use 1 parameter for the argb.

when modding the code I tried with ubyte but B4A doesn't have this type unlike some other languages.

 

[Johan Schoeman]

It didn't rotate is just moved away from the center.

The attached file should solve the problem. I have changed the imageview size in designer script to test it and it seems to be OK on Samsung S4 mini and Samsung 7"tablet. Will appreciate some feedback if you have different devices to test it on. It should now rotate properly (i.e around the centre point of the imageview and not just move away from the centre (and then try to rotate around the bottom right hand corner of the smaller image that was generated)