Type that doesn't use much memory?

I am making a "3 value" array, not really sure what it is called (varName[x, y, z] = Color.Blue)
Each of these 3D points in the array is used to hold a Color value.
So I used- Color[,,]varName= new Color[width, height, depth];
This took up way too much memory and froze everything up (the height, width, and depth can be 500+)
I'm only using maybe 10 different colors, so I changed it to an int array, then assigned each number 1-10 a different color-
int[,,]varName= new int[width, height, depth];
This helped a ton but still can't get up there to the 500+ area (500 ^ 3 different values)
So what type could I use that takes up the least amount of memory?
And also, I notice after I create the array, and even after I close the program out, everything is running very slow.
How can I clear the array after it gets used?
Would varName = null; do anything?

Edit:
I found a list of types and it looks like either byte or sbyte is my best bet.
Or is there anything better?
I'm using positive numbers, 0-10.

Ask yourself this; do you *really* need an array with 125,000,000 elements? are you sure that there is not a smarter approach to your problem? Sometimes it is easy to start down a path thinking it is the only logical way and end up in a tight scenario. Perhaps a reevaluation of your design is in order at this point.

For example, you say there are only 10 colors, so you are duplicating a ton of data. Think of a way to compress that. If you only have ten colors, then why not maintain a collection (sort of like a histogram) with 10 colors that map to the elements that use that color? That could give you a significant savings pretty easily.

I've considered this, but can't find a more compact way of doing it.
Maybe I should explain a little more.
I am basically creating a cube made up of images.
A 3D object can be thought of as a stack of 2D planes, and that's what this is.
Stack image on top of image on top of image until it is a cube.
I was originally just using an array of bitmaps, which worked fine also, but took up even MORE memory than the [ , , ] Color array.
The point of this project is to rotate the cube around, so I have to keep track of all the coordinates and what color goes in each coordinate.

Yes, byte is your best bet if you're committed to his strategy. BigEd is right though; the design appears to be fundamentally broken. If you are going to display a rotated cube, I recommend "rotating" your viewing orientation rather than the cube. Then leave the cube as a static object on disk and access elements as needed. You shouldn't need to access every voxel in the cube for any one rendering. Raytracing may be your friend. Also, you might consider something like DirectX, which is designed for this sort of thing.

If you're trying to actually process the data object itself to rotate it, I guess you could do that, but then do you HAVE to read it all into memory at once? Could you do it by scanning through the image reading a small buffer in from disk?

Just some thoughts. Hope that helps!

If you declare it as Color[,,], is is allocated as one big portion of memory. I would try to declare it as so called "jagged arrays" as Color[][][], which needs more work to deal with, but splits the allocated memory to smaller independet parts.

Thanks for all the help people!
Couple things,
Rotating the view would be the same amount of work as rotating the cube.
If there is some way to render the cube rotated without accessing every part of it, I have no clue how because every single point except maybe the very middle point will change locations completely.

I think I'm good now though using byte. I also made it where the cube is created only at the start and the rotations are done off the original cube.
So now I'm doing cubes of 500 pixels without a problem.