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

[jon pipitone]

Hey Soren,

One far less glamorous way we've dealt with improving access speeds is to
move images onto a ramdisk (e.g. /dev/shm) and manipulate them there.

Jon.


On Thu, Sep 13, 2012 at 10:38 AM, Soren Christensen <sorench at gmail.com>wrote:

> Hi Vladimir,
>  The dataset is pretty large and contain multiple temporal frames so I
> am caching certain views that allows for quick interaction. That is,
> volume navigation+cross time navigation. So only one temporal frame is
> kept at the GPU at time in addition to 3 buffers for the temporal
> frames of the current orthogonal views. Once the frames are advanced
> the cached buffers are displayed and nothing needs transferring from
> the CPU. Once the frame advancement is stopped, the volume at the
> stopping frame is then read from file, replacing the existing one. So
> I have 4 dimension orderings in use: x y z (fastest->slowest) for the
> volume at the current frame and x z t, y z t, x y t  for the cached
> frames.  I need to frequently refresh these buffers from the file so
> as far as I can see reordering the file will only optimize for one of
> the 4 hyper slab requirements. Yes maybe just reading it all into RAM
> and just have access functions get the right reordering is the way to
> go - it does not seem to be difficult, but it is essentially what
> set_dimorder_apparent already does, so if I could use that it would
> just save me coding it up.
> Thanks for the tip on the compression too.
>
> Cheers
> Soren
>
>
>
>
> On Thu, Sep 13, 2012 at 11:40 PM, Vladimir S. FONOV
> <vladimir.fonov at gmail.com> wrote:
> > 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
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>