Thread: Rotate a pixel array and calculate bounding box

Hi All,

I'm having a bit of a problem here. I'm trying to develop an "image" manipulation application. However, the visual data is based on actual information in a two-dimensional array. Due to the nature of other calculations, I can't convert the data to a picture (forcing 0-255) then convert it back based on some precalculated conversion unit; it would introduce too many rounding errors and data degradation.

That said, what is the most accurate mechanism by which to take an array PixelArray(x,y) and rotate it to a predetermined angle?

Also, what are some appropriate mechanisms by which to predetermine a bounding box?

Regards.

Originally Posted by gberz3

Hi All,

I'm having a bit of a problem here. I'm trying to develop an "image" manipulation application. However, the visual data is based on actual information in a two-dimensional array. Due to the nature of other calculations, I can't convert the data to a picture (forcing 0-255) then convert it back based on some precalculated conversion unit; it would introduce too many rounding errors and data degradation.

That said, what is the most accurate mechanism by which to take an array PixelArray(x,y) and rotate it to a predetermined angle?

Also, what are some appropriate mechanisms by which to predetermine a bounding box?

Regards.

I don't think it's possible to do what it sounds like you want to do. See attachment

So if we have an array with values for our colours like in the example on the left, and we tilt it to a 45 degree angle, our edges will look like those shown, but how do we fill in the inside? Also notice that the length of the sides are different now, (about 41% longer)

I think no matter how you do it, you will be forced to degrade the image.

Also, I am curious about the statement "forcing 0-255" This sounds like your array is filled with values 0-255, which point back to a colour palette, I don't know what requirements your program has, but why not make a 3 dimensional array, and keep red green blue values inside of it, then you can do all your manipulation in RGB. Then (I assume your output needs to be in some indexed colour format, or else you wouldn't be using palettes at all), you could create the palette at the end when outputting the finished image, and convert the image to an indexed colour array.

Meaning you would have 2 files, the working file, in RGB, and the finished file, in some indexed colour format such as .gif (consider how photoshop uses the working format .psd, then only converts to .jpg or whatever format you want, at the end when you save your finished product specifically in that format)

It's my assumption that because you considered converting to an image for the rotation, that you have the capability to rotate it as an image, but not as an array. I can't help with rotating a pixel array, that is well above my capabilities, but if you do all the work in RGB, then you might be able to bypass the issue alltogether, as rotating the pixel array would not create noticeable colour conflicts in RGB the same way that it would with indexed colours (meaning colours that aren't defined would not have to change much in order to become a colour that is defined).

Anyway, IDK if that helps or not, it might be too late to consider using RGB in your array, IDK. GL w/ your project. Hope someone else can offer you some useful advice.

And you should post your project when you finish, I would love to try it out

That was an awesome post. Thanks for your help. Actually I've been working with a 3-dimensional array, but in order not to confuse the issue, I spoke of it in 2D.

Basically I have a 3D array with X,Y coordinates as the first two, then two values associated; a BooleanValue that lets me know that after rotation and adding a bounding box that it was one of the original pixels and not part of the bounding box, and a PixelValue (I only need one because the end result is *always* grayscale, so I just fill RGB(#,#,#))

. . .I know, I know, that was a terrible run-on sentence. . .

I've been using the information from this site to perform my rotation calculations:

Geometric Transformations

. . .but it's still not perfect. I've also been filling the next X,Y with the current values in order to "fill" any potential missing pixels upon rotation. Still, the method isn't terribly consistent, and I'm currently at the point where the bounding box is skewing further transformations.

My original goal was, as I said, to mark "original" pixels in order to keep up with them. I'm thinking now that I might need to simply add some type of transformation limit in order to maintain data consistency. Below is an example of my array written RealBasic with semi-demi-pseudocode :

Code:

const kPixelValue = 0
const kOriginalPixel = 1
dim PixelArray(50,100,2) as double

PixelArray(1,1,kPixelValue) = 4839.344  
//This is the original value read in from the file.  I need to keep this value and "fake" it in the picture.  But I can't afford to convert to a 0-255 value (the range of RGB) and convert back because I will never get back an accurrate original value.  Otherwise I could simply convert it and use available RB picture manipulation functions.
PixelArray(1,1,kOriginalPixel) = 1    //This tells the array that it is an original pixel

Anyway, that's the long and short. Thanks again, and thanks in advance.