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

[Soren Christensen]

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