Creating a 3D Array

[Joe Van Dyk]

What's the best data structure to use if I want to store RGB color data
(integers between 0-255 for red, green, and blue) for each pixel in an
image?

A vector of vector of vector of ints? (my best guess)

If I'm going to need to store data for an image that's 10k by 10k
pixels, how can I quickly allocate and save that data into the data
structure?

Thanks,
Joe

 

[Jakob Bieling]

What's the best data structure to use if I want to store RGB color
data (integers between 0-255 for red, green, and blue) for each pixel
in an image?

A vector of vector of vector of ints? (my best guess)

I would use a single vector of an appropriate struct:

struct color
{
unsigned char r, g, b;
};

std::vector <color> v;

And then use indexing arithmetics to get the right element.

If I'm going to need to store data for an image that's 10k by 10k
pixels, how can I quickly allocate and save that data into the data
structure?

v.resize (10000 * 10000); // get ~286Mb


For indexing you would do: x + y * width

hth

 

[Sgt. York]

What's the best data structure to use if I want to store RGB color data
(integers between 0-255 for red, green, and blue) for each pixel in an
image?

A vector of vector of vector of ints? (my best guess)

If I'm going to need to store data for an image that's 10k by 10k
pixels, how can I quickly allocate and save that data into the data
structure?

Thanks,
Joe

Borrow the COLORREF mechanism from win32:

#define RGB(r, g ,b) ((DWORD) (((BYTE) (r) | \
((WORD) (g) << 8)) | \
(((DWORD) (BYTE) (b)) << 16)))

typedef DWORD COLORREF;

std::vector< std::vector<COLORREF> > colorArray;
COLORREF black = RGB(0,0,0); // initialize to black
colorArray.resize(10000, std::vector<COLORREF>(10000, black));

Then you can grab a pixel thus:

COLORREF rgb = colorArray[x][y];

Be sure to catch exceptions, that's a pretty big array.

-York

 

[Daniel T.]

I would use a single vector of an appropriate struct:

struct color
{
unsigned char r, g, b;
};

std::vector <color> v;

And then use indexing arithmetics to get the right element.


v.resize (10000 * 10000); // get ~286Mb


For indexing you would do: x + y * width

However, for something that big you might be better off with a deque...

 

[Ben Pope]

Borrow the COLORREF mechanism from win32:

#define RGB(r, g ,b) ((DWORD) (((BYTE) (r) | \
((WORD) (g) << 8)) | \
(((DWORD) (BYTE) (b)) << 16)))

typedef DWORD COLORREF;

You genuinely recommend this?

What's wrong with C++?

Ben Pope

 

[Sgt. York]

You genuinely recommend this?

What's wrong with C++?

Ben Pope

Hey Mr. Pope, nice way to rip that out of context. My entire reply
showed how to store these integers in a simple 2D array of std::vectors.
Last time I checked, STL's vectors were traditionally considered "C++"
....

You can use anything you want to hold the color values, I've just found
the packing of colors bytes this way to be useful. You might be
surprised to hear this works in C++. If your panties are bunched up
because of the "DWORD" and "BYTE" defines, here's a revelation: They are
really just "32-bit unsigned ints" and "unsigned chars," respectively.
Chutzpah!

 

[Ben Pope]

Hey Mr. Pope, nice way to rip that out of context. My entire reply
showed how to store these integers in a simple 2D array of std::vectors.
Last time I checked, STL's vectors were traditionally considered "C++" ...

Which I don't have a problem with, and was not commenting on. Hence, I
removed it.

You can use anything you want to hold the color values, I've just found
the packing of colors bytes this way to be useful. You might be
surprised to hear this works in C++.

I'm not at all surprised that it works. I just think here are better
ways of doing it.

If your panties are bunched up
because of the "DWORD" and "BYTE" defines, here's a revelation: They are
really just "32-bit unsigned ints" and "unsigned chars," respectively.
Chutzpah!

Actually my concern was the macro:

#define RGB(r, g ,b) ((DWORD) (((BYTE) (r) | \
((WORD) (g) << 8)) | \
(((DWORD) (BYTE) (b)) << 16)))


Something a little nicer might be:

struct rgb {
rgb(unsigned char red, unsigned char green, unsigned char blue) :
r(red), b(blue), g(green) {}
unsigned char r;
unsigned char g;
unsigned char b;
};


Or perhaps:

class rgb {
public:
rgb(unsigned char red, unsigned char green, unsigned char blue) :
val_(r | g<<8 | b<<16) {}

/* suitable functions to set & retrieve components */

private:
// 32 bit unsigned type
typedef unsigned int rgb_t;
rgb_t val_;
};


Ben Pope

 

[Sgt. York]

Which I don't have a problem with, and was not commenting on. Hence, I
removed it.


I'm not at all surprised that it works. I just think here are better
ways of doing it.


Actually my concern was the macro:

#define RGB(r, g ,b) ((DWORD) (((BYTE) (r) | \
((WORD) (g) << 8)) | \
(((DWORD) (BYTE) (b)) << 16)))


Something a little nicer might be:

struct rgb {
rgb(unsigned char red, unsigned char green, unsigned char blue) :
r(red), b(blue), g(green) {}
unsigned char r;
unsigned char g;
unsigned char b;
};


Or perhaps:

class rgb {
public:
rgb(unsigned char red, unsigned char green, unsigned char blue) :
val_(r | g<<8 | b<<16) {}

/* suitable functions to set & retrieve components */

private:
// 32 bit unsigned type
typedef unsigned int rgb_t;
rgb_t val_;
};


Ben Pope

Now you've made a good point. I took your previous post as a slam
because you did not offer this alternative advice.

I've gotten use to windows development and since the color macros are
everywhere (from 3.0 to Vista), I've taken them for granted. But you
are correct, it's not the purist way and macros are rather "stinky" and
should be thrown to the dogs when the opportunity arises.

-York