0

I have an image which is not a square (m x n dimension). Also its dimensions are not to the base 2 (i.e m not = 2^k & n not = 2^k). I have dealt with this by placing the image in a larger square (the next power of two) using the following:

int width = (int)Math.ceil(Math.pow(2, Math.log(img.width)/Math.log(2)));
int height = (int)Math.ceil(Math.pow(2, Math.log(img.height)/Math.log(2)));

Depending on which yields the biggest dimension, I set the square to be drawn at the max dimension, that is:

if (img.width > img.height) {
    // draw width * width square
}

if (img.height > img.width) {
    // draw height * height square
}

Issue:

The quadtree now looks completely different as it is storing all the non-image nodes in the tree. This obviously affects the supposed image data (i.e. min/max depths) and the entire tree shape itself. My question is, am I doing this in an efficient way and if so, how do I not store the data that doesn't belong to the image? If it isn't the best way to draw a non-square image could someone point me in the right direction? All articles on google seem to be far too in depth for my purposes.

Carl Manaster
  • 39,912
  • 17
  • 102
  • 155
user559142
  • 12,279
  • 49
  • 116
  • 179
  • 1
    A quadtree is typically used to keep track of objects in your world space (physics/logic). What has that got to do with drawing your image (rendering)? – Karl Knechtel Feb 17 '11 at 16:06
  • 1
    Quadtrees are quite common for storing images that have reasonable amounts of identical colored areas. They don't do that well when there are lots of varying colors across few pixels. You need bigger squares of the same color to get decent compression. – ventaur Feb 17 '11 at 16:41

2 Answers2

0

The nice thing about quadtrees is they will store large chunks of identical data. Your extra blank image data should only be adding a little to your overall storage size. I suggest, you add an extra bit of information with your data structure that stores the actual original dimensions of the image. When deserializing your quadtree, you can "cut" off the extra part based on the actual dimensions to produce your original.

ventaur
  • 1,821
  • 11
  • 24
  • how do you go about 'chopping the extra part' off though – user559142 Feb 17 '11 at 18:32
  • Whenever the code is dealing with a node that falls entirely outside the bounds, ignore it, and move on to the next node. What kind of operations are you performing on the tree? – Tom Anderson Feb 17 '11 at 18:41
  • To my knowledge of Java, you would use getSubimage(x, y, width, height) on the deserialized image. If you're storing the original image at 0,0 of your "larger square", the call would simply be: img.getSubimage(0, 0, originalWidth, originalHeight). – ventaur Feb 17 '11 at 20:56
  • I need to show my code but it's too big to post here. How can I get around this? – user559142 Feb 18 '11 at 00:35
  • I'm no Java expert, but my language of choice is very similar. I don't know what to tell you about posting a large bit of code, but I don't think it's necessary. The getSubimage method I mentioned above is what I found when searching for "how to crop an image in java". That's all you'll need to do after recreating your image from the data structure. Use the extra data you store for the original image size to construct a rectangle that you use to crop the image back to its original size; effectively, cutting off the extra part. – ventaur Feb 18 '11 at 14:53
0

Perhaps instead of having your tree terminate in (notional) individual pixels, it could store small blocks of p pixels by o pixels, for some p x o which would make the number of blocks per side a power of two. That would make your tree behave nicely, at the expense of introducing another concept into the structure.

Tom Anderson
  • 46,189
  • 17
  • 92
  • 133