From robert.d.vincent at mcgill.ca  Wed Jun  1 00:25:58 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Wed, 1 Jun 2016 00:25:58 -0400
Subject: [MINC-users] minccomplete's completeness
In-Reply-To: <CABEEk14N7QH2HPvCE2KG+7wj78hZ4z60z+VNHbQBUtcj0nzopA@mail.gmail.com>
References: <CABEEk17TXVkmC9D=ZQWccGVufvUcC0FDi3zN=5CXQXSUb=tRew@mail.gmail.com>
	<CAMCwi7OtT0JuGZkR1fdruOViK5vGOKG6g8_wuFTdpUk4XpsXRw@mail.gmail.com>
	<CABEEk16JJOgLewbz4qppLioMAcC-nR0jYoWqW7ptEKQMoLHONg@mail.gmail.com>
	<CAAd5DeQC6+T-aZBhNJv+n-NJ-ZzbdY6oG=DUvrX6CiYu8_bp6w@mail.gmail.com>
	<CABEEk14N7QH2HPvCE2KG+7wj78hZ4z60z+VNHbQBUtcj0nzopA@mail.gmail.com>
Message-ID: <CAAd5DeSB2zgHS4mvWVQFV8TDL2hjpFymfJ3FmbX=jTvjrbjo=w@mail.gmail.com>

Hi Alex,

I just checked in a fix for nii2mnc. I am sure there are other tools that
do not set the attribute - I'll try to find and fix them.

    -bert

On Mon, May 30, 2016 at 11:37 AM, Alex Zijdenbos <zijdenbos at gmail.com>
wrote:

> Nice work, Bert!
>
> I have since built in some paranoid checking in all of my scripts, and one
> thing that keeps turning up is that nii2mnc doesn't actually set the
> 'complete' flag. Iow, anything created by nii2mnc fails minccomplete. Any
> chance you fixed that as well?
>
> Thanks,
>
> -- A
>
> On Mon, May 16, 2016 at 12:38 PM, Robert D. Vincent <
> robert.d.vincent at mcgill.ca> wrote:
>
> > Hi all,
> >
> > I have just checked in changes to volume_io, voxel_loop and the following
> > minc tools:
> >
> > mincaverage, minccalc, minccmp, mincconcat, mincconvert, minccopy,
> > mincextract, minclookup, mincmakescalar, mincmakevector, mincmath,
> > mincresample, mincreshape, mincsample, mincstats, minctoraw, mincwindow.
> >
> > These tools will still behave as before, in that they will run to
> > completion with a corrupt file. However, they will report the error as a
> > non-zero exit code (EXIT_FAILURE), in addition to whatever messages are
> > currently displayed by the libraries.
> >
> > Two existing tools, mincinfo and mincdump, seem to already have correct
> > handling of read errors. At least two others, mincblob and mincmorph,
> > should pick up the changes via volume_io.
> >
> > This covers the majority of the command line tools. It may also make
> sense
> > to reflect these changes in some of the basic scripts (e.g. mincpik,
> > mincdiff) - let me know if there are any particularly salient cases we
> > should take care of.
> >
> >     -bert
> >
> > On Sat, May 14, 2016 at 5:04 PM, Alex Zijdenbos <zijdenbos at gmail.com>
> > wrote:
> >
> > > On this note: nii2mnc is one of the tools that doesn't appear to set
> the
> > > image:complete attribute. I haven't found any others yet but since I
> > > started running minccomplete on anything I generate, I may come up with
> > > more :)
> > >
> > > On Sat, May 14, 2016 at 6:53 AM, Vladimir S. FONOV <
> > > vladimir.fonov at gmail.com
> > > > wrote:
> > >
> > > > Hello,
> > > >
> > > > the only thing minccomplete does is read the contents of the
> > > image:complete
> > > > attribute. Which is not even respected by all minc tools.
> > > > One real way to check the consistency of the minc file would be to
> > enable
> > > > checksum , integrated into HDF5 file format.
> > > >
> > > > Currently it can be enabled by setting the environment variable
> > > > MINC_CHECKSUM to 1 , at the time when file is created. Obviously,
> this
> > > > works only with MINC2 file format and it was not tested very well
> yet.
> > > >
> > > > On Fri, May 13, 2016 at 3:35 PM, Alex Zijdenbos <zijdenbos at gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I managed to generate a large number of broken MINC files;
> > > > possibly/likely
> > > > > due to a filesystem problem. The processes that created them (e.g.,
> > > > > mincaverage) did not produce any warnings and completed
> successfully;
> > > in
> > > > > addition, minccomplete tells me that the files are complete.
> > > > >
> > > > > Unfortunately, trying to read these files throws HDF5 and miicv
> > errors
> > > > (see
> > > > > below) and they are obviously corrupt.
> > > > >
> > > > > I am thinking that it would be useful to complete minccomplete by
> > > having
> > > > it
> > > > > actually test-read the data, such that it would report on file
> > > integrity?
> > > > > This would make it easy to find these kinds of corruptions - and
> > could
> > > > even
> > > > > tack that end the end of scripts to make sure outputs are intact.
> I'm
> > > > > currently using 'mincstats -quiet -min' to locate them, but it
> seems
> > > the
> > > > > natural place for this test would actually be minccomplete.
> > > > >
> > > > > -- A
> > > > >
> > > > > HDF5-DIAG: Error detected in HDF5 (1.8.9) thread 0:
> > > > >   #000: H5Dio.c line 174 in H5Dread(): can't read data
> > > > >     major: Dataset
> > > > >     minor: Read failed
> > > > >   #001: H5Dio.c line 449 in H5D_read(): can't read data
> > > > >     major: Dataset
> > > > >     minor: Read failed
> > > > >   #002: H5Dchunk.c line 1729 in H5D_chunk_read(): unable to read
> raw
> > > data
> > > > > chunk
> > > > >     major: Low-level I/O
> > > > >     minor: Read failed
> > > > >   #003: H5Dchunk.c line 2760 in H5D_chunk_lock(): data pipeline
> read
> > > > failed
> > > > >     major: Data filters
> > > > >     minor: Filter operation failed
> > > > >   #004: H5Z.c line 1120 in H5Z_pipeline(): filter returned failure
> > > during
> > > > > read
> > > > >     major: Data filters
> > > > >     minor: Read failed
> > > > >   #005: H5Zdeflate.c line 125 in H5Z_filter_deflate(): inflate()
> > failed
> > > > >     major: Data filters
> > > > >     minor: Unable to initialize object
> > > > > mincstats (from miicv_get): Can't read dataset
> > /minc-2.0/image/0/image
> > > > > _______________________________________________
> > > > > 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
> > >
> > _______________________________________________
> > 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
>

From zijdenbos at gmail.com  Wed Jun  1 10:10:32 2016
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 1 Jun 2016 10:10:32 -0400
Subject: [MINC-users] minccomplete's completeness
In-Reply-To: <CAAd5DeSB2zgHS4mvWVQFV8TDL2hjpFymfJ3FmbX=jTvjrbjo=w@mail.gmail.com>
References: <CABEEk17TXVkmC9D=ZQWccGVufvUcC0FDi3zN=5CXQXSUb=tRew@mail.gmail.com>
	<CAMCwi7OtT0JuGZkR1fdruOViK5vGOKG6g8_wuFTdpUk4XpsXRw@mail.gmail.com>
	<CABEEk16JJOgLewbz4qppLioMAcC-nR0jYoWqW7ptEKQMoLHONg@mail.gmail.com>
	<CAAd5DeQC6+T-aZBhNJv+n-NJ-ZzbdY6oG=DUvrX6CiYu8_bp6w@mail.gmail.com>
	<CABEEk14N7QH2HPvCE2KG+7wj78hZ4z60z+VNHbQBUtcj0nzopA@mail.gmail.com>
	<CAAd5DeSB2zgHS4mvWVQFV8TDL2hjpFymfJ3FmbX=jTvjrbjo=w@mail.gmail.com>
Message-ID: <CABEEk17QY2STP2K9SYkWUZwrmN37i-TTJKL39PfH4XfvXPYhPQ@mail.gmail.com>

Thanks, Bert!

I actually worked in explicit MINC integrity tests in the central sub I
have that spawns processes (similar to MNI::Spawn), so that every MINC
volume that is present in a spawned command line, is explicitly checked.
Besides nii2mnc, the only thing it has turned up so far is pyminc. But
there are likely a few more things out there.

-- A

On Wed, Jun 1, 2016 at 12:25 AM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi Alex,
>
> I just checked in a fix for nii2mnc. I am sure there are other tools that
> do not set the attribute - I'll try to find and fix them.
>
>     -bert
>
> On Mon, May 30, 2016 at 11:37 AM, Alex Zijdenbos <zijdenbos at gmail.com>
> wrote:
>
> > Nice work, Bert!
> >
> > I have since built in some paranoid checking in all of my scripts, and
> one
> > thing that keeps turning up is that nii2mnc doesn't actually set the
> > 'complete' flag. Iow, anything created by nii2mnc fails minccomplete. Any
> > chance you fixed that as well?
> >
> > Thanks,
> >
> > -- A
> >
> > On Mon, May 16, 2016 at 12:38 PM, Robert D. Vincent <
> > robert.d.vincent at mcgill.ca> wrote:
> >
> > > Hi all,
> > >
> > > I have just checked in changes to volume_io, voxel_loop and the
> following
> > > minc tools:
> > >
> > > mincaverage, minccalc, minccmp, mincconcat, mincconvert, minccopy,
> > > mincextract, minclookup, mincmakescalar, mincmakevector, mincmath,
> > > mincresample, mincreshape, mincsample, mincstats, minctoraw,
> mincwindow.
> > >
> > > These tools will still behave as before, in that they will run to
> > > completion with a corrupt file. However, they will report the error as
> a
> > > non-zero exit code (EXIT_FAILURE), in addition to whatever messages are
> > > currently displayed by the libraries.
> > >
> > > Two existing tools, mincinfo and mincdump, seem to already have correct
> > > handling of read errors. At least two others, mincblob and mincmorph,
> > > should pick up the changes via volume_io.
> > >
> > > This covers the majority of the command line tools. It may also make
> > sense
> > > to reflect these changes in some of the basic scripts (e.g. mincpik,
> > > mincdiff) - let me know if there are any particularly salient cases we
> > > should take care of.
> > >
> > >     -bert
> > >
> > > On Sat, May 14, 2016 at 5:04 PM, Alex Zijdenbos <zijdenbos at gmail.com>
> > > wrote:
> > >
> > > > On this note: nii2mnc is one of the tools that doesn't appear to set
> > the
> > > > image:complete attribute. I haven't found any others yet but since I
> > > > started running minccomplete on anything I generate, I may come up
> with
> > > > more :)
> > > >
> > > > On Sat, May 14, 2016 at 6:53 AM, Vladimir S. FONOV <
> > > > vladimir.fonov at gmail.com
> > > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > the only thing minccomplete does is read the contents of the
> > > > image:complete
> > > > > attribute. Which is not even respected by all minc tools.
> > > > > One real way to check the consistency of the minc file would be to
> > > enable
> > > > > checksum , integrated into HDF5 file format.
> > > > >
> > > > > Currently it can be enabled by setting the environment variable
> > > > > MINC_CHECKSUM to 1 , at the time when file is created. Obviously,
> > this
> > > > > works only with MINC2 file format and it was not tested very well
> > yet.
> > > > >
> > > > > On Fri, May 13, 2016 at 3:35 PM, Alex Zijdenbos <
> zijdenbos at gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I managed to generate a large number of broken MINC files;
> > > > > possibly/likely
> > > > > > due to a filesystem problem. The processes that created them
> (e.g.,
> > > > > > mincaverage) did not produce any warnings and completed
> > successfully;
> > > > in
> > > > > > addition, minccomplete tells me that the files are complete.
> > > > > >
> > > > > > Unfortunately, trying to read these files throws HDF5 and miicv
> > > errors
> > > > > (see
> > > > > > below) and they are obviously corrupt.
> > > > > >
> > > > > > I am thinking that it would be useful to complete minccomplete by
> > > > having
> > > > > it
> > > > > > actually test-read the data, such that it would report on file
> > > > integrity?
> > > > > > This would make it easy to find these kinds of corruptions - and
> > > could
> > > > > even
> > > > > > tack that end the end of scripts to make sure outputs are intact.
> > I'm
> > > > > > currently using 'mincstats -quiet -min' to locate them, but it
> > seems
> > > > the
> > > > > > natural place for this test would actually be minccomplete.
> > > > > >
> > > > > > -- A
> > > > > >
> > > > > > HDF5-DIAG: Error detected in HDF5 (1.8.9) thread 0:
> > > > > >   #000: H5Dio.c line 174 in H5Dread(): can't read data
> > > > > >     major: Dataset
> > > > > >     minor: Read failed
> > > > > >   #001: H5Dio.c line 449 in H5D_read(): can't read data
> > > > > >     major: Dataset
> > > > > >     minor: Read failed
> > > > > >   #002: H5Dchunk.c line 1729 in H5D_chunk_read(): unable to read
> > raw
> > > > data
> > > > > > chunk
> > > > > >     major: Low-level I/O
> > > > > >     minor: Read failed
> > > > > >   #003: H5Dchunk.c line 2760 in H5D_chunk_lock(): data pipeline
> > read
> > > > > failed
> > > > > >     major: Data filters
> > > > > >     minor: Filter operation failed
> > > > > >   #004: H5Z.c line 1120 in H5Z_pipeline(): filter returned
> failure
> > > > during
> > > > > > read
> > > > > >     major: Data filters
> > > > > >     minor: Read failed
> > > > > >   #005: H5Zdeflate.c line 125 in H5Z_filter_deflate(): inflate()
> > > failed
> > > > > >     major: Data filters
> > > > > >     minor: Unable to initialize object
> > > > > > mincstats (from miicv_get): Can't read dataset
> > > /minc-2.0/image/0/image
> > > > > > _______________________________________________
> > > > > > 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
> > > >
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>

From andrew at biospective.com  Thu Jun  9 14:44:38 2016
From: andrew at biospective.com (Andrew Wood)
Date: Thu, 9 Jun 2016 14:44:38 -0400
Subject: [MINC-users] Building RMINC
Message-ID: <CABApf9GKJ-wVbHkP9FzauGbze1vC-oaXbTBuZJROL88RO8H_6Q@mail.gmail.com>

Hi all,

I've been having trouble building RMINC (git tag v1.4.1.1):

$ R CMD INSTALL -l /data/scratch/
--configure-args='--with-build-path=install/minc-toolkit/' ./RMINC/

I get a few compiler warnings in minc_anova.c, then the installation
crashes:

** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object '/data/scratch/RMINC/libs/RMINC.so':
  /data/scratch/RMINC/libs/RMINC.so: undefined symbol: ncopts
Error: loading failed
Execution halted


Anyone have any idea what I'm doing wrong?

Thanks,
Andrew

From vladimir.fonov at gmail.com  Thu Jun  9 14:48:09 2016
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Thu, 9 Jun 2016 14:48:09 -0400
Subject: [MINC-users] Building RMINC
In-Reply-To: <CABApf9GKJ-wVbHkP9FzauGbze1vC-oaXbTBuZJROL88RO8H_6Q@mail.gmail.com>
References: <CABApf9GKJ-wVbHkP9FzauGbze1vC-oaXbTBuZJROL88RO8H_6Q@mail.gmail.com>
Message-ID: <5759B9E9.1010701@gmail.com>

Probably wrong version of libminc or it was compiled in a wrong way...

On 16-06-09 02:44 PM, Andrew Wood wrote:
> Hi all,
>
> I've been having trouble building RMINC (git tag v1.4.1.1):
>
> $ R CMD INSTALL -l /data/scratch/
> --configure-args='--with-build-path=install/minc-toolkit/' ./RMINC/
>
> I get a few compiler warnings in minc_anova.c, then the installation
> crashes:
>
> ** testing if installed package can be loaded
> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>    unable to load shared object '/data/scratch/RMINC/libs/RMINC.so':
>    /data/scratch/RMINC/libs/RMINC.so: undefined symbol: ncopts
> Error: loading failed
> Execution halted
>
>
> Anyone have any idea what I'm doing wrong?
>
> Thanks,
> Andrew
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com

From christopher.hammill at sickkids.ca  Thu Jun  9 16:28:12 2016
From: christopher.hammill at sickkids.ca (Christopher Hammill)
Date: Thu, 9 Jun 2016 20:28:12 +0000
Subject: [MINC-users] Building RMINC
In-Reply-To: <CABApf9GKJ-wVbHkP9FzauGbze1vC-oaXbTBuZJROL88RO8H_6Q@mail.gmail.com>
References: <CABApf9GKJ-wVbHkP9FzauGbze1vC-oaXbTBuZJROL88RO8H_6Q@mail.gmail.com>
Message-ID: <77ADF04BBB2CFC4EA7813E02F7F3A8A5110003FC@SKMBXX01.sickkids.ca>

Hi Andrew,

I have been building RMINC against minc-toolkit-v2 typically, if you have the option I'd recommend trying to build against that. What platform are you installing on? I can try to investigate the problem.

Cheers,

Chris
________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Wood [andrew at biospective.com]
Sent: Thursday, June 09, 2016 2:44 PM
To: MINC users mailing list
Subject: [MINC-users] Building RMINC

Hi all,

I've been having trouble building RMINC (git tag v1.4.1.1):

$ R CMD INSTALL -l /data/scratch/
--configure-args='--with-build-path=install/minc-toolkit/' ./RMINC/

I get a few compiler warnings in minc_anova.c, then the installation
crashes:

** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object '/data/scratch/RMINC/libs/RMINC.so':
  /data/scratch/RMINC/libs/RMINC.so: undefined symbol: ncopts
Error: loading failed
Execution halted


Anyone have any idea what I'm doing wrong?

Thanks,
Andrew
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

From andrew at biospective.com  Thu Jun  9 17:08:21 2016
From: andrew at biospective.com (Andrew Wood)
Date: Thu, 9 Jun 2016 17:08:21 -0400
Subject: [MINC-users] Building RMINC
In-Reply-To: <77ADF04BBB2CFC4EA7813E02F7F3A8A5110003FC@SKMBXX01.sickkids.ca>
References: <CABApf9GKJ-wVbHkP9FzauGbze1vC-oaXbTBuZJROL88RO8H_6Q@mail.gmail.com>
	<77ADF04BBB2CFC4EA7813E02F7F3A8A5110003FC@SKMBXX01.sickkids.ca>
Message-ID: <CABApf9G7P=nv3SSAeP5stXRzFNbFV0w0HwjZ8-sG44eHG5=n+g@mail.gmail.com>

Hi Christopher,

I'm compiling against release-1.0.08 of minc-toolkit.  I've never really
understood the differences between minc-toolkit and minc-toolkit-v2, but I
can try switching to that.

I'm on Ubuntu 12.04 (64-bit) with R version 3.2.5.

Cheers,
Andrew

On Thu, Jun 9, 2016 at 4:28 PM, Christopher Hammill <
christopher.hammill at sickkids.ca> wrote:

> Hi Andrew,
>
> I have been building RMINC against minc-toolkit-v2 typically, if you have
> the option I'd recommend trying to build against that. What platform are
> you installing on? I can try to investigate the problem.
>
> Cheers,
>
> Chris
> ________________________________________
> From: minc-users-bounces at bic.mni.mcgill.ca [
> minc-users-bounces at bic.mni.mcgill.ca] on behalf of Andrew Wood [
> andrew at biospective.com]
> Sent: Thursday, June 09, 2016 2:44 PM
> To: MINC users mailing list
> Subject: [MINC-users] Building RMINC
>
> Hi all,
>
> I've been having trouble building RMINC (git tag v1.4.1.1):
>
> $ R CMD INSTALL -l /data/scratch/
> --configure-args='--with-build-path=install/minc-toolkit/' ./RMINC/
>
> I get a few compiler warnings in minc_anova.c, then the installation
> crashes:
>
> ** testing if installed package can be loaded
> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>   unable to load shared object '/data/scratch/RMINC/libs/RMINC.so':
>   /data/scratch/RMINC/libs/RMINC.so: undefined symbol: ncopts
> Error: loading failed
> Execution halted
>
>
> Anyone have any idea what I'm doing wrong?
>
> Thanks,
> Andrew
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
> ________________________________
>
> This e-mail may contain confidential, personal and/or health
> information(information which may be subject to legal restrictions on use,
> retention and/or disclosure) for the sole use of the intended recipient.
> Any review or distribution by anyone other than the person for whom it was
> originally intended is strictly prohibited. If you have received this
> e-mail in error, please contact the sender and delete all copies.
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From redoute at cermep.fr  Wed Jun 15 09:53:14 2016
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Wed, 15 Jun 2016 15:53:14 +0200
Subject: [MINC-users] information loss after mincreshape
Message-ID: <57615DCA.4030009@cermep.fr>

Dear all,
I'm processing dynamic PET data acquired on Siemens Biograph mMR.

after conversion from DICOM to MINC using dcm2mnc, I can extract frames 
timings using:

mincinfo -varvalue time xxx.mnc

BUT,

after mincreshape +xdirection +ydirection +zdirection xxx.mnc xxx_res.mnc

mincinfo -varvalue time xxx_res.mnc outputs only "0"

any ideas about this bug?

Thanks
Jerome



-- 
==================================================================
J?r?me Redout?
Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
CERMEP - Imagerie du vivant
59 Bd Pinel. 69677 Bron - FRANCE
tel : 33 (0)4 72 68 86 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================



From robert.d.vincent at mcgill.ca  Wed Jun 15 13:09:20 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Wed, 15 Jun 2016 13:09:20 -0400
Subject: [MINC-users] information loss after mincreshape
In-Reply-To: <57615DCA.4030009@cermep.fr>
References: <57615DCA.4030009@cermep.fr>
Message-ID: <CAAd5DeRyf=N5BP_0O0=n15onhVqTvYH+OTELe3jgrWwUG1548A@mail.gmail.com>

Hi J?r?me,

Thanks for the report, I've reproduced it here. It seems that mincreshape
fails to copy the time dimension properly. I will fix it as soon as
possible.

    -bert

On Wed, Jun 15, 2016 at 9:53 AM, J?r?me Redout? <redoute at cermep.fr> wrote:

> Dear all,
> I'm processing dynamic PET data acquired on Siemens Biograph mMR.
>
> after conversion from DICOM to MINC using dcm2mnc, I can extract frames
> timings using:
>
> mincinfo -varvalue time xxx.mnc
>
> BUT,
>
> after mincreshape +xdirection +ydirection +zdirection xxx.mnc xxx_res.mnc
>
> mincinfo -varvalue time xxx_res.mnc outputs only "0"
>
> any ideas about this bug?
>
> Thanks
> Jerome
>
>
>
> --
> ==================================================================
> J?r?me Redout?
> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
> CERMEP - Imagerie du vivant
> 59 Bd Pinel. 69677 Bron - FRANCE
> tel : 33 (0)4 72 68 86 18 (bureau)
> tel : 33 (0)4 72 68 86 00 (standard)
> fax : 33 (0)4 72 68 86 10
> ==================================================================
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From robert.d.vincent at mcgill.ca  Wed Jun 15 13:19:16 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Wed, 15 Jun 2016 13:19:16 -0400
Subject: [MINC-users] information loss after mincreshape
In-Reply-To: <CAAd5DeRyf=N5BP_0O0=n15onhVqTvYH+OTELe3jgrWwUG1548A@mail.gmail.com>
References: <57615DCA.4030009@cermep.fr>
	<CAAd5DeRyf=N5BP_0O0=n15onhVqTvYH+OTELe3jgrWwUG1548A@mail.gmail.com>
Message-ID: <CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>

One thing I'd like to check: is the file you're using a regularly-sampled
file, i.e. is there a constant time duration for each image?


On Wed, Jun 15, 2016 at 1:09 PM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi J?r?me,
>
> Thanks for the report, I've reproduced it here. It seems that mincreshape
> fails to copy the time dimension properly. I will fix it as soon as
> possible.
>
>     -bert
>
> On Wed, Jun 15, 2016 at 9:53 AM, J?r?me Redout? <redoute at cermep.fr> wrote:
>
>> Dear all,
>> I'm processing dynamic PET data acquired on Siemens Biograph mMR.
>>
>> after conversion from DICOM to MINC using dcm2mnc, I can extract frames
>> timings using:
>>
>> mincinfo -varvalue time xxx.mnc
>>
>> BUT,
>>
>> after mincreshape +xdirection +ydirection +zdirection xxx.mnc xxx_res.mnc
>>
>> mincinfo -varvalue time xxx_res.mnc outputs only "0"
>>
>> any ideas about this bug?
>>
>> Thanks
>> Jerome
>>
>>
>>
>> --
>> ==================================================================
>> J?r?me Redout?
>> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
>> CERMEP - Imagerie du vivant
>> 59 Bd Pinel. 69677 Bron - FRANCE
>> tel : 33 (0)4 72 68 86 18 (bureau)
>> tel : 33 (0)4 72 68 86 00 (standard)
>> fax : 33 (0)4 72 68 86 10
>> ==================================================================
>>
>>
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>
>

From redoute at cermep.fr  Thu Jun 16 03:28:29 2016
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Thu, 16 Jun 2016 09:28:29 +0200
Subject: [MINC-users] information loss after mincreshape
In-Reply-To: <CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>
References: <57615DCA.4030009@cermep.fr>
	<CAAd5DeRyf=N5BP_0O0=n15onhVqTvYH+OTELe3jgrWwUG1548A@mail.gmail.com>
	<CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>
Message-ID: <5762551D.2000706@cermep.fr>

Hi Robert,
thank you again !

you're right, this file seems to have regular sampling: here is the 
output of pre mincreshape file:

> 149.60534445733998155
> 449.60534445734003839
> 749.6053444573399247
> 1049.6053444572999069
> 1349.6053444572999069
> 1649.6053444572999069
> 1949.6053444572999069
> 2249.6053444572999069
> 2549.6053444572999069
> 2849.6053444572999069
> 3149.6053444572999069
> 3449.6053444572999069
> 3749.6053444572999069
> 4049.6053444572999069
> 4349.6053444573008164
> 4649.6053444573008164
> 4949.6053444573008164
> 5249.6053444573008164
> 5549.6053444573008164
> 5849.6053444573008164
> 6149.6053444573008164
> 6449.6053444573008164

Best
Jerome


Le 15/06/2016 19:19, Robert D. Vincent a ?crit :
> One thing I'd like to check: is the file you're using a regularly-sampled
> file, i.e. is there a constant time duration for each image?
>
>
> On Wed, Jun 15, 2016 at 1:09 PM, Robert D. Vincent <
> robert.d.vincent at mcgill.ca> wrote:
>
>> Hi J?r?me,
>>
>> Thanks for the report, I've reproduced it here. It seems that mincreshape
>> fails to copy the time dimension properly. I will fix it as soon as
>> possible.
>>
>>      -bert
>>
>> On Wed, Jun 15, 2016 at 9:53 AM, J?r?me Redout? <redoute at cermep.fr> wrote:
>>
>>> Dear all,
>>> I'm processing dynamic PET data acquired on Siemens Biograph mMR.
>>>
>>> after conversion from DICOM to MINC using dcm2mnc, I can extract frames
>>> timings using:
>>>
>>> mincinfo -varvalue time xxx.mnc
>>>
>>> BUT,
>>>
>>> after mincreshape +xdirection +ydirection +zdirection xxx.mnc xxx_res.mnc
>>>
>>> mincinfo -varvalue time xxx_res.mnc outputs only "0"
>>>
>>> any ideas about this bug?
>>>
>>> Thanks
>>> Jerome
>>>
>>>
>>>
>>> --
>>> ==================================================================
>>> J?r?me Redout?
>>> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
>>> CERMEP - Imagerie du vivant
>>> 59 Bd Pinel. 69677 Bron - FRANCE
>>> tel : 33 (0)4 72 68 86 18 (bureau)
>>> tel : 33 (0)4 72 68 86 00 (standard)
>>> fax : 33 (0)4 72 68 86 10
>>> ==================================================================
>>>
>>>
>>> _______________________________________________
>>> 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
>


-- 
==================================================================
J?r?me Redout?
Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
CERMEP - Imagerie du vivant
59 Bd Pinel. 69677 Bron - FRANCE
tel : 33 (0)4 72 68 86 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================



From redoute at cermep.fr  Thu Jun 16 04:55:39 2016
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Thu, 16 Jun 2016 10:55:39 +0200
Subject: [MINC-users] information loss after mincreshape
In-Reply-To: <CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>
References: <57615DCA.4030009@cermep.fr>
	<CAAd5DeRyf=N5BP_0O0=n15onhVqTvYH+OTELe3jgrWwUG1548A@mail.gmail.com>
	<CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>
Message-ID: <5762698B.3020900@cermep.fr>

Robert,
You're right, if the frame durations are variable, mincresample copy the 
time dimension properly!!
Je

Le 15/06/2016 19:19, Robert D. Vincent a ?crit :
> One thing I'd like to check: is the file you're using a regularly-sampled
> file, i.e. is there a constant time duration for each image?
>
>
> On Wed, Jun 15, 2016 at 1:09 PM, Robert D. Vincent <
> robert.d.vincent at mcgill.ca> wrote:
>
>> Hi J?r?me,
>>
>> Thanks for the report, I've reproduced it here. It seems that mincreshape
>> fails to copy the time dimension properly. I will fix it as soon as
>> possible.
>>
>>      -bert
>>
>> On Wed, Jun 15, 2016 at 9:53 AM, J?r?me Redout? <redoute at cermep.fr> wrote:
>>
>>> Dear all,
>>> I'm processing dynamic PET data acquired on Siemens Biograph mMR.
>>>
>>> after conversion from DICOM to MINC using dcm2mnc, I can extract frames
>>> timings using:
>>>
>>> mincinfo -varvalue time xxx.mnc
>>>
>>> BUT,
>>>
>>> after mincreshape +xdirection +ydirection +zdirection xxx.mnc xxx_res.mnc
>>>
>>> mincinfo -varvalue time xxx_res.mnc outputs only "0"
>>>
>>> any ideas about this bug?
>>>
>>> Thanks
>>> Jerome
>>>
>>>
>>>
>>> --
>>> ==================================================================
>>> J?r?me Redout?
>>> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
>>> CERMEP - Imagerie du vivant
>>> 59 Bd Pinel. 69677 Bron - FRANCE
>>> tel : 33 (0)4 72 68 86 18 (bureau)
>>> tel : 33 (0)4 72 68 86 00 (standard)
>>> fax : 33 (0)4 72 68 86 10
>>> ==================================================================
>>>
>>>
>>> _______________________________________________
>>> 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
>


-- 
==================================================================
J?r?me Redout?
Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
CERMEP - Imagerie du vivant
59 Bd Pinel. 69677 Bron - FRANCE
tel : 33 (0)4 72 68 86 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================



From matthijs.vaneede at sickkids.ca  Fri Jun 17 14:57:37 2016
From: matthijs.vaneede at sickkids.ca (Matthijs van Eede)
Date: Fri, 17 Jun 2016 18:57:37 +0000
Subject: [MINC-users] minccomplete's completeness
In-Reply-To: <CABEEk17QY2STP2K9SYkWUZwrmN37i-TTJKL39PfH4XfvXPYhPQ@mail.gmail.com>
References: <CABEEk17TXVkmC9D=ZQWccGVufvUcC0FDi3zN=5CXQXSUb=tRew@mail.gmail.com>
	<CAMCwi7OtT0JuGZkR1fdruOViK5vGOKG6g8_wuFTdpUk4XpsXRw@mail.gmail.com>
	<CABEEk16JJOgLewbz4qppLioMAcC-nR0jYoWqW7ptEKQMoLHONg@mail.gmail.com>
	<CAAd5DeQC6+T-aZBhNJv+n-NJ-ZzbdY6oG=DUvrX6CiYu8_bp6w@mail.gmail.com>
	<CABEEk14N7QH2HPvCE2KG+7wj78hZ4z60z+VNHbQBUtcj0nzopA@mail.gmail.com>
	<CAAd5DeSB2zgHS4mvWVQFV8TDL2hjpFymfJ3FmbX=jTvjrbjo=w@mail.gmail.com>,
	<CABEEk17QY2STP2K9SYkWUZwrmN37i-TTJKL39PfH4XfvXPYhPQ@mail.gmail.com>
Message-ID: <960852518D084247B51C83A707C3EF3E53CBED4F@SKMBXX03.sickkids.ca>

Hi All,

We have a fix for pyminc, which will soon be in the master branch, but also a question about how you should set the image:complete flag in a MINC file. The first thing we tried was:

miset_attr_values(self.volPointer, MI_TYPE_STRING, "image", "complete", len("true_"), "true_")

which creates a new entry in the MINC file header like this:

int image ;
    image:vartype = "group________" ;
    image:complete = "true_" ;
    image:signtype = "signed__" ;

But this is not the entry that minccomplete is after. Then we used the following which does work, but which seems a bit sketchy:

miset_attribute(self.volPointer, "/minc-2.0/image/0/image", "complete", MI_TYPE_STRING, len("true_"), "true_")

Does anyone know why you can't set the image:complete attribute using the first method?

Thanks,
Matthijs

________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Alex Zijdenbos [zijdenbos at gmail.com]
Sent: Wednesday, June 01, 2016 10:10 AM
To: MINC users mailing list
Subject: Re: [MINC-users] minccomplete's completeness

Thanks, Bert!

I actually worked in explicit MINC integrity tests in the central sub I
have that spawns processes (similar to MNI::Spawn), so that every MINC
volume that is present in a spawned command line, is explicitly checked.
Besides nii2mnc, the only thing it has turned up so far is pyminc. But
there are likely a few more things out there.

-- A

On Wed, Jun 1, 2016 at 12:25 AM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi Alex,
>
> I just checked in a fix for nii2mnc. I am sure there are other tools that
> do not set the attribute - I'll try to find and fix them.
>
>     -bert
>
> On Mon, May 30, 2016 at 11:37 AM, Alex Zijdenbos <zijdenbos at gmail.com>
> wrote:
>
> > Nice work, Bert!
> >
> > I have since built in some paranoid checking in all of my scripts, and
> one
> > thing that keeps turning up is that nii2mnc doesn't actually set the
> > 'complete' flag. Iow, anything created by nii2mnc fails minccomplete. Any
> > chance you fixed that as well?
> >
> > Thanks,
> >
> > -- A
> >
> > On Mon, May 16, 2016 at 12:38 PM, Robert D. Vincent <
> > robert.d.vincent at mcgill.ca> wrote:
> >
> > > Hi all,
> > >
> > > I have just checked in changes to volume_io, voxel_loop and the
> following
> > > minc tools:
> > >
> > > mincaverage, minccalc, minccmp, mincconcat, mincconvert, minccopy,
> > > mincextract, minclookup, mincmakescalar, mincmakevector, mincmath,
> > > mincresample, mincreshape, mincsample, mincstats, minctoraw,
> mincwindow.
> > >
> > > These tools will still behave as before, in that they will run to
> > > completion with a corrupt file. However, they will report the error as
> a
> > > non-zero exit code (EXIT_FAILURE), in addition to whatever messages are
> > > currently displayed by the libraries.
> > >
> > > Two existing tools, mincinfo and mincdump, seem to already have correct
> > > handling of read errors. At least two others, mincblob and mincmorph,
> > > should pick up the changes via volume_io.
> > >
> > > This covers the majority of the command line tools. It may also make
> > sense
> > > to reflect these changes in some of the basic scripts (e.g. mincpik,
> > > mincdiff) - let me know if there are any particularly salient cases we
> > > should take care of.
> > >
> > >     -bert
> > >
> > > On Sat, May 14, 2016 at 5:04 PM, Alex Zijdenbos <zijdenbos at gmail.com>
> > > wrote:
> > >
> > > > On this note: nii2mnc is one of the tools that doesn't appear to set
> > the
> > > > image:complete attribute. I haven't found any others yet but since I
> > > > started running minccomplete on anything I generate, I may come up
> with
> > > > more :)
> > > >
> > > > On Sat, May 14, 2016 at 6:53 AM, Vladimir S. FONOV <
> > > > vladimir.fonov at gmail.com
> > > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > the only thing minccomplete does is read the contents of the
> > > > image:complete
> > > > > attribute. Which is not even respected by all minc tools.
> > > > > One real way to check the consistency of the minc file would be to
> > > enable
> > > > > checksum , integrated into HDF5 file format.
> > > > >
> > > > > Currently it can be enabled by setting the environment variable
> > > > > MINC_CHECKSUM to 1 , at the time when file is created. Obviously,
> > this
> > > > > works only with MINC2 file format and it was not tested very well
> > yet.
> > > > >
> > > > > On Fri, May 13, 2016 at 3:35 PM, Alex Zijdenbos <
> zijdenbos at gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I managed to generate a large number of broken MINC files;
> > > > > possibly/likely
> > > > > > due to a filesystem problem. The processes that created them
> (e.g.,
> > > > > > mincaverage) did not produce any warnings and completed
> > successfully;
> > > > in
> > > > > > addition, minccomplete tells me that the files are complete.
> > > > > >
> > > > > > Unfortunately, trying to read these files throws HDF5 and miicv
> > > errors
> > > > > (see
> > > > > > below) and they are obviously corrupt.
> > > > > >
> > > > > > I am thinking that it would be useful to complete minccomplete by
> > > > having
> > > > > it
> > > > > > actually test-read the data, such that it would report on file
> > > > integrity?
> > > > > > This would make it easy to find these kinds of corruptions - and
> > > could
> > > > > even
> > > > > > tack that end the end of scripts to make sure outputs are intact.
> > I'm
> > > > > > currently using 'mincstats -quiet -min' to locate them, but it
> > seems
> > > > the
> > > > > > natural place for this test would actually be minccomplete.
> > > > > >
> > > > > > -- A
> > > > > >
> > > > > > HDF5-DIAG: Error detected in HDF5 (1.8.9) thread 0:
> > > > > >   #000: H5Dio.c line 174 in H5Dread(): can't read data
> > > > > >     major: Dataset
> > > > > >     minor: Read failed
> > > > > >   #001: H5Dio.c line 449 in H5D_read(): can't read data
> > > > > >     major: Dataset
> > > > > >     minor: Read failed
> > > > > >   #002: H5Dchunk.c line 1729 in H5D_chunk_read(): unable to read
> > raw
> > > > data
> > > > > > chunk
> > > > > >     major: Low-level I/O
> > > > > >     minor: Read failed
> > > > > >   #003: H5Dchunk.c line 2760 in H5D_chunk_lock(): data pipeline
> > read
> > > > > failed
> > > > > >     major: Data filters
> > > > > >     minor: Filter operation failed
> > > > > >   #004: H5Z.c line 1120 in H5Z_pipeline(): filter returned
> failure
> > > > during
> > > > > > read
> > > > > >     major: Data filters
> > > > > >     minor: Read failed
> > > > > >   #005: H5Zdeflate.c line 125 in H5Z_filter_deflate(): inflate()
> > > failed
> > > > > >     major: Data filters
> > > > > >     minor: Unable to initialize object
> > > > > > mincstats (from miicv_get): Can't read dataset
> > > /minc-2.0/image/0/image
> > > > > > _______________________________________________
> > > > > > 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
> > > >
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> 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

________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

From vladimir.fonov at gmail.com  Fri Jun 17 15:54:20 2016
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Fri, 17 Jun 2016 15:54:20 -0400
Subject: [MINC-users] minccomplete's completeness
In-Reply-To: <960852518D084247B51C83A707C3EF3E53CBED4F@SKMBXX03.sickkids.ca>
References: <CABEEk17TXVkmC9D=ZQWccGVufvUcC0FDi3zN=5CXQXSUb=tRew@mail.gmail.com>
	<CAMCwi7OtT0JuGZkR1fdruOViK5vGOKG6g8_wuFTdpUk4XpsXRw@mail.gmail.com>
	<CABEEk16JJOgLewbz4qppLioMAcC-nR0jYoWqW7ptEKQMoLHONg@mail.gmail.com>
	<CAAd5DeQC6+T-aZBhNJv+n-NJ-ZzbdY6oG=DUvrX6CiYu8_bp6w@mail.gmail.com>
	<CABEEk14N7QH2HPvCE2KG+7wj78hZ4z60z+VNHbQBUtcj0nzopA@mail.gmail.com>
	<CAAd5DeSB2zgHS4mvWVQFV8TDL2hjpFymfJ3FmbX=jTvjrbjo=w@mail.gmail.com>
	<CABEEk17QY2STP2K9SYkWUZwrmN37i-TTJKL39PfH4XfvXPYhPQ@mail.gmail.com>
	<960852518D084247B51C83A707C3EF3E53CBED4F@SKMBXX03.sickkids.ca>
Message-ID: <5764556C.2000701@gmail.com>

That is going to be one more of the "special features" of minc2 format.

Technically, the attribute location should be /minc-2.0/image/<n>/image

where <n> is the currently selected resolution level (MINC2 supports 
storing images at multiple resolution).

 From the point of view of minccomplete it uses image:complete attribute 
in minc2 file only, which was automagically mapped to that name by MINC1 
API .

For the actual API call,
miset_attr_values is not going to work, because currently it can't find 
the location of this attribute.
To make it work, one could modify these lines:
https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L918
https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L502
https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L600

and
https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L783

and add one more special case on where to look for this attribute.

miset_attribute - is supposed to be a private internal function , not 
visible to the API users.


On 16-06-17 02:57 PM, Matthijs van Eede wrote:
> Hi All,
>
> We have a fix for pyminc, which will soon be in the master branch, but also a question about how you should set the image:complete flag in a MINC file. The first thing we tried was:
>
> miset_attr_values(self.volPointer, MI_TYPE_STRING, "image", "complete", len("true_"), "true_")
>
> which creates a new entry in the MINC file header like this:
>
> int image ;
>      image:vartype = "group________" ;
>      image:complete = "true_" ;
>      image:signtype = "signed__" ;
>
> But this is not the entry that minccomplete is after. Then we used the following which does work, but which seems a bit sketchy:
>
> miset_attribute(self.volPointer, "/minc-2.0/image/0/image", "complete", MI_TYPE_STRING, len("true_"), "true_")
>
> Does anyone know why you can't set the image:complete attribute using the first method?
>


-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com

From matthijs.vaneede at sickkids.ca  Fri Jun 17 17:00:00 2016
From: matthijs.vaneede at sickkids.ca (Matthijs van Eede)
Date: Fri, 17 Jun 2016 21:00:00 +0000
Subject: [MINC-users] minccomplete's completeness
In-Reply-To: <5764556C.2000701@gmail.com>
References: <CABEEk17TXVkmC9D=ZQWccGVufvUcC0FDi3zN=5CXQXSUb=tRew@mail.gmail.com>
	<CAMCwi7OtT0JuGZkR1fdruOViK5vGOKG6g8_wuFTdpUk4XpsXRw@mail.gmail.com>
	<CABEEk16JJOgLewbz4qppLioMAcC-nR0jYoWqW7ptEKQMoLHONg@mail.gmail.com>
	<CAAd5DeQC6+T-aZBhNJv+n-NJ-ZzbdY6oG=DUvrX6CiYu8_bp6w@mail.gmail.com>
	<CABEEk14N7QH2HPvCE2KG+7wj78hZ4z60z+VNHbQBUtcj0nzopA@mail.gmail.com>
	<CAAd5DeSB2zgHS4mvWVQFV8TDL2hjpFymfJ3FmbX=jTvjrbjo=w@mail.gmail.com>
	<CABEEk17QY2STP2K9SYkWUZwrmN37i-TTJKL39PfH4XfvXPYhPQ@mail.gmail.com>
	<960852518D084247B51C83A707C3EF3E53CBED4F@SKMBXX03.sickkids.ca>,
	<5764556C.2000701@gmail.com>
Message-ID: <960852518D084247B51C83A707C3EF3E53CC0D72@SKMBXX03.sickkids.ca>

So.... what should I do at the moment then? Should I leave this solution (using the private internal miset_attribute function) in pyminc currently to ensure the image:complete flag can be set? And change things when the API has been fixed?

________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Vladimir S. FONOV [vladimir.fonov at gmail.com]
Sent: Friday, June 17, 2016 3:54 PM
To: minc-users at bic.mni.mcgill.ca
Subject: Re: [MINC-users] minccomplete's completeness

That is going to be one more of the "special features" of minc2 format.

Technically, the attribute location should be /minc-2.0/image/<n>/image

where <n> is the currently selected resolution level (MINC2 supports
storing images at multiple resolution).

 From the point of view of minccomplete it uses image:complete attribute
in minc2 file only, which was automagically mapped to that name by MINC1
API .

For the actual API call,
miset_attr_values is not going to work, because currently it can't find
the location of this attribute.
To make it work, one could modify these lines:
https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L918
https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L502
https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L600

and
https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L783

and add one more special case on where to look for this attribute.

miset_attribute - is supposed to be a private internal function , not
visible to the API users.


On 16-06-17 02:57 PM, Matthijs van Eede wrote:
> Hi All,
>
> We have a fix for pyminc, which will soon be in the master branch, but also a question about how you should set the image:complete flag in a MINC file. The first thing we tried was:
>
> miset_attr_values(self.volPointer, MI_TYPE_STRING, "image", "complete", len("true_"), "true_")
>
> which creates a new entry in the MINC file header like this:
>
> int image ;
>      image:vartype = "group________" ;
>      image:complete = "true_" ;
>      image:signtype = "signed__" ;
>
> But this is not the entry that minccomplete is after. Then we used the following which does work, but which seems a bit sketchy:
>
> miset_attribute(self.volPointer, "/minc-2.0/image/0/image", "complete", MI_TYPE_STRING, len("true_"), "true_")
>
> Does anyone know why you can't set the image:complete attribute using the first method?
>


--
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
_______________________________________________
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

From robert.d.vincent at mcgill.ca  Fri Jun 17 17:04:44 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Fri, 17 Jun 2016 17:04:44 -0400
Subject: [MINC-users] minccomplete's completeness
In-Reply-To: <5764556C.2000701@gmail.com>
References: <CABEEk17TXVkmC9D=ZQWccGVufvUcC0FDi3zN=5CXQXSUb=tRew@mail.gmail.com>
	<CAMCwi7OtT0JuGZkR1fdruOViK5vGOKG6g8_wuFTdpUk4XpsXRw@mail.gmail.com>
	<CABEEk16JJOgLewbz4qppLioMAcC-nR0jYoWqW7ptEKQMoLHONg@mail.gmail.com>
	<CAAd5DeQC6+T-aZBhNJv+n-NJ-ZzbdY6oG=DUvrX6CiYu8_bp6w@mail.gmail.com>
	<CABEEk14N7QH2HPvCE2KG+7wj78hZ4z60z+VNHbQBUtcj0nzopA@mail.gmail.com>
	<CAAd5DeSB2zgHS4mvWVQFV8TDL2hjpFymfJ3FmbX=jTvjrbjo=w@mail.gmail.com>
	<CABEEk17QY2STP2K9SYkWUZwrmN37i-TTJKL39PfH4XfvXPYhPQ@mail.gmail.com>
	<960852518D084247B51C83A707C3EF3E53CBED4F@SKMBXX03.sickkids.ca>
	<5764556C.2000701@gmail.com>
Message-ID: <CAAd5DeRDMD-ZTtTSNbCFHqeRwsHqtXikgdhMQvL+us0Gbs6W3Q@mail.gmail.com>

Hi all,

I am in the process of making the fix to the API. Should be checked in this
afternoon.

    -bert

On Fri, Jun 17, 2016 at 3:54 PM, Vladimir S. FONOV <vladimir.fonov at gmail.com
> wrote:

> That is going to be one more of the "special features" of minc2 format.
>
> Technically, the attribute location should be /minc-2.0/image/<n>/image
>
> where <n> is the currently selected resolution level (MINC2 supports
> storing images at multiple resolution).
>
> From the point of view of minccomplete it uses image:complete attribute in
> minc2 file only, which was automagically mapped to that name by MINC1 API .
>
> For the actual API call,
> miset_attr_values is not going to work, because currently it can't find
> the location of this attribute.
> To make it work, one could modify these lines:
> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L918
> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L502
> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L600
>
> and
> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L783
>
> and add one more special case on where to look for this attribute.
>
> miset_attribute - is supposed to be a private internal function , not
> visible to the API users.
>
>
>
> On 16-06-17 02:57 PM, Matthijs van Eede wrote:
>
>> Hi All,
>>
>> We have a fix for pyminc, which will soon be in the master branch, but
>> also a question about how you should set the image:complete flag in a MINC
>> file. The first thing we tried was:
>>
>> miset_attr_values(self.volPointer, MI_TYPE_STRING, "image", "complete",
>> len("true_"), "true_")
>>
>> which creates a new entry in the MINC file header like this:
>>
>> int image ;
>>      image:vartype = "group________" ;
>>      image:complete = "true_" ;
>>      image:signtype = "signed__" ;
>>
>> But this is not the entry that minccomplete is after. Then we used the
>> following which does work, but which seems a bit sketchy:
>>
>> miset_attribute(self.volPointer, "/minc-2.0/image/0/image", "complete",
>> MI_TYPE_STRING, len("true_"), "true_")
>>
>> Does anyone know why you can't set the image:complete attribute using the
>> first method?
>>
>>
>
> --
> Best regards,
>
>  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From robert.d.vincent at mcgill.ca  Fri Jun 17 17:37:18 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Fri, 17 Jun 2016 17:37:18 -0400
Subject: [MINC-users] minccomplete's completeness
In-Reply-To: <CAAd5DeRDMD-ZTtTSNbCFHqeRwsHqtXikgdhMQvL+us0Gbs6W3Q@mail.gmail.com>
References: <CABEEk17TXVkmC9D=ZQWccGVufvUcC0FDi3zN=5CXQXSUb=tRew@mail.gmail.com>
	<CAMCwi7OtT0JuGZkR1fdruOViK5vGOKG6g8_wuFTdpUk4XpsXRw@mail.gmail.com>
	<CABEEk16JJOgLewbz4qppLioMAcC-nR0jYoWqW7ptEKQMoLHONg@mail.gmail.com>
	<CAAd5DeQC6+T-aZBhNJv+n-NJ-ZzbdY6oG=DUvrX6CiYu8_bp6w@mail.gmail.com>
	<CABEEk14N7QH2HPvCE2KG+7wj78hZ4z60z+VNHbQBUtcj0nzopA@mail.gmail.com>
	<CAAd5DeSB2zgHS4mvWVQFV8TDL2hjpFymfJ3FmbX=jTvjrbjo=w@mail.gmail.com>
	<CABEEk17QY2STP2K9SYkWUZwrmN37i-TTJKL39PfH4XfvXPYhPQ@mail.gmail.com>
	<960852518D084247B51C83A707C3EF3E53CBED4F@SKMBXX03.sickkids.ca>
	<5764556C.2000701@gmail.com>
	<CAAd5DeRDMD-ZTtTSNbCFHqeRwsHqtXikgdhMQvL+us0Gbs6W3Q@mail.gmail.com>
Message-ID: <CAAd5DeRXhAHqm1pSDhD77a9Fh5J1+dGnU1=i0mjtCvjs7MD-4g@mail.gmail.com>

Hi all,

The develop branch now has a fix for the bug Matthijs just reported. The
official call to
miset_attr_values(volume, MI_STRING_TYPE, "image", "complete", 5, "true_")
should do the right thing now.

Please let me know immediately if it doesn't!

    -bert


On Fri, Jun 17, 2016 at 5:04 PM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi all,
>
> I am in the process of making the fix to the API. Should be checked in
> this afternoon.
>
>     -bert
>
> On Fri, Jun 17, 2016 at 3:54 PM, Vladimir S. FONOV <
> vladimir.fonov at gmail.com> wrote:
>
>> That is going to be one more of the "special features" of minc2 format.
>>
>> Technically, the attribute location should be /minc-2.0/image/<n>/image
>>
>> where <n> is the currently selected resolution level (MINC2 supports
>> storing images at multiple resolution).
>>
>> From the point of view of minccomplete it uses image:complete attribute
>> in minc2 file only, which was automagically mapped to that name by MINC1
>> API .
>>
>> For the actual API call,
>> miset_attr_values is not going to work, because currently it can't find
>> the location of this attribute.
>> To make it work, one could modify these lines:
>> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L918
>> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L502
>> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L600
>>
>> and
>> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L783
>>
>> and add one more special case on where to look for this attribute.
>>
>> miset_attribute - is supposed to be a private internal function , not
>> visible to the API users.
>>
>>
>>
>> On 16-06-17 02:57 PM, Matthijs van Eede wrote:
>>
>>> Hi All,
>>>
>>> We have a fix for pyminc, which will soon be in the master branch, but
>>> also a question about how you should set the image:complete flag in a MINC
>>> file. The first thing we tried was:
>>>
>>> miset_attr_values(self.volPointer, MI_TYPE_STRING, "image", "complete",
>>> len("true_"), "true_")
>>>
>>> which creates a new entry in the MINC file header like this:
>>>
>>> int image ;
>>>      image:vartype = "group________" ;
>>>      image:complete = "true_" ;
>>>      image:signtype = "signed__" ;
>>>
>>> But this is not the entry that minccomplete is after. Then we used the
>>> following which does work, but which seems a bit sketchy:
>>>
>>> miset_attribute(self.volPointer, "/minc-2.0/image/0/image", "complete",
>>> MI_TYPE_STRING, len("true_"), "true_")
>>>
>>> Does anyone know why you can't set the image:complete attribute using
>>> the first method?
>>>
>>>
>>
>> --
>> Best regards,
>>
>>  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>
>

From matthijs.vaneede at sickkids.ca  Fri Jun 17 18:08:10 2016
From: matthijs.vaneede at sickkids.ca (Matthijs van Eede)
Date: Fri, 17 Jun 2016 22:08:10 +0000
Subject: [MINC-users] minccomplete's completeness
In-Reply-To: <CAAd5DeRXhAHqm1pSDhD77a9Fh5J1+dGnU1=i0mjtCvjs7MD-4g@mail.gmail.com>
References: <CABEEk17TXVkmC9D=ZQWccGVufvUcC0FDi3zN=5CXQXSUb=tRew@mail.gmail.com>
	<CAMCwi7OtT0JuGZkR1fdruOViK5vGOKG6g8_wuFTdpUk4XpsXRw@mail.gmail.com>
	<CABEEk16JJOgLewbz4qppLioMAcC-nR0jYoWqW7ptEKQMoLHONg@mail.gmail.com>
	<CAAd5DeQC6+T-aZBhNJv+n-NJ-ZzbdY6oG=DUvrX6CiYu8_bp6w@mail.gmail.com>
	<CABEEk14N7QH2HPvCE2KG+7wj78hZ4z60z+VNHbQBUtcj0nzopA@mail.gmail.com>
	<CAAd5DeSB2zgHS4mvWVQFV8TDL2hjpFymfJ3FmbX=jTvjrbjo=w@mail.gmail.com>
	<CABEEk17QY2STP2K9SYkWUZwrmN37i-TTJKL39PfH4XfvXPYhPQ@mail.gmail.com>
	<960852518D084247B51C83A707C3EF3E53CBED4F@SKMBXX03.sickkids.ca>
	<5764556C.2000701@gmail.com>
	<CAAd5DeRDMD-ZTtTSNbCFHqeRwsHqtXikgdhMQvL+us0Gbs6W3Q@mail.gmail.com>,
	<CAAd5DeRXhAHqm1pSDhD77a9Fh5J1+dGnU1=i0mjtCvjs7MD-4g@mail.gmail.com>
Message-ID: <960852518D084247B51C83A707C3EF3E53CC0D88@SKMBXX03.sickkids.ca>

That works! Thanks Vlad and Bert for this lightning fast turnaround!

Cheers,
Matthijs
________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Robert D. Vincent [robert.d.vincent at mcgill.ca]
Sent: Friday, June 17, 2016 5:37 PM
To: MINC users mailing list
Subject: Re: [MINC-users] minccomplete's completeness

Hi all,

The develop branch now has a fix for the bug Matthijs just reported. The
official call to
miset_attr_values(volume, MI_STRING_TYPE, "image", "complete", 5, "true_")
should do the right thing now.

Please let me know immediately if it doesn't!

    -bert


On Fri, Jun 17, 2016 at 5:04 PM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi all,
>
> I am in the process of making the fix to the API. Should be checked in
> this afternoon.
>
>     -bert
>
> On Fri, Jun 17, 2016 at 3:54 PM, Vladimir S. FONOV <
> vladimir.fonov at gmail.com> wrote:
>
>> That is going to be one more of the "special features" of minc2 format.
>>
>> Technically, the attribute location should be /minc-2.0/image/<n>/image
>>
>> where <n> is the currently selected resolution level (MINC2 supports
>> storing images at multiple resolution).
>>
>> From the point of view of minccomplete it uses image:complete attribute
>> in minc2 file only, which was automagically mapped to that name by MINC1
>> API .
>>
>> For the actual API call,
>> miset_attr_values is not going to work, because currently it can't find
>> the location of this attribute.
>> To make it work, one could modify these lines:
>> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L918
>> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L502
>> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L600
>>
>> and
>> https://github.com/BIC-MNI/libminc/blob/develop/libsrc2/grpattr.c#L783
>>
>> and add one more special case on where to look for this attribute.
>>
>> miset_attribute - is supposed to be a private internal function , not
>> visible to the API users.
>>
>>
>>
>> On 16-06-17 02:57 PM, Matthijs van Eede wrote:
>>
>>> Hi All,
>>>
>>> We have a fix for pyminc, which will soon be in the master branch, but
>>> also a question about how you should set the image:complete flag in a MINC
>>> file. The first thing we tried was:
>>>
>>> miset_attr_values(self.volPointer, MI_TYPE_STRING, "image", "complete",
>>> len("true_"), "true_")
>>>
>>> which creates a new entry in the MINC file header like this:
>>>
>>> int image ;
>>>      image:vartype = "group________" ;
>>>      image:complete = "true_" ;
>>>      image:signtype = "signed__" ;
>>>
>>> But this is not the entry that minccomplete is after. Then we used the
>>> following which does work, but which seems a bit sketchy:
>>>
>>> miset_attribute(self.volPointer, "/minc-2.0/image/0/image", "complete",
>>> MI_TYPE_STRING, len("true_"), "true_")
>>>
>>> Does anyone know why you can't set the image:complete attribute using
>>> the first method?
>>>
>>>
>>
>> --
>> Best regards,
>>
>>  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.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

________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

From matthijs.vaneede at sickkids.ca  Mon Jun 20 10:17:04 2016
From: matthijs.vaneede at sickkids.ca (Matthijs van Eede)
Date: Mon, 20 Jun 2016 14:17:04 +0000
Subject: [MINC-users] Retrieve MINC library version from C code
Message-ID: <960852518D084247B51C83A707C3EF3E53CC21FA@SKMBXX03.sickkids.ca>

Hi All,

When libminc is installed using cmake, a version is set using version_major, version_minor and version_patch. And running something like:

mincresample -version

will return the version of the MINC library used. Is that information available through the library itself? I've looked around, but couldn't find it. Is there a library function call that returns this information (something along the lines of MINCget_libversion(&major, &minor, &patch))?

Thanks,
Matthijs

________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

From robert.d.vincent at mcgill.ca  Mon Jun 20 11:00:06 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Mon, 20 Jun 2016 11:00:06 -0400
Subject: [MINC-users] Retrieve MINC library version from C code
In-Reply-To: <960852518D084247B51C83A707C3EF3E53CC21FA@SKMBXX03.sickkids.ca>
References: <960852518D084247B51C83A707C3EF3E53CC21FA@SKMBXX03.sickkids.ca>
Message-ID: <CAAd5DeSoq64Rzc3k8Nex_J=jBWUbjnZBrh7Fr3Vtt5tkDEaQ_A@mail.gmail.com>

Hi,

See miget_version(), which unfortunately just returns a string.

    -bert

On Mon, Jun 20, 2016 at 10:17 AM, Matthijs van Eede <
matthijs.vaneede at sickkids.ca> wrote:

> Hi All,
>
> When libminc is installed using cmake, a version is set using
> version_major, version_minor and version_patch. And running something like:
>
> mincresample -version
>
> will return the version of the MINC library used. Is that information
> available through the library itself? I've looked around, but couldn't find
> it. Is there a library function call that returns this information
> (something along the lines of MINCget_libversion(&major, &minor, &patch))?
>
> Thanks,
> Matthijs
>
> ________________________________
>
> This e-mail may contain confidential, personal and/or health
> information(information which may be subject to legal restrictions on use,
> retention and/or disclosure) for the sole use of the intended recipient.
> Any review or distribution by anyone other than the person for whom it was
> originally intended is strictly prohibited. If you have received this
> e-mail in error, please contact the sender and delete all copies.
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From matthijs.vaneede at sickkids.ca  Mon Jun 20 11:23:16 2016
From: matthijs.vaneede at sickkids.ca (Matthijs van Eede)
Date: Mon, 20 Jun 2016 15:23:16 +0000
Subject: [MINC-users] Retrieve MINC library version from C code
In-Reply-To: <CAAd5DeSoq64Rzc3k8Nex_J=jBWUbjnZBrh7Fr3Vtt5tkDEaQ_A@mail.gmail.com>
References: <960852518D084247B51C83A707C3EF3E53CC21FA@SKMBXX03.sickkids.ca>,
	<CAAd5DeSoq64Rzc3k8Nex_J=jBWUbjnZBrh7Fr3Vtt5tkDEaQ_A@mail.gmail.com>
Message-ID: <960852518D084247B51C83A707C3EF3E53CC4A63@SKMBXX03.sickkids.ca>

That works, thanks Bert!

Matthijs
________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Robert D. Vincent [robert.d.vincent at mcgill.ca]
Sent: Monday, June 20, 2016 11:00 AM
To: MINC users mailing list
Subject: Re: [MINC-users] Retrieve MINC library version from C code

Hi,

See miget_version(), which unfortunately just returns a string.

    -bert

On Mon, Jun 20, 2016 at 10:17 AM, Matthijs van Eede <
matthijs.vaneede at sickkids.ca> wrote:

> Hi All,
>
> When libminc is installed using cmake, a version is set using
> version_major, version_minor and version_patch. And running something like:
>
> mincresample -version
>
> will return the version of the MINC library used. Is that information
> available through the library itself? I've looked around, but couldn't find
> it. Is there a library function call that returns this information
> (something along the lines of MINCget_libversion(&major, &minor, &patch))?
>
> Thanks,
> Matthijs
>
> ________________________________
>
> This e-mail may contain confidential, personal and/or health
> information(information which may be subject to legal restrictions on use,
> retention and/or disclosure) for the sole use of the intended recipient.
> Any review or distribution by anyone other than the person for whom it was
> originally intended is strictly prohibited. If you have received this
> e-mail in error, please contact the sender and delete all copies.
> _______________________________________________
> 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

________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

From a.janke at gmail.com  Thu Jun 23 19:44:10 2016
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 24 Jun 2016 09:44:10 +1000
Subject: [MINC-users] minc-toolkit v1 and v2
Message-ID: <CAG0CB21ZsLP0yksvk_Lp9U_C92kjXswR0KGiop8um0O0Ud8QdA@mail.gmail.com>

Hi all,

Is there a defined way to deal with version 1.9 being installed in
/opt/minc-itk4 and the models being installed in /opt/minc/share?

For now I'm symlinking but perhaps I should instead set MNI_DATAPATH
to /opt/minc in /opt/minc-itk4/minc-toolkit-config.sh ?



a

From vladimir.fonov at gmail.com  Fri Jun 24 09:43:56 2016
From: vladimir.fonov at gmail.com (Vladimir S. Fonov)
Date: Fri, 24 Jun 2016 09:43:56 -0400
Subject: [MINC-users] minc-toolkit v1 and v2
In-Reply-To: <CAG0CB21ZsLP0yksvk_Lp9U_C92kjXswR0KGiop8um0O0Ud8QdA@mail.gmail.com>
References: <CAG0CB21ZsLP0yksvk_Lp9U_C92kjXswR0KGiop8um0O0Ud8QdA@mail.gmail.com>
Message-ID: <576D391C.2050203@gmail.com>

Maybe I should change installation scheme:

/opt/minc/<version>  - for binaries and
/opt/minc/share - for data files ?

This way one can combine multiple versions of the binaries with a single 
installation of models.

On 16-06-23 07:44 PM, Andrew Janke wrote:
> Hi all,
>
> Is there a defined way to deal with version 1.9 being installed in
> /opt/minc-itk4 and the models being installed in /opt/minc/share?
>
> For now I'm symlinking but perhaps I should instead set MNI_DATAPATH
> to /opt/minc in /opt/minc-itk4/minc-toolkit-config.sh ?
>
>
>
> a
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


From a.janke at gmail.com  Sun Jun 26 03:04:11 2016
From: a.janke at gmail.com (Andrew Janke)
Date: Sun, 26 Jun 2016 17:04:11 +1000
Subject: [MINC-users] minc-toolkit v1 and v2
In-Reply-To: <576D391C.2050203@gmail.com>
References: <CAG0CB21ZsLP0yksvk_Lp9U_C92kjXswR0KGiop8um0O0Ud8QdA@mail.gmail.com>
	<576D391C.2050203@gmail.com>
Message-ID: <CAG0CB200GoUcBBO5bicdBr0NHcBSxvEX0M9Z_eEuJdPTVgTyKA@mail.gmail.com>

Hi Vladimir,

It's your packaging so it's your call but I think what you are
suggesting makes a lot of sense going into the future. The only change
I'd make would be to use /opt/minc/data instead of /opt/minc/share.
Yes I know this breaks debian/Ubuntu packaging rules but for users it
may be more clear.

ta

a


On 24 June 2016 at 23:43, Vladimir S. Fonov <vladimir.fonov at gmail.com> wrote:
> Maybe I should change installation scheme:
>
> /opt/minc/<version>  - for binaries and
> /opt/minc/share - for data files ?
>
> This way one can combine multiple versions of the binaries with a single
> installation of models.
>
>
> On 16-06-23 07:44 PM, Andrew Janke wrote:
>>
>> Hi all,
>>
>> Is there a defined way to deal with version 1.9 being installed in
>> /opt/minc-itk4 and the models being installed in /opt/minc/share?
>>
>> For now I'm symlinking but perhaps I should instead set MNI_DATAPATH
>> to /opt/minc in /opt/minc-itk4/minc-toolkit-config.sh ?
>>
>>
>>
>> a
>> _______________________________________________
>> 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

From redoute at cermep.fr  Mon Jun 27 08:10:37 2016
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Mon, 27 Jun 2016 14:10:37 +0200
Subject: [MINC-users] information loss after mincreshape
In-Reply-To: <CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>
References: <57615DCA.4030009@cermep.fr>
	<CAAd5DeRyf=N5BP_0O0=n15onhVqTvYH+OTELe3jgrWwUG1548A@mail.gmail.com>
	<CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>
Message-ID: <577117BD.7060200@cermep.fr>

Hi Robert,
did you find how to fix the mincreshape bug?
thank you
Best regards

Jerome

Le 15/06/2016 19:19, Robert D. Vincent a ?crit :
> One thing I'd like to check: is the file you're using a regularly-sampled
> file, i.e. is there a constant time duration for each image?
>
>
> On Wed, Jun 15, 2016 at 1:09 PM, Robert D. Vincent <
> robert.d.vincent at mcgill.ca> wrote:
>
>> Hi J?r?me,
>>
>> Thanks for the report, I've reproduced it here. It seems that mincreshape
>> fails to copy the time dimension properly. I will fix it as soon as
>> possible.
>>
>>      -bert
>>
>> On Wed, Jun 15, 2016 at 9:53 AM, J?r?me Redout? <redoute at cermep.fr> wrote:
>>
>>> Dear all,
>>> I'm processing dynamic PET data acquired on Siemens Biograph mMR.
>>>
>>> after conversion from DICOM to MINC using dcm2mnc, I can extract frames
>>> timings using:
>>>
>>> mincinfo -varvalue time xxx.mnc
>>>
>>> BUT,
>>>
>>> after mincreshape +xdirection +ydirection +zdirection xxx.mnc xxx_res.mnc
>>>
>>> mincinfo -varvalue time xxx_res.mnc outputs only "0"
>>>
>>> any ideas about this bug?
>>>
>>> Thanks
>>> Jerome
>>>
>>>
>>>
>>> --
>>> ==================================================================
>>> J?r?me Redout?
>>> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
>>> CERMEP - Imagerie du vivant
>>> 59 Bd Pinel. 69677 Bron - FRANCE
>>> tel : 33 (0)4 72 68 86 18 (bureau)
>>> tel : 33 (0)4 72 68 86 00 (standard)
>>> fax : 33 (0)4 72 68 86 10
>>> ==================================================================
>>>
>>>
>>> _______________________________________________
>>> 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
>


-- 
==================================================================
J?r?me Redout?
Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
CERMEP - Imagerie du vivant
59 Bd Pinel. 69677 Bron - FRANCE
tel : 33 (0)4 72 68 86 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================



From robert.d.vincent at mcgill.ca  Wed Jun 29 07:46:27 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Wed, 29 Jun 2016 07:46:27 -0400
Subject: [MINC-users] information loss after mincreshape
In-Reply-To: <577117BD.7060200@cermep.fr>
References: <57615DCA.4030009@cermep.fr>
	<CAAd5DeRyf=N5BP_0O0=n15onhVqTvYH+OTELe3jgrWwUG1548A@mail.gmail.com>
	<CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>
	<577117BD.7060200@cermep.fr>
Message-ID: <CAAd5DeTnr3YnvJ562t9pAQeToA_y_JvzY7J7uR8pxtkLM4faeA@mail.gmail.com>

Hi,

Sorry, I haven't had a chance to look at it yet. I'll try to get to before
the end of this week.

    -bert

On Mon, Jun 27, 2016 at 8:10 AM, J?r?me Redout? <redoute at cermep.fr> wrote:

> Hi Robert,
> did you find how to fix the mincreshape bug?
> thank you
> Best regards
>
> Jerome
>
> Le 15/06/2016 19:19, Robert D. Vincent a ?crit :
>
>> One thing I'd like to check: is the file you're using a regularly-sampled
>> file, i.e. is there a constant time duration for each image?
>>
>>
>> On Wed, Jun 15, 2016 at 1:09 PM, Robert D. Vincent <
>> robert.d.vincent at mcgill.ca> wrote:
>>
>> Hi J?r?me,
>>>
>>> Thanks for the report, I've reproduced it here. It seems that mincreshape
>>> fails to copy the time dimension properly. I will fix it as soon as
>>> possible.
>>>
>>>      -bert
>>>
>>> On Wed, Jun 15, 2016 at 9:53 AM, J?r?me Redout? <redoute at cermep.fr>
>>> wrote:
>>>
>>> Dear all,
>>>> I'm processing dynamic PET data acquired on Siemens Biograph mMR.
>>>>
>>>> after conversion from DICOM to MINC using dcm2mnc, I can extract frames
>>>> timings using:
>>>>
>>>> mincinfo -varvalue time xxx.mnc
>>>>
>>>> BUT,
>>>>
>>>> after mincreshape +xdirection +ydirection +zdirection xxx.mnc
>>>> xxx_res.mnc
>>>>
>>>> mincinfo -varvalue time xxx_res.mnc outputs only "0"
>>>>
>>>> any ideas about this bug?
>>>>
>>>> Thanks
>>>> Jerome
>>>>
>>>>
>>>>
>>>> --
>>>> ==================================================================
>>>> J?r?me Redout?
>>>> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
>>>> CERMEP - Imagerie du vivant
>>>> 59 Bd Pinel. 69677 Bron - FRANCE
>>>> tel : 33 (0)4 72 68 86 18 (bureau)
>>>> tel : 33 (0)4 72 68 86 00 (standard)
>>>> fax : 33 (0)4 72 68 86 10
>>>> ==================================================================
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> --
> ==================================================================
> J?r?me Redout?
> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
> CERMEP - Imagerie du vivant
> 59 Bd Pinel. 69677 Bron - FRANCE
> tel : 33 (0)4 72 68 86 18 (bureau)
> tel : 33 (0)4 72 68 86 00 (standard)
> fax : 33 (0)4 72 68 86 10
> ==================================================================
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From robert.d.vincent at mcgill.ca  Thu Jun 30 10:18:57 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Thu, 30 Jun 2016 10:18:57 -0400
Subject: [MINC-users] information loss after mincreshape
In-Reply-To: <577117BD.7060200@cermep.fr>
References: <57615DCA.4030009@cermep.fr>
	<CAAd5DeRyf=N5BP_0O0=n15onhVqTvYH+OTELe3jgrWwUG1548A@mail.gmail.com>
	<CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>
	<577117BD.7060200@cermep.fr>
Message-ID: <CAAd5DeQa56NyWmHTu9zO5JnZY6XLzF0crwVNvvqcADizgMP_hw@mail.gmail.com>

Hi Jerome,

I believe I have fixed the issue. After thinking about it, I believe it is
safe to preserve the information whenever it happens to be present, so that
is now the behavior of mincreshape.

I pushed the fix to the develop branch.

    -bert

On Mon, Jun 27, 2016 at 8:10 AM, J?r?me Redout? <redoute at cermep.fr> wrote:

> Hi Robert,
> did you find how to fix the mincreshape bug?
> thank you
> Best regards
>
> Jerome
>
> Le 15/06/2016 19:19, Robert D. Vincent a ?crit :
>
>> One thing I'd like to check: is the file you're using a regularly-sampled
>> file, i.e. is there a constant time duration for each image?
>>
>>
>> On Wed, Jun 15, 2016 at 1:09 PM, Robert D. Vincent <
>> robert.d.vincent at mcgill.ca> wrote:
>>
>> Hi J?r?me,
>>>
>>> Thanks for the report, I've reproduced it here. It seems that mincreshape
>>> fails to copy the time dimension properly. I will fix it as soon as
>>> possible.
>>>
>>>      -bert
>>>
>>> On Wed, Jun 15, 2016 at 9:53 AM, J?r?me Redout? <redoute at cermep.fr>
>>> wrote:
>>>
>>> Dear all,
>>>> I'm processing dynamic PET data acquired on Siemens Biograph mMR.
>>>>
>>>> after conversion from DICOM to MINC using dcm2mnc, I can extract frames
>>>> timings using:
>>>>
>>>> mincinfo -varvalue time xxx.mnc
>>>>
>>>> BUT,
>>>>
>>>> after mincreshape +xdirection +ydirection +zdirection xxx.mnc
>>>> xxx_res.mnc
>>>>
>>>> mincinfo -varvalue time xxx_res.mnc outputs only "0"
>>>>
>>>> any ideas about this bug?
>>>>
>>>> Thanks
>>>> Jerome
>>>>
>>>>
>>>>
>>>> --
>>>> ==================================================================
>>>> J?r?me Redout?
>>>> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
>>>> CERMEP - Imagerie du vivant
>>>> 59 Bd Pinel. 69677 Bron - FRANCE
>>>> tel : 33 (0)4 72 68 86 18 (bureau)
>>>> tel : 33 (0)4 72 68 86 00 (standard)
>>>> fax : 33 (0)4 72 68 86 10
>>>> ==================================================================
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> --
> ==================================================================
> J?r?me Redout?
> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
> CERMEP - Imagerie du vivant
> 59 Bd Pinel. 69677 Bron - FRANCE
> tel : 33 (0)4 72 68 86 18 (bureau)
> tel : 33 (0)4 72 68 86 00 (standard)
> fax : 33 (0)4 72 68 86 10
> ==================================================================
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From redoute at cermep.fr  Thu Jun 30 10:29:56 2016
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Thu, 30 Jun 2016 16:29:56 +0200
Subject: [MINC-users] information loss after mincreshape
In-Reply-To: <CAAd5DeQa56NyWmHTu9zO5JnZY6XLzF0crwVNvvqcADizgMP_hw@mail.gmail.com>
References: <57615DCA.4030009@cermep.fr>
	<CAAd5DeRyf=N5BP_0O0=n15onhVqTvYH+OTELe3jgrWwUG1548A@mail.gmail.com>
	<CAAd5DeQbJXmb2e_6DBQpSN3oc6dZbPp2qb0Ve6esGOK+ZLt_bQ@mail.gmail.com>
	<577117BD.7060200@cermep.fr>
	<CAAd5DeQa56NyWmHTu9zO5JnZY6XLzF0crwVNvvqcADizgMP_hw@mail.gmail.com>
Message-ID: <57752CE4.8080202@cermep.fr>

Thank you!

I 'm going to test it right now

Best
Jerome

Le 30/06/2016 16:18, Robert D. Vincent a ?crit :
> Hi Jerome,
>
> I believe I have fixed the issue. After thinking about it, I believe it is
> safe to preserve the information whenever it happens to be present, so that
> is now the behavior of mincreshape.
>
> I pushed the fix to the develop branch.
>
>      -bert
>
> On Mon, Jun 27, 2016 at 8:10 AM, J?r?me Redout? <redoute at cermep.fr> wrote:
>
>> Hi Robert,
>> did you find how to fix the mincreshape bug?
>> thank you
>> Best regards
>>
>> Jerome
>>
>> Le 15/06/2016 19:19, Robert D. Vincent a ?crit :
>>
>>> One thing I'd like to check: is the file you're using a regularly-sampled
>>> file, i.e. is there a constant time duration for each image?
>>>
>>>
>>> On Wed, Jun 15, 2016 at 1:09 PM, Robert D. Vincent <
>>> robert.d.vincent at mcgill.ca> wrote:
>>>
>>> Hi J?r?me,
>>>> Thanks for the report, I've reproduced it here. It seems that mincreshape
>>>> fails to copy the time dimension properly. I will fix it as soon as
>>>> possible.
>>>>
>>>>       -bert
>>>>
>>>> On Wed, Jun 15, 2016 at 9:53 AM, J?r?me Redout? <redoute at cermep.fr>
>>>> wrote:
>>>>
>>>> Dear all,
>>>>> I'm processing dynamic PET data acquired on Siemens Biograph mMR.
>>>>>
>>>>> after conversion from DICOM to MINC using dcm2mnc, I can extract frames
>>>>> timings using:
>>>>>
>>>>> mincinfo -varvalue time xxx.mnc
>>>>>
>>>>> BUT,
>>>>>
>>>>> after mincreshape +xdirection +ydirection +zdirection xxx.mnc
>>>>> xxx_res.mnc
>>>>>
>>>>> mincinfo -varvalue time xxx_res.mnc outputs only "0"
>>>>>
>>>>> any ideas about this bug?
>>>>>
>>>>> Thanks
>>>>> Jerome
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ==================================================================
>>>>> J?r?me Redout?
>>>>> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
>>>>> CERMEP - Imagerie du vivant
>>>>> 59 Bd Pinel. 69677 Bron - FRANCE
>>>>> tel : 33 (0)4 72 68 86 18 (bureau)
>>>>> tel : 33 (0)4 72 68 86 00 (standard)
>>>>> fax : 33 (0)4 72 68 86 10
>>>>> ==================================================================
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>> --
>> ==================================================================
>> J?r?me Redout?
>> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
>> CERMEP - Imagerie du vivant
>> 59 Bd Pinel. 69677 Bron - FRANCE
>> tel : 33 (0)4 72 68 86 18 (bureau)
>> tel : 33 (0)4 72 68 86 00 (standard)
>> fax : 33 (0)4 72 68 86 10
>> ==================================================================
>>
>>
>> _______________________________________________
>> 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
>


-- 
==================================================================
J?r?me Redout?
Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
CERMEP - Imagerie du vivant
59 Bd Pinel. 69677 Bron - FRANCE
tel : 33 (0)4 72 68 86 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================