I have calculated that the current Mandelbrot iterates 208,200 times. But if I use a break to control the iterations it outputs kinda like a printer that has ran out of ink half way through, so I am obviously not doing it correctly, does anyone know how iteration controls should be implemented?
int iterations = 0;
for (x = 0; x < x1; x ++)
{
for (y = 0; y < y1; y++)
{
// PAINT CONTROLS HERE
if (iterations > 200000)
{
break;
}
iterations++;
}
}
You need to change the values of y1 and x1 to control the "depth" of your Mandelbrot set.
By breaking at a certain number of iterations, you've gone "deep" for a while (because x1 and y1 are large) and then just stop part way through.
It's not clear what you're asking. But taking the two most obvious interpretations of "iterations":
1) You mean to reduce the maximum iterations per-pixel. I wouldn't say this affects the "smoothness" of the resulting image, but "smooth" is not a well-defined technical term in the first place, so maybe this is what you mean. It's certainly more consistent with how the Mandelbrot set is visualized.
If this is the meaning you intend, then in your per-pixel loop (which you did not include in your code example), you need to reset the iteration count to 0 for each pixel, and then stop iterating if and when you hit the maximum you've chosen. Pixels where you hit the maximum before the iterated value for the pixel are in the set.
Typically this maximum would be at least 100 or so, which is enough to give you the basic shape of the set. For fine detail at high zoom factors, this can be in the 10's or 100's of thousands of iterations.
2) You mean to reduce the number of pixels you've actually computed. To me, this affects the "smoothness" of the image, because the resulting image is essentially lower-resolution.
If this is what you mean, then you need to either change the pixel width and height of the computed image (i.e. make x1 and y1 smaller), or change the X and Y step sizes in your loop and then fill in the image with larger rectangles of the correct color.
Without a better code example, it's impossible to offer more specific advice.
Related
I have two areas, which are both given in there bounds.size. Now the z-axis doesnt matter for me, since im working in 2D. I want to add these vectors so i have a vector, which represents the jointed area. Simply adding these vectors the normal way does not work. The way the area looks in the end is not important, its just important that the size is the same as, both areas combined.
Edit: I have the bounds.size of two polygoncolliders and i want to get a value that represents the bounds.size of the two polygoncolliders combined
area 1 and area 2 combined
The way the area looks in the end is not important, its just important that the size is the same as, both areas combined.
As there are nigh infinite possibilities otherwise, I'm going to limit myself to results where x = y, for the simple reason that you don't end up with silly vectors like (0.5,80000) but rather a more balanced (200,200).
This isn't all that hard when you look at it algebraically:
float result_area = first_area + second_area;
Calculating the area is easy:
float area = myVector.X * myVector.Y;
Thus rendering the sum of the areas also easy:
float result_area = myFirstVector.X * myFirstVector.Y + mySecondVector.X * mySecondVector.Y;
For the sake of example, let's say first_area = 50 and second_area = 350, thus resulting in result_area = 400;
Since we are limited to results where x = y, the result is the square root of the area:
float theSquareRoot = Math.Sqrt(result_area);
myResultVector.X = theSquareRoot;
myResultVector.Y = theSquareRoot;
As I said, there are many other possible result vectors. For other cases, you're either going to have to define a given ratio (e.g. a ratio of 1 : 4 would give you (10,40) for the same example), but the calculation is a bit harder and you mentioned that you don't care about the exact shape anyway.
You could also just make a vector where X = result_area and Y = 1 (or vice versa), without having to calculate a square root.
Note that you've overengineered it. The area of an object is a onedimensional value (a number); yet you're expressing it using a twodimensional value (a number pair) to represent them.
Since you don't care about particular X/Y values, only what their product is, I would suggest you avoid vectors where possible, so you don't make it unnecessarily complicated.
I am developing a face tracking application using Kinect, and I have output like the following.
What I want to do is the extract the exact face area, either the yellow-lined area or the red rectangular, it would be great if you can tell me how to do both. Basically, I am expecting an output with only the interested area with black otherwise.
Right now I have all the point coordinates that I need, but I am not sure which class and method to use.
Please note that I am working with video frames, if it makes any difference.
Thank you,
I haven't done this in C#, but in c++, running something like this generates an array of RGB values:
const XnRGB24Pixel *pImage = imageMD->RGB24Data(); // generate array
XnRGB24Pixel pixelRGB = *pImage; // get the first element of array
byte red = pixelRGB.nRed // read the RED value
The array is 1-dimensional and elements are stored in it row wise from the bottom (last row, then the row before last row, ...). Going through them with a nested for loop like this would give you the rectangular area you want:
for(int y = RECTANGLE_Y1; y < RECTANGLE_Y2; y++)
{
for(int x = RECTANGLE_X1; x < RECTANGLE_x2; x++)
{
pixelRGB = pImage[y*RESOLUTION_WIDTH + x]; // get the element
// work with pixelRGB
}
}
Replace RECTANGLE_X1 and RECTANGLE_Y1 with the coordinates of the lower left edge coordinates of your rectangle and RECTANGLE_X2 and RECTANGLE_Y2 with the upper right edge coordinates.
For getting the values of pixels inside the non-rectangular area, a similar approach would work if you can figure out the geometric calculations necessary to recognize when a given [x,y] are inside the area; but even after that, I don't have any clue on how to store it in conventional data structures.
Hope this helps.
I basically have a grid, lets say 100 x 100 which is filled with url's of a photo collection. Some of these are duplicates as I may only have 50 photos but I want to duplicate them to make sure the 100 x 100 grid is filled.
I randomly fill the grid with the URL's and then display them which is fine. The problem I have is that obviously sometimes photos with the same URL are randomly places together either on the x axis or y axis or sometimes both.
How can I make sure that I fill the grid so that these images with the same URL are as far apart as possible thus preventing 2 of the same photos appearing next to each other.
Any help appreciated
Mike
If you really want "as far apart as possible" then (1) I bet you're out of luck and (2) if that were achievable it would probably produce not-very-random-looking results. But if all you want is "somewhat far apart", it's not so bad. Here are a few things you can do.
(1) Classify grid positions according to the parity of their x,y coordinates: that is, whether they're odd and even. Divide the photos into four roughly-equal-sized batches. Now select from different batches according to the parity of the coordinates. The following code (which is a bit too "clever"; sorry) does this, modulo bugs and typos.
System.Random rng = new System.Random();
for (int x=0; x<nx; ++x) {
for (int y=0; y<ny; ++y) {
k = ((x&1)<<1) + (y&1); // 0..3
int n_photos_in_batch = (n_photos+3-k) >> 2;
int photo_number = (rng.Next(0,n_photos_in_batch-1) << 2) + k;
// use this photo
}
}
Downsides: doesn't do anything to move copies of a photo any further away from one another than one step. Reduces randomness somewhat since all copies of any given photo will be in a fixed subset of positions; in some contexts this may be visible and look rather silly.
Variations: we're basically covering the grid with 2x2 tiles, and restricting the range of photos allowed to occur in each tile. You could use larger tiles, or differently-shaped tiles, or arrange them differently. For instance, if you say k = ((x&1)<<1) ^ (y&3) you get 2x2 tiles arranged in a kinda-hexagonal pattern, which is actually probably better than the version above.
(2) Loop over positions in your grid (raster order will do, though there might be better alternatives) and for each one choose a photo that (a) doesn't already occur too near to the position you're looking at and (b) is otherwise random. The following code (again, modulo bugs and typos) does something like this, though for large grids you might want to make it more efficient.
System.Random rng = new System.Random();
radius = MAX_RADIUS; // preferably not too big, so that the search isn't too slow
while ((2*radius+1)*(2*radius+1) >= n_photos) --radius; // gratuitously inefficient!
for (int x=0; x<nx; ++x) {
for (int y=0; y<ny; ++y) {
// which photos already appear too near to here?
System.Collections.BitArray unseen = new System.Collections.BitArray(n_photos,True);
for (x1=x-radius; x1<=x+radius; ++x1) {
for (int y1=y-radius; y1<=y+radius; ++y1) {
if (0 <= x1 && x1 < nx && 0 <= y1 && y1 < nx && (y1<y || (y1==y && x1<x))) {
unseen[photos[x1,y1]] = False;
}
}
}
// now choose a random one of them
int n_unseen = 0;
for (int i=0; i<n_photos; ++i) if (unseen[i]) ++n_unseen;
System.Debug.Assert(n_unseen>0, "no photos available");
int j = rng.Next(0,n_unseen-1);
for (int i=0; i<n_photos; ++i) {
if (unseen[i]) {
if (j==0) { photos[x,y] = i; break; }
--j;
}
}
}
}
Notes: This is much more expensive than option 1. The validity check on x1,y1 is gratuitously inefficient here, of course. So is the choice of radius. The obvious more-efficient versions of these, however, may break down if you adopt some of the variations I'm about to list. This code, as it stands, won't do anything to keep photos apart if there are fewer than 9. The choice of radius is actually completely bogus, for the grid-traversal order I've used, because there are never more than 2r^2+2r "excluded" positions; again, that may change if you traverse the grid in a different order. Etc.
Variations: there's no real reason why the region you search over should be square. Circular might well be better, for instance. You could, with some extra work, construct a region that always has exactly as many points in it as you have photos (though if you do that you'll get a mostly-periodic pattern of photos, so better to be a bit less aggressive ). It might be better to process the grid entries in a different position -- e.g., spiralling out from the centre.
(3) Option 2 above will keep photos unique within a certain range (about as large as it can be given how many different photos you have) but not care about keeping copies further away apart from that. You could, instead, decide how bad it is having two identical photos at any given distance and then choose photos to minimize total badness. This will be even more expensive than option 2. I shan't bother giving sample code; you can probably work out how you might do it.
[EDITED to add ...]
(4) Here's a cute variation on the theme of (1). It will work best when the grid is square and its size is a power of 2, but you can adapt it to work more generally. It takes time only proportional to the size of your grid, however many photos you have. For each position (x,y): Throw away all but the bottom k bits of the coordinates, for some k. Bit-reverse them and interleave the bits, giving a number m from 0 to 2^(2k)-1. Choose k so that this is somewhere on the order of, say, n_photos/4. Now, at position (x,y) you'll put photo number round(n_photos*m/2^(2k) + smallish_random_number). There are a few details I'll leave for you to fill in :-).
Fastest way is somthing like this:
You have array of n imgs URL & grid x*y
Find a central cell of the grid.
Randomly extract imgs URL from array and put each URL around central cell (first URL put to the center)
Do it until you don't fill all grid cells or while you have URLs in array.
If every URL is used then you should take URLs from concentric circles that you are made. Folow from the central cell to the circle with the bigest radius.
URLs taken by this method you should randomly put around biggest circle.
This algorithm will work if you have enough URLs for drawing less then 2 disks to the grid.
You can successfully modify it if you will follow the rule that URLs from one set must fill as big circle as it can.
What you want is a space-filling-curve for example a hilbert curve. It fills your grid with a continous line separating each square by only 1 bit. Because the nature of a sfc is to recursivley fill the space and maintain a neighborhood you can exploit this and place the picture along the line. If you don't want to place the same picture in the direct neighboorhood you can use a depth-seach on the sfc on each node eliminates copies.
I am currently implementing a method that accepts two bitmap objects. We can assume that said objects are of equal dimensions etc. The return of the method is a list of Pixel changes (this is stored in a self-made object). This is being developed in an iterative manner so the current implementation was a basic one... simply work through each pixel and compare it to its counterpart. This method for generating changes is slower than acceptable (500ms or so), as such I am looking for a faster process.
Ideas that have crossed my mind are to break down the image into strips and run each comparison on a new thread or to compare zones of the screen as objects first then only examine in detail as required.
current code for your understanding...
for (int x = 0; x < screenShotBMP.Width; x++)
{
for (int y = 0; y < screenShotBMP.Height; y++)
{
if (screenShotBMP.GetPixel(x, y) != _PreviousFrame.GetPixel(x, y))
{
_pixelChanges.Add(new PixelChangeJob(screenShotBMP.GetPixel(x,y), x, y));
}
}
}
As you will deduct from the code the concept of the class in question is to take a screenshot and generate a list of pixel changes from the previously taken screenshot.
You should definitely look at the Lockbits method of manipulating bitmap data.
It is orders of magnitude faster than GetPixel/SetPixel.
EDIT:
Check this link for some code (albeit in VB, but you should get the drift) that almost does what you want. It is simply checking two bitmaps for equality and returning true or false. You could change the function so each pixel check adds to your _pixelChanges list if necessary, and return this list instead of a boolean.
Also, it may be faster if you swap round the iterator loops. i.e. have the inner loop iterating over X, and the outer loop iterating over Y.
Use BitBlt with option XOR.... . Should be much faster.
In my office at work, we are not allowed to paint the walls, so I have decided to frame out squares and rectangles, attach some nice fabric to them, and arrange them on the wall.
I am trying to write a method which will take my input dimensions (9' x 8' 8") and min/max size (1' x 3', 2', 4', etc..) and generate a random pattern of squares and rectangles to fill the wall. I tried doing this by hand, but I'm just not happy with the layout that I got, and it takes about 35 minutes each time I want to 'randomize' the layout.
One solution is to start with x*y squares and randomly merge squares together to form rectangles. You'll want to give differing weights to different size squares to keep the algorithm from just ending up with loads of tiny rectangles (i.e. large rectangles should probably have a higher chance of being picked for merging until they get too big).
Sounds like a Treemap
Another idea:
1. Randomly generate points on the wall
Use as many points as the number of rectangles you want
Introduce sampling bias to get cooler patterns
2. Build the kd-tree of these points
The kd-tree will split the space in a number of rectangles. There might be too much structure for what you want, but its still a neat geeky algorithm.
(see: http://en.wikipedia.org/wiki/Kd-tree)
Edit: Just looked at JTreeMap, looks a bit like this is what its doing.
If you're talking on a pure programing problem ;) There is a technique called Bin Packing that tries to pack a number of bins into the smallest area possible. There's loads of material out there:
http://en.wikipedia.org/wiki/Bin_packing_problem
http://mathworld.wolfram.com/Bin-PackingProblem.html
http://www.cs.sunysb.edu/~algorith/files/bin-packing.shtml
So you 'could' create a load of random squares and run it through a bin packer to generate your pattern.
I've not implemented a bin packing algorithm myself but I've seen it done by a colleague for a Nike website. Best of luck
Since you can pick the size of the rectangles, this is not a hard problem.
I'd say you can do something as simple as:
Pick an (x,y) coordinate that is not currently inside a rectangle.
Pick a second (x,y) coordinate so that when you draw a rectangle between
the two coordinates, it won't overlap anything. The bounding box of
valid points is just bounded by the nearest rectangles' walls.
Draw that rectangle.
Repeat until, say, you have 90% of the area covered. At that point you
can either stop, or fill in the remaining holes with as big rectangles
as possible.
It might be interesting to parametrize the generation of points, and then make a genetic algorithm. The fitness function will be how much you like the arrangement - it would draw hundreds of arrangements for you, and you would rate them on a scale of 1-10. It would then take the best ones and tweak those, and repeat until you get an arrangement you really like.
Bin packing or square packing?
Bin packing:
http://www.cs.sunysb.edu/~algorith/files/bin-packing.shtml
Square packing:
http://www.maa.org/editorial/mathgames/mathgames_12_01_03.html
This actually sounds more like an old school random square painting demo, circa 8-bit computing days, especially if you don't mind overlaps. But if you want to be especially geeky, create random squares and solve for the packing problem.
Building off Philippe Beaudoin answer.
There are treemap implementations in other languages that you can also use. In Ruby with RubyTreeMap you could do
require 'Treemap'
require 'Treemap/image_output.rb'
root = Treemap::Node.new 0.upto(100){|i| root.new_child(:size => rand) }
output = Treemap::ImageOutput.new do |o|
o.width = 800
o.height = 600
end
output.to_png(root, "C:/output/test.png")
However it sorts the rectangles, so it doesn't look very random, but it could be a start. See rubytreemap.rubyforge.org/docs/index.html for more info
I would generate everything in a spiral slowly going in. If at any point you reach a point where your solution is proven to be 'unsolvable' (IE, can't put any squares in the remaining middle to satisfy the constraints), go to an earlier draft and change some square until you find a happy solution.
Pseudocode would look something like:
public Board GenerateSquares(direction, board, prevSquare)
{
Rectangle[] rs = generateAllPossibleNextRectangles(direction, prevSquare, board);
for(/*all possible next rectangles in some random order*/)){
if(board.add(rs[x]){
//see if you need to change direction)
Board nBoard = GenerateSquares(direction, board, rs[x]);
if(nBoard != null) return nBoard; //done
else board.remove(rs[x]);
}
}
//all possibilities tried, none worked
return null;
}
}
I suggest:
Start by setting up a polygon with four vertices to be eaten in varying size (up to maxside) rectangle lumps:
public double[] fillBoard(double width, double height, double maxside) {
double[] dest = new int[0];
double[] poly = new int[10];
poly[0] = 0; poly[1] = 0; poly[2] = width; poly[3] = 0;
poly[4] = width; poly[5] = height; poly[6] = 0; poly[7] = height;
poly[8] = 0; poly[9] = 0;
...
return dest; /* x,y pairs */
}
Then choose a random vertex, find polygon lines within (inclusive) 2 X maxside of the line.
Find x values of all vertical lines and y values of all horizontal lines. Create ratings for the "goodness" of choosing each x and y value, and equations to generate ratings for values in between the values. Goodness is measured as reducing number of lines in remaining polygon. Generate three options for each range of values between two x coordinates or two y coordinates, using pseudo-random generator. Rate and choose pairs of x and pair of y values on weighted average basis leaning towards good options. Apply new rectangle to list by cutting its shape from the poly array and adding rectangle coordinates to the dest array.
Question does not state a minimum side parameter. But if one is needed, algorithm should (upon hitting a hitch with a gap being too small) not include too small candidates in selection lists (whic will occasionally make them empty) and deselect a number of the surrounding rectangles in a certain radius of the problem with size and perform new regeneration attempts of that area, and hopefully the problem area, until the criteria are met. Recursion can remove progressively larger areas if a smaller relaying of tiles fails.
EDIT
Do some hit testing to eliminate potential overlaps. And eat some spinach before starting the typing. ;)
Define input area;
Draw vertical lines at several random horizontal locations through the entire height;
Draw horizontal lines at several vertical positions through the entire width;
Shift some "columns" up or down by arbitrary amounts;
Shift some "rows" left or right by arbitrary amounts (it may be required to subdivide some cells to obtain full horizontal seams;
Remove seams as aesthetically required.
This graphical method has similarities to Brian's answer.