Interesting idea - agreed that we are not particularly efficient in terms of memory use inside slicer.

There are a few considerations:

• vtk and itk filters have a built-in assumption of direct pointer access to a contiguous block of memory for images, so anything that gets compressed would have to be hidden from them. For example we could make vtkMRMLVolumeNode::GetImageData() trigger a decompression and return a new uncompressed copy. We'd then need to observe modifications to it and reflect them back to the compressed copy.

• there is a definite time/space tradeoff here. We used to compress all files going to/from command line modules, but realized this was very time consuming and served no purpose in that scenario; this is just to point out that compression is not free.

• I like the idea of the zram linux system you pointed to. Doing the compression at the system level would avoid some of the memory access issues and would put the time/space decisions into the user's hands.

Yes, actually I have already tried it on a older C2D 4gb machine. A similar calculation on my 8gb machine would take up around 6 gb of ram. Using zRam I saw a speedup of around 50% because of the reduced/non existent swapping.

The implementation uses a very light form of compression. Since many of the datasets include relatively lots of 0000's the break-even point between compression/cpu load is attractive. But ofcourse you are right. Also on the conclusion that a system level implementation would be better (and as a module faster). But windows/mac do not allow for this kind of memory management easily.

As you have mentioned you could write a seperate routine for it in get/set image data to make it transparent.