[MINC-users] Time frame start values

[Alex Zijdenbos]

Hi Bert - thanks much for your help with this! We'll look at it and get
back to you. The PET time dimension is obviously not as clear-cut as I once
thought it was :-}

-- A

On Sun, Mar 31, 2019 at 12:48 PM Robert D. Vincent <bert at phalarope.com>
wrote:

> Hi Alex,
>
> I may have solved some of these issues - I just pushed a few small updates
> to github.
>
> With at least some of the PET data I have, using the Acquisition time field
> is useful for the PET timings, although it produces a non-zero start value
> in most cases.
>
> Also I found and fixed a bug where we incorporated Siemens proprietary
> information into the PET DICOM, but our Siemens-specific code is only
> correct when used with MR data.
>
> Please try these out and let me know if you're still having problems.
>
>     -bert
>
> On Fri, Mar 29, 2019 at 4:39 PM Jean-Philippe Coutu <jp at biospective.com>
> wrote:
>
> > Hi Robert,
> >
> > I like your idea of using the frame widths, and I just wanted to mention
> > one caveat we stumbled upon recently, where this might not work. We have
> > had to convert a dataset where the time frames were not contiguous, and
> > therefore there were effectively missing time frames. I think this is
> > unusual and maybe dcm2mnc should not be expected to be able to convert
> > that, but I just thought I would mention it. I think having this option
> you
> > suggest would definitely be good for this case though.
> >
> > We have been fixing up 4D cases for a while now, which largely seem to
> have
> > issues in get_file_indices(), mostly because of what you stated: unusual
> > worthlessness of certain dicom fields for certain situations/scanners.
> > Basically there is no ideal order of prioritisation for which dicom tags
> > are always more reliable than other when it comes to finding time indices
> > (and also all sorts of range-checking issues). We haven't made pull
> > requests for those changes yet because I think we need to reorganise
> them a
> > bit better.
> >
> > Best,
> > JP
> >
> > On Thu, Mar 28, 2019 at 9:42 AM Robert D. Vincent <bert at phalarope.com>
> > wrote:
> >
> > > Hi Alex,
> > >
> > > I've heard of these issues in a number of instances, I am (slowly, when
> > > time permits) trying to resolve one particular case in dcm2mnc.
> > >
> > > PET files often use the DICOM field 0054:1300, the "Frame Reference
> > Time",
> > > as the main (or only) indication of PET frame start times. However, as
> > you
> > > can see at the link I have provided, the exact meaning of this field is
> > > undefined, so it is unusually worthless even for DICOM. Some PET
> > sequences
> > > use other fields to indicate the frame times, but consistency here is
> > poor.
> > >
> > > https://www.dabsoft.ch/dicom/3/C.8.9.4.1.5/
> > >
> > > My intended solution is to use the frame widths ("Actual Frame
> Duration",
> > > 0018:1242) to reconstruct the MINC dimension by simply setting the
> start
> > > time of each frame to the sum of the preceding frame widths. This
> relies
> > on
> > > the accuracy of these frame widths, but in my experience this may be
> more
> > > reliable than relying on the frame times. However, if the frame times
> are
> > > somehow meaningful, that information will be lost (or at least not
> stored
> > > in a standard place). So my plan is to make this depend on a command
> line
> > > option.
> > >
> > >     -bert
> > >
> > > On Thu, Mar 28, 2019 at 9:15 AM Alex Zijdenbos <zijdenbos at gmail.com>
> > > wrote:
> > >
> > > > Hello all,
> > > >
> > > > I've running into an issue I don't know what to do with (yet). How
> are
> > > (or
> > > > should) start values be interpreted in a MINC time-dimension?
> > > >
> > > > For spatial dimensions, the voxel positions are in the center of the
> > > voxel;
> > > > but in converting dynamic PET data from various scanners, we are
> seeing
> > > > what looks like variations between scanners in terms of whether the
> > start
> > > > is center-frame, or start-of-frame.
> > > >
> > > > We also sometimes end up with negative time steps out of dcm2mnc,
> which
> > > > calls into question whether (a) that should ever happen; and (b) how
> > for
> > > > example mincreshape behaves when re-ordering that dimension. My
> > > assumption
> > > > is that mincreshape will interpret the start to be center-frame, and
> > that
> > > > therefore changing the sign of the time-step might end up with a
> wrong
> > > > start value.
> > > >
> > > > If anybody has thoughts about or experience with these issues, please
> > > share
> > > > :-)
> > > >
> > > > Thanks,
> > > >
> > > > -- A
> > > > _______________________________________________
> > > > MINC-users at bic.mni.mcgill.ca
> > > > https://mailman.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > > >
> > > _______________________________________________
> > > MINC-users at bic.mni.mcgill.ca
> > > https://mailman.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> > >
> > _______________________________________________
> > MINC-users at bic.mni.mcgill.ca
> > https://mailman.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> https://mailman.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>