数据结构存储大量数据？

Question

In my application,I have to load volumedata from set of images (MRC images) and keep the pixel data in memory.(images are grayscaled ,so one byte per pixel).

My development environment is QT framework ,MinGW for Windows and GCC for Linux.

At the moment,I use a simple data structure to store volumedata as :

unsigned char *volumeData;

and do one huge allocation as follows.

volumeData=new unsigned char[imageXsize * imageYsize * numofImages];

Following are the important methods to access image-data in a given plane,such as

unsigned char* getXYPlaneSlice(int z_value);
unsigned char* getYZPlaneSlice(int x_value);
unsigned char* getZXPlaneSlice(int y_value);

With my simple data-structure it was easy to implement above methods.

But we might need to adopt to volume size as 2000x2000x1000 (~3.7Gb) in the future.And current datastructure will not be able to handle that huge data.

1. How to avoid fragmentation ? Now,even with 1000x1000x200 data, application crash giving bad_alloc. Whats the best way to change the datastructure for this ? shall I use something like linked-list which each chunk is of size 100mb.

2. Also,user should be able to perfome some image-processing filters on volume-data and also should be able to reset to original pixel value. That means, I should keep two copies of volume-data. With current implemetation its like.

   unsigned char *volumeDataOriginal;

   unsigned char *volumeDataCurrent;

So with 2000x2000x1000 data-range its going to utilize about 8Gb (4Gb for each volume). But in Win32 , the address space is 4GB.How to tackle this ? I should go with 64bit application ?

EDIT : Here is a snapshot of my application

Basically,I load the volume-data (from set of images,from MRC format..etc) and display them in different plane-viewers (XY,YX,YZ.Image shows XY-plane-viewer).I need to keep above 3 data-access methods to show an image in a particular plane.using slider-bar user can change which image to show in the selected plane)

Thanks in advance.

Answer 1

I think you should take a look at hdf5 . This is a binary format for storing huge amounts of data collected from things like telescopes, physics experiments, and gene-sequencing machines. The benefits of using something like this are many, but three immediate thoughts are: (1) tested, (2) supports hyperslab selection, and (3) you get compression for free.

There are C/C++, java, python, matlab libraries available.

Answer 2

64 bit is probably the easiest way to handle this... let the OS fault in the pages as you use them. Otherwise, it's hard to sugegst much without knowing your access patterns through the data. If you're regularly scanning through the images to find the value at the same pixel coordinates, then it's pointless to talk about saying having pointers to images that save and reload on demand.

For undo data, you could keep a full backup copy as you suggest, or you could try to have an undo operation that looks ath the change made and is responsible for finding an efficient implementation. For example, if you just flipped the bits, then that's non-destructive and you just need a functor to the same bit-flip operation to undo the change. If setting all the pixels to the same tone was a common operation (eg filling, clearing), then you could have a boolean and a single pixel to encode that image state, and use the full buffer for undos.

Answer 3

The simplest solution to your problem would be to use 64-bit address spaces - modern Macs support this out of the box, on Windows and Linux you will need to install the 64-bit version of the OS. I believe Qt can be used to build 64-bit apps quite nicely. 32-bit systems won't be able to support single allocations of the size you're talking about - even a Mac with 4 GB of address space available to applications won't be able to make a single 3.7 GB allocation as there will not be a contiguous space of that size available.

For undo I would look at using memory-mapped files and copy-on-write to copy the block:

http://en.wikipedia.org/wiki/Copy-on-write

This means you don't actually have to copy all the original data, the system will make copies of pages as they are written to. This will greatly aid performance if your images are significantly bigger than real memory and you're not changing every part of the image. It looks like boost::map_file with "private" access might be helpful for this.

If you really, really need to support 32-bit systems, your only alternative is to break those big blocks down somehow, typically into planes or sub-volumes. Both are horrible to work with when it comes to applying 3D filters etc. though, so I really would avoid this if you can.

If you do go the sub-volume route, one trick is to save all the sub-volumes in memory-mapped files, and map them into your address space only when you need them. When unmapped from the address space they should stay around in the unified buffer cache until purged, effectively this means you can utilise more RAM than you have address space (particularly on Windows where 32-bit applications only get 2 GB of address space by default).

Finally, on 32-bit Windows you can also look at the /3GB switch in boot.ini. This allows you to allocate 3 GB of address space to applications rather than the normal 2 GB. From the problem you describe I don't think this will give you enough address space, however it may help you with some smaller volumes. Note that the /3GB switch can cause problems with some drivers as it reduces the amount of address space available to the kernel.

Answer 4

You can use a memory mapped files to manage large datasets with limited memory. However if your file sizes are going to be 4GB then going to 64 bit is recommended. The boost project has a good multi-platform memory mapping library that performs very close to what you are looking for.

http://en.wikipedia.org/wiki/Memory-mapped_file http://www.boost.org/doc/libs/1_44_0/libs/iostreams/doc/classes/mapped_file.html to get you started. Some sample code below --

#include <boost/iostreams/device/mapped_file.hpp>
boost::iostreams::mapped_file_source input_source;
input_source.open(std::string(argv[1]));
const char *data = input_source.data();
long size = input_source.size();
input_source.close();

Thanks, Nathan

Answer 5

One option I would consider is memory mapping, instead of mapping all images, maintain a linked list of images which are lazily loaded. As your filter works through the image list, load as needed. In the loading phase, map an anonymous (or of some fixed temporary file) block of the same size and copy the image there as your backup. And as you apply filters, you just backup to this copy. As @Tony said above, 64-bit is your best option, and for multi-platform memory mapped files, look at boost interprocess.

Answer 6

Use STXXL : Standard Template Library for Extra Large Data Sets.

I first heard about it on SO :)

Answer 7

You could use a two-level structure: An array of pointers to the single images or (much better) a bunch of images. So you could keep ie 20 images in one memory block and put the pointers to the 20-images-blocks into the array. This is still fast (compared to a linked-list) when doing random access.

You can then implement a simple paging-algorithm: At first all pointers in the array are NULL. When you first access an image-block you load the 20 images of that block into memory and write the pointer into the array. The next access to those images does not load anything.

If your memory gets low because you have loaded and loaded many image-blocks you can remove the image-block you have least used (you should add a second field beside the pointer where you put in the value of a counter that you count up each time you load an image-block). The image-block with the lowest counter is the least used one and can be dropped (memory is reused for the new block and the pointer is set to NULL).

Answer 8

The trend these days in working with very large volume data is to break the data up into smaller data bricks of say 64x64x64. If you want to do volume rendering with lighting, then you should have a 1 voxel overlap between neighboring bricks so that individual bricks can be rendered without needing neighboring bricks. If you want to do more complex image processing with the bricks, then you can increase the overlap (at the expense of storage).

The advantage of this approach is that you only need to load the bricks that are necessary into memory. The rendering/processing time for a brick-based volume is not significantly slower than a non-bricked base volume.

For a more involved discussion of this from the volume rendering side, check out papers on the Octreemizer. Here is a link to one on citeseer .

Answer 9

The main problem is probably if you want total random access to your data.

The best approach would be to think about the algorithms you want to use, and of they can't be written that the mainly stride through the data in only one direction. Ok, thats not always possible.

If you want to code a middle-weight solution yourself, you should do it like this:

• use mmap() to map slices of your data structure into memory
• encapsulate the data in a class, so you can catch access to to currently non-mapped data
• mmap() the required region on demand, then.

(Actually, this this is what the OS is doing anyway, if you mmap() the whole file at once, but by taking a bit of control, you might make the on-demand algorithm smarter, over time, and fit you requirements).

Again, this is no fun if you jump around on those image-voxels. Your algorithm must fit the data-access -- for every solution you choose to store your data. Total Random Access will "break" everything , if your data is larger then your physical memory.

Answer 10

If hardware and OS allows it, I would go 64 bit, and map the file to memory (see CreateFileMapping on Windows and mmap on Linux).

On Windows, you can make a view over the mapped file which allows copy-on-write. I'm sure you can get that functionality on Linux as well. Anyway, if you create a read only view over the source file, then that will be your "original data". Then you create a copy-on-write view over the source file - this will be the "current data".

When you modify current data, the modified underlying pages will be copied and allocated for you, and the pages for the source data will remain intact. If you make sure that you do not write identical data to your "current data", you will also get an optimal usage of memory, because your current data and original data will share memory pages. You do have to take page alignment into consideration though, because copy-on-write works on page basis.

Also, reverting from current to original data is a simple job. All you need to do is to recreate the mapping for the "current data".

By using file mapping, the tedious work of managing memory will be handled by the OS. It will be able to use all available memory in a very efficient way. Way more efficient than you could ever accomplish with normal heap allocations.

I would start by researching CreateFileView() and MapViewOfFile() for use on Windows. For Linux you have mmap(), but that's as far as my knowledge goes. I haven't touched anything *nix since 2000...

Answer 11

Have a look at SciDB . I am no expert of it, but from its sample use cases and a paper describing it , it allows you to naturally map your data into a 3D (+1D for time/versioning) array like this:

CREATE ARRAY Pixels [
    x INT,
    y INT,
    z INT,
    version INT
] (
    pixel INT
);

And to implement your query getXYPlaneSlice :

Slice (Pixels, z = 3, version = 1);

To avoid duplication of data when only a part of the data is changed, you do not need to fill the whole array for version 1 since SciDB supports sparse array. Then when you need to load the newest data, you could load with version = 0 to get the old version, and update the result with another load with version = 1 .