[MINC-users] MINC 2 api and RAM/HD access

[Vladimir S. FONOV]

Hello Soren,

maybe it will be worth to reorganize your file so that the slabs you
are reading are actually stored as fastest-varying (using mincreshape
-dimorder ), also you might want to disable built-in compression when
creating the file ( MINC_COMPRESS environment variable).

P.S. What is the reason for not reading the whole MINC file into
array, and then just dealing with it without minc api ?

On Thu, Sep 13, 2012 at 4:10 AM, Soren Christensen <sorench at gmail.com> wrote:
> Hi,
>  I am am working on some MINC files sized at ~3GB and views ("hyper
> slabs" in minc speak) of this data to the GPU for display purposes. I
> can't put the whole thing on the GPU at once so I am using
> miget_voxel_value_hyperslab and setting the apparent order as
> appropriate for the view I want. This seems to be a little slow,
> especially over my nfs mount. I assume this is due to the extensive
> jumping around the file required for changing the stride on the data.
> It would be great if the MINC file could be loaded into RAM, and I
> could then continue to use the MINC2 api on the file. The alternative
> is of course to read in the whole voxel volume, but then I have to
> worry about stride etc my self - I'd rather leave that to the API if
> possible.  Is there a way to "cache" the data in RAM for this purpose?
>   I can't find it in the API, but I was hoping for some pointers as to
> what it would take to achieve this.
>
> Thanks
> Soren
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



-- 
Best regards,

 Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com