: : : Anyone have an idea how to do this?
: : :
: : : Have a 100*100 grid where the user can draw in an image of black
: : : pixels (so can be 1s or 0s). Was going to feed this into an array
: : :
: : : I have to then rotate this around (the info in the array), but with
: : : many degrees of freedom not just 90 deg shifts
: : :
: : :
: : :
: : : anyone have an idea??
: : :
: :
: : The biggest problem with rotation around a point (x,y) with an angle
: : t is that you are working with pixels rather than a continuum. It's
: : easy to calculate where in the continuum a pixel would end up, but
: : it's not possible to put a pixel in a pixel. You'll need to 'smear'
: : each pixel out over multiple destination pixels (atleast, that's one
: : approach).
: : Basically, what you do is consider the pixel as a square in the
: : continuum, then rotate it around (x,y) with angle t. It'll come out
: : the same pixel only then itself also turned over the angle t. Then,
: : you'll need to 'pixelize' the angled square. For instance, you could
: : say the turned pixel affects the destination pixels equal to the
: : amount of how much of the turned pixel is contained within the
: : destination pixel.
: : I've created a MS Paint illustrative picture, and attached it to
: : this post.
: : The left side shows what happens to a pixel when it is rotated in
: : the continuum (actually I drew it wrong, but you get the idea: the
: : square itself rotates). The left shows what I mean by 'smearing'
: : each rotated pixel over the destination pixels. The grid shows the
: : destination pixels and the red shows how the converted pixel would
: : look when it is rotated in the continuum (actually, here too I drew
: : it wrong, and also the red pixel is way too big, because it should
: : actually be the same size as the raster, but the point, I hope, is
: : clear). The numbers there are the percentages at which the rotated
: : pixel affects the final color of the destination pixel. It's equal
: : to the percentage of overlap. So in the centers, we get a 100%
: : influence, but at the edges only around 10%.
: : The idea is to do this for each pixel and remember the influences.
: : Then, when all these influences are calculated, each destination
: : pixel will have a collection of influences. Then you arithmatically
: : balance these influences to determine the final color:
: : If 70% influence from a red pixel, and also 15% from a blue, the
: : final pixel should be such that the red pixel has more effect on the
: : color, thus more red than blue. More exactly: 70/85 part red, 15/85
: : part blue. Then you turn this into an RGB color for the pixel (this
: : is all pretty sketchy still; if you want I could help you with how
: : to precisely implement this).
: : Note that it's also possible that a pixel has no influences, which
: : means the rotation 'frees up' the pixel (or: when rotating, this
: : pixel is placed somewhere else but no other pixel comes on this
: : spot). You'll need to give these pixels the standard background
: : color.
: :
: : Also, when using a 100*100 pixel picture, the rotated picture can
: : take up as much as 100 * Sqrt(2) ( = Sqrt(100² + 100²) = size of the
: : diagonals) pixels squared (ie 100*Sqrt(2) x 100*Sqrt(2) ).
: :
: : This is just a thought, and is not ready to be programmed yet.
: : You'll need to furtherly develop it. One thing you need to do is
: : calculate the destination of the corner points of each pixel (using
: : Sines and Cosines; with this I can help if you want). Then, you'll
: : need to develope a function that calculates, given 4 points which
: : represent the corners of the deformed pixel, the percentage of area
: : that is filled in a destination pixel by this deformed pixel. Then
: : do this for each pixel (calculate the position of it's deformed
: : corner pieces and then calculate the influence on each of the pixels
: : it overlaps). After that, you need to calculate the final color for
: : each destination pixel by looking at the influences and color of all
: : the pixels that influence this destination pixel.
: :
: : Anyway, sounds like fun :) I don't know how clear my explanation
: : was, so don't hesitate to ask questions about it.
: :
: : Best Regards,
: : Richard
: :
: : The way I see it... Well, it's all pretty blurry
:
:
:
: wow!!!! thank you SO much!!! You went above & beyond the call of
: duty!!! I will have to print this out and show it to my dad as he is
: helping (I am a n00b at visual basic)
:
: The program is for a neural network and recognising the smiley face
: at any angle, they work on a fuzzy type of principle so it doesnt
: have to be super-accurate rotation at all, maybe the rotated pixel
: can just "snap" into the nearest fit?.
:
:
That's also very possible, but I couldn't directly think of a way to make sure every pixel has a place, and for small resolutions (like 100*100 or less) every pixel lost matters.
But you could surely try it, and if it works out well enough then you don't have to get it complicated.
In that case, I suggest you take the center, calculate it's new position and check in which pixel it ends up.
The problem I had with this is that two different pixels could end up at the same spot and overwrite eachother. An easier fix than the long-story-idea would be to also here average the pixels.
I guess it all depends on the precision you need from it. Neither solution is perfect, and probably each solution has pictures that work well on that one but not on the other, but also pictures that work better on the other.
Best Regards,
Richard
The way I see it... Well, it's all pretty blurry
